Contents

 Some fundamentals 1
Building on a sound BASE 2
Virtual structures 3
Balancing the role - Adair's model 3

 The project process 6

Feasibility study 7

 Project initiation 8
Identifying and managing risk 9

 Project definition 12

 Planning 13
The activity planning process 14
Deliverable breakdown structure 15
Planning tools 16
Network diagrams 17
The critical path 18
Gantt charts 19
Estimating 20

 Implementation 21
Change control 21
Milestone management 23
Reviewing 24
Chairing an effective review meeting 25
Participating in effective meetings 25

 Project closure 27



V6.1 May08
Contents |
 Some fundamentals

 What is a project?
Not everything in life is a project; some things are processes. But if we can recognise those
things that are projects, we can apply a project approach, and thereby maximise our chances of
success.
How do we define a project? Typically, it is something that has most, if not all, of the following
characteristics:
 An identifiable deliverable
 Boundaries of time, cost and quality
 A finite timescale – a start and a finish
 A one-off finite existence
 Involvement of several people, often on an ad-hoc basis
 A limited set of resources
 Delivers business benefits to the organisation

 What is project management?

Project management is the application of knowledge, skills, tools and techniques to meet
project requirements



V6.1 May 08
Project management- | 1
 Building on a sound BASE

 Ensuring a sound start

When building a house, or anything of substance, it is important to lay sound foundations.
A project, similarly, has to be built on a strong base if it is to be robust, and able to withstand the
inevitable knocks it will encounter in its lifetime. It is important, therefore, to ensure that there
is a solid base.
What is this BASE?

Time
B

S
B A S E

E Cost Quality

The ‘Project Triangle’ needs to stand on its base.

Determine in advance:
 Who exactly are the stakeholders that you will have to satisfy?
 What are their relative priorities of time, cost and quality?
 Have you got clear and unequivocal authority to get things done?
 How will the progress and the final deliverable be evaluated?

Ensure that you have a solid BASE before you accept responsibility for the project.



V6.1 May 08
Project management- | 2
 Virtual structures

 The ‘ideal’
Stakeholders, Sponsor
Project Board Steering Committee

One person, with

Project Manager authority delegated
from the Project Board

Team Member * Team Member * Team Member * Team Member * Team Member * Visible Project Team

‘Invisible’ Team
A B C D (departmental staff)

* May be internal or external staff

The success of a project frequently depends upon the ability of the Project Manager to play a full
part in the two groups that they are linked with - The Project Board and the Project Team. The
Project Manager has a core responsibility to represent the work of each one to the other - and
ensure that there are no surprises either way!

 Some issues
Senior Manager

Other
Project Manager
Line Managers

Direct Team Indirect Team

Exercise control Exercise influence

In virtual teams, the project manager may have some people dedicated to the project, but will
also frequently have to work through indirect team members who report to their own line
manager. In this case, the project manager may have to work through influence and persuasion
rather than direct control.

Balancing the role - Adair's model



V6.1 May 08
Project management- | 3
In virtually every management situation there are three basic elements:

Area of Maximum
Performance

Task

Team Individuals

 The needs of the activity

 The needs of the team
 The needs of the individual

Often these needs are in conflict. The temptation sometimes is to let the short term needs of
one element overshadow the others, but often this produces a backlash later which disrupts all
three elements.
The effective project manager will keep the three elements in mind at all times, especially when
planning, and will assess the priorities for each situation and act accordingly.
The three needs will seldom coincide, but having them overlapping as much as possible will
produce better results from the team.
In fact, the effectiveness of the project manager is judged by the extent to which each individual
knows their part in the team to deliver the activity.



V6.1 May 08
Project management- | 4
 Keeping the balance
The project manager will need to carry out activities in each of the three areas.

Task activities

Defining the project fully

Building the project plan

Identify resources, people process, systems

Time

B A S E

Establish responsibilities and

Cost Quality

accountabilities
Checking performance against plan

Review assess and replace as required

Change control

Risk management

Team activities Individual activities

Build and develop the team Develop freedom to act and
Task
authority
Common purpose/targets
Defining roles/responsibilities
Agree and communicate
project structures Setting objectives for the roles
Team Individual
Agree ways of working Motivating individuals to achieve
behaviour Regular updates in progress
Create positive team spirit, Support individuals/help reach
develop team working potential
Team deals openly with Give recognition
problems
Understand team markers, skills,
Give feedback on progress strengths and weaknesses
Train and develop team members



V6.1 May 08
Project management- | 5
The project process

Feasibility study / Pre-project work

Initiation

Time
Risk Analysis
Definition
Planning
Change
Control Implementation

Closure


 V6.1 May 08
Project management- | 6
 Feasibility study

In certain situations a feasibility study may be required to investigate a problem or an idea and
propose one or a selection of options as the way forward. Current thinking dictates that this is
handled as a separate project. The outcome of the feasibility project would be used to drive a
second project.
At this stage the expenditure has been low, and a formal assessment will enable the project to
be properly resourced or aborted, depending on just how viable the solution is.
The feasibility study examines three key criteria:
 Strategic – does the proposed project fit with company or departmental goals?
 Commercial – is the project financially viable?
 Technical – is the proposed solution technically feasible?

If the answer to any of these questions is unsatisfactory, there is a chance to terminate the
project before any appreciable costs have been incurred.
The minimum outcome of any feasibility project will be:
 Initial business case
 Outline scope
 Risk assessment
 Outline project plan
These documents would be used as input to a second project that will deliver the solution.
A feasibility study process would include:
 Problem definition
 Investigation stage
 Creation of options
 Recommendations



V6.2 May 08
Project management |7
 Project initiation

 Introduction
Project Initiation is the first phase of the project process and ensures that the pre-requisites for
starting a project are in place. The phase expects that a certain amount of high-level work would
be completed. This would be:
 Initial business case
 Outline scope
 Risk assessment
 Outline project plan

The two major outputs from this phase are the Project Organisation Structure (POS) and the
outline Project Definition Document (PDD).
The POS is based on the three level model described in the previous section. This can easily be
created as an organagram and circulated to all new project team members.
The PDD is a key Project Management document as it describes why we are doing the project
and what needs to be delivered. Suggested sections are as follows:
 Introduction and background to the project
 Outline business case
 Project boundaries
 The objectives and scope - what is to be done
 Outline project deliverables
 What is excluded from the project
 Known Constraints
 Evaluation of success criteria
 RAIDC Spreadsheet (Risks, Actions, Issues, Decisions and Changes)
 Any customer quality requirements
 Outline plan

There may well be industry sector specific sections that are added to the Project Definition
Document that come under the following headings:
 Health and Safety
 Environmental

In reality the project should move quickly through this phase.



V6.2 May 08
Project management |8
 Identifying and managing risk

Risk is any threat or potential occurrence which may prevent the project from achieving its
business objectives. It may affect time, cost or quality. All projects face risk to some extent, but
clearly risk will vary from project to project.
Risk should be addressed as early in the project as possible. This should be done in a systematic
way and then managed through the life of the project. We would recommend the compilation
of a risk log that is monitored regularly throughout the project. Two types of risk are always
present in almost all projects
Project risk – associated with the technical aspects of the work to achieve the desired project
outcomes.

Process risk – associated with the project process, procedures, tools and techniques used,
communication, stakeholders and team performance.

Any risk that occurs then becomes a project issue, and must be dealt with appropriately.

 The risk management process

 Identify risks
This should be done with the core project team, by brainstorming, or by using checklists and
previous experience. Include those risks that are under the control of the project team as
well as those largely outside the control of the team.
 Assessment of the risk
Go through each risk in turn, assessing
a) the probability of the risk occurring.
b) the impact of the risk on the project.
 Categorise
Use a risk matrix to determine the ‘risk category’.

High
Medium High Critical
Probability
Increasing

Low Medium High

Low
Insignificant Low Medium

Low High
Increasing Impact



V6.2 May 08
Project management |9
Critical – is likely to have a catastrophic affect on the project schedule/costs and is likely to
affect project milestones especially the project end-date. Actions must be put in place to deal
with these and must be monitored regularly and carefully. The affect on the project may be
terminal.
High – is likely to have a major impact on the project schedule/costs and is likely to affect
project milestones. Actions must be put in place to deal with these and must be monitored
regularly and carefully.
Medium – is likely to have a significant impact on the project but is not expected to impact on
the achievement of project milestones. To be reviewed regularly at project review meetings etc.
Low – not expected to have any serious impact on the project. Review regularly for category and
monitor.
Insignificant – has very little or no impact on the project.

 Take action
When dealing with risk you may need to address both the cause of the risk and the effect it
has on the project depending upon its seriousness and impact on the project.
The actions taken can be described in 5 categories. The acronym RATPC describes the
categories:
Reduce: the action plans in place either reduce the impact, the probability or both.
Accept: let the risk happen, because the impact and the probability are both acceptable.
Transfer: the risk is transferred to a third party.
Prevent: remove the risk so that there is no likelihood of it occurring or that there is no
impact.
Contingency: a set of actions in place to that are set to happen if the risk occurs.
Ignoring the risk is not an option!

 Monitor and manage risk

As the project rolls out you need to track risk. Some risks will become more significant
others will diminish.
By managing risk in this way, you are more likely to deal with problems early and be able to
resolve them in an effective manner.



V6.2 May 08
Project management | 10
 Documenting risk – the risk log
The risk log provides a repository for all information concerning individual risks. The log lists all
the risks identified during the project and subsequently should be monitored and updated on a
regular basis.
A risk log would contain some or all of the following information:
 Risk Number: a unique identifier
 Description of Risk
 Probability: probability of the risk occurring
 Impact: impact on the project if the risk occurs
 Category (RATPC)
 Timing: identifies when the project risk is likely to occur
 Triggers: identifies those events that will indicate that the risk is about to happen
 Proposed Actions: actions in place to deal with the risk
 Risk Owner: owner of the risk
 Current Status: status i.e. live, increasing, reducing, dead.

 Contingency
Contingency is included in a project to take into account the unexpected – unidentified risks.
Contingency often takes the form of a pot of money or time that is set to one side in case it is
required.
The contingency provision is typically under the control of the Project Manager but agreed with
the Project Board. The Project Manager authorises the use of the contingency resource used by
the project team. The contingency should be clearly shown on the project plan, where it is
needed.
The amount of contingency required should reflect the degree of risk associated
with an activity, a group of activities or achieving a milestone.
Some typical contingency values might be:
Zero risk = zero contingency
Low = 5 – 7%
Medium = 10 – 15%
High = 15 – 25%



V6.2 May 08
Project management | 11
 Project definition

Project Definition phase is where the Project Manager and Project Board confirm their
understanding of:
 Why the project needs to be completed
 What has to be achieved

This will take the form of a written “contract” between the Project Board and the Project
Manager.

The output will be an enhanced Business case and Project Definition Document (PDD).
The Business Case will contain updated reasons for “Why the project needs to be completed”
including financial information if appropriate.
The PDD will contain the following elements:
 Introduction and background to the project
 Final business case
 Project boundaries
 The final objectives and final scope - what is to be done
 Final project deliverables
 What is excluded from the project
 Known Constraints
 Evaluation of success criteria
 RAIDC Spreadsheet (Risk, Actions, Issues, Decisions and Changes)
 Any customer quality requirements
 Project plan.

Although the term final is used there is no implication of “no changes”. Any changes to these
documents must be changed in a controlled way. See change control.

During the Initiation phase there will be a danger of information overload, therefore this phase
will be a series of iterations and will involve the Project Manager having regular review meetings
with the Project Board and team members.



V6.2 May 08
Project management | 12
 Planning

 Introduction to planning
Planning is the most important step in the whole project. It is vital that this phase is done well.
A plan is the backbone of every project; it is one of the key documents that cover all aspects of
the project. Planning is a process that enables the Project Manager and their team to:
 To define clearly what deliverables are required
 Provide activity plans on how the deliverables will be delivered
 Provide resources for the required activities
 To think ahead and predict risks and issues
 Monitor progress against plan

It is important that your plan is a robust one, but it must be “fit for purpose” so that team
members of the project team use it to execute, monitor and control the project.
There may up to three levels of plans within a project:
 A Project Plan that illustrates the overall project
 A Milestone Plan that details the work required to deliver the next deliverable or achieve the
next milestone
 Team Plans that are for the individual teams within the project team

The ability to plan in a flexible and creative manner is the key to achieving substantial gains in
performance and control over time. The greater the number of activities which need to mesh,
the greater the need for effective planning
Planning need not be onerous or restricting. Indeed, it must be flexible to be successful. Plan
and control what you can, and allow time to handle the unexpected.

 Principles of planning
 A plan will always change
 A plan is only as good as the information available at that point in time
 The plan is nothing – planning is everything
 A plan is only as good as the identified assumptions attached
 It’s wise to plan, but foolish to look further than you can see.



V6.2 May 08
Project management | 13
 The activity planning process

 Step by step approach

Use MS PowerPoint or
Create a Deliverable Breakdown other drawing tool
Structure

Use a random
brainstorming technique to
List all the Activities collect ideas, then evaluate
whether or not they are
required

Ensure that all activities are

Determine Dependencies linked

Use MS Project or Post-its

Draw a Network Diagram and a whiteboard

Based on appropriate
Add Time Estimates resources

Identify the Critical Path

Critical Path

Use MS Project or Excel

Create a Gantt Chart Gantt Chart



V6.2 May 08
Project management | 14
 Deliverable breakdown structure

This is designed to identify the components that make up the project deliverables. It does not
show how much work is involved, or who will do the work, but it is an important checklist of all
that has to be done.
If the project deliverable is building of a new shed, the DBS might look something like:

New shed

Requirements New shed

Old shed built
dismantled for new shed

Shed Fixtures and Site New Shed

Shed Shed Design fittings prepared shed Completed
dismantled pieces requirements delivered
removed
Electricity cabling Shed ordered
plan

Shed Fixtures Electricity

assembled and connected
fittings
added

These are the deliverables of the new shed.



V6.2 May 08
Project management | 15
 Planning tools

 Gantt charts and network analysis

Professional project planning normally uses two types of chart representation: Gantt charts and
network diagrams. Gantt charts are accredited to a Frenchman, Henri L Gantt.
Network analysis is the generic term for the techniques that evolved in the United States during
the Fifties and Sixties. Techniques such as critical path analysis (CPA), project evaluation review
technique (PERT), method of potentials and precedence diagrams came from around that time.
The ideas behind them all are basically the same.
Most people are familiar with Gantt charts as a pictorial representation of the time-lines and
milestones in a project. They are generally simple and bold, and are the best tool for monitoring
and controlling the project and communicating what needs to be done with the team.
However, for thinking through the logic and understanding the relationships between activities -
Network Analysis is a valuable first step before constructing the Gantt charts.

 Comparing the Gantt chart with the network diagram

Gantt Chart Network Diagram

1. Clearly shows duration of activities Does not show duration of activities

against calendar time. against calendar time.
2. Clearly shows work breakdown structure. Does not show work breakdown
structure.
3. Does not easily show dependencies. Clearly shows dependencies.
4 Difficult to identify the critical path. Easy to calculate the critical path.

As can be seen, both Gantt charts and network diagrams have their place in planning. In reality,
with the increasing use and sophistication of software tools, Gantt charts do show logic, and
network diagrams are plotted against a calendar time. But if the software does not allow this,
we need both.



V6.2 May 08
Project management | 16
 Network diagrams

 Method of potentials
There are two main parts to a diagram, the box and the line. The box represents the activity and
all its relevant information and the line links the boxes to show the flow of the logic. The flow is
from left to right. To describe an activity we draw a box with a number of compartments. A
simplified form of the notation is shown below:

Earliest Latest Start

Start Time
Time

Activity Activity
Activ
Name ity
Number

Total
Duration
Float

 Earliest start time (EST) : The earliest time the activity can start
 Latest start time (LST) : The latest time the activity can start
 Activity description : The name given to the activity
 Activity duration (D) : Estimate of how long the activity will take
 Activity number: Unique number for the activity, i.e. 100 or 200. They are used for
reference purposes so that an activity can be described without ambiguity
 Total Float (F): The total amount of time by which an activity may be delayed or extended
without affecting the end date of the project.



V6.2 May 08
Project management | 17
 The critical path

 Using network diagrams

Let us look at a network, showing the concept of the critical path.

5 5 12 12 15 15
G H I
7 0 3 0 5 0

0 0 0 0 1 1 5 12 7 14 12 19 20 20
Start A B L M O Finish
0 0 11 0 14 0 2 7 5 7 1 7 0 0

We have included a start and end activities that act as milestones. They are particularly useful
for merging paths at the end of the project.
Being able to identify the critical path - and then anticipating any problems with it - is the secret
of meeting timescales.
Some definitions of the critical path are:
 The path of zero float or slack
 The path where LST = EST
 The sequence of activities which determines the total time for a project
 The longest sequence of irreducible activities
 The critical path of the above diagram is activity start, A, B, G, H, I, Finish.



V6.2 May 08
Project management | 18
 Gantt charts

Gantt charts are very useful and effective tools for controlling projects, spotting deviations and
problems, sharing information with the team and reporting progress.
In principle they are simple to construct and can capture a great deal of information about the
project plan. A Gantt chart gives a very effective overview and perspective of the whole project
and enables everyone to see the dependencies and sequence of activities.
A Gantt chart has three basic parts:
 A timeline
 Activity breakdown
 A Gantt for each activity, the length of which represents the time estimated as necessary for
the activity

A Gantt chart may also be used to schedule resources, such as personnel, equipment or budget.
This can help avoid over-scheduling of people or equipment, particularly where these may be
employed on a number of projects.
A typical top level chart may look something like this:

January February March April

Initiation

Definition

Planning

Implementation

Close-out

Although it is possible to show dependencies on a Gantt chart, this can become complicated,
and a network diagram is a better tool to use. Identifying the dependencies, then controlling
and managing them successfully is critical to project success.



V6.2 May 08
Project management | 19
 Estimating

By their nature projects are very difficult to estimate. There is often uniqueness about them. If
the actual time and cost do coincide with the original estimates, it is often more by luck than
judgement. But a rough estimate is infinitely better than no estimate at all, because it provides
something to work towards and encourages motivation.
In practice, changes in the composition of the project team or enlargement of the project scope
can quickly invalidate the estimate, but it is nevertheless vital to have something to work from.

 Why estimate?
 It provides a basis for control, so that actual progress can be monitored
 It gives focus and motivation to the project team
 It enables resourcing requirements to be assessed at functional and departmental levels
 Early estimates enable the overall viability of the project to be assessed
 Without estimates, it is difficult to see when the project is going out of control on either time
or cost.

 Rules of estimating
 Be absolutely sure you understand what work is involved before estimating.
 Involve other members of the team. Two heads are better than one.
 Use historical data where it is available.
 Be pessimistic rather than optimistic.
 Narrow down the estimates as the project progresses.
 Contingency should reflect the degree of risk.

The PERT formula is a useful way of structuring your thinking

to+3tm+2tp
te =
6

te= Estimate, to= Optimistic, tm= most likely, tp = most pessimistic



V6.2 May 08
Project management | 20
 Implementation

 Managing progress
Once a project is under way there is still a lot you can do to ensure that the project delivers.
Monitoring progress is the process of measuring whether activities conform to the project plan.
To manage and monitor the progress:
 Monitor the start and end times of activities and what they have delivered. Always speak to
the person responsible for the work. Talk in terms of “time spent so far and “time to
complete”.
 Avoid unnecessary scope creep (see change control)
 Regularly review plans against risks Monitor the critical path
 Keep the Project board and other stakeholders informed
 Keep the team informed

 Reporting
Project managers need reporting systems that are time-sensitive and communicate the project's
current and future positions to the project board, the direct team and the indirect team.

 Monitoring progress process

A project manager must evaluate information available and then decide a course of action to
remain in control.
1. Collect and collate information from previous week
2. Compare actual data with the plan
3. Diagnose variance from plan (plus and minus, cost and time)
4. Formulate plan for corrective action, including escalation to project board if necessary
5. Implement planned action

The project manager must keep asking the following questions:

 Is the project within agreed budget?
 Is the project within agreed timescales?
 Is the project within agreed quality limits?

Change control



V6.2 May 08
Project management | 21
 Introduction
Changes to scope will happen during the life of the project, they should not be unexpected.
When changes occur, they usually fall into one of two categories. Either they are raised by the
customer or by the project team. There are three important questions that need to be answered
before the change is actioned:
 Who pays for the change and do they agree to pay?
 What is the timescale of the change?
 What is the impact of the change on the end date of the project?

The answer to these questions will determine whether the change goes ahead or not. The
change to scope can only be agreed by the Project Board.
The important point to remember is that the change must be processed in a controlled way.

 Change control process

A simple change control process is as follows:
 Requester raises change control documentation detailing change
 Project manager analyses change - working out cost, time and impact on the project
 Project board signs-off or rejects change
 Project manager actions change
 For larger projects the process may be longer

The main rule is that every project must have a change control process which must be used.



V6.2 May 08
Project management | 22
 Milestone management

Each Gantt on the Gantt chart should have some kind of deliverable or milestone that tells you
whether or not you have completed that activity.
The project manager will need to keep a sharp eye on these milestones to ensure that the
project is not going off track.
The stakeholders, too, will want to feel assured that things are progressing according to plan,
but they are unlikely to want to see a regular Gantt chart. Instead, they may require some kind of
simplified table that will enable them to stay in the picture, and alert them if things need
attention.
The format of this will be a cultural thing in line with the style of management and the type of
organisation, but a simple milestone management document will have some core information
along the lines of the example below.

Activity
Number What When Who Dependencies Status

Green; project on track to deliver next milestone and project end date
Orange; next project on track to miss next milestone but to deliver project end date
Red; project on track to miss next milestone and miss project end date



V6.2 May 08
Project management | 23
 Reviewing

 Introduction
Although the project manager should review progress on a daily basis, it is important to hold
formal reviews with the team. These can take the form of 15 minute one-to-one’s through to
formal meetings with the project board.

 Review meetings
Review meetings are an important part of the communication process. The purpose of the
review is to examine whether the process is working, as well as checking progress on the
activity. The former aspect is often omitted, to everyone’s cost.
Reviewing before implementation enables everyone to be clear on their role and the deliverables
before getting too far into the project. Review during implementation gives an opportunity to
check progress and process. What’s going well? What’s going badly?
The project board may request monthly meetings to review the progress of the project so far.
The meetings should follow a pre-determined agenda.
Never treat review meetings lightly. Team motivation and morale can suffer through not
knowing what's going on, so be wary of cancellation without good cause. All types of review
meetings can be moved rather than clash with project milestones.
Typical process elements for review may include:
 How appropriate are the project plan and budget?
 How appropriate is the strategy for achieving the project objectives?
 How suitable are the project structure and reporting relationships for the activity?
 How clearly defined are the project roles and responsibilities?
 How effective are the IT systems in helping the project team?
 How effective are the project communications and control procedures?



V6.2 May 08
Project management | 24
 Chairing an effective review meeting

 Best practice
1. Be clear on the purpose and desired outcome, and build an agenda before the meeting.
Short meetings with limited number of agenda items for discussion are better.

2. Begin the meeting precisely on time.

3. Establish timings and stick to them. Clarify any rules about the leadership of the meeting,
speaking time, etc. Handle the rules consistently, impartially, firmly and diplomatically.

4. Define the subjects for discussion and request concise, relevant comments.

5. Always explain why a subject is being taken up for discussion; whether to inform, gather
points of view, develop ideas, solve problems or reach a decision. Not all matters justify
discussion; some can be taken for information only.

6. Encourage everyone to contribute. Allocate each participant a turn to speak in the order
that they can make their requests.

7. Stop repetition.

8. Summarise the discussion as it proceeds and draw conclusions.

9. Never leave a topic without a conclusion:

 What should happen?
 What has been achieved?
 When it should happen
 Who is responsible?

10. Make sure that everyone has understood the conclusions properly, and that they are clear to
the person taking the minutes or actions.

11. Finish the meeting on time, or preferably before.

12. If the meeting lasts more than one hour, have a break.

Participating in effective meetings



V6.2 May 08
Project management | 25
 Best practice
1. Ensure that you turn up on time.

2. Don’t book back to back meetings in your diary

3. Ask for an agenda before you attend.

4. If you are asked to give a presentation, find out what is expected of you and for how long
you are expected to speak.

5. Start by thinking what you want to achieve and what you want to say.

6. Make sure you are concise and to the point.

7. Always be positive. Being negative builds barriers.

8. Make notes on your actions, be clear that you understand what you have to do and by
when.

9. Don’t interrupt another speaker.

10. Listen to what is being said.

11. Clarify what has been said if you don’t understand.



V6.2 May 08
Project management | 26
 Project closure

One of the key definitions of a project is its finite timescale. If the start and end become vague
the project and the techniques used can lose their effectiveness over operational management.
A clear end stops the project from drifting into operational use and is recognition that the
project is complete.

 Customer acceptance
 Ensure that the acceptance criteria have been met and receive the customer’s acceptance of
this.
 Ensure that processes and procedures are in place for support of the deliverables
 Identify any follow up actions

 Post project review

 An important part of any project is the review process that takes place after the project has
been completed. The review takes the form of a meeting. The following questions can form
the content of any agenda:
 Have the project goals been achieved on time, on cost and on quality?
 What improvements could be made in the way we worked?
 What major problems occurred during the project and how could they have been avoided?
 What are the learning points from the project?
 What changes need to be made to our company procedures or processes?
 What did we do really well that we should try to do again?
The review should not be a witch hunt, but an objective review of how well the project team
achieved its goals and objectives. It can sometimes be helpful to have post project reviews
conducted by people who have had no previous involvement in the project, in order to offer
objective views, but it is important that they build trust and rapport and are regarded as an asset
rather than as inquisitors or examiners.

 Project audit
A project audit is different from a post project review in that it takes place at least a year after
the completion of a project and is usually associated with larger projects. Project audits examine
whether the project has achieved the goals and objectives that were set out in the project
definition. These areas include:
 Technical performance
 Financial return in comparison with the original business case for starting the project.



V6.2 May 08
Project management | 27