Hi all,
I want to know that what difference is between Need, Want and Expectation when we want to collect business requrements. I will be thankful to answer with examples.
Hello Snikookar,
In specifying requirements you will encounter a number of categories by which requirements can be priortised to ensure that the most valuable / significant / mandatory items are focused on before the lesser wants and that expectations are only delivered if project time and budget allow.
In it's simplest form priority is typically: MUST have, SHOULD have and COULD have (which equate to your need, want and expect).
Take a look at MOsCoW.
Hope this helps,
Joe
Hi Snikookar,
I think MOSCOW categorisation can help you here. MoSCoW Rules is a technique used to prioritise a list of requirements based on the relative merits of each or their value to the business.Time and cost play a significant role in project delivery, so it is important to understand at the outset which features are essential to the delivery of benefits and the business needs most. "MoSCoW Rules" is a well established technique which is used to assign priority to requirements:
It is complementary to Pareto's Law, often referred to in IT development as the "80/20 rule", which states that 80% of the objectives should be achievable with 20% of the resources
These are requirements that are fundamental to the successful delivery of the project's objectives, i.e. the minimum usable subset. Without them the system or service is unusable. It is essential to be critical of all "Must Have" requirements and when assigning this priority the business should be told that the significance lies in the statement "Without them the system or service is unusable."
Regards,
K
Kieranc,
Agree with everything you said and wanted to get your views on the following...
Projects often die the death of a thousand cuts - we're running short of time and money so we'll just cut the scope a little bit here and rule that requirement out of scope and so on until the solution the project would deliver if allowed would be all but useless.
Does this mean then that once a requirement/scope statement is cut that the remaining should be reprioritised? The idea is that a requirement previously classified as Should Have may have become Must Have on the grounds that without it so much "significant value to the business" is lost that the solution is not worth the candle.
This reprioritiation is the only reprioritisation that could happen (no 'wants' can become 'coulds' , no 'coulds' can become 'shoulds' and no way for requirements to lose priority).
This raises the question of should the 'should have' been categorised as 'must have' to begin with or can it change priority?
It would be good to know your thoughts - and the thoughts of anyone else interested in this.
Guy
what are you trying to get at? A need is something that can link back to the concrete business objectives, the reason the project was chartered in the first place. A want is something the users say they want, regardless of if it maps back to the business objectives. An expectation is what the users think they are going to get. Here are some interesting examples from a couple of recent projects.
1) The ROI was determined to be $20 million a year recurring by closing a revenue leakage hole in a client system. The client was basically handing out at least $20 million a year to their customers. Needs were any features that were directly required to close the revenue leak.
2) The finance team was based in malaysia. They were paid about $5/hour. They and their US managers wanted to add a significant number of usability features to improve the productivity of those resources. This was a want because it did not tie back to the core business objective. To save $50K/year they were willing to put at risk $20 million/year. These wants are not directly tied to the core business objectives. These wants are they key scope items that kill most projects
3) Expectations - on another project the business stakeholders left the company and new business stakeholders came on board in the last month of the project. When they started to do user acceptance testing they were very upset because the system was not what they expected. The system had a clear business case and every feature could be tied back to the business case. We are currently working with them to understand the value of the features that they would like instead and then walk them through the process of understanding the original business case. The original business stakeholders had discarded the features because the actual business value was miniscule - but the features do sound cool.
brought to you by enabling practitioners & organizations to achieve their goals using: