Project portfolio management

Prerequisite: Good strategy work

Prioritising projects needs strategic orientation. A project for the development of an innovative function would probably be evaluated differently in a company that strives for innovation leadership than in a company that wants to occupy the cost leadership position. That is why a clearly formulated and consistently coordinated strategy is a necessary prerequisite for effective project portfolio management.
As a rule, five strategy building blocks contribute to this:

• Corporate strategy
• Business field strategy
• Product (line) strategy
• Technology strategy
• Platform and module strategy

Each building block formulates the strategy from a different perspective. In most cases, different experts are called in to elaborate the respective strategy building block with a high level of competence. In order to ultimately create a coherent whole, several iterations are often necessary, which, in addition to the strategy building blocks mentioned, also affect others, such as the production, purchasing or patent strategy.

Good strategy work can be highly complex and needs an efficient process to achieve the necessary harmonisation across all building blocks. But it is the most important prerequisite for making the right decisions about the project portfolio.

Assessment and prioritisation of the project portfolio

Derived from the various strategies, the responsible areas develop their desired roadmaps and project requirements. The product roadmap plays a leading role in this. This roadmap translates the product (line) strategy into an action plan that product management requests to implement the strategy. The creators of the roadmap usually have no direct insight into the resource situation in R&D. Since not all projects can be realised, the desired roadmap must first be evaluated and prioritised. Basically, this could be done by the product management itself, as those responsible can best assess the importance of their product projects. But competing projects from other areas, such as the technology roadmap, make this task complex and a cross-functional challenge.

A set of evaluation criteria is used so that projects from the different areas can be evaluated in a way that allows for overarching prioritisation. Although the details vary from company to company, the following criteria are typically considered to evaluate these aspects:

• economic parameters
• strategic aspects
• market share developments
• competitive situation
• deadline situation
• use of resources
• risks
• procurement situation
• competence profile
• regional coverage

From these criteria, an individual scoring model is developed to evaluate and compare projects. The scores determined lead to an initial ranking of project priorities. In the simplest case projects are evaluated only according to profitability using the net present value. Project risks can be taken into account with different internal rates of return.

However, this initial ranking must be checked again with regard to content-related dependencies and adjusted if necessary. Even with the use of sophisticated scoring models, it is not always ensured that the logical sequence (technology / advance development - module and/or platform development - product development) also results in the correct priority sequence.

Once this adjustment has been made, the prioritised projects can be matched with the available capacities. This results in a project roadmap with clearly defined deadlines and subject-specific allocated resources. The latter may be necessary down to the name level of an expert if only that single expertise is available and needed.

To make the implementation of this roadmap more reliable, it is advisable not to fully utilise the available resources in planning. This is because unforeseeable events always occur, which then have to be absorbed with reserves. It has been shown that the economic optimum lies at a planned utilisation of about 80% - 90% (work-in-progress limit), whereby this value must be determined specifically for the company. Why? If one utilises one's own resources at a lower level, unnecessary capacity costs are incurred. However, if you utilise your own capacities more, unforeseeable events will lead to delays in projects. Priorities are changed, resources are shifted to make up for delays. This further aggravates the situation. The continuous flow comes to a halt. The pipeline becomes clogged. Market launch dates are postponed. Revenues are lost (queuing costs or cost of delay).

Process and roles for managing the project portfolio

The project portfolio is subject to continuous change. Market and customers, technologies, but also the planning and resource situation are always evolving. Of course, the goal is to keep the project roadmap stable. But important changes could mean that sticking to the roadmap is detrimental to the company. That is why the project portfolio must be continuously reviewed and adjusted. This is done with an efficient management process under the governance of a project portfolio committee.

On the one hand, it is the task of this committee to determine the priority of new projects using the scoring model described above or the necessary manual adjustments, and to decide on their inclusion in the project roadmap based on the results. On the other hand, ongoing projects must also be updated as necessary, since both the capacity requirements and the project score can change in the course of a development. Ongoing projects are first dealt with in the project steering committee - another committee besides the project portfolio committee. As long as the plan and actual for a project are within a defined range, there is no feedback to the portfolio committee. However, as soon as a relevant deviation becomes apparent, the priority of the project or the capacity allocation must be redefined. This is done exclusively by the project portfolio committee.

The basis for this is a structured documentation of the project planning that is appropriate to the project progress. This project profile contains all relevant planning data, which are required, for example, to determine the score or for capacity and schedule planning. In the first phase, some planning parameters can only be roughly determined or estimated. The further the project progresses (requirements specification or product backlog in an agile environment), the more detailed and precise the planning becomes. It is a good idea to release projects in phases in the portfolio committee. This means that the project is not completely released on the basis of the first initial - usually rough - planning. Only a certain phase, for example the creation of the specifications or the implementation, is released on the basis of an updated plan. This ensures that the prioritisation is up to date and also that the termination criteria are permanently questioned in each team.

To manage this process efficiently, fixed roles are defined in the project portfolio committee.