Understanding requirements, the basis of delivering quality

The APM Body of Knowledge 7^th edition defines quality as “the fitness for purpose or the degree of conformance of the outputs of a process or the process itself to requirements” so to deliver quality one must meet the requirements. This places requirements at the very foundations of quality management. A project that delivers a result that doesn’t meet the requirements, even if it is on time and budget, has failed.

First, I must address specifications; the terms ‘specifications’ and ‘requirements’ are often used interchangeably, but requirements drive the design process, the specifications result from it. Specifications define the solution and its components. If a customer specifies a solution that is not fit for purpose, the liability lies with them, not the supplier. For example, when a major aerospace manufacturer specified a crane that proved unsuitable to save time, they bore the entire costs of sorting out the mess.

Requirements come in a wide range of types, so we should be clear about their differences and significance:

1. True requirements define what the business/customer really needs. True requirements extend beyond the technological focus of the project and include human factors, as well as the whole of the solution or project’s life to decommissioning and disposal.
   
   Understanding the true requirements starts with the project’s critical success criteria – what will make the project a success or failure? This system level thinking causes customers to take a step back from ‘specifying’ mode into a holistic, reflective mode. High-level critical success criteria give a good insight to what is really important. It is supported by how success will be measured i.e. how the project will be accepted.
   
   Planning for project acceptance is often left until late in the project and draws in many stakeholders who often haven’t been consulted earlier. This results in a flurry of last-minute changes as their insights and consequent changes are taken on-board, with consequent delay and cost escalation. Planning for acceptance from the start stimulates thinking holistically in terms of benefits, capabilities and outcomes, encouraging the stakeholders to consider scenarios that may well have been overlooked earlier.

Systems thinking is immensely helpful in exploring and documenting the true requirements by probing the complete scope of the problem and ensuring the (potentially complex) interactions between the solution and its context are understood. It also helps in flushing out incorrect requirements, eliminating internal inconsistencies and avoiding inappropriate solution specification.

2. Documented requirements are what the business/customer asks for, often known simply as ‘the requirements’. The documented requirements may differ from the true requirements in:

• • Being incomplete.
  • Being incorrect.
  • Being incoherent (internal contradictions).
  • Specifying a solution (quite possibly inappropriate), rather than the true requirements

Since documented requirements are normally the basis for contracts, any of the above problems are likely to lead to contractual issues and project variations/change notes causing redesigns, rework, delays and cost escalation. Moreover, rarely are all documented requirements essential. The design process needs to trade off meeting requirements against cost and time – this requires confidence by the design team in being able to drop low-importance requirements to achieve project success. A clear understanding of the complete system and its interactions and what constitutes ‘fit for purpose’ aids this.

Another way to differentiate requirements relates to functionality:

1. Functional requirements are about what the solution does and are the natural focus of customer attention.
   
   
2. Non-functional requirements are about everything else; they are prone to being under-defined or even overlooked yet are still vital for success. Key non-functional requirements to be considered include:

• • Initial solution performance, capacity for growth, adaptability to changing circumstances and durability.
  • Usability and users’ training.
  • Availability, reliability and maintainability.
  • Security (both physical and cyber).

The users’ requirements must also be understood early – an unusable solution is worthless. It's easy for designers and engineers to create an unusable solution that meets the functional requirements and is nevertheless not fit for purpose. I encountered one such example, a web-based form for a contact centre that lengthened call duration by 200 per cent. Naturally it was never used. Likewise the Millennium Bridge in London: an apparently perfect engineering and aesthetic solution showed a serious design defect when faced by its users. When first opened, it swayed slightly and users found themselves unconsciously walking in step with the sway, driving the sway to resonate harder and making it uncomfortable. Though this sway phenomenon has been well-known for centuries, the dynamic interaction of users with the product hadn’t been thought through.

Requirements validation and project life cycle choice

It’s clear that documented requirements must be validated as early as possible to avoid wasted effort/costs and deliver a quality solution. Pure linear or waterfall life cycles can’t do this; the principal weakness of pure waterfall methodologies is that the documented requirements are only validated fully at the end of the project, when the completed solution undergoes acceptance testing. This almost guarantees they will be late and over budget as flaws in the documented requirements are revealed.

Soft system tools and techniques involve users in the capture and validation of requirements, as well in the acceptance testing of the solution, and help to minimise late changes from their insights, but few people can really imagine a complicated solution with any degree of accuracy and detail. Agile and iterative methods address this issue through the close-knit integration of the customers into a team in which requirements are explored incrementally and validated continuously.

Hybridising iterative and linear approaches avoids the primary risks of either, and is consistent with the core principle of most project life cycles i.e. multiple phases or stages with gates separating them. Agile use of digital tools (modelling, simulation, digital twins, BIM, alternative solutions etc) in the concept and definition phases allows clear understanding and validation of the requirements, also, confirming the solution will deliver the benefits expected. The tight control and efficiency of waterfall for execution and commissioning will deliver that quality solution as quickly and cheaply as possible.

In conclusion, a clear understanding of the true requirements is the foundation of delivering a quality solution and project success. Agile approaches offer concurrent exploration of requirements and their validation, but in their pure form are unsuitable for many major projects. Validating the requirements early in the project, before committing to major development/construction costs is possible in a classic waterfall approach, but only if there is no ‘rush to concrete’ and all preparatory work is done before delivery starts. Hybrid approaches are a better option for most big projects, using agile approaches to validate requirements and solution before using a waterfall approach to deliver quickly and efficiently.

You may also be interested in:

• Priorities must be rebalanced to strengthen focus on quality for project success
• When does quality need to be managed?
• Successful quality management requires expert risk management

_{Image: Anthony Sullivan/Shutterstock.com}