Saturday, January 24, 2004

Analyst Best Practices #4: Working in Distributed Teams. 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: Analyst Best Practices 1 Analyst Best Practices 2 Project Management Analyst Best Practices 3 Communications 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. [QUOTE OFF] [Ed Taekema - Road Warrior Collaboration] 9:05:27 PM    Trackback []

Analyst Best Practices #5: Requirements. 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. [Ed Taekema - Road Warrior Collaboration] 9:04:09 PM    Trackback []

Agile Knowledge Management. 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? [Ed Taekema - Road Warrior Collaboration] 9:00:56 PM    Trackback []

Analyst Best Practices #6: Doing the Work. 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. [Ed Taekema - Road Warrior Collaboration] 8:58:41 PM    Trackback []