Note:

PRINCE is a registered trademark owned by OGC (Office of Government Commerce).

PRINCE2 is an unregistered trademark owned by OGC (Office of Government Commerce).

Published here November 2002.

Introduction | Project Life Cycle | Management Levels | Authority Documentation
Special Project Management Roles | Document Description
Planning and Scheduling | Control | Summary | Endnotes

Summary

PRINCE2 and the Guide take very different approaches to the presentation of their material. Indeed, they really serve different purposes and are therefore not directly comparable. We believe that the Guide takes the best approach for purposes of teaching the subject content of each knowledge area, but it is not so effective when it comes to providing guidance for running a particular project. Of course the corollary is also true. In a life-cycle-based presentation like PRINCE2, it is difficult to do justice to each knowledge area.

For example, as we discussed under planning and scheduling, PRINCE2's approach is a single unified methodology starting from developing the initial product breakdown structure through to identifying the corresponding network schedule. In our view, this straight forward and well-explained proposition should clearly lay to rest the controversies that we have seen in North America. That is, over whether a work breakdown structure should be product or activity based, which comes first, and how they are related.

While PRINCE2 is designed for a variety of customer/supplier situations, the 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 both the organization and the details of control.[57] The implication is that PRINCE2 is in the hands of the supplier rather than the sponsoring organization. The manual as such does not cover the situation of multiple prime contracts (i.e. trade contracts) directly under the control of an owner as is the case, for example, with a developer using construction management techniques. In such cases, the issues of work coordination responsibility is much more complex.

In describing a project, the Guide explains that "Projects are often implemented as a means of achieving an organization's strategic plan" and "Projects are undertaken at all levels of the organization."[58] The Guide is generally written from this perspective throughout, that is to say, from the project owner's perspective rather than from that of a supplier or seller. Consequently, the Guide covers more ground than does PRINCE2.

Nevertheless, within its self-prescribed limitations, PRINCE2 provides a robust easy-to-follow methodology for running most projects, that is, where the objectives are clear and the deliverables are either well described, or capable of being so.

It seems to us that both PRINCE2 and the Guide have chicken-and-egg problems in the area of documentation for project initiation. Our strong preference is for the generic project example 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 stage-gate measure.

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 defined as far as possible through the necessary customer/user input. With the products defined, 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. Such a life cycle design represents a simple straight forward progression with only two major project documents as stage-gate controls. Considering that it is in the conception and definition phases that the most critical project decisions are made, it is surprising that more focus is not given to this part of the project life cycle by both the Guide and PRINCE2. Indeed, as PRINCE2 observes, "A lot of time can be wasted in producing a very good plan to achieve the wrong objective"[59] and "Finding out that a product doesn't meet requirements during its acceptance trials is expensively late."[60]

While on the subject of project life cycle, there is room for improvement in both documents for 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 do things anyway?

Clearly, both the front and back ends of the project are fruitful territories for academic research and improved best practices: 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.

Control  Control

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page