REQUIREMENTS CAPTURE, THE FOUNDATION STONE OF THE PROJECT PYRAMID

Why is it that clients are resistant to the suggestion that requirement definition is the most important, and time and resource intensive, phase of any project?  Why do they think that diving right in with the development is a good idea?  And why do they think that change control is an optional extra, or unnecessary or even an obstacle to project success?  Well, maybe not ALL clients because realisation has slowly been dawning that the requirement is king.

The tools and techniques have been around for years, promoted by, among others, the International Institute of Business Analysis (IIBA); however, I still find myself discussing projects with new clients who think that the 50 page booklet they have produced will guarantee the delivery of the benefits required from a ￡3 million system implementation!  To counter this, while engaged in 2000 by Bovis Lend Lease EMEA to set up a business analysis department, I produced an in-house guide (based on my experience in various organisations) to gathering requirements, to be used in training and mentoring business analysts and those in the business who worked with them.  I called it ‘SRS 2000′ and the next 15 years I have found more and more use for it, updating it every year until I arrived at the current version, ‘SRS 2015′.

I recently accepted an invitation to publish my notes as a slim volume on requirement-gathering and this will shortly be available as a pdf file to download from this website in the belief that having had a good look at it you will be in touch to ask us to apply it to your requirements!

Change control is another undervalued area.  While talking to the IT manager of an SME recently I was not surprised to hear that “we freeze the specification on day one and that is what we deliver”!  Hmm … I came across this a lot 20 years ago and it is less prevalent these days but too many managers still think that the requirements  signed off at the start of the project are identical with the system that will finally be delivered.  Some of my projects have taken two to three years to complete.  Hands up all those who think that, given changing legislation, new technologies, updated business practices and a thousand other factors, the requirements at the end of the project match those at the start … Freeze your spec and you practically guarantee delivery of an obsolescent system that may match the requirements at the start but will not deliver the goods at rollout time.

Change control requires an analyst to capture the change and define it in relation to its impact on the overall requirement in terms of time, money, resources, quality, interfaces to other systems (among other factors) someone with the authority to say whether the change should go ahead, be ignored, modifed or added to a wish list for the next iteration of the system, a budget to pay for the changes and a senior manager to sign off the funds.  Sign it off then revamp the project plan which should be regarded as a work in progress.  Not easy, but we are here to give you a hand.