Pros and Cons of the PMI Standard
Please note: this is not an in-depth review of PMI's "Standard for Portfolio Management".[2] Rather, it is a summary of the key points we encountered when using it to cross-check our own PPM processes that we had developed in a client project designed to improve the organization's PPM capability.
Pros
Firstly, the coverage of the PMI Standard must be mentioned as a "pro". It delivers a documented set of processes on 79 pages and stays at an appropriate level of detail. The Standard comes in three sections: A Portfolio Management Framework section features an introduction as well as a chapter on the portfolio stakeholder roles and responsibilities; the actual standard section describes the processes; and an Appendix discusses tools and techniques.
The PMI standard has a good introductory chapter that details the linkage
between portfolio management, organizational strategy and the project execution.
These linkages are not only described in words but are also illustrated as shown
in Figure 2 below.
Figure 2: An Organizational Context of Portfolio Management[3]
Also the distinction between portfolios and programs is also most welcome because the two terms and their related contents are still confused by many people, thus any clarification is a step forward.
Cons
The PMI PPM Standard's processes do not seem to provide for handling
of new project requests during the year. As can be seen in Figure
3 below taken from the Standard's Chapter 3.1[4]
(with subsequent details described in Chapter 3.2.1[5]),
the "Monitoring and Controlling Process Group" has one entry point coming from
the "Aligning Process Group". But this aligning process is typically most active
at the time of the corporate planning and budgeting cycle that, for most enterprises,
takes place only once a year.
Figure 3: Portfolio Management Processes - High Level Illustration[6]
From our experience, however, there is a second entry point that missing from the Standard - the portfolio management must be able to handle any new project request on an on-going basis during the year. True that in an ideal world all conceivable initiatives and projects should be identified during the annual planning, but we don't live in an ideal world and such project requests just happen during the year anyway. In other words, prioritization and balancing are not one-off exercises. The portfolio processes must be designed in a way to accommodate not only a re-balancing but also re-prioritizing at any time. Initiation of such activities may come from within the portfolio, e.g. based on a project audit recommending discontinuation of funding of a running project, or from outside the portfolio, e.g. as a result of new project requests.
The importance of dependencies in prioritization is not acknowledged. Neither the Portfolio Management Processes section nor the Appendix on Tools and Techniques pays attention to dependencies between projects. Based on experience however, the neglect of dependencies may cause serious issues in strategic initiatives or even lead to their failure along with subsequent consequences to the benefits expected from such endeavours.
Why? Because if initiatives and projects are evaluated and prioritized as stand-alone items only, some projects inevitably
will get a low ranking and thus may not get the right skills and/or resources or may even be put on hold. That is fine so long
as no seemingly low-ranking project is a prerequisite to a subsequent high-ranking strategic or "must-have"[7] project.
In such a case, the higher ranked project can only go live if and when the prerequisite results of the other project(s) are
available because together, they form a package, see Figure 4.
Figure 4: Dependencies between projects influence the ranking
Consequently, the lower ranking projects must be adjusted to at least the same rank as the project for which they are a prerequisite. If the prioritization mechanism does not consider such adjustments, it is incomplete and may jeopardize achievement of whole strategic objectives.
The process descriptions do not include the roles and responsibilities per key activity. Without a mapping of the activities taking place in a process to the respective roles and responsibilities, a key element for the practical application of a process-oriented standard is missing. Since only the WHAT and HOW are stated but not the WHO, guidance is missing on who should do what.
As our last point, terminology must be mentioned: As good as the distinction between portfolio and programs as such may be, the choice to call projects and programs "components" is very artificial and abstract and thus more confusing than helpful.
2. Project Management Institute (PMI): The Standard for Portfolio Management, Pennsylvania, USA, May 2006. The document can be ordered from http://www.pmibookstore.org/PMIBookStore/productDetails.aspx?itemID=790&varID=1 (site accessed February 21, 2007)
3. Ibid, Figure 1-2, page 7
4. Ibid, page 24
5. Ibid, pages 26-36
6. Ibid, figure 3-2, page 25
7. "must" projects are driven by internal or external constraints that cannot be influenced (such as regulatory compliance requirements)
|
Reality
Check
