Topic 9: Portfolio and program management

The relationship between portfolios, programs and projects

The program manager and the portfolio manager. Neither of these roles is as mature as the role of project manager and there is considerable debate about what program managers and portfolio managers do and what they are responsible for. Portfolio managers are responsible for deciding which projects are initiated and which are to continue to achieve the best outcomes for the organisation. Each organisation should have one, and only one portfolio of investment projects. Program managers are responsible for ensuring that the group of projects under them are achieved in the most efficient way. Program managers, therefore, achieve their aims through coordination of the projects, but do not directly manage them.

Portfolio management

'Portfolio management' in the area that we are talking about is management of a portfolio of projects. It is not interested in 'doing things right', but in 'doing the right things' to achieve the aims of the organisation. The portfolio will consist of more than one project which may be grouped into one or more programs. In the developing language of portfolio management, targets are generally referred to as the KPIs, even though they may not be KPIs in the traditional management sense.

Most projects do not deliver business benefits, but instead they create the facility for a business unit to achieve the business benefits. Many of the projects undertaken in business are of the 'infrastructural' nature. By this we mean projects that do not provide a benefit in their own right, but enable other projects to achieve their aims. One of the key roles of portfolio management is to maintain the register of business benefits over time. The portfolio manager must be able to stop a project from initiating and then stop a project that is in development. They do this through corporate governance.

Corporate governance should stop:
* the ongoing development of ideas that are unlikely to be funded
* projects from being started when they are unlikely to achieve their business benefits or when they would achieve less business benefits than other projects
* projects that are unlikely to achieve their business benefits (whether through the fault of the project or a changed business environment).

The two main issues for corporate governance should be:
* What constitutes 'off-the-rails'?
* What level of reporting/monitoring is sufficient to find out about projects at risk of failing, without affecting the projects efficiency?

Corporate governance is normally enacted through a range of 'gates' that are associated with the project lifecycle. For example
Gate 1—Idea registration., Gate 2—Initial business case., Gate 3—Full business case., Gates 4–X—Design and other stages., Monitoring, Gate X+1—Deployment, Gate X+2—Post project

Given that portfolio management is substantially concerned with achieving a number of quantitative KPIs, then it is not surprising that the Radar and Bubble Charts, which excel at this type of display, have become the hallmark of portfolio management.

Program management

The PMI defines a program as: "a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually" (PMI 2006: 4).

The hierarchy of terms goes like this. Portfolio management (which goes across an organisation) has one or more programs, which have benefits from being coordinated jointly. A program has one or more projects—which are unique endeavours with clear goals and requirements; which have zero or more sub-projects; where both projects and any sub-project have zero or more control accounts; but where projects, sub-projects and control accounts all have more than one task, and one or more deliverables.

Within the definition of the standard, and within industry, there are two related but quite different program constructs:
* the goal driven, top-down program
* the project driven bottom-up program.

PMI define program management as: "the centralized coordinated management of a program to achieve the program's strategic benefits and objectives" (PMI 2006:4). The PMI also notes that the themes of program management are 'benefits management, stakeholder management and program governance'.

The relationship of shared projects in a program is typically: shared personnel, shared infrastructure, shared knowledge domain, inter-related benefits—the projects are trying to impact the same KPIs, cross-project impacts because some of the projects deliver items to the other projects, the benefits to be obtained (or not obtained) are not independent technical directions, architecture and risks are inter-related. Program managers need to work with the project managers to allocate the limited resources among the projects.

Everything about portfolio management may apply just as well to the management of the program's group (portfolio) of projects. The program is likely to have KPI measurements, benefits, budgets, alternative projects, a list of currently running projects, governance issues and projects that are not performing as desired.

The greatest value that most program managers can provide is knowledge. It is impossible for a project manager to know unknown unknowns. However, if a project manager is working within a particular domain, with similar technical, personnel, governance, legal, environmental, etc. impacts, then it is reasonable to assume that any risk that may arise on one project has the potential to arise on some other projects. e.g., within a program, a project risk or issue should be entered into a log, the estimated impacts and actual impacts (of issues) should also be annotated into this log. Consider also standard WBS elements, standard contracts, project methodology, forms, templates, guidelines etc. Another area in which the program manager becomes involved is cross-project impacts.

Throughout this unit we have differentiated the project management workflow from the product development or system engineering workflow. Within a program, that has common resources, the product development tasks are likely to be similar or have some key elements in common. These tasks can be captured from the project plan of one project, and then extended to include documentation that could not be economically developed within the one project. Reviews of recently completed tasks can determine whether these elements have been correctly documented, or whether the information and templates provided were useful or need updating. This interaction between the program and projects can quickly improve the level of information contained within the methodology. The final area of review and improvement that the program manager must do is to delete the material no longer being used. Apart from helping project managers, the program manager also has the responsibility of gathering data on project performance and reporting the consolidated status of the projects.

Running a department of project managers

There are three elements required to efficiently achieve project outcomes within an organisation:
* portfolio management—working on the right projects
* project management—doing your best to deliver the project requirements at the lowest budget/schedule possible
* project management department management—ensuring that you have the best project managers and systems to ensure that #2 is at the leading edge of what is possible.

The manager of the project management department will not deliver a project per se. It is their role to ensure that each project will be managed by a project manager who will achieve the best outcomes possible for the organisation. This is done through three key elements:
* people development
* organisational processes
* people assignment.

The OGC suggests that the P3M3 can be used as the basis for improving portfolio, programme and project management processes. It is structured
with five levels of maturity:
Level 1—initial process
Level 2—repeatable process
Level 3—defined process
Level 4—managed process
Level 5—optimised process.

Each process area has a consistent structure, which is both descriptive and focused on outcomes. These are: functional achievement/process goals., approach., deployment., review., perception performance measures.