General

Requirements management establishes stakeholders’ wants and needs, and then reviews these to create a set of baseline requirements for use in solutions development and benefits management. Its goals are to:

• ensure that all relevant stakeholders have the opportunity to express their wants and needs;
• reconcile multiple stakeholder requirements to create a single viable set of objectives;
• achieve stakeholder consensus on a baseline set of requirements.

A clear and agreed expression of requirements and their acceptance criteria is essential for the success of any project, programme or portfolio. Requirements may be expressed as physical deliverables, business benefits, aspirations, functions or technical needs.

 

 

The planning step will define the techniques and approaches that will be used to work with stakeholders to capture and agree requirements. The initiation step will ensure the necessary resources are mobilised and requirements management can start.

The planning and initiation steps are usually performed as part of an overarching scope management procedure but may be separated out where requirements are particularly complex or extensive.

The first specific step in the procedure is to capture all types of requirements. Most will be generated by internal and external stakeholders (such as clients and users) but there may also be a background of legal or regulatory requirements that must also be included.

The requirements must be analysed to ensure they are practical, achievable and define ‘what’ is required rather than ‘how’ it will be achieved. A well specified requirement has the following characteristics:

• unique: it addresses only one core requirement;
• current: it is up to date and relevant to the business need;
• consistent: it doesn’t conflict with other requirements;
• understandable: it is clear and unambiguous;
• verifiable: the compliance of products designed to meet the requirement can be verified through inspection, demonstration or testing;
• traceable: the requirement can be traced from the originating need, through the delivery process to the delivered product;
• prioritised: its importance is understood relative to other requirements.

The remaining steps will be undertaken according to the context of the work. For example, the approach for software development using a parallel life cycle and an agile approach would be different from that using a serial life cycle; managing requirements for business transformation will be different from construction.

Capturing requirements can be done in any number of ways ranging from personal interviews, surveys and workshops, to focus groups, modelling and simulation.

Some development methodologies, including agile, are designed to enable the continuous capture and refinement of requirements on the assumption that the stakeholders may not be sure of their needs at the outset.

Analysing requirements involves looking for any gaps, overlaps or conflicts in what different stakeholders have asked for. It will need some initial high level solutions development, planning and benefits management to appreciate the implications of the requirements. The result is a thorough understanding of requirements and the way they contribute to the overall objective.

The consult step is primarily about providing feedback to stakeholders and building consensus. The results of the analysis are communicated through individual consultation or group workshops. This leads to a debate about the functionality and alternative ideas.

Consultation may well result in further requirements being captured and analysed. The eventual result is a baselined set of options for functional requirements. These can then be used to examine alternative solutions during solutions development.

One well established technique that addresses requirements management, solutions development and some aspects of benefits management is called value management. While value is a subjective term and means different things to different people, in the P3 environment it is a means of maximising value for money and is represented by the ratio:

The goal of value management is not to maximise the satisfaction of requirements, nor to minimise the use of resources, but to establish the balance that maximises the ratio of the two.

Projects, programmes and portfolios

Initial project requirements are defined during the identification process and only need to be detailed enough to identify the probable solution and complete the brief. Requirements management is performed in detail during the definition process along with solutions development in order to complete a full investment appraisal and business case.

On small projects with relatively straightforward objectives this may all be done by the project manager. As the requirements become more complex, specialists may need to be involved. Even on small projects “failure to fully understand stakeholder requirements” is one of the most common causes of project failure. This is not an exercise that can be done casually.

For projects that are part of a programme or delivered by a contractor to a client, requirements will be derived from the programme requirements or client’s brief. They will relate to an output and, depending on how well the requirements are described, may result in a reduction in effort needed.

Where it is intended to use agile techniques, the requirements management procedure must be efficient and dynamic. It must use rigorous prioritisation mechanisms, such as MoSCoW, to ensure that only valuable and justifiable requirements are included in each package of work.

An early matter to resolve is whether the requirements are expressed as outputs, outcomes or benefits. This will govern whether the project includes benefits realisation as part of an extended project life cycle. If the requirements include multiple benefits that involve more than one area of business change and multiple outputs, the work is best governed as a programme rather than a project.

Programme requirements will typically be expressed as a combination of outputs and benefits. These may have quite complex relationships that can be described in a benefits map.

The relationship between requirements management and the subsequent functions of solutions development and benefits management is not entirely sequential. Particularly in the identification process and definition process of the life cycle, stakeholder requirements will need some high level quantification of benefits and evaluation of solutions before arriving at a baseline set of requirements. The programme management team are responsible for requirements management as it applies to the programme’s benefits and the team must decide how much responsibility for requirements management of outputs will be delegated to the project teams.

A useful dividing line between the programme and projects is for the programme to express the functional requirements needed from an output. It is then for the project teams to manage the technical requirements that will deliver the required functionality.

 

 

If using value management the programme management team must balance value across the projects. For example, re-prioritising and redistributing resources may result in greater overall value across the programme, even though this appears to reduce the value from one a particular project.

A standard portfolio is made up of projects and programmes with independent requirements. The requirements of the portfolio are concerned with efficient use of resources for the host organisation and improvement in the discipline of P3 management. Once these requirements are set in the portfolio initiation process they will remain fairly constant.

The initial requirements of a structured portfolio will be expressed in terms of the organisation’s strategic objectives. These will be a mixture of stand-alone and interrelated requirements. The requirements management procedure in a structured portfolio assesses the strategic objectives and clarifies them with the executive board.

The assessment of requirements will start during the portfolio initiation process. Interrelated objectives should be identified and may be collected into a programme with independent objectives delivered through projects. This design activity will be constantly reviewed as part of the prioritisation and balancing activities in the portfolio management process.

Most requirements management activity will be delegated to the project and programme management teams, but the portfolio management team must perform two key functions.

Firstly, they must act as the interface between the projects and programmes on the one hand and the executive board who own the strategy on the other. On behalf of the executive board, the portfolio management team must ensure that their requirements are accurately translated into projects and programmes. On behalf of the project and programme management teams, they must ensure that the strategic requirements are adequately defined so that the projects and programmes have sufficient information to deliver the right outputs and benefits.

Secondly, they must coordinate projects and programmes to ensure that the many, localised, requirements management processes work in harmony. This part of the portfolio co-ordination process and may involve taking central responsibility for dealing with key stakeholders. It will definitely involve vetting detailed project and programme requirements to monitor gaps, overlaps and conflicts.