Skip to main content

Author: Claude Emond

The Standard for Portfolio Management – Something Big is Missing!

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!

Don’t Forget to Leave Your Comments Below!

Simon Moore, Strategic Project Portfolio Management: Enabling a Productive Organization, Microsoft Executive Leadership Series, Wiley, 2009

Dorian Mougel, «La seule prise en compte du ROI est-elle vraiment pertinente pour mesurer les bénéfices des projets?», mémoire de maîtrise, MSMPP, CESI, Lyon, 2008

Velocity Part 5.1. Elevating Technical Maturity; Resource Availability Issues

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.

Don’t forget to leave your comments below

[i] White paper on «Theory of Constraints Project Management», at

Velocity Part 5 – Elevating the Capacity to Change Constraint

In my previous blog, I listed and explained briefly what needed to be elevated to ensure we used correctly the main constraint of organisational/cultural change projects, namely the capacity and will to change of the humans involved in and/or impacted by such projects. In this blog entry and at least the four others to come, I will discuss the different means of elevating the “capacity” part of this constraint.

In my last blog entry, among possible means to elevate capacity, I identified at least four. Three were related to better managing knowledge issues: the know what, the know what to do and the know how to do. The fourth one was related to better managing resource availability issues, including human resources, monetary resources, physical resources, as well as time resources.

I will tackle the resource availability issues of organisational/cultural change projects in this and the next blog entry. Those issues are not that different from those on other types of projects. They are also often presented as the main subject around which revolves TOC[1] when applied to project management. So before going too far discussing those, I believe we have to revisit what has been written about TOC-Project Management by the principal person concerned, Eliyahu M. Goldratt. So this is what I will do today.

Most people aware of Goldratt’s book Critical Chain [2], but who are not really using in real life the principles laid out there (as I was myself guilty of for a long time), believe that TOC-Project Management is only about paying more attention to project resources by:

  • identifying them properly, and
  • managing them more realistically through the setting-up, tracking and protecting of buffers.

In a not too distant past life, I myself stated many times that the critical chain was our traditional critical path including resource constraints and availabilities into it….and that, consequently, the critical chain was always longer than the critical path. This is a very reducing view of what Goldratt wrote and promotes, a view shared, alas,by many project managers. It is also a view shared by many critical chain project management software providers, who added buffer management functionalities to the usual CPM [3] scheduling algorithms used in traditional PM software packages…and then called it a day!

In fact, what I am currently trying to discuss here in these blog entries, about organisational/cultural change constraints, is also discussed in Goldratt’s writings: those writings go beyond simple resources availability issues to also cover behavioural as well as buy-in (associated with the will to change) issues, among others. I am just trying here to put those writings in a different perspective, in order to apply them specifically to organisational/cultural change projects. I really believe that my main contribution here will be to clarify misconceptions about TOC as it applies to project management, as well as (maybe) add some original proposals to elevate buy-in to the level required to accelerate and succeed the realisation of organisational/cultural change projects.

For now, to make sure we all have the same understanding of TOC-Project Management, I would rather like to let the master and his direct followers speak for themselves. I thus invite you to read or read again Goldratt’s business novel, Critical Chain (as I will do again myself) and/or peruse the new version (2009) of the Goldratt Institute’s very complete white paper introducing Theory of Constraints Project Management [4]. Once you have done so, please feel free to comment here about what you found in those readings that talks about other things than simple resource availability issues.

In the next blog entry, I will (at last) share my vision on what are those simple resource availability issues and how to deal with them.

Stay tuned !

Don’t forget to leave your comments below

1. TOC = Theory of constraints (as developed by Goldratt)
3. CPM = Critical Path Method

Velocity Part 4 – What needs to be Elevated in the “Capacity and Will to Change” Constraint

In my last blog entry, I discussed the process of constraint management at the heart of Goldratt’s Theory of Constraints (TOC). I presented briefly the steps to follow to manage the «capacity and will to change», which I believe to be the main constraint in projects involving an organisational, cultural or transformational change of some sort. I wrote that we had to see the positive side of this constraint instead of seeing only its consequence if not managed (increased “resistance to change”). In Goldratt’s view, a capacity or flow constraint is often something beneficial that needs, not to be eliminated (which is most of the time impossible), but rather, to be elevated to increase its throughput. What he says is that such a bottleneck is useful because it permits you to control flow or throughput. After all, this is the reason (and a very good idea) why bottles have bottlenecks!

The positive aspect of the capacity and will to change bottleneck is that, if you get and permit people to express themselves on how they feel about the change they are going to contribute to and/or be affected by, the multiple perspectives thus presented will permit you to:

  • see risks that you might have not anticipated by yourself,
  • see other alternatives and even seize some opportunities that are presented to you to accelerate and/or increase the benefits anticipated both for the organisation and for the project stakeholders, … and/or
  • discover and create new benefits from this project, at the end of it or as it evolves.

While introducing these new propositions that enhance the value of your project, you will develop, with everybody involved, a clearer vision of the objective, the why of this project [i] ; this common, shared vision is a necessary prerequisite [ii] to be able to elevate the capacity and will to change constraint.

Once the why of the project is well understood, we can look at what has to be done to elevate the constraint and… at how to do it, in the best way possible, to achieve and accelerate project success. When looking at the two elements of the constraint, capacity and will, we can look at these as two types of maturity, the same as the ones discussed in the Hersey-Blanchard Situational Leadership model:

  • the capacity available, which can be associated to a technical maturity level (I can or I cannot ). I associate this with the part of Vroom’s Expectancy Theory of Motivation I discussed previously and that I called the Capability Principle [iii]
  • the amount of «will» displayed, which can be associated to a «psychological maturity» level («I want or I want not»). Still referring to Vroom’s theory, I call this the «Desirability Principle».

The Elements of Technical Maturity

I believe that technical maturity depends on at least these three different types of knowledge:

  • the know what:
    • information on the object and purpose of the project,
    • information on its evolution, as well as
    • information on individual and group/team perceptions and expectations as they also evolve from the beginning to the end of the project.
  • the know what to do:
    • information on the specific actions or deliverables to execute, individually and as a team to achieve success
  • the know how to do:
    • a project structure organised around clear roles and responsibilities,
    • the use of specific strategies, processes or sequences of actions to achieve success individually and as a team, as well as
    • the availability of the skills (competency) required individually or as a group to achieve the results anticipated.

However technical maturity is not only a question of knowledge, but also depends on the availability of proper physical resources when required, including among others:

  • availability of economic (budgets, money and proper cash flows) resources in the quantity and at the time required;
  • availability of material resources (materiel, space, equipment, informational/TI resources, tools, etc.) of the proper nature, and in the quantity and at the time required;
  • availability of the qualified performing/affected humans:
    • in the quantity and at the time required, as well as
    • at the necessary level of readiness when required (a very important parameter of the «capacity maturity» equation, the «elevation» of which will be discussed in a later blog entry)…..
  • ….and, finally availability of enough time 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. 

The Elements of Psychological Maturity

It seems obvious that the wilI to change cannot be treated independently of the capacity to change. The change contemplated cannot be achieved if one has the will but does not have the capacity required to succeed that change. Will without proper means is just wishful thinking and really not sufficient to succeed. Those means must be found and made available. In fact, many studies on the phenomenon of resistance to change have concluded that the main reason people resist change is not a question of desire, but a question of perceived capacity: they just do not believe they CAN make that change or CAN survive, uninjured, this change. More often than not, resistance to change comes from insecurity with respect to one’s ability (a capacity issue) to evolve towards or to succeed in the newly changed environment.

The reverse proposition is also true. Even if you have the «capacity» to change, if you do not have the desire to change, things will just not happen by themselves. So, besides the «capacity issue», what other elements have to be taken into account to elevate «psychological maturity»?

I believe that psychological maturity depends on at least:

  • two parameters, those identified by Vroom’s in his Expectancy Theory of Motivation and that influence desirability, namely:
    • the nature of the element(s) of the change project answering to both the current and evolving needs/expectations of the performing/affected stakeholders, the WIIFM (what’s in it for me), and
    • the perceived value of this WIIFM, when compared to the effort required to obtain it (is it worth it ?…also called by Vroom the “valence” of the need/expectation that will be met)
  • …. as well as on the existence of proper collaborative behaviours, those that will change a group into a team of highly motivated and performing interdependent individuals.

I think the table is set now to discuss in more details, in my next blog entries,  the methods and approaches that can be used to elevate both the technical and the psychological maturity levels of a change project stakeholders and, in so doing, the capacity and will to change constraint. More coming on this subject !

Velocity Part 3 – Five Basic Steps to Effective Constraint Management

Constraint management is at the heart of Goldratt’s Theory of Constraints (TOC). This management process involves five basic steps [i] :

  1. Identify the constraint
  2. Exploit the constraint
  3. Subordinate other activities to the constraint
  4. Elevate the constraint
  5. Avoid negative inertia and Go back to step 1

In my last blog entry, I identified “the capacity and the will to change” as the limiting constraint of cultural change projects. So I believe I am done with step one. I understand from steps two and three that all efforts must then be shifted to exploiting the identified constraint and that, while doing that, this constraint must be at the center of all our other decisions.

Since we are talking about humans here as being part of the identified constraint, and not about a machine or a piece of equipment, the use of the word Exploits in step 2 of TOC could certainly start us on the wrong foot, in our efforts to promote change. I believe that, for cultural/organisational change projects, it should be replaced by the word Recognise. Recognise what? The existence of this capacity and will to change of those affected, which is the very least we can do when contemplating any change. Once we have recognised this and accepted it, all our decisions will have to go towards analysing this constraint and doing everything to improve its current condition…or at least maintain it, if the way it behaves is acceptable. This is the key to making the contemplated change a success and, if possible, accelerating the benefits associated with this change.

In most change management endeavours, it is rare that we speak very positively of the initial conditions met, people wise, at the beginning of the project. The words that come to mind are not desire to change but rather resistance to change. The capacity and will to change constraint is not seen as something positive we can use, but rather as something negative we have to fight. So, while no one is talking about exploiting resistance to change, not many recognise the positive aspect of one’s capacity and will to change.

I believe most people have a desire to change, if the right conditions are met. According to the Change Gap model, for any group in a given change situation, roughly 10% are change enablers and are seeking change.  Eighty percent of the group are waiting to see how things evolve but are still open to persuasion. The remaining 10% would prefer to die rather than admit they can be in a better position if they accept the change. So I believe we can build part of our change strategy on the desire to change of the change enablers. We must also recognize the high potential of the 80% to be change agents with the right persuasion.. For that, we have to do the right things and find the right conditions to increase both their capacity and will to change

The next step, once we recognise that we are not dealing with negative resistance to change but rather with positive potential desire to change, is to work towards changing this potential into real desire. We have to elevate the capacity and will to change of those 80% who are open to persuasion and ready to get their own benefits from this change…if they recognize the benefits and have the means to get to them. This can only be done by working on both parameters of the constraint, the capacity and the will to change. In my next blog entry, I will propose means and strategies to elevate or increase the capacity to change. In the entry after that, I will propose means and strategies to elevate the will to change.

Anyone, invited to manage a cultural/organisational change project, has to look at it very positively. So, instead of fearing and fighting resistance to change, this person should see desire to change as a positive force to harness and, hence, should design ways to elevate current capacity and will to change.


Don’t forget to leave your comments below