A blog looking at business communication, knowledge management, scripting tools, OS technology news and other things of interest to mobile tech workers. As I find interesting news this will also contain pointers to thoughts related to configuration managment, change management and general software development.
"The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality," however, needed to produce only one pot -albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."
I think this is generally true when we learn anything new. At some point it is necessary to get some early experience and possibily suffer through some painful failures before it all comes together. Seems to especially apply to collaborative tools. It takes too much effort if it is at all possible to design what it should be in advance. Better to get started early with your thought leaders and let the effort develop momentum and smarts.
Here is an excellent addition to any analyst's or consultant's toolbox, again from Jeff Nichols.
First it is all about scope. I wish I had learned this sooner in my career. I now spend far more time managing an engagement's scope both upfront and as it progresses than I have done before and it works.
Become an expert at defining scope. If you can’t say precisely what problem you’re trying to solve, your “solution” will be off the mark.
Second, thinking matters ... Most of us in this role are good at thinking 'on our feet'. But that shouldn't be the normal mode of operation. Setting time aside and prioritizing it high so we can think through an issue is critical to good performance.
Take time to study and think. Find reference books and read them. The heart of analysis is problem solving, and that requires think time.
Create opportunities for brainstorming. Ask for a meeting with subject matter experts, either one-one or one-few. Come prepared, have an agenda (don’t waste their time), lay out the question or issue and talk about it.
Here is good overview of Wiki thinking and has a set of Wiki sites focused on education. My favourite quote:
Q: Are you saying that anyone can come in and change any page?
A: You bet.
Q: Are you insane? That means some villain could change or delete
anything. What's to stop a fiend from coming in and erasing
all my hard work, or playing devilish tricks with my reputation?
A: If you don't calm down, I'll have to take this cattle prod
to your hide.
Denham Gray over at Knowledge-at-work has this interesting post about extreme knowledge and its roots in extreme programming methods. One connection perhaps not mentioned is that XP is part of a general movement in software development away from large, lumbering and inflexible processes to more human focused, light processes. This has coallesced into a statement that values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That was from the Manifesto for Agile Software Development. The theme of people first I think meshes quite well with some of the themes on Mr. Gray's blog. Perhaps we should start talking about Agile Knowledge Management?
Great set of initial answers to key KM questions. I especially like this quote:
What do you believe Knowledge Management (KM) really is?
Support the people, do not make technology the focus, look at ways to help communication, dialog, critique, networking. Perhaps the single most effective step, is putting people in contact with people and enabling facile notification, communication / annotation / feedback / commentary.
I think is is bang on. It is really about getting people to communicate as much and as effectively as possible. Technology can help overcome communication barriers like distance but it still needs to keep this primary goal in mind. KM is about people dialoging with people.
The last six months have been an extended PDA experiment for me. I bought a Palm 515 on eBay and have been using it along with Franklin Planner software on both my laptop and my Palm. The goal was to replace my paper based Franklin Planner system that I have been using for years. The benefit to me if successful was to reduce the bulk I travel with every week, a worthy Road Warrior goal, and also to possibly increase the effectiveness of my planning and information management.
I have watched my clients use PDAs to great effect. They are able to sync their Outlook/Lotus Notes schedules and sometimes even their email. This way they always have their electronic schedule current and available to them. This seems to be the most obvious use pattern out there. This is effective because their planning largely consists of meeting management and schedule recording.
My case as a Road Warrior is a bit different. My schedule is driven by client engagement confirmations that are not communicated via email. I need to plan and manage adhoc information from three main sets of activities: client engagements, inhouse work, and perhaps even more importantly, my at home days since there are so few of those. Its like I have three jobs and a purely electronic solution doesn't seem to work for me.
Part of this is also that when I am not travelling, I really don't want to fireup my laptop to get at the PC version of the Franklin software. Its like I want to avoid that part of my world when time is my own. Trouble is, that is where I can plan ... the larger views of the month and year are easier to see, I can more quickly get a picture of future commitments ... all this is much easier on the PC version than on the Palm version. But I have laptop phobia on the weekends ... and the planning doesn't happen. I also find that the Franklin Palm software runs very slowly even on a Palm 515.
So I find myself wishing to get my paper based planner back. Not having it close has actually been stressful. I feel like I am out of control. Perhaps my Franklin Planner works better for me because I have had a long relationship with paper based planning tools. I find myself looking longingly at the archived Franklin Planner pages for the last years. There is a sense of permanance to the record that I am missing with the purely electronic system. Perhaps had I started using pda like tools sooner it would work better for me. I wonder what other road warriors have done? Anyway, it looks like I am going to the Franklin store tommorrow.
I have found the palm to be very effective at information management using tools like AvantGo, Acrobat for Palm, JPluck, Franklin Planner for Palm and the palm address manager but have found it to be inadequate as a planning and overall life management tool. For now I am going to go back to using my paper based planner and continue to use the palm to store data that I need close at hand. Perhaps that will produce the best synergy of the two tools.
Jeff Nichols continues his series on Analyst Best Practices with this post about gathering requirements. A set of good general guidance about how do project requirements. His last practice, though, I think is dangerous.
Stay objective. Don't inject your opinion into the business and user requirements process. Let users and stakeholders tell you what's needed, organize the information well, but don't become a stakeholder or user.
My problem with is that anyone who is gathering requirements is always going to influence the requirements. Your relationship with the participants, your past experiences, lessons learned (as Jeff mentions in the post), amount of time, the urgency, how much coffee your've had ... all influence the questions you ask and the direction your requirements gathering will take.
My recommendation is a different way to deal with this unavoidable subjectivity. Recognize that you will influence the requirements and allow yourself to become engaged in the process. It will make it more enjoyable for you.
Then, make sure you involve more people, more eyes, more experience, more perspectives... and then it will balance out your perspective and give you better requirements in the end.
Dont' pretend to be objective ... but rather have a strategy for identifying where your subjectivity will lead to weak results and compensate by bringing others in to complement your work.
Jeff Nichols over at Pervasive Computing has been running an excellent series of posts about good practices for analysts / consultants that are great guides. As a Road Warrior Consultant / Analysis I am finding them very helpful. Here are links to the first set in the series:
And now he has some rules for working in distributed teams. Unlike Jeff, in my experience as a consultant, the travel has not decreased since 9-11. These guidelines, however, are still helpful because as a team, all my peers are remote. So here they are, suggestions for how to collaborate effectively as a member of a distributed team:
[QUOTE ON]
Use the time with your client/sponsor wisely. Come to meetings prepared, have an agenda, have a recommendation if possible.
Send your client/sponsor lots of FYI messages as the work progresses. This gives them insight into your thinking, your solution process, and lets them feel comfortable that you're "on the job".
Make sure you get a 2nd or even 3rd set of eyes on any communication to the masses before it's published. Communication sensitivity increases with the square of the audience size.
Take pride in your written communications. Check for spelling and grammar errors, even in email. No one wants a sloppy analyst solving their problem.
Be clear; be precise. The analyst's job is to bring clarity to projects.
Assume all email is read aloud, publicly, by you, in front of everyone you know. There is no such thing as a private email.
Never, ever write an email when irritated or upset. If you're tempted, take a break. Deliver bad news or disagree by voice or in person, preferably one-one.
I just installed the new version of PyDS, 0.70 ... and got my Blogmark working ... I love it! Great job Georg. PyDS just keeps getting better and better.
And I got the search working!! That is so cool! Check out the search tool to the right! Also noticed that the ping settings now stick between invocations of the PyDS server! This is a tremendous release. Thanks again Georg.
My experience in introducing social software tools to my organization is that success is completley tied to solving real problems. You can just add wikis, blogs etc on top of an already overloaded organization. It needs to have an immediate impact on important problems. If life doesn't get better, the tools won't get used. George Seimens has thought about this too and here is his list of important factors in getting social software/ knowledgeware used to potential:
Nature of tool – How complicated is it? How different is it from how work is being done now? Complexity is proportional to adoption and intended task.
People – Is the targeted user willing to adopt and explore new processes? Will it save time? Will it result in increased productivity? Will it help them better do their work? Will it improve their sense of competence (or will it reduce competence due to frustrations)?
Environment of use – Does the tool/initiative solve real problems for the end user? (or only management)? Do people have to alter their work habits to use the tool? Can they do their job without it (if they can, most won’t adopt it)?
I may not catch it but I just heard the 'preview' discussion on NBC's Today show. Seems like it will mainly be a 'what parents need to know' thing because this is 'mostly teenagers' doing online journals ... Oh well. I guess any coverage is good coverage in the mainstream press.
I've recently moved my laptop to XP from Win2K and am having some time to rethink my use of a personal Wiki for my personal information management tool. So far I am exceptionally happy with how the wiki has worked out. One thing that has fallen by the wayside though, are attachments.
I can do attachments in the wiki, but it is timeconsuming and things get stored in multiple locations which is not helpful for information organization.
I am going to try two different ways of solving this problem. First, I am going to look at extending the wiki tool (MoinMoin) so that it can 'autoattach' files from the file system. The idea is bulk attachments are grabbed automatically whenever a topic is edited. This may take the form of a wrapper around the EditMoin tool that lets me use my editor of choice for editing a topic.
The other idea is to refer to the attachments not as actual attachments, but rather to have the filesystem location where I author these things be a local website that I can create links to automatically, or even better, have the directory structure in a format so that a link could be templated into a page to go to the page where the pseudo attachments live.
My basic goal is to have the wiki attachments self organize or self-discover. This will make using it as a PIM / Information Browser tool even better.
Not sure if any of this makes sense. Stay tuned. More information as I try out the options.
This holiday season turned into a protracted battle with various illnesses such as strep, ear infections, bruised bones and sore muscles, spontaneous vomiting, high fevers ... It is taking us all a lot longer to spin up into normal operations. I should be back into posting more normally again in a few days. Holidays are stressful enough as it is, but this was just silly.
Syndication
Contact me