For many years already, the Standish Group describes in their Chaos report about the number of successful and less successful projects. How many projects are delivered On Time, On Budget and On Scope?
Many organizations are using these cpi’s as early warning indicators using RAG (Red, Amber, Green) to express if, e.g. the planning is at risk. Green when everything is running smoothly, Amber when the governance body, the project board, needs to know that problems are encountered but the project manager has options to solve, and Red when the project is off track and the project board has to make a decision. Because it’s an early warning indicator the indicator will switch from amber or red to green when the issue has been solved or a decision has been taken.
On a periodic basis many organizations look at their portfolio and calculate how many projects are at risk and use this information in their performance management systems to show how well they are performing.
Figure 1: Portfolio progress
If you look at figure 1, I could imagine a manager to say “we are doing pretty well with our projects, of course we do have our problems but on average between 10 and 20% of our projects have issues.” Does this sound familiar? In this example there are only two projects that report Amber in the last month, but what does this say? Are we really in control on all the projects? Let’s have a closer look. For initiative a we had some problems in July and as a consequence the end date was postponed. Initiative b is really a project at risk with several problems and the end date was moved more than once. Only initiative c will deliver at the original end date and I has been delivered at the original end date. Thus the manager had to say: “we really have problems with the delivery of our projects, only around 20% of our projects will be delivered On Time.” So if you report on your project portfolio progress it’s good to use the OTOBOS indicators but use the information from the original project portfolio plan as your baseline, and use e.g. changed end dates, to calculate how many of the projects in the portfolio are successful or not.
This post will be used in a new book MoP practices in practice, for portfolio managers who want to embed the MoP theory in their organization. In the coming months several blog posts and articles will be published waiting for your feedback. To see all, select the tag MoP_practices_in_practice.
Somehow, thius sunds too simple for me. Is OTOBOS the only way to define ‘successful”? Looking from a portolio perspective, when are project timelines, budget and scope baselined? Not all project will be well defined when establishing a portfolio plan, so you need top cater for variances in time, budget an schedule. And how do you deal with tolerances?
@Wouter. Fully agree that this only is too simple to define success. Most important is in my opinion how satisfied the key stakeholders are with the results. In this blog I am focussing on the fact that early warning indicators such as a planning cpi is often misused as an indicator for project success from a project manager perspective. If you want to show project portfolio success based on original end dates compared with actual end dates it gives a much better indication how your organization delivers projects. In that case I would suggest that you use the end dates from the originally approved PIDs (including the tolerance).
Dear Mister Portman,
I think tis is a nice way to get a high-level insight on th initiatives that are part of a portfolio.
I do think, that it should me combined with an issue & risk log in which you also state; how you will mitigate these risks, issues and when.
It looks like it could be used for monitoring and communication purposes.
Next to that I would like to suggest, you explain what you mean by CPI’s, to avoid confusion with CPI ( as in Consumer Price Indices).
Good luck writing your book and delivering results in project & progam management.
I agree that on portfolio level, a comparison with only the last approved planning, budget and scope is too limited. At least you should compare with the ambitions stated at the beginning of the portfolio schedule (in my company we define/update the project portfolio every 3 months).
I our (small) company we have a mixture of waterfall projects and agile release teams (combined in 1 release train/program), and have adapted SAFe as framework for Agile delivery. I was wondering if reporting practices of agile release programs on portfolio level is also being addressed in your book?