|
This paper provides a brief overview of project
management principles and approaches and is intended to introduce core
concepts and terminology to managers and staff who will be involved with a
project. References are provided for those seeking more detailed guidance.
The Business Need
Project management frameworks and methodologies address the need to
meet business objectives on time and within budget. Sound methodologies
draw on the mass of practical experience in project management and
encapsulate best practices. When applied appropriately these methodologies
provide the tools to create a dependable route map that assists those
leading an organisation through a significant change. The skills and
techniques required to manage a project differ from those necessary to
manage business as usual. Adhering to an effective methodology therefore
helps ensure that unfamiliar tasks and responsibilities are understood;
risks are managed and work is focused on business objectives and
priorities.
PRINCE
PRINCE (note 1) is a well-established public domain methodology
that has been widely used . Key features of robust project management
methodologies such as PRINCE are:
Business Case
Projects should be underpinned by the preparation of a clear business
case. The business case sets out the business drivers for the project that
allows all those involved to understand this rationale and to situate
their work in that business context. The business case also evidences the
organisations commitment to the project.
A Structured Approach
Work should be organised into well-defined stages and tasks,
identifying personnel and resources required, the end stage products that
will be delivered and the work that will be undertaken. Dependencies and
timing are also planned so that progress can be tracked against time,
budget and products.
Typically the project plan may need to be revised in light of changing
circumstances, risks that materialise or further information that comes to
light as the project progresses. When situations are identified that are
expected to have a material impact on scope the issue is referred to the
Project Board (see below). This ensures that the project remains focused
on, and justified in relation to, the business benefits. In extreme cases
a decision can be taken to disband the project where appropriate.
Clear Roles & Responsibilities
Key roles and responsibilities should be defined so that all those
involved in the project understand the contribution they are expected to
make and how this relates to other roles. This interim organisational
structure, which is distinct from the organisation applying for business
as usual, is established for the duration of the project and disbanded at
the end of the project. The roles include:
Project Board. The project board is responsible for the ultimate
outcome of the project. At the outset it approves the project scope. It
also approves products delivered at the end of each stage (it may
delegate product assurance as appropriate) and authorises the launch of
subsequent stages. This provides the primary means for the project board
to ensure that the project remains on track. The project manager
periodically reports project progress to the project board. The board is
responsible for resolving material issues impacting project scope (cost,
delivery date, end products, staffing, other resources) brought to its
attention by the project manager.
Project Manager. The project manager is responsible for planning
(what will be done) and scheduling (when it will be done and by who),
tracking progress and monitoring budgets. The project manager takes
day-to-day operational decisions but remains accountable to the project
board. The project manager refers matters that will materially impact
the scope of the project (products, completion date, cost or personnel)
to the project board for resolution.
Executive. The Executive (or customer) is the person who
commissions and authorises the project. The executive is a member of the
project board.
User. The User is the person who will use the result of the
project. A User representative is a member of the project board.
Supplier. The Supplier (or specialist) provides the expertise
necessary to do the work. The Supplier is represented on the on the
project board.
Task Manager. The Task Manager is responsible for managing a
particular task assigned to him. The Task Manager reports to the project
manager in respect of the relevant task.
Risk Management
Risks should be explicitly identified and managed. The risk management
process is continuous and begins with project initiation. Significant
risks and changes in risks should be reported to the project board.
Meetings
Formal project board meetings should be linked to key events:
Project Initiation at which the project initiation document is
approved (see below)
End Stage Assessments at which the products delivered for that
stage are approved. (Products are quality assured against previously
agreed specifications).
Project Closure.
The project manager also conducts checkpoint reviews with project
personnel to monitor progress. These form the basis for periodic Highlight
Reports issued to inform the project board of progress.
Project Initiation Document
At the outset a project initiation document (PID) should define the
project. It will include:
a project description
the business case
the project organisation
the initial project plan
Skills, Knowledge & Abilities
A proven project management methodology can provide the tools to
prepare a route map but a successful project depends on assigning staff
with the appropriate skills, knowledge and abilities to plan and perform
the work. A sound plan cannot compensate for deploying staff that do not
have the requisite business and technical knowledge.
References
For further information on project management and PRINCE see:
Managing Successful Projects using PRINCE 2, published by the
Stationery Office
PRINCE 2: A Practical Handbook, Colin Bentley, published by
Butterworth-Heinemann UK
Practical PRINCE 2 (forthcoming 2002), Colin Bentley, published by
the Stationery Office
Appendix Key Documents
The following key documents or equivalents will be used on most
projects (this list follows PRINCE terminology):
Business Case - setting out the business rationale for the project
Project Initiation Document - defining the scope and organisation
of the project, it forms the basis for managing the project.
Project Plan defining stages, identifying personnel and resources
required, and the work that will be undertaken and dependencies between
tasks and stages.
Issue Log tracking significant issues
Highlight Report giving a periodic snapshot of project status
Product Description used to check actual products delivered meet
the previously defined criteria
Request for Change used to control scope change
Risk Log tracking significant risks and risk management activity
End Stage Report issued to the project board at the end of a
stage
Work Package defining discrete parcels of work to be completed
End Project Report concluding a project
Endnotes
(1) PRINCE (Projects in Controlled Environments) was developed for IT
project management by the UK Government Central Computer and
Telecommunications Agency (CCTA) in 1989. It has subsequently been
improved and expanded in the light of practical experience to provide an
approach for the management of all types of projects. The current version,
PRINCE2, was developed in 1996. PRINCE is a registered trademark of CCTA
|
