Unclear and incomplete requirements remain the most often cited reason for not only project risk and unpredictable schedules, but for outright project failure. Yet one of the most common faults I see in projects is the belief that it is OK to defer writing down and sharing early versions of requirements. This is usually supported by all sorts of rationalizations that attempt to justify that position, but it’s just plain wrong.

Often I hear that someone doesn't want to write requirements down so they don't have to 'correct' them later. My experience is that not sharing requirements at the earliest possible time makes it more likely that the corrections that are required later in the project will have a much higher cost and schedule impact than catching them early. There is also the risk that the required changes will be so impactive that they can't be corrected and still make project commitments.

Why people defer documenting requirements is founded in many behaviors. Sometimes it’s as simple as a belief that there is not time… the urgency of the immediate outweighing the importance of the long term. Sometimes it’s about personal or team power since the part of the team that holds the requirements has power over the part of the team that is in the dark.

Contracting your implementation to a local contractor or another group inside your company easily doubles this risk, and sourcing your project offshore easily quadruples the risk.

So my view remains a steady, ‘share early and share often’. I firmly recommend that requirements start with a one page description, progress through use scenarios and workflows, and then precede to the details with disclosure to all project stakeholders every step along the way.

For more ideas about requirements, click on the ‘search’ at the top of this page and and search for ‘requirements’.

Home | Privacy