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”
#1 by Gaurav Gautama at November 26th, 2007
If I understand ‘Expectations’ as what customer ‘expects’ and this has been made explicit by the customer - then, it should be treated like any other ‘Necessary’ requirements.
And the real challenge of requirements phase is to ensure that requirements are siphoned through discussion and consensus into either ‘We-are-doing-this’ and ‘We-are-not-doing’ this. The end result of which is clarity of expectation - leaving this ambiguous is typically at the root of this situation of ‘are-we?’ or ‘are-we-not?’
Expectation, in summary, is what the customer knows and has agreed to receive.
So what happened to the good old ‘Customer Delight’? Delight happens when ‘expectations’ are exceeded - how do we exceed (or even barely meet) expectations if we do not know the expectations are (not what we think they are - but what customer really has)? I think, the secret is on setting unambiguous mutually acceptable expectations, and with our awareness of what the customer really wanted to start with, try and offer the same and more (no obligations - whatsoever). Therefore, I believe in a singular ‘expectation’/'desire’/'necessary’. And a sincere effort to deliver over and above this.