Ed Taekema - Road Warrior Collaboration 16.1.2004

January 2004
    1 2 3 4
5 6 7 8 91011

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.

XML-Image Syndication

XML-Image Comment Feed

Letterimage Contact me


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.

posted at 22:58:56    #
Creative Commons License
This work is licensed under a Creative Commons License.