Sunday, February 25, 2007

Detail, Shmetail....

What's wrong with fully detailed and comprehensive requirements? Plenty.
Well for starters requirements change. Stakeholders will change their minds throughout the project, because their needs have changed or because once they've seen what you've built, they realize that it is nothing like they thought it should be.

Stakeholders will ask for everything and anything. They are highly motivated to tell you everything that they might possibly want, because they may not get another chance. Therefore, the requirements include the kitchen sink within the features, resulting in higher development and maintenance time and costs.

It takes longer to develop, deploy and gain from your investment. By taking the time to define all of the requirements up front, you forgo the opportunity to focus on implementing the highest-priority requirements right now and hit the streets with something that could be used tomorrow. Therefore, your customer misses out on the benefits that would have gained earlier.

As anti project as many may think change is, it really is only change prevention and probably your number one cause of project dissatisfaction. Once you baseline your requirements, you need to assure even changing the font of a document flows through a highly complex CM model that only you and a handful of process geeks understand to ensure that your project doesn't suffer from scope creep.

Traditional change management processes usually involve a group of people—a change control board (CCB)—mysteriously lead in most cases by the Manager of the project. This group will spend considerable time (and money) to decide whether your change will pass through the saintly process of an allowed change. These processes typically take days and in many companies weeks to process a potential change.

So before you enter into requirements management, or change management give consideration on what you are writing and why, also what you are trying to prevent and why. Do you really care as a PM if your stakeholders ask for change, do you really need to enforce your judgement on the situation?

2 comments:

-TBD- said...

"To prevent large, unmanageable meetings, the RFCs are distributed to all members for comments, and attendance at the meetings is optional. Support tools or e-mails should handle most changes, and only more complex, high-risk or high-impact changes will require a physical meeting."
- ITIL

Terry Schamberger said...

ITIL certainly has its value but if ot will become a challenge to walk through its steps and hack and slash. Then say the word.