Conclusions
PRINCE2 is a solid, easy-to-follow and uncompromising project management methodology requiring meticulous attention to detail. It provides clear instructions and ample indication of the many considerations involved in all but the simplest of projects. It applies where the objectives are clear and the deliverables are either well described, or capable of being so. It is recommended for formal execution of all projects requiring this degree of attention on grounds of size, complexity, risk and/or safety.
According to the manual:
"PRINCE2 is designed for a variety of customer/supplier situations. For clarity, the PRINCE2 manual has been written on the assumption that the project will be run for a customer with a single (prime) supplier involved throughout. This has a bearing on not only the organization of the project, but also the controls."[40]
The implication is that PRINCE2 is in the hands of the supplier rather than the sponsoring organization, although direction and the corresponding level of control are clearly in the hands of the owner's Executive.
The manual does not cover the situation of multiple prime contracts (i.e. trade contracts) directly under the control of an owner. An example would be the case of a developer using construction management techniques where the issues of work coordination responsibility is much more complex.
Our strong preference is for a comprehensive general project management methodology to start with a "conception" phase. This phase, short or long, is the opportunity to assemble the owning organization's needs that could be potential projects, and analyze and select the best opportunity for serious study. This is the time to articulate that best opportunity in terms of big picture, vision and benefit. It should result in a viable business case as the measure of acceptability at each stage-gate.
Following approval of the business case, the project then moves into its second major phase. In this phase the project's concept is developed by studying and testing alternatives and conducting feasibility studies. At the same time, the intended products are identified as far as possible through the necessary customer/user input. With the products identified, an implementation plan can be formulated that covers the project's scope and quality grade, and time and cost tolerances.
The whole can then be assembled into a formal project brief or project charter and presented to management for approval of a major commitment of cash and resources to cover execution. Such a life span design represents a simple straightforward progression with only two major project documents as stage-gate controls. Considering that it is in the conception and definition phases where the most critical project decisions are made, it is surprising that more focus is not given to this part of the project life span. Indeed, as PRINCE2 observes, "A lot of time can be wasted in producing a very good plan to achieve the wrong objective"[41] and "Finding out that a product doesn't meet requirements during its acceptance trials is expensively late."[42]
While on the subject of project life span, there is room for improvement in dealing with the final phase of a project in which the product(s) are transferred into the "care, custody and control" of the customer or user. The product resulting from the project may be excellent and fully up to specification, but if the final transfer is not handled with appropriate delicacy, the reaction to it may still be negative and the project seen as a failure. We use the term "delicacy" advisedly, because this part of the project is often fraught with political overtones. After all, who wants to change the way they normally do business according to some higher management edict?
Clearly, both the front and back ends of the project are fruitful territories for academic research and improved good practice: the front end for better project identification and selection, and the back end for better communication and training in the use of the project's product. If these aspects were properly recognized and documented in standard methodologies, perhaps sponsors would be more willing to set aside the necessary funding to ensure higher chances of project success.
Throughout history, man has successfully trained a variety of animals to become "beasts of burden" to get their goods and themselves from point A to point B. Among many others, classic animals range from the donkey, to the horse to the elephant. At one end of the scale, the donkey seems to be a rather simple and obdurate animal, while at the other the elephant tends to be overkill for anything but really heavy-duty tasks. While it is true that the availability of the selection of animals varies from geographical location to geographical location, nevertheless by far the majority of journeys fall somewhere in the "middle of the bell curve". Hence the horse has become the animal of choice.
And so it seems to us, when presenting project management methodologies for the population at large, it is the middle ground that should be covered. Thus we feel that PRINCE2 could be significantly simplified, not by cutting corners but by analyzing the workflow and asking the legitimate question: "Is this really necessary on the average project?" Then for those who feel the need for "higher ceremony" for reasons of risk, exposure, accountability, audit trail, or what ever, could then refer to suitable appendices offering additional steps and routine to provide the added protection.
Alternatively, perhaps someone could develop a "junior" PRINCE2, even based on
the simplified diagram we displayed earlier in Figure 3.
We also feel that a similar document is needed that is dedicated to the "front end"
phases of project work rather than being buried in the OGC's broader Managing Successful
Programmes manual. After all, these phases are where the major decisions are made,
the decisions upon which the real success of projects, that is the successful delivery
of product benefits, depend.
Always remember that project management is an overhead and, like even the elephant, must justify its existence in terms of product benefits. To be fair, in discussing managing Product Delivery, PRINCE2 does say: "The process needs careful implementation to avoid being over-bureaucratic."[43]
R. Max Wideman
Fellow, PMI
40. Ibid, p228
41. Ibid, p173
42. Ibid, p271
43. Ibid, p127
|
Downside:
Project Management Product Description Documents