Requirements Management

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.