Powerful project portfolio management

Procedure

An interdisciplinary team of company executives and experienced consultants from CO Improve was formed to develop the conceptual solutions. Sales, R&D, Purchasing, Controlling, PMO and IT were involved. The concepts were developed in subgroups in joint workshops. For fast and efficient progress, CO Improve prepared draft concepts tailored to the company's situation, which were then jointly processed and further developed. The manageability of the individual solution elements was tested with those affected in the organisation using real examples and the feedback taken into account for the final optimisation. Only then was the rollout included in the annual budget and project approval process.

At the beginning of the project, it was determined that, according to the already existing project categorisation, only the "large" projects should be the subject of strategic project portfolio management. Smaller projects should be allowed to be approved decentrally by the business unit managers. A base load for these smaller projects is reserved and deducted from the capacities to be determined for the project resources.

Strategic budget allocation

In order to make a strategically oriented allocation of resources for development projects possible and at the same time to prevent all projects from competing directly with each other in the selection process, it was agreed to begin budget planning firstly with a division of the budget according to business areas (product groups) and secondly with a division of the budget according to project types (pre-development, new product development and product maintenance).

The first agreement resulted in a part of the personnel resources previously allocated to the business units being transferred to central resource pools. Only in this way will it be possible to shift personnel resources easily in the future as strategic priorities change. The implementation was realised in the parallel initiative "Organisational Structure".

Budget allocation and ongoing control by project type ensures that urgent product maintenance does not cannibalise new product development and that the latter does not cannibalise pre-development. It was supported by another organisational measure, the introduction of a central pre-development area. In this way, the company's strategic claim to innovation and the safeguarding of the future return target are met.

Evaluation criteria

In the next step, we jointly designed a two-stage evaluation procedure for project assessment and prioritisation. The aggregation of the assessment takes place in a scoring model. Three criteria are assessed:

• Profitability
• Strategic importance
• Risk

For the evaluation of profitability, a detailed business case template was developed, which for the turnover side shows the sales forecasts and price development in the various markets and for the cost side takes into account the development of manufacturing costs and individual project costs in a contribution margin calculation.

Finally, an imputed interest rate is used to calculate a net present value for each project so that projects can be compared directly with each other. Of course, the valuation stands and falls with the quality of the data. For this purpose, we had planned a powerful market intelligence and strategic product management in the solution approach. This prerequisite was also implemented in the parallel "organisational structure" initiative.

Discussing the strategic importance of a project is always difficult and is often done from the gut. This does not have to be wrong at all. For an objectified determination of strategic importance, the company has opted for a separate scoring model. Here, the goals of the corporate and product strategy are explicitly listed and the contribution of each project to the implementation of each strategic goal is evaluated. This way, a strategy contribution is calculated that can be used for the aggregating Scoring-Modell.

The risk assessment is again aggregated from various risks. Development risks are considered with regard to technological maturity and already completed functional validation, market and sales risks and budget risks.

Workload model and multi-project resource planning

A major consequence of overstretching the available personnel capacities is harmful multitasking (Eliyahu M. Goldratt: Critical Chain). This multitasking further aggravates the situation. A vicious circle is created.

But development projects are subject to high variability and unpredictable events. That is simply in the nature of things. In this respect, it is important to keep buffers at the time of release in multi-project resource planning and to determine in planning terms which projects can actually be started in the order of their prioritisation. A complete optimisation of the processes through planning is illusory.

Experience has also shown that the aggregation of individual project plans is not successful or is too time-consuming. And often, at the time of project approval, no project team has been set up to carry out project planning. Inevitably, separate project resource planning becomes necessary, which is sufficiently precise but not too costly. Two alternatives are possible. The use of standard workload models or project-specific planning based on analogy considerations.

In the present project, the company decided on project-specific planning because of the great variance of the projects. For this purpose, we jointly defined project resource categories - 22 in the first step, a relatively high number. A month was chosen for the temporal resolution of the resource requirements. The responsible product area managers tested the planning and found the effort to be acceptable. In perspective, the planning effort will decrease further because more project plans will be available for analogy considerations.

At the time of the project release decision, the project plans that will be prepared in the business units in the future will be aggregated in order of priority. As soon as the defined buffer of one of the 22 project resource categories is attacked, the project cannot be released initially. As a reaction option, increasing the capacity at the bottleneck point is of course sensible.