Engineering requirements for project success

How well a project meets stakeholders' expectations is an accurate way to measure its success. The typical parameters being measured are the components of the so-called project management triangle - cost, time, and scope. In other words, the measurement reveals whether the project met expectations in terms of being delivered within budget, on time and according to an agreed specification... or not.

There are a number of factors that consistently contribute to the unfortunate fact that so many projects fail to meet all three expectations. These include an insufficient understanding of the business requirements, ineffective communication between stakeholders, lack of consensus regarding the project's vision, and inadequate levels of executive sponsorship and commitment.

From conception to completion, IT-based projects must be managed so they fulfil the business requirements. All the activity within a project must be governed so it produces results that demonstrably contribute to meeting the requirements. While that may sound pretty obvious, all too often the requirements are incorrect, incomplete or vague, and are therefore interpreted differently by different people. Without strong requirements-oriented direction right from the start, projects are immediately destined for failure. If the team doesn't know where it is supposed to be going, how can it possibly hope to get there?

Requirements are the starting point for everything within a project. They should also be the criteria that guide every aspect of a project. From setting the vision, scope, budgets and schedules, through to functional implementation, functional verification and final release, requirements must bind them all. It's hardly surprising then that so much attention must be paid to ensuring high performance within the twinned disciplines of requirements engineering and requirements assurance, or REA.

The REA disciplines are twinned because engineering an accurate and highly detailed set of requirements is not enough in isolation. Once the requirements have been produced, business analysts and project managers need to ensure they are adhered to - and that people don't just wander off and do their own thing without proper justification, negotiations and controls. Requirements assurance is therefore concerned with protecting the integrity of the requirements as the project runs its course.

One key aspect of assuring this adherence to the requirements is the process of traceability. It's a process that demonstrates the link between every requirement and its solution. Overall, traceability enables business analysts and project managers to track a requirement's life cycle through the project. More specifically, the process regulates how high-level, generalised requirements are broken down into the component parts that comprise a requirement's solution. In the language of REA, this breakdown is known as decomposition and it features in the twin functions of engineering and assurance.

Decomposition is an essential function within REA. For the assurance aspect, it allows BAs and PMs to trace and monitor all the links in the delivery chain that connect a high-level requirement with its operational solution. It ensures all the work within a project directly serves a requirement's fulfilment and is therefore justifiable because it is necessary.

From conception to completion, IT-based projects must be managed so they fulfil the business requirements.

For BAs in particular, decomposition is a critical initial step in the structured process of engineering requirements. A skilled BA will be able to decompose a high-level requirement into its component parts and identify what is needed to produce those parts. The first BA skill that must be applied in decomposition is known as elicitation. Once again, this is a structured process that - in broad terms - is designed to extract and detail the reasons that motivate or produce a business requirement and to then assist in detailing the system requirements that will best fulfil it.

A rigorous elicitation process forms the basis for producing, documenting and communicating a set of requirements that are elaborated in a way that is universally clear, commercially justifiable, technically or functionally feasible and traceable to their outcome. Requirements that are correctly elicited and adequately decomposed will contain sufficient detail to facilitate producing every link in its delivery chain. They will help ensure a consistent interpretation of the requirements as they relate to everyone involved in the project - from the most senior executives to the most junior programmers.

At the same time, they will demonstrate the purpose of producing the links and clarify why everyone is doing what they are doing. And that is important because it produces a unity of purpose within the project and forges cohesive delivery teams that are - from the very start - consistently empowered to contribute on time, on budget and on spec.

It should be clear that, far from being some sort of new-fangled business school speak, requirements engineering and assurance are powerful, structured mechanisms that are designed to proactively mitigate the risks of budget overruns, time overruns and functional under-delivery. The right approach from the start prevents disaster at the end.

Overruns and under-delivery are so commonplace in IT-based projects they have come to be widely regarded as inevitable, occupational hazards. And that's understandable based on the realities of past experience across so many companies' compromised and cancelled projects.

Everyone knows that once a project goes south, there's no point in crying over spilt milk. But, by initiating a professional approach to tried-and-tested best practices in REA, companies can prevent it from being spilt in the first place.