We can now approach the final transgression, which constitutes the deadly sin of project lust, in confident spirits...

Unclear baseline requirements / Too many changes late in the project – Before I launch into the penitence for this transgression I’d like to paint a slightly richer picture as less specific requirements documents (or project specifications) are often treated through the use of different contract types rather than being viewed as a negative. Let me give you a generalist’s view of the types of contracts used for varying levels of scope clarity:

• Fixed Price Contract / Explicitly defined requirements: The more time you spend defining exactly what has to be done the more accurately a vendor, or your internal project team, can estimate the schedule and cost. Therefore a fixed price contract becomes a reality as the risk of scope misinterpretation is greatly reduced and hence the vendor can be confident that any scope changes can be processed through the change request process.
   
• Incentive Share Contract / Key functional areas explicit but associated detail implicit: On the sliding scale of clear scope definition this is somewhere in the middle. The client  has spent some time considering what is to be achieved, in terms of scope, but hasn’t executed a detailed plan and analyse phase to flesh out all of the lower level details.  Whilst the risk is shared between the client and the vendor a reasonable estimate can still be made and the vendor is incentivised to deliver early/below budget.
   
• Time & Materials Contract / Implicitly defined requirements: With a scope document that sets out the framework of what is to be achieved but leaves room for interpretation the vendor will not usually want to commit to any type of contract apart from time and materials. The simple reason is that anything but a T&M contract would mean the risk profile for the vendor is significantly greater than the client. 

So now you have the background and the theory I want to make some general recommendations regarding base-lining requirements. I understand the emotions and excitement involved at the beginning of a project and the near-desperation to get into the nuts and bolts of delivery from both a project team and sponsor’s perspective. However it is precisely for this reason that we should stop and take a breath. Remember the sin we’re talking about here? Lust… ‘unrestrained desire without consideration of the consequences’. Launching into a project driven by the errant desire to ‘get going’ without thinking about the adverse impact this could have further down the track is a project sin. So my recommendation is to put that emotion and energy into getting the scope as clearly defined as is practical before moving past the plan/analyse phase. The model for requirements changes throughout the project lifecycle has been widely promulgated and, in the interests of brevity, I won’t go through the whole model again but will give the main points. A change made at the analyse stage will cost about $1 US. If you only discover that change at the design stage it will cost approx $10 US, build stage will cost in the region of $100 US, testing is about $1000 US and finally if your project has gone into ‘production’ it can cost any where up to and above $10,000 US for the same requirement change. I won’t dwell any further on this point as I think the numbers speak for themselves. Try to spend as much time as possible on the planning and analysis phases.

The key technique to help you along this path is the trusty Work Breakdown Structure (WBS). This will help you structure your requirements so gaps become much clearer. There are so many good descriptions of the WBS out there on the web I’d recommend just popping the search word ‘WBS’ into Google and you’ll be buried in detail on how to use them and how you can make them work for your project.

Now to the conclusion...