Skip to content

Requirements and your Business Case

October 15, 2010

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.

An approach I have used in the past splits the project into two parts. Part one is the System Definition Phase where we gather the requirements. This phase is sold on a time boxed/effort capped basis. Once the requirements have been produced the customer then can then estimate the development part quite reliably.  This first phase not only produces requirements but also a high level architecture. As a bonus you end up knowing your assumptions and risks very well.

This is all good but how can you know what effort is required to define all the requirements you may ask. The short answer is I don’t.  I won’t know how long it will take to do all of the requirements. I do know however to a quite reasonable reliability how long it takes to get enough requirements that allows 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 a key question and part of the guidance I give to business analysts. I give the business analyst guidance when to stop refining use cases and to move on to the next one. This also allows the BA 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 you to quote a reliable time box to create ‘just enough’ requirements. How big the time box 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.

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: