GPM First
Chapter 29 of Benefit Realisation Management (978-1-4094-0094-3) by Gerald Bradley

Requirements for Software to Support the Process


‘Build a system that even a fool can use, and only a fool will want to use it.’

(George Bernard Shaw, 1856-1950)

‘The least flexible component in any system is the user.’

(Lowell Jay Arthur)


29.1 General Requirements

Software to support the process is never more than an enabler, nevertheless a comprehensive integrated software system can provide a high degree of support to the concepts, processes, techniques and mind-set changes which are central to BRM.

In fact, it is difficult to imagine how large programmes or portfolios of projects and programmes can be effectively managed without sophisticated software. This chapter gives a brief description of the fundamental requirements for such software.

Over the years sigma has used standard Microsoft products and other systems to support different parts of the overall change management process. But lack of a single integrated product has given rise to frustration, inefficiencies, inconsistencies and loss of quality. So the software should fully support, in a cohesive and integrated manner, all the BRM processes and techniques described in this book, with the ability to integrate activities at different levels – organisation, portfolio, programme and project. Since BRM should form the core of any change process, the software should also support, at least at a basic level, the related management disciplines, as shown in Figure 29.1.

As well as covering the basic elements of these disciplines (as discussed in earlier chapters), the software should also provide a simple interface with any existing systems, particularly in the following areas:

  • performance management;

  • personnel systems for stakeholders;


Figure 29.1 The relationship between BRM and other management disciplines


  • project management;

  • benefit tracking.

A schematic of the software structure from a user’s perspective is illustrated in Figure 29.2 opposite.

The software should also be easy to use, intuitive and include options for hiding features based on user role (for example, a Programme or Project Manager might not see all the portfolio options). Navigation might also be role dependent.

The software should be able to support several hundred users, and up to a thousand change initiatives, with a security system that will allow varied access rights. This level of activity should be possible without significant degradation in response times. The system should maintain audit trails and include facilities to restore data that has been erroneously deleted.

It should also be capable of effective use in workshops, to support and even to drive the facilitation process, and to streamline data capture.


29.2 Scope and Architecture

The software operates at a variety of levels in terms of:

  • goals – vision, objectives and benefits; and

  • delivery structures – portfolios, programmes, projects and work packages.


It should be possible to enter it at any of these levels. The underlying system architecture is likely to look similar to the structure in Figure 29.2 below:

Figure 29.2 Possible architecture for the BRM software




29.3 Compatibility with the BRM Process Including Reviews

Navigation options in the software should be compatible with the six-phased cyclical process used by sigma and which is amplified with flowcharts in Chapter 23. It should be able to generate automatically the documents required for reviews, as described in Chapter 18 to 22. To accommodate this a report generation and/or customisation facility will be required.


29.4 Mapping Requirements

The software must include sophisticated, flexible, easy-to-use mapping facilities which can handle several hundred entities in each map and which is fully integrated with its central database where more detailed information can be held, including owners, scores, measures, targets, timescales, costs, resource requirements and responsibilities.

The mapping facilities should:

  • utilise shape and/or colour to distinguish between different entity types;

  • include flexible and easy-to-use linking options;

  • contain an ability to weight paths and calculate scores for the complete range of map entities – objectives, benefits, enablers and changes;

  • provide for different views of a map including version control;

  • include an ability to ‘drill down’ on any entity to view or amend related details. All the maps in this book have been generated with software meeting these requirements.



29.5 Change Delivery Mechanisms

The software must be able to hold a detailed picture of each change identified, whether via the BDM or some other process, including resource requirements, planned delivery timescales and costs.

The ability to group changes into change delivery mechanisms, such as programmes projects, using a ‘drag and drop’ facility on a delivery breakdown structure, is very useful and facilitates ‘what if’ analyses on solution options.


29.6 Analysis and Consolidation

The software should include analytical ability to enable:

  • sensitivity analysis covering weightings and map scores;

  • comparisons between options, including resource requirements and costs, for grouping changes into delivery packages such as projects and programmes;

  • the generation of IAMs – see Section 13.3;


and a facility to consolidate entries (for example, when duplicates have been identified), merging and adjusting the relevant attributes and links. The system should produce an audit trail of any consolidations made.


29.7 Measurement and Tracking

Ideally the software should include provision for the recommended Measures Dictionary, where each measure could contain:

  • dimensions (for example, by product, function, geographic region);

  • historic data;

  • baseline value (based on historic data but could be frozen at the start of a project);

  • predicted improvement profile for each benefit, programme or project;

  • change measure contributions;

  • how frequently, by whom and how the measure is to be tracked;

  • actual values as these are tracked;

  • an ability to apportion actual improvements between benefits, projects and programmes.



29.8 Reporting – Dashboard

The system should incorporate a variety of reporting and display mechanisms, including dashboard facilities and the ability to use maps in conjunction with a BRAG Status (see Section 15.3), to monitor business performance, programme and project milestones, and benefit realisation.

It should also be able to generate all the standard reports for managing the programme and for review bodies.


29.9 Portfolio Management

The software should include a facility to generate comparisons between different investments within a portfolio, using:

  • financial measures, such as NPV;

  • consolidated scores based on a weighted set of attributes;

  • Portfolio Investment Matrices.



29.10 Security

Since the system will be used by several hundred people, with different roles and responsibilities, from a variety of stakeholder groups, access must be controlled by sophisticated security, with restrictions on both update and view, depending on user or role.


29.11 Available Software

New software products in the portfolio/programme/project and benefits space regularly come on to the market; though at the time of going to press, few are able to support BRM adequately and through the whole change life-cycle, including the monitoring and reporting of actuals.

sigma seeks to monitor the marketplace for relevant products and so for up-to-date information on those which most closely deliver the functionality outlined in this chapter, please visit the sigma website at

A fully integrated system for BRM and Programme Management is a valuable aid, releasing time and energy for analysis, innovation and stakeholder engagement. But at its best it is only an enabler and will not of itself change hearts and minds.

Submit your own content for publication

Submit content