Often there is much hustle about projects running into “fire” and delays in delivery unlike the ones where the scope is chiseled out very hard.

Over the past several years I have been a part of many such projects. To share a rough figure over 30 % of the projects have been in this so called “fire” because off other significant reasons but 70% (the biggest chunk) because of mismanaged “Requirements Phase” and the common excuse being “Client is not sure of what he wants”.

Often during the Business and Technology tussle we miss out the actual objective of the requirements exercise and end up catering to most of the unexpected and impromptu needs.

To begin with lets take a look at the simplified version of a typical project cycle as can be illustrated as :

Simple View of a Development Cycle
(Click on the image to see a full view)

For any project the critical phase is Requirements as it forms the basis of the entire activity for the remaining cycle. In most of the engagements when I analyzed I came across that most of the user requirement turned to be something not in scope (specific to the case where “Client is not sure what he wants”).

To find a cure for this recurring issue I tried a more objective approach for the requirements. To put it visually here it is

Requirements Phase - The New Approach

In the above illustration

1. Are the User Expectations (a.k.a. the wishlist)

(As a matter of fact whenever a business decides to design or redesign an Application they would like it to be more scalable in context to be able to make use of the same for a longer period of time before it calls for a re-engineering once again so they often try to visualize things in a time scale and come up with requirements which happen to be expectations a.k.a the wish list which is beyond the necessities )

2. The common area where some of the expectations are more or less treated as necessities to be able to give the scalability

(These are typical requirements which are covered under any project as a result of effective planning by Project Managers – the common term they use is “buffers”)

3. Necessities is a must have or the core basis of the project.

Trying this approach helped improve a lot of the time line and “out of scope” issues. Keeping a realistic view of requirements (2+3) helped plan the development activity accurately unlike “Guesstimates”