Downside
MSP uses the term "tranche" which is a word of French origin. It is more generally understood to refer to a slug of money in one form or another. It is not well known in North America and rarely used, so it is somewhat disconcerting to see it used to refer to a set of projects that represent deliverables rather than money.
The text is well illustrated by copious diagrams generally presented in solid colors. However, for our liking we tended to find some of them overburdened by the red color used and hence rather overpowering. Too much color tends to make the illustrations unnecessarily busy and cluttered with a consequent obscuring of the message.[12] In other cases, the graphics artist seems to have got carried away with wavy-lined connectors. We are not sure whether wavy connectors have some symbolic significance such as ephemeral or transient impacts, but since we are used to straight-line or single-curvature connectors in most flow diagrams, we found this rather disturbing.[13]
In a short section titled "Responsibilities for Program Planning and control" it states, in part:[14]
"The Senior Responsible Owner is responsible for approving the Program Plan and leading the monitoring activities, including the reviews at the end of each tranche." [i.e. at the end of each set of projects.]
"The Program Manager is responsible for designing and implementing the Program Plan, the Resource Management Strategy and the monitoring and control activities"
"The Business Change Manager(s) is responsible for managing the transition and will need to work closely with the Program Manager on designing the Project Portfolio and scheduling the projects to ensure the transition will align with required benefits realization." [Emphasis added]
In the information-technology industry at least, even once a program plan has been formulated, there is no certainty that the content of individual projects will remain whole. It's called "flexibility". The problem with program/project portfolio management in this instance is that one tends to think of projects like tiles on a Scrabble board - to be held, played or stopped to best advantage of the player. So, presumably the last item quoted means that in practice some projects may have to be accelerated, and others slowed down, or even canceled altogether.
The reality is that, aside from those projects that are in deep technological difficulty, you might get away with stopping a project once on grounds of market shift, competition, or whatever. Or you might just get away with it a second time. But the nature of successful project people is that they enjoy succeeding against the challenge and odds of serious constraints. To "pull the rug from under them" (as they say) at some crucial point is to be thoroughly demoralizing. So the next time around you ask your people to "accelerate", they'll just yawn and tell you to "Forget it!"
Given the importance of exercising control over the extensive resources required for the types of programs contemplated in the MSP, one might have expected more attention to this aspect of program management.
The last chapter, Chapter 16 - Closing a Program, is also quite short and appears to be somewhat ambivalent. For example: "Program closure may be scheduled at any point after the completion of the last project within the Project Portfolio." And: "To a large extent, when the program formally closes will depend on the amount of support required to ensure the new operational environment delivered by the program is fully embedded."[15] This appears to be somewhat at odds with the definition of program that we cited earlier and in which it states: " they achieve outcomes and realize benefits". Note the present tense not future.
However, "Closing a program identifies the need for future assessment of benefit realization as well as a formal review of those achieved so far." Yet: "Program closure involves formal confirmation that the Business Case has been satisfied ..."[16] We suggest that benefits are like profits - you simply don't know their real value until the last penny has been accounted for, so that this closure is open to a lot of speculation, with the potential for undue optimism. We are inclined to think that perhaps a program should remain open for a specified period after the project tranche has been completed. This is to ensure that there is impetus to garner all of the planned benefits and that the program is fully accounted for.
There is an interesting area of program/portfolio management that does not yet seem to be on the radar screens of project management gurus, much less in any of the methodologies that we've seen to date. It is, in our view, the most crucial step in achieving a successful outcome. That is, the launch of the products of projects or, more specifically, the "transfer of the care, custody and control" of the product into its working environment.
We hear vaguely of the need for training and support for some products, but this tends to be somewhat brushed aside as a separate activity. What we don't hear about is the need for "marketing and selling" the product into its working environment. These activities are well established in the commercial or retail sectors, but are they not also essential activities if the full benefits of project products are to be garnered within the framework of project portfolio management? After all, acceptance by the stakeholders is the first step to "stakeholder satisfaction", so we feel that this is a serious missing link in present-day project management.
12. Examples: Managing Successful Programmes, Figure 2.1 p10, Figure 3.2 p26, Figure 3.4 p28
13. Examples: Managing Successful Programmes, Figure 4.1 p31, Figure 4.2 p33, Figure 4.3 p36
14. Managing Successful Programmes, p69
15. Ibid, p119
16. Ibid.
|
Further
Observations
