Author: Claude Emond

I decided to put on hold my Velocity series to write this blog entry. The timing for this seemed just right, considering that a new group of dedicated volunteers are about to embark on a review the current edition of The Standard for Portfolio Management (PMI, 2nd edition, 2008) in order to release its 3rd edition in 2011 or around then.                 

Mea culpa, mea maxima culpa!

I was one of the co-leaders and co-authors of the 1st edition of this standard, published in 2006. Since then, I have had many occasions to test its contents, both in measuring client organisations against it and in trying to implement the described processes with them. In light of those experiences, I have to admit that something big is missing in this standard, as we imagined it, something that has not been fixed in the 2nd edition either. And, I have humbly to say mea culpa, mea maxima culpa for this situation.

It has to be understood that this standard, produced at the time simultaneously with The Standard for Program Management, was a very first foray by PMI into the strategic management processes owned by the corporate boardrooms of organisations. I remember that at the time, many PMI members were questioning the relevancy for PMI to go in this direction, as documented during the PMI Anaheim’s World Congress of October 2004; some argued that this was not project management.

Although I believe that PMI must be involved in providing governance standards on all aspects of project-oriented processes, I have to agree that portfolio management is not only about managing projects, project portfolios being only one of the many portfolios an organisation has to concurrently balance to manage its operational delivery capabilities, among others: its current assets portfolio, its money portfolio and its human resources portfolio. This is one of the reasons, I believe, that PMI finally titled the new standard not The Standard for Project Portfolio Management, but The Standard for Portfolio Management….as well as the reason why we wrote in the standard that such a portfolio included projects, programs, sub-portfolios as well as «other works» (which could be anything that needed visibility in order to balance work and organisational capacities).

Project portfolio management was not very well understood even in 2004 and, frankly, this situation has not evolved much yet. Personally, I have yet to see an organisation which has a well documented workable, complete corporate project portfolio management process; many have new product development projects portfolios and/or IT projects portfolios and/or Capital projects portfolios management processes, most often than not managed separatelyc without proper integration.

When we started working on the standard in 2004, PMI instructed us that it had to be in line with the contents of the OPM3 standard (1st edition) and of the newly published 3rd edition of the PMBoK (2004). Right of the bat, those of us in the standard production team, who had some experience with project portfolios, had to oppose this directive. OPM3 was using the IPECC (Initiate, plan, execute, control, close) process on all three levels of project activities: projects, programs, portfolios. We submitted that a corporate projects portfolio could not be managed through an IPECC process, since closing the portfolio meant closing the organisation all together. We got PMI to agree (so I believed at the time) that portfolio management was not a project management process but rather an ongoing operational business process. A more proper PDCA-like process to manage it was IPECA: Initiate, Plan, Execute, Control, Adjust/Adapt !!

So, we were coming from very far conceptually and we ended up writing a flawed standard.

Since then, much has been experienced and written about the subject…. And many organisations have not waited for PMI to update its standard to address the real issues of project portfolio management. Among others, the current standard:

does not propose any process for project benefits management, materialised benefits being fundamentally why we do projects does not propose any process to generate and capture project ideas in order to ensure that we really generate the best project proposals possible and thus have the best portfolio in terms of value does not propose any mechanisms to choose the right projects when the strategic plan used as a basis for project selection and management is flawed in terms of having all the required objectives to ensure the viability and sustainability of the organisation

Benefits Management Processes

Back in 2004, when one browsed the internet using the expression benefits management, the results were few and not very useful. I just Googled it this morning and ended up after 0,33 seconds with 254 millions entries !!! Most interestingly, the first entry was titled in the list provided by Google: What is Benefits Management or Project Portfolio Management [1]. Well, this is quite a final argument for including benefit management processes in a portfolio management standard, to cover both benefits materialisation planning (including change management sub-processes) and the tracking of those benefits after the transfer of project deliverables to operations.

Actually, one does not need to look all over the place for some clues about what those processes should consist of. Both the Government of Tasmania [2] and the British Office for Government Commerce (the OGC) [3] have already done most of the work for us. They both offer plenty of documentation as well as tools to go around the business of ensuring and managing your project benefits in a project portfolio management setting. All you have to do now is just go to their internet sites, learn the trade, adapt it and apply it to your current context.

Project Idea Capture Processes

I have to admit I was completely clueless about the need to include an idea capture process before starting to read, a couple of months ago, Simon Moore’s Strategic Project Portfolio Management: Enabling a Productive Organization [4]. What he writes there is a very convincing case for having a project proposal management process that does not merely try to filter projects to be selected for delivery, but also really stimulates the generation and submittal of as many ideas as possible. His argument is that it is through the promotion of creativity that an organisation will be able to generate and realize the most valuable projects, and thus have the best projects portfolio possible to manage, the one that really maximise beneficial. For doing that, he calls for proposal management processes that are simple and that encourage proposal submittals. The processes he proposes even include some steps to mix submittals together to generate more complete, synergistic proposals. His book contains many more brilliant ideas to improve portfolio management and should be read by all those concerned with this subject.

Ensuring the Project Portfolio Really Supports the Organisation’s Long Term Viability

The current standard basically says that the projects chosen should be in line with one or more of the strategic objectives of the organisation, and that the ones contributing the most to those objectives over time should be given priority in their selection and programming. This is in line with most of the things I have read on the subject.

The problem is that, besides being very complicated when those objectives are too numerous, it is not sufficient to ensure the viability of the organisation if the strategic plan is incomplete. Actually, most of the strategic plans I have encountered (…when they exist and are documented!!) are generally oriented towards growth. Most of them do not address maintaining current productivity levels; they thus lack objectives that aim at protecting current assets and operations against deterioration.

One of the organisations I worked with is paying dearly because of this flaw in its strategic plan. Although it had an impressive amount of detailed strategic objectives (24 of them, which made the scoring model quite complicated both in contents and effective use), none of them addressed protecting its current assets and operations against deterioration over time. This situation had prevailed for so many years that this organisation ended up with a huge portfolio of urgent projects to renew and upgrade its assets to continue operating, representing capital investments in the billions of dollars over the next 10 years. This is a level of project activities that they have both difficulty in funding and the manpower capacity to deliver. In fact, when I started working with upper management on the portfolio management process, they were using a subterfuge to include those projects in their portfolio, since they were aligned with none of the objectives included in the strategic plan. They had designed in their selection process a special class of projects for those projects that did not generate any benefits when assessed against the objectives of the current strategic plan; it was the projects that were to be measured against the operational risk of NOT doing them. Those special projects currently represent more than 85% of the content of their current multibillion dollars portfolio. Fortunately, we succeeded this last year to upgrade the strategic plan to include current assets protection and renewal to keep current operations from deteriorating and endangering the sustainability of the organisation.

Through many such implementation difficulties, I finally realised that there should be, over and above the usual alignment to strategic objectives required to select and manage the projects in the corporate portfolio, an additional level of alignment, being prioritised over and above the strategic objectives: the alignment with the global mission of the organisation (WHY it exists). This is to ensure that the projects that sustain the most this mission over the short, medium and long terms, are the ones being delivered. I eventually got Dorian Mougel, one of my master degree students in France, to write a thesis explaining how to design a portfolio management process that does just that [5].

What to Conclude?

I sure hope that the people who are about to produce the coming 3rd edition of PMI’s The Standard for Portfolio Management will get to consider improving it by completing it with processes and mechanisms addressing those three issues (among others). In the mean time, while this 3rd edition is in the making, I invite all those involved with implementing and improving project portfolio processes to listen to and take into account what the Government of Tasmania, the OGC and Simon Moore are telling us. I also encourage them to take a close look at the strategic plans they use for alignment in order to make sure that they also include as the ultimate alignment mechanism the contribution of contemplated project activities toward BOTH maintaining current operations and sustaining the organisation’s mission today, tomorrow and into the future!

Perfection of means and confusion of goals seem — in my opinion — to characterize our age.
Albert Einstein

In my last blog entry, I started discussing how to elevate the capacity to change constraint through the management of resource availability. Last time, I referred you directly to the words of Goldratt and his staff on the Theory of Constraints (TOC), as they apply it to managing projects, namely his business novel, Critical Chain, and a summary of the principles it contains [i].

For Goldratt, resource availability is one of the main issues in managing projects successfully. As discussed in a previous blog entry[ii], I think we can group resource availability issues in four categories:

• availability of economic resources in the quantity and at the time required (budgets, money and proper cash flows);
• availability of material resources of the proper nature, and in the quantity and at the time required (materiel, space, equipment, informational/TI resources, tools, etc.);
• availability of the required qualified performing/affected humans (human resources issues)
  • in the quantity and at the time required, as well as
  • at the necessary level of readiness when required
• finally, availability of time in sufficient quantity to realise what is necessary in the timeframe that is desired and/or has been set for the anticipated change to be implemented and for its benefits to materialise. 

All these resource availability issues are linked to the realisation strategy of the project at hand, namely answering the questions:

• Which specific economic, material and human resources are required?
• When, in which logical sequence, and for how long will these resources need to be made available?
• How will they be used?
• By whom will they be transformed into the necessary deliverables? …as well as
• How will those answers change as the project evolve and how these changes will be tracked and taken into account?

More often than not, in many projects, those questions are answered without properly sharing information on the why of the project, and on the specific what that has to be done as the situation evolves. Such projects often end up not having, over time, the proper resources required to succeed. The results presented in studies like the Chaos Report[iii] are quite eloquent and reflect this problem:

On the success side, the average is only 16.2% for software projects that are completed on time and on budget. In larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions.

I submit here that such a situation is not caused by the fact that we do not have sufficient resources to make those projects, but by the fact that they were ill-defined to start with. Even if and when the resources required are sufficient, they are being wasted through unshared, ill-fated deployment plans.

I once asked participating project managers in one of my workshops, how many of them believed that they were working on a project with unrealistic timeframe and/or insufficient resources. All of them (there were 15) raised their hands. This cannot be possible. They were all coming from the same huge multinational organisation, a world leader in its field of business. The problem was that these 15 project managers did not have the same perceptions that their project sponsors/clients had about what was the nature of the projects at hand and, then, about what were the required resources necessary over time to succeed in delivering anticipated benefits. 

The first condition a project manager has to meet, in order to elevate resource availability constraints on the project s/he has to deliver, is to ensure everyone contributing on this project sees the same project, understands the same project, values the same project …and desires the same project outcome. This condition must be met not only at the beginning of the endeavour, but every single day of the project as it evolves. There is no use discussing resources on a project, unless this condition is met and unless perceptions on the why and what of the project at hand are aligned. Once this condition is met, at least resource issues will be understood the same way and, as a whole, your organisation’s project portfolio will be balanced over time to assign the proper resources on your projects. This includes those organisational change projects that are perceived in many different ways by the stakeholders, none of these ways being the right perception, because it is not a shared perception.

 Let’s not forget that famous Einstein quote you saw at the top of this article, “Perfection of means and confusion of goals seem — in my opinion — to characterize our age”. I believe this to be right, particularly in the western hemisphere. I know that organisational resources are not infinite, but I believe we can do a lot more with what we have if we start to work together on the same projects (meaning having a shared perception of why it is about, what it is and what is required to make it happen). Make sure you have common goals, as this will automatically elevate the resource availability constraints… because it will ensure that the right resources are used on the right projects, at the right time. It will ensure that those resources that are already available in successful organisations stop being wasted by being used on the wrong project or at the wrong time.