Requirements and your business case
Dealing with clients I see a particular pattern in the early stages of a project. Having been stung in the past by cost blow-outs many organizations now demand a business case to justify the funding of a project. Key part of that business case is a reliable cost estimate. To provide a reliable cost estimate is dependent upon the quality of the requirements model - the more detailed the better the estimate. Or vice versa - the less detailed the requirements the less reliable the cost estimate becomes.
The project sponsors who want to start their projects find themselves in a quandary: they know that to achieve a reliable cost estimate they need the requirements - but that would cost a significant part of the project budget which they want to get approved.
This situation leads to a practice of putting up a strawman budget. Because everybody knows the estimated budget is quite arbitrary, the steering committee that approves funding for the project is often led to make equally arbitrary budget cuts to it. In the end the project goes ahead and the project manager is faced with the need of making ends actually meet, quite often by negotiating feature reductions with the users.
At Object Consulting, where we use Process MeNtOR as our process to deliver fix-price software projects, we sell projects in two parts. Part one is the System Definition Phase where we gather the requirements. This phase is sold to our client on a time boxed/effort capped basis. Once the requirements have been produced we then quote the development part as a fix price project. The process allows us to be quite precise what activities go into this first phase. Having tuned it over the years we produce in this phase not only requirements but also a high level architecture and determine the approach that is required to identify not only effort but also be able to quantify the risks to an acceptable level.
This is all good but how can we know what it takes to define all the requirements you may ask. The short answer is we don't. We don't know how long it will take to do all of the requirements. We do know however to a quite reasonable reliability how long it takes to get enough requirements that allow us to do a reliable estimate. There is a big difference between the two.
The former (all requirements) is basically an open ended affair. The more detail you create the more questions appear. The more questions appear the longer it takes. If you were to chart productivity in business analysis over time you get a sharp bulge at the start and then a steady decline over time. Take that and add to it the fact that requirements have a natural tendency to change over time; after a sufficient amount of time your speed of requirements definition has become less than the rate of change of requirements - you have entered the domain of Analysis Paralysis.
What we do instead is to focus on producing 'just enough requirements'. In this context 'Just enough' means the amount of requirements that we need to have to determine a build approach and to be able to size it for costs. To do 'Just enough' requirements means that we need to make sure we cover the whole scope of the problem domain but dive in only so deep. The 'How deep' is part of the tuning we have applied to Process MeNtOR over time. It gives the business analyst guidance when to stop refining use cases and to move on to the next one. It also allows us to work iteratively: Identify several use cases, then refine them later. Repeat for the next set of use cases and so on.
On top of this sits a maturity matrix. It tracks how far individual use cases have matured. So even with larger numbers of use cases in a project ( hundreds) we do not loose track of the big picture. A team of business analysts can on a regular basis review its efforts and focus it so that the overall target of 'just enough requirements' is being met.
This approach allows us to quote a reliable time box to create 'just enough' requirements. How big the time box will be is driven by a scope description and the targeted reliability of the estimate.
For a fix cost project this phase can still be a major chunk of the overall project budget. So what happens business is not willing to fund this without a definitive business case?
Find out in my next blog.