|
The conventional structure of projects
typically starts with some kind of initiation stage. A proposal for a
project is reviewed formally, or informally. Approval is given for the proposed approach and
the allocation of funding, resources or whatever else is needed. The
formality or informality of this and the subsequent stages will of course
vary enormously depending upon the scale of the project, the size of the foreseen costs,
the management norms of the organisation and so on.
The
initiation and approval stages are followed by a series of project stages. Typically, the stages
are
defined in a sequence such as Requirements Analysis, Design, Build/Construction, Test, Implementation or Deployment,
and project closure. In actuality, the neatly defined stages may well meld
into each other which will injure the manageability of the project. There
are good reasons for why the 'melding' happens, which we'll discuss
elsewhere.
In the case of PRINCE2, ongoing maintenance or
support of what has been implemented is
outside the scope of the project. Depending on the methodology, there may then be
the 'retirement' stage in which whatever has been implemented is deemed no
longer serving its purpose in some way and is decommissioned.
In the case of systems projects, the implemented system is labelled a
'legacy system' - although it's not entirely certain this is yet a formally
recognised stage in structured project methods! However, 'legacy system' is useful shorthand for the round of proposals which will
advocate replacement of those systems in the not-too-distant future.
There may be
formal reviews or 'gateways'
between some or all stages. The intention is that the completeness or
success of each stage is reviewed by senior stakeholders - folk with an
interest in the outcome of the project. The idea is that their approval is
needed before further funding and other resources are consumed in the next stages. In theory, there are several
further options
available to the reviewers. Those options include; directing that rework is
done to achieve the expected requirements of the current stage, redirect the project
in some other way (such as change its objectives) or decide the project is not
viable and declare its termination.
The Problems with Conventional Project Structure Models
Many organisations will have experienced
serious problems in delivering useful outcomes and results when using
conventional project management methods. Our discussion here refers
primarily to the use of those conventional methods in projects concerned with
change management, business performance improvement, systems implementation and system
development. These are the kind of complex projects we characterise as
essentially learning-processes (related article).
The emphasis in conventional
project methods is on tasks, activities and products. Many of those tasks will be
concerned with generating documentation deliverables known as 'management
products'. Progress tends to be measured in terms of completed products, completed tasks or
review stages passed. In effect, project structures place the emphasis upon
'doing stuff' or 'busy-ness'. Although many people in organisations will feel
that their job security depends upon looking busy - and their perception is probably accurate - we
argue that this emphasis on 'doing stuff' is misplaced.
In our view, the emphasis
should more valuably be placed upon delivering useful, practical, improved
performance results which directly contribute to the achievement of the real objectives of the organisation. Few would argue with that. Many
would agree with it, but go straight back to structuring their projects in
the conventional way. They do that because of a mistaken belief that the
conventional methods share their aim of achieving results. They don't. The
aim of conventional methods is simply to follow a defined process (related
article) in order to deliver a product or 'solution' of some kind;
that's
distinctly different from
the improved performance wanted by the organisation.
Whilst we do not contend that all project
problems can be laid at the door of these kind of methodologies, we do
contend that it is time to question the faith placed in them, and to
acknowledge that there are serious underlying structural problems to PRINCE2 and related methodologies.
Those shortcomings mean that for many
organisations wishing to achieve earlier practical results, at lower cost
and in shorter time scales, PRINCE2 will not be an appropriate choice.
Our analysis shows that they
(eg. PRINCE2) will
generally increase project costs and lead to lengthy phases (each of many
months) during which costs accrue and
resources are consumed without benefit to the wider organisation.
|
