Portfolio management processes are often seen as an end-to-end process, with new project requirements as input into the portfolio and project outcomes as output from the process. But basically this does not reflect reality. A portfolio is defined to achieve certain, defined results for the organization. Therefore, it is important to capture and measure the benefits of the projects. Even an investment portfolio manager is not measured by which shares he or she has bought, but by the increase in value that has been achieved.
The project results are the reason to run a portfolio and carry out all these important projects. It is precisely in the operating field that the earnings are realized, which is confirming that we have made the right investments.
Similar as shown in the BCG Matrix (Boston Consulting Group), the same applies to the project delivery items. They also have to face the influences of the real world, as the 4E matrix below shows:
Ideally, you should try to achieve the best overall benefit (red field), because this is where the value (product of use and benefit) for the organization is at its greatest. The higher the degree of use, the more value is created. This is also a reason to standardize processes within the organization.
Not in every case one will land with a new solution in the "nirvana" of utilization. Perhaps you have delivered a very good project, but the solution is used in only one business unit. A follow-up project can then ensure the deployment of the solution across the entire organization and hence increase its value. Often we see this with pilot installations.
On the other hand, the full functionality of the project delivery item is not yet reached at the end of the project. This can be intentional, for example if the time-to-market was more important than the functionality. We particularly see this effect in agile projects, where functionality is delivered step by step. The value for the organization is achieved by enhancing the project deliverables. This might be achieved by one-time projects or as planned releases.
If you don't manage to generate the greatest possible value, you should think about whether the solution was the right one and replace it with a better one if necessary.
At the end of the project product lifecycle, the product is either replaced or completely removed from the organization (elimination).
The operation of the project results triggers a new project demand for the 4 E's.
|Enhance||-||Improve by adding new features. This could trigger a new project to create a new version of the solution.|
|Expand||-||get more out of the solution. In a complex environment (e.g. global organization) a roll-out project is required.|
|Exchange||-||by something else to meet the requirements. This usually leads to a new project.|
|Eliminate||-||the solution is no longer needed because the requirement no longer exists. However, to take a running application out of service, a project is often required.|
New project demand is created during the operational phase of a project and is therefore the missing link between traditional end-to-end portfolio management and the holistic cycle approach.
Last but not least, the operational phase is very important to refine the benefit management, because only now can we measure whether the projects deliver what they promised.
For this reason, a project delivery status should always be a framework or dashboard that measures project success in reality!