|
Low Risk Project Management
Project Management Basics
 Each Project has Four Phases:
- Preparing for the Project
- Setting up the Project
- Implementing the Project
- After Project Implementation
|
Remember that we are discussing LOW RISK project management here, not zero
risk. By the very nature of project management there will always be uncertainty. These
notes are about reducing uncertainty and not about eliminating it.Every project must have
a deliverable, a delivery date, a budget, acceptance criteria, and a nominated person to
receive it. These five items will enable us to define the objectives of the project and
its business case so that the project may begin with some chance of success. In the same,
way, each of these phases will have a deliverable, a delivery date, a budget, acceptance
criteria and a nominated person. The project should not be allowed to go from one stage
into the next until a formal Risk Assessment has been performed against the deliverables
and plans to achieve them. This Risk Assessment would normally be a formal part of the
Review and Revise process in between phases. The deliverable from the Risk Assessment
would be a data base of risks and the plans to manage each one during the next phase. |
|
Preparing for the project is really setting up the deliverables of the project. So the
deliverable for the preparation phase is really the production of the items listed below.
In setting out the beginning of this phase, delivery date, budget, acceptance criteria and
nominated person will need to be agreed before the phase begins.
During this phase we will define the five items listed for the entire project.:
- A Deliverable,
- Normally this will be the objective of the project i.e. to deliver a new WWW page or a
new accounting system, or even a major banking on line system. This definition of what is
required will be what the project team will use to prepare their project plans and
proposals, so it must be as detailed as possible, and must be something which is either
already accepted by the end user community or which can be sold easily to the end user
community.
Without this defined objective, the project is bound to sink in chaos sooner
or later. It is surprising how many projects cannot produce this statement of what is
required. If there is a Statement of User Requirements it has often been drawn up by a
technician and the users, when pressed, often do not understand it!
|
- A Delivery Date,
- The date that the end result of the project is required.
- A Budget,
- At this time, the best that can be expected is the Business Case for the project. This
will include the costs of the project, the benefits to be accrued, and the way in which
the product of the project will be measured to ensure that the benefits can be achieved.
- Acceptance Criteria, and
- A clear and unambiguous statement of how the receivers of the project will be able to
agree with the Project Manager that the project is completed.
- A Nominated Person to receive it
- Normally this person at this stage will be the Project Sponsor, a senior director or
manager of the user community, with direct access to the management board, who is in a
position to define the requirements and to commit to achieving the savings, as well as to
agree the objectives of the project.
|
- A Deliverable,
- This phase of the project should normally expect to have three deliverables:
- A detailed Work Breakdown Structure and Project Implementation Plan
- A Technical Solution to the Project
- Any Contracts and Documents of Understanding which will define people's commitments.
I call this the Project Fire Triangle, because it is analogous to the triangle used by
the Fire Services, comprising fuel, oxygen, and temperature. If you remove any one of
these the fire will go out, for instance by spraying with an inert gas such as carbon
dioxide and thus depriving the fire of oxygen. |
 |
| In the same way if the three documents are not created to match as one we
get this effect: Naturally, nobody reading these pages is likely to be the kind of
project manager who takes no interest in writing a project plan to implement the technical
solution, or ensuring that the contracts in place support the project plan. |
 |
A Delivery Date,
The date that the three documents described above are to be delivered, and the various
resources required to perform the project are either committed or in place.
A Budget,
The budget for this phase, and also a refining of the budget for the total project.
Acceptance Criteria, and
A clear and unambiguous statement of how the receivers of the project will be able to
agree with the Project Manager that the three documents described are completed and
acceptable, and that the resources required to complete the project are committed.
A Nominated Person to receive it
The Project Sponsor, a senior director or manager of the user community.
This is not a treatise on project management, so I don't propose to say much here;
after all, the work has been done now, and all that remains is a mechanical process!!
Seriously, during the implementation phase all risks must be constantly monitored in
accordance with the risk assessments made earlier. It is also vital to manage the contract
very tightly as the requirements become changed or clarified. The deliverable from this
phase will be the project itself.
During this period, while the experience of the project is fresh in peoples' minds, it
is helpful to hold a structured but non-threatening review of experience gained. Did the
project meet the users' requirements, was it late, did it meet its budget? Where there any
lessons learned which we would like other people in the organisation to benefit from? If
things went wrong, why did they go wrong, and what can we do better next time? In
particular it is important to ensure that the risk assessments are re-visited and that any
problems which had not been anticipated are drawn out and understood for the next project!
 Project
Risk Management Index
Robert Tusler
To discuss the contents of this article, or for advice or information about project
risk management, email us.
 Robert Tusler
is a member of the Alliance of Business Consultants
[RETURN TO TOP]
This Page was created using WebEdit, 4 August
1996
Most recent revision 08 September 1998
|
