The Requirements Challenge
Failure to capture correct requirements costs around 100 times more to fix when in the build phase of a project. Although this an acknowledged truth, it is usually jettisoned in favour of seeing activity (not necessarily progress). Yet the requirements challenge goes right to the heart of every project and it does so on two distinct levels.

The battle that sometimes ensues usually results in an IT solution desperately searching for the problem it was supposed to fix.
The nature and timing of requirements
Project schedules and budgets are determined by the quality and scope of the solution that is to be delivered. Yet schedules and budgets are often fixed long before requirements are complete, let alone the solution or the plan to deliver…so how should it be done? There are broadly two options at either end of the spectrum:
  • In the project initiation/definition phase (i.e. before commencing project delivery) ensure the detailed requirements are signed-off and the solution has been validated, planned and budgeted. In such a controlled environment, risks are constrained and minimised but scope is pre-determined. Typically, this is done in project rescues and damage limitation exercises (as it tends towards a deterministic outcome) resulting in a clear trend towards meeting schedule and budget targets.
Stacks Image 61
  • More commonly, when project delivery begins only high-level requirements are available. Without factoring an (often unacceptably large level of contingency to cover both the production of the lower-level requirements, the solution selection and implementation) element of risk a schedule and budget cannot be defined: yet more often than not, this happens. In reality this approach provides a probabilistic outcome due to the level of risk incurred by starting work without having a full understanding of the problem, let alone the solution…and yet appealing for a definitive, precise schedule and budget.
The decision as to whether to start work with high-level or detailed requirements is as much about the appetite for risk as it is for wanting to have a well-defined schedule and budget.
What good requirements look like
Although there is much written about requirements, it usually presupposes them to be complete and correct (and that's never possible). Existing literature on good requirements analysis is invariably generic and states 'what' they should be but not how to create them. How many times, for instance, have you seen £ hundred-million "major business transformation programmes" with 10,000+ requirements get totally stuck?! I can name a few…and I daresay you can too.
Stacks Image 72
Requirements are not a statement of the how or what the solution should look like. They are an elemental decomposition/series of statements that, collectively scope the problem we are trying to solve (and should be verified by the WBS). When requirements read as "the system will perform this or that functionality" they cease to be requirements and become part of the solution design.

Even when requirements are correctly understood, they can never be complete - so there has to be a time-box. And the shorter the better. No matter what time is allocated for requirements capture, a new requirement will appear one day later: it will always be so. Allow for multiple requirements time-boxes and, assuming there is a business case for each time-box , deliver the project in phases.
Stacks Image 69
Techniques that good business analysts employ include the approaches (above) and concern themselves with detailed word-smithing to describe a problem that needs overcoming. (And don't believe those who hide poor requirements under the guise of some fast-track, new-wave development methodology: I don't buy that excuse. A good requirement is a good requirement. How it is satisfied is the the domain of the development method). Good tools and techniques such as Method 1; Jackson Structured Development; requirements hierarchies with the MECE test applied; simple CUT statements (often described as SMART); prioritisation by MoSCoW, and genuine ownership of requirements from the business don't go out of fashion. Good practice is good practice!

Thereafter the analyst has to consider the practicalities of satisfying the requirements, whereupon the business case, the solution options, the quality and the scope (n.b. these are different) are all discussed iteratively to find a satisfactory way forward. But this section of work is always done in the world of the problem: the one causing the users such tangible pain. Once the solutions are considered, we are in a different world: one whose success is measured by its ability to satisfy the requirements and remove the pain.
Some characteristics of bad requirements exercises...
If you are experiencing any of these (and this is by no means an exhaustive list), the chances are that you're heading towards project failure...
  • An unclear scope statement or none at all
  • A scope definition that hasn't been written down…yet...
  • Scope of work that is too large/ambitious/innovative
  • An incomplete list of stakeholders and/or no stakeholder map
  • Analyst receives nor seeks "pushback" to raw requirements
  • Too many requirements
  • Too long a period of time to capture requirements (more than 8 weeks and you could be in danger)
  • Requirements that specify what the solution will be like
  • Non-functional requirements (e.g. performance, maintenance, recovery) not captured or understood
  • Change in requirements but no change in total budget or end-date
  • Project starts with no or unclear requirements and no plan to address that
  • Evaluation of potential solutions before requirements are complete
  • Scope creep with no or ambivalent change control

Return to top