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
