ENGN3221

(PROJECT & OPERATIONS MANAGEMENT)

Module 1 - PROJECT MANAGEMENT

CONTENTS
1.0 Introduction ............................................................................ 1-1
2.0 What is a Project? ....................................................................... 1-1
2.1 Project Characteristics ..................................................... 1-2
3.0 Project Management Stages ........................................................ 1-3
4.0 Project Proposal and Initiation ................................................... 1-3
4.1 Non-Numeric Models for Project Selection ..................... 1-4
4.2 Numeric Models for Project Selection ............................. 1-5
4.3 The models - Fact or Fiction? .......................................... 1-6
4.4 Risk Analysis ................................................................... 1-6
4.5 The Proposal ................................................................... 1-6
5.0 Project Organisation ................................................................... 1-7
5.1 Functional Structure ...................................................... 1-7
5.2 Project Structure ............................................................ 1-8
5.3 Matrix Structure ............................................................. 1-9
5.4 Mixed Structure ............................................................. 1-9
5.5 The Project Team ............................................................ 1-9
5.6 The Role of the Project Manager ..................................... 1-10
6.0 The Project Plan ......................................................................... 1-11
6.1 Project Analysis and Design ........................................... 1-11
6.2 Work Breakdown Structure (WBS) ................................. 1-12
7.0 Scheduling ............................................................................ 1.15
7.1 Networks ........................................................................ 1-15
7.2 Constructing an AoA Network ....................................... 1-16
7.3 Calculating Activity Times ............................................. 1-18
7.4 Critical Path and Time ................................................... 1-20
7.5 Float (Slack) ................................................................... 1-20
7.6 Gantt Charts ................................................................. 1-21
8.0 Resource Management ................................................................ 1-23
8.1 Critical Path Method (CPM) .......................................... 1-23
8.2 Resource Loading ............................................................ 1-25
8.3 Resource Levelling .......................................................... 1-26
9.0 Project Monitoring for Control .................................................. 1-28
9.1 The Monitoring Process .................................................. 1-28
9.1.1 Response Time ..................................................... 1-28
9.1.2 What Information Should Be Collected ............... 1-28
9.1.3 Data Collection ................................................... 1-29
9.2 Feedback (Reporting) .......................................................... 1-30
9.3 Monitoring Overall Project Performance ............................. 1-30
10.0 Risk Management ....................................................................... 1-31
10.1 Risk in relation to Project Completion .............................. 1-32
10.2 Five steps in Risk Management .......................................... 1-33
10.2.1 Identifying the Risks ......................................... 1-33
10.2.2 The Impact of Risk ............................................ 1-33
10.2.3 Reducing the Risk ............................................. 1-35
11.0 Project Termination .................................................................... 1-35
12.0 Project Report ............................................................................ 1-36
 ENGN3221

(PROJECT & OPERATIONS MANAGEMENT)

Module 1 - PROJECT MANAGEMENT

(Chapter 16 – Operations Management, Heizer and Render)

1.0 Introduction
Project Management is a relatively new discipline, generally traced to the Manhattan project (development of the
atomic bomb). Initially it was used for complex Research and Development (R&D) projects (mainly in the defence
field), such as the ICBM (Polaris) program. Today, project-based management is used in all branches, and at all
levels, of business and industry - from major projects in the heavy engineering industries such as defence,
shipbuilding, construction and energy, to the IT related products and services.

2.0 What is a Project?

Operations Management and Project Management have very similar core features. They both involve the
management of a variety of resources; both are subject to mixed objectives and conflicting priorities; both create
change and both generally involve people from throughout an organisation. The one parameter which distinguishes
a project from an operation is the uniqueness of the project.

While it is perhaps overemphasised, this aspect is summed up in the following definition of a project:

“a one-time, unique endeavour by people to do something that has not been done that way before.” 1

Project Management, then, is the process by which a project is brought to a successful conclusion.

Operations Management, on the other hand, “is the process of transforming inputs into useful outputs and thereby
adding value to some entity; ....2

The basic purpose of initiating a project is to accomplish some goals. By structuring the tasks to be done as a project
allows the responsibility and authority for the attainment of that goal to be focused on an individual or small group.
This focus allows the project manager to be responsive to changes in the goal or variations in the tasks that may
impact on achieving the goal. It allows better control of resources and better customer relations and stops side
tracking of tasks. Setting up and managing a project is not without some down sides. There will be competition for
resources between projects and ongoing operations leading to potential conflict. How well these issues are managed
to achieve a successful project is the measure of a good project manager.

1
Smith, B., 1985 “Project concepts”, in Effective Project Administration, Institution of Mechanical Engineers.
2
Meredith, Jack R, 1992, “The Management of Operations: A Conceptual Emphasis”, 4th Ed. John Wiley & Sons, Inc. New York

1-1
2.1 Project Characteristics
Irrespective of the size of the project, it will have the following attributes:

Purpose A project, as a one-time activity, will have a well-defined target end point.

Life Cycle Identifying a life-cycle for a project confirms its tranciency. The table shown below provides a
four-stage view of the project-management life cycle.3

Stage Name Management objectives

Germination Proposal and initiation • project definition

• scope and business objectives
• feasibility
• initial estimates to ±30%
• go/no-go decision

Growth Design and appraisal • systems design for sanction

• planning and resourcing
• estimates to ±10%
• baseline
• sanction

Maturity Execution and control • education and communication

• detail planning and design
• control estimate to ±5%
• work allocation
• progress monitoring
• forecasting completion
• control and recovery

Death Finalisation and close-out • completion of work

• use of product
• achievement of benefits
• disbanding /rewarding the team
• audit and review
• historical records
The life cycle will typically have a slow beginning, build up in size, peak and then start to decline before termination.

3
Turner, JR.1993 The Handbook of Project-Based Management McGraw-Hill, London (p 23).

1-2
Interdependencies Projects will always involve interaction between functional departments within the
organisation in which they are operating. It is normal for functional departments to
interact on a regular basis, but a project’s interaction will be different. It will follow a
cycle of little activity, followed by intense interaction, through to little and finally no
interaction upon completion of the project. Reliable information from functional areas
is essential to accu ate project planning, therefore interactions need careful
management.

Uniqueness No two projects are exactly alike. During its lifetime, the risk and uncertainty
associated with a project will cause a management by exception approach to be taken.

Conflict The project manager will have to resolve many conflicts during the project’s life, in
order to achieve on-time and within budget, deliverables. The conflicts may arise in a
variety of areas, such as resource allocation, profit/performance levels, change of
specification etc.

A project has a hierarchical structure cascading down to the smallest element of work possible.

PROJECT

Tasks
Work
Packages
Work
Units

3.0 Project Management Stages

Although they are not inherently distinct, progressive stages can be identified within the life of a project.
• Proposal and initiation
• Design and Appraisal
• Execution and control
• Finalisation and close-out

4.0 Project Proposal and Initiation

As a Project Manager you may be “given” a preselected project or you may be involved in the selection of an appropriate
project. The evaluation and selection of the most appropriate project on which to spend an organisation’s money is a
very important one. This feasibility exercise brings its own cost to the project (non-recoverable ones if the project doesn’t
go ahead), therefore some systematic approach to the analysis is required.

1-3
4.1 Non-Numeric Models for Project Selection
Non-Numeric models are driven by a factors which take priority over analytic (resources, time and money) studies.

The Sacred Cow

A project instigated on the suggestion of a senior executive - usually pursued until its successful completion or until it is
seen as not being worth resourcing further.

Operating Necessity

A project is only started if it is required to keep a system operating. The question of whether to proceed with the project
then reduces to one of “is the system worth saving, given the cost of the project?”

Competitive Necessity

If it is essential to maintain a competitive position, a project must be carried out to put in place a new system. For
instance, a project may be started to install a more modern robotics line to keep up with a competitor, or to develop a
new product line based on what a competitor is doing (eg. Boeing 777).

Product Line Extension

A project may be initiated to deliver an outcome that fits into an existing range of products or services or is part of a
strategic push into a new area. This may not require a full cost justification if it is seen as of strategic importance to the
organisation.

Peer Review

A project may be selected by a review of experts or senior executives based on appropriate merit criteria. This is how may
research projects are selected for funding by government organisations.
1-4
4.2 Numeric Models for Project Selection
Numeric models endeavour to analyse the various options for implementing a project; understand the broad issues
involved; quantify the options to a degree which enables them to be ranked; and provide a vision for the project.

Profit (Profitability)

The great majority of organisations will select a project for resourcing based on the forecast profitability that will accrue.
There are many accounting techniques which help in reaching this decision, some of which are listed below: .
• Payback Period
• Average Rate of Return
• Discounted Cash Flow
• Internal Rate of Return

Whilst very useful - in isolation, these models have some major disadvantages:
• They ignore all non-monetary factors
• Models that reduce cash flow are biased towards the short run
• They rely on accurate estimates of cash inflows and/or profitability. (With R&D projects, this can be
difficult to obtain)

Scoring

Assigning either a weighted or unweighted score to relevant features of a project, allows it to be ranked against other
options.

Unweighted 0-1 Factor Model

A set of relevant factors are selected to form the basis of the evaluation. The project is then given a 1 or 0 score,
depending on whether or not it meet the criteria. Many raters will be used, and their scores averaged to provide an
overall assessment of the project. The main disadvantage of this system is that it assumes all factors have an equal
importance to the project. A sample project evaluation form is shown below:

Project ..........................................................................................
Rater................................................ Date .................................

Qualifies Does not Qualify

No increase in energy requirements 1
Potential market size, dollars 1
Potential market share, percent 1
No new facilities required 1
No new technical expertise required 0
No decrease in quality of final product 1
Ability to manage project with current personnel 0
No requirement for reorganisation 1
Impact on work force safety 1
Impact on environmental standards 1
Profitability - rate of return more than 15% after tax 1
Profitability - Estimated annual profits more than $100,000 1
Time to break-even less than 3 years 1
Need for external consultants 0
Consistency with current lines of business 0
Impact on company image - with customers 1
Impact of company image - with our industry 0
TOTAL 12 5

1-5
Unweighted Factor Scoring Model
Rather than limit the decision to qualifies (1) or does not qualify (0), the selection criteria are given a rating of, say 0-5.

Weighted 0-1 Factor Model

This model applies numeric weights to each criteria, so that it reflects its relative importance to the project. The overall
score for each project is then given by:
n
S = ∑ S j Wj where S = criteria score
j =1 W = criteria weight
Such techniques are good when trying to rank one project against another, but this makes them a relative, rather than an
absolute, tool. These numeric methods attempt to quantify what are essentially, subjective criteria. Therefore, a spread
of assessors should be used to reach a reasonable decision.

4.3 The Models - Fact or Fiction ?

We have discussed both objective (factual) models and subjective (opinion based) models. An objective assessment
procedure is often given greater credence (It is based on fact and must therefore be correct) than a subjective procedure
which relies on opinion. This rationale is not always accurate. The objective “fact” may be based on false or limited data
and often the opinion of an expert can be more encompassing and more accurate.

4.4 Risk Analysis4

Hand-in hand with the evaluation of a project, should go the assessment of risk. By their very nature, projects carry a
high degree of uncertainty, and therefore risk. The level of risk involved in a project is often a reflection of the size and
complexity of the project.

Risk management initially involves an assessment of the impact of risk(s) involved in a project. This may include factors
such as -
• Likelihood of risk
• Consequence of risk
• Public perception of risk

During the evaluation phase, there are two common methods of accounting for perceived risk and its predicted impact:
• making some allowance in the numeric estimates;
• calculating a range of possible outcomes, and the probability of each coming to fruition.

4.5 The Proposal

We have discussed the process involved in evaluating and selecting a project. The background information for this will
be derived from the project proposal. A proposal should always be formulated before the initiation of a project and
“although the majority of a project’s expenditure occurs in execution and control, the greatest influence over cost is during
proposal and initiation. ....although only 0.1 % of costs may be incurred during proposal and initiation, perhaps 90% of the
expenditure has actually been determined by the end of this stage.” 5

The proposal will be either for in-house use, or for submission to a customer (perhaps as part of an overall tender eg, for
a defence contract). Such a proposal should contain:

a) The Technical Approach

• Clear, unambiguous objectives of the project. (The importance of initial definition of outcomes and scope cannot be
overstated.)
• The project model - note the major sub-systems.
• Detail the approach to each sub-system so that informed evaluation may take place.
• Describe how the sub-systems will interface with each other.
• Explain test, inspection and audit procedures to ensure compliance with specifications.

4
(Risk management is discussed in more detail in Section 9.0)
5
Turner, JR.1993 The Handbook of Project-Based Management McGraw-Hill, London (p 281)

1-6
b) The Implementation Plan
• Set constraints for the project cost, duration and performance.
• Include aggregated totals for all costs.
• Highlight the plan with graphical representations of time-tables, gantt charts, PERT/CPM networks.
• Detail resource allocation for the duration of the project.

c) Logistic Support and Administration Plan

• Describe how routine infrastructure is to be supplied.
• Explain how the progress and budgetary position of the project is to be reported.

d) The Project Organisation - (Past Experience)

• Give details of the project organisation.
• Highlight the previous experience of the group on other projects.
• Include names, titles and relevant experience.
(Remember - this is a valuable resource - the aim is to convince the assessor that this group is the best for the project.)

5.0 Project Organisation

When a project is initiated, how it should fit into the overall structure of an organisation, becomes an issue.

There are a number of popular organisational structures focused on, product line, geographical location, customer group,
etc.

5.1 Functional Structure

The Functional Structure is probably the most common since it marries easily with the existing functional hierarchy
within the parent organisation. Project tasks are assigned to relevant operational areas (a new technology project may be
allocated to the Engineering Division; but the Finance Division will deal with the project accounting) and the area
managers takes responsibility for tasks in their area.

Chief Project
Executive Coordination

Functional Functional Functional

Manager Manager Manager

Staff Staff Staff

Staff Staff Staff

Staff Staff Staff

1-7
 Advantages Disadvantages
• Maximum flexibility of staff. • This project is not the total focus of those working
• Experts are used on many projects. on the project.
• Specialists are grouped and can share knowledge and • Activities orientated towards functional activities,
expertise. not project problem orientated.
• A base technology continues after the life of the • No one person given total (and sole) responsibility
project. - lack of coordination.
• Normal lines of authority and career paths • Projects appropriate to the functional area tend to
• Room for professional growth in an expertise area. be given preference.
• Motivation tends to be weak.
• Fragmented (non-holistic) view of the total project
is taken.
• Progress is slow for all these reasons.

5.2 Project Structure

The project manager manages a dedicated project team, and the operational managers have no involvement. The
Project has its own technical, administrative and support staff and the project manager (or Chief Executive Officer
(CEO)), has total control. At the extreme, an entire company may be set up for one project (eg. Snowy Mountain
Authority).

Chief
Project
Executive
Coordination

Project Project Project

Manager Manager Manager

Staff Staff
Staff

Staff Staff Staff

Staff Staff
Staff

Advantages Disadvantages
• The project manager has full line of authority. • Duplication of resources and effort
• All project team members are responsible to the • Resources (equipment and people) may be
project manager. stockpiled between projects.
• Short communication lines for the project. • Individual experts may not keep abreast of new
• Strong separate identity for the project. and relevant technology.
• Structure can react more rapidly to change. • Inconsistency in policy implementation.
• Holistic approach to the project. • Projectitius becomes epidemic. The strong loyalty
can cause friendly rivalry to turn to bitter
recriminations. The team may resist break-up
because of an uncertain future and prolong the
project life unnecessarily.

1-8
5.3 Matrix Structure
In an attempt to combine the best elements of both structures, many organisations use a hybrid matrix structure. A
project controller or coordinator, assigns a project manager who must form a team from within the organisation to
achieve the project’s objectives. The team members must be drawn from functional areas in which they normally
reside .

Chief
Executive

Functional Functional Functional Manager of

Manager Manager Manager Project Managers

Staff Staff Staff Project Manager

Staff Staff Project Manager

Staff

Staff Staff Staff Project Manager

(Black boxes represent staff engaged in project activities.) Project

Coordination

Advantages Disadvantages
• Project manager is totally responsible for the project - • Dual authority - functional areas can wield line
building the team, Planning and controlling the authority and the project may suffer.
progress and budget. • The project can still resist death.
• Can draw on expertise from functional areas as • The PM needs to negotiate resources from the
required. functional groups - a strong PM is needed for a
• For project related matters, the members report to the successful project.
PM. On all other matters (pay, career..) they report to • Since the principle of unity of command is
their functional head. violated, team members can end up with “two
• Team members have a functional “home” to return to bosses” and split loyalties.
after the project.
• Structure is flexible to the client’s needs.
• Functional areas ensure adherence to policies and
standards.

5.4 Mixed Structure

The Mixed Structure is a further hybrid of the functional and project structures. A project may exist in an
organisation under the leadership of a manager reporting directly to the CEO. This will exist alongside the
functional areas and the project manager will have equal (if not greater) authority. Team members will be drawn
from the functional areas, but report directly to the project manager.

5.5 The Project Team

One of the first tasks for a project manager is to put together the team of people that will make the project “happen”.
Given that most personnel will be “borrowed “ from functional areas the project manager needs good negotiating
skills to get the right people. He/she most also be able to spot the right people. Getting this right is key to a successful
project. With skilled, motivated team members the task of the project manager is significantly easier. The most
effective team members have some common characteristics:

1-9
High technical ability
Team members must be able to solve most of the technical problems for a project without recourse to outside to
outside assistance. Although the major technical problems faced by a project are generally solved by the functional
departments, the exact way in which such solutions are applied invariably requires some adaptation. In addition, a
great many minor technical difficulties occur that need to be handled rapidly.

Political sensitivity
It goes without saying that the project manager needs to be politically sensitive, but senior team members also need
to be politically aware. Support for a given project from senior management depends on the preservation of a delicate
balance of power between projects and functional units and between projects themselves.

Strong problem orientation

The chances of a successful project completion are greatly increased if the team members are problem orientated
rather than discipline orientated. Problem orientated people tend to adapt themselves and learn what ever problem
solving skills or techniques it takes, whereas discipline based people view the problem from only one perspective.

Strong goal orientation

Team members must have a focus on results rather than activity. During a project there will be times of high load
requiring individuals to work what ever hours it takes and other times where there is little activity. Project work
would not suit somebody who likes a constant work load.

High self esteem

Team members should never hide failure from the project manager. To do this effectively requires the individual to be
comfortable and non threatened in admitting their own errors. Team members should also be sufficiently comfortable
with their colleagues such that they can share criticism and praise constructively. Obviously the project manager must
create an environment that is secure and open such that effective communication can take place.

Good communicators
Team members must be able to communicate effectively with each other, the customer, functional areas and senior
management.

5.6 The Role of the Project Manager

“the project manager, who has responsibility for the detailed planning, coordination and ultimate outcome of the
project …For the duration of the project, he has the authority to insist on thorough planning, the freedom to
challenge functional departments’ assumptions and targets, and the responsibility to monitor every effort bearing on
the successful completion of the project”.6

To be successful in this role the project manager must have certain attribute. S/he must be:

• A team leader The ability to engender commitment and cooperation from all areas of the project team
is paramount to the project’s success.

• Flexible Change is the nature of projects

• Decisive The project environment is a dynamic one, requiring prompt decision making and
actions across a wide range of functional areas. Delays in the decision making process
can lead to costly over runs for the project.

• A negotiator Projects tend to draw from a cross-section of the organization, interfering with
traditional organisational structures and relationships. Skills in conflict resolution can
overt potential interdepartmental problems allowing those involved to focus on the
project as a whole.

• Results oriented Throughout a maze of changes and problems to be solved, the project manager must be
able to focus on achieving the desired end. The planned objectives for the overall project
will drive the problem solving process.

6
A guide to the Project Management Body of Knowledge Project Management Institute Standards Committee, Upper Darby USA 1996 (p42)

1-10
These traits must be coupled with strong people skills. As will become clear the human resource is perhaps the most
valuable to any project. An ability to understand the personalities and behaviours of the team and motivate all
members to a successful outcome for the project is important in a project manager.

“Clearly, a knowledge of theory of personalities and the influences of perception and attribution on personality and
theory of motivation is critical to the success of the project manager in developing the team and motivating team
members in gain conformity and compliance in the successful discharge of the team function”.

6.0 The Project Plan

“The Project Plan is a formal, approved document used to manage and control project execution” 7

The project plan must contain the following information:

• An overview
• Objectives - Project Charter
• General approach - description of the PM approach
• Contractual aspects - (including an outline of project deliverables )
• Scheduling information (Work Breakdown Structure WBS)
• Resources required and budget
• Personnel involved (giving key or required staff )
• Performance measures and evaluation
• Potential problems - risks, constraints, conflicts, assumptions....

6.1 Project Analysis and Design

The Project Plan should detail what is to be done and by whom (Activity definition) and when it is to be done (Activity
sequencing and duration estimation). 8 This requires all the activities to be specified and coordinated. Some
activities can be done simultaneously, whilst others must be carried out in sequence.

Step 1 List all the major events and activities required for completion of the project, in the general order in which
they would normally occur. This may result in 2 to 20 tasks. These tasks can then be broken down in to
2 to 20 sub-tasks. 20 is not a hard upper limit, however, beyond this, coordination between tasks becomes
difficult. Each of the activities at a given level should be of the same scope and complexity.

Step 2 Prepare a network and time chart from the information given by task 1.
At this point it is worth defining the difference between:

Events - outcomes resulting from activities Activities - specific tasks of work to be done

These are often confused and in planning, a clear distinction between the two is necessary.

Step 3 Consolidate steps 1 and 2 into a Master Project Schedule. This will include various milestones,
contractual deadlines, resources requirements

7
A guide to the Project Management Body of Knowledge Project Management Institute Standards Committee, Upper Darby USA 1996 (p42)
8
A guide to the Project Management Body of Knowledge Project Management Institute Standards Committee, Upper Darby USA 1996 (p59]

1-11
6.2 Work Breakdown Structure (Hierarchical Planning)
‘Work breakdown is a technique by which the work of a project is divided and subdivided for management and control
purposes. Rather than breaking the work of the project into a low level of detail in a single step, it is developed through
increasing levels of detail.’ 9

The hierarchical trees shown below illustrates a product-based work breakdown structure (WBS) for a defence project
and also one for a software development project.

Software Product
Release 5.0

Project Project Detail Construction Integration

Management Requirements Design and Test

Planning Software Software Software Software

User User User User

Meetings Documentation Documentation Documentation
Documentation

Training Program Training Program Training Program Training Program

Administration
Materials Materials Materials Materials

For each event or outcome a project action plan can be drawn up containing the tasks to be carried out in order to
achieve the outcome. These actions form the basis for all subsequent planning and therefore must be to an
appropriate low level of detail. They will need to contain information on:
• The immediate predecessor to the task.
• The estimated duration of the task
• The resources required to carry out the task in terms of money, labour, equipment, materials etc.
• Who is responsible for what, in the successful completion of the task.

Sample Action Plan

Deliverables:

Measure(s) of accomplishment:

Key constraints and assumptions:

Estimated Immediate Estimated

Tasks Resources Predecessor Tasks Duration Assigned to:

9
Turner, JR.1993 The Handbook of Project-Based Management McGraw-Hill, London (p 102]

1-12
These plans should not be drawn up in isolation. It is wise to contact individuals in each area of expertise to input
the necessary details. It may be appropriate that individuals be given responsibility for developing a series of sub
levels of a given outcome which the project manager must then consolidate into the overall plan.

These project action plans can then be consolidated into the hierarchical structure to form the WBS. The lowest
level or leaves of the structure are the individual work elements to which individual responsibility, performance,
budgets and scheduling can be assigned.

Such a chart allows the project manager to see how the project fits together and who is responsible for what. A series
of action plans for running a college “Career Day”.

ACTION PLAN
Objective: Career Day
Steps Responsibility Time Prec. Resources
(weeks)
1. Contact Organizations
a. Print forms Secretary 6 - Print shop
b. Contact organizations Program manager 15 1.a Word processing
c. Collect display information Office manager 4 1.b
d. Gather college particulars Secretary 4 1.b
e. Print programs Secretary 6 1.d Print shop
f. Print particpants’ certificates Graduate assistant 8 - Print shop

2. Banquet and Refreshments

a. Select guest speaker Program manager 14 -
b. Organize food Program manager 3 1.b Caterer
c. Organize liquor Director 10 1.b Dept. of Liquor Control
d. Organize refreshments Graduate assistant 7 1.b Purchasing

3. Publicity and Promotion

a. Send invitations Graduate assistant 2 - Word processing
b. Organize gift certificates Graduate assistant 5.5 -
c. Arrange banner Graduate assistant 5 1.d Print shop
d. Contact faculty Program manager 1.5 1.d Word processing
e. Advertise in college paper Secretary 5 1.d Newspaper
f. Class announcements Graduate assistant 1 3.d Registrar’s office
g. Organize posters Secretary 4.5 1.d Print shop

4. Facilities
a. Arrange facility for event Program manager 2.5 1.c
b. Transport materials Office manager .5 4.a Movers

1-13
Another useful chart, which may be drawn from the action plans, and allows quick determination of responsibilities
is the Linear Responsibility Chart. This may contain details of who need to authorise or check a particular task or
outcome and can be useful in monitoring that these approval stages are being carried out.

Linear Responsibility Chart

Responsibility
WBS
Project Office Field Oper.
Subproject Task Project Contract Project Industrial Field
Manager Admin. Eng. Eng. Manager

Determine Need A1 O


A2
O


Solicit Quotations B1 O

Write Approp. Request C1

O

C2
O

C3





- -
- -
- -

Legend:

Responsible

Support

Notification

O Approval

Final Planning Stage

The next step is to review all budget and time estimates with the various groups and individuals in the organisation
and revise them and the WBS as required. This is an important review procedure that should not be overlooked.

On completion of the review, the various levels of the WBS need to be aggregated at the next level up. This
continues until the top of the tree is reached and an overall aggregate plan of the project’s budget, time, resources and
variability is known. This will be used for pricing the proposal, adding contingency etc.

The WBS will be used in determining the Master Project Schedule (MPS) which integrates the many schedules and
is a comprehensive summary of the project. This will contain the information gained in the preceding steps and
highlight any major milestones that must be achieved.

1-14
7.0 Scheduling - Master Project Schedule (MPS)
Scheduling is the conversion of the project action plans into an operating timetable and thus usually forms the
major tool in the management of a project. It is not necessary to have one large schedule for the whole project.
For large projects this would become unwieldy. It is better to have a number of schedules which cascade down the
levels of our WBS as appropriate. It is not necessary to schedule everything in detail.

The basic approach of all scheduling techniques is to form an actual or implied network of activity and event
relationships that graphically presents the sequential relationship between the tasks in the project. Such a tool
illustrates the interdependence of all tasks, work packages and outcomes to determine the estimated project
completion time.

7.1 Networks
There are a number of network techniques used to assist in the scheduling of a project. Two of the most common
are the Program Evaluation And Review Technique (PERT) developed by the US Navy with Booz-Hamilton and
Lockheed Corporation, for the development of the Polaris missile/submarine project and the Critical Path Method
(CPM), sometimes called critical path analysis (CPA), developed by DuPont at about the same time. They are very
similar in structure and approach but developed for different project types. CPM is used mainly for construction
projects, PERT for R&D projects. (More complex projects are often network modelled using a techniques called GERT
- Graphical Evaluation and Review Technique) 10 It should be noted that these are not the only tools available,
however, when used, they have been shown to reduce overrun and costs.

Networks are a mathematical technique used to calculate the schedule. They are seldom useful in communicating the
schedule. Bar charts or activity listings are best used for that.

Types of network

There are three types of network:

• activity-on-arrow (AoA) networks - often called IJ networks as each activity is defined by an IJ (start/finish)
number. The work element is represented by an arrow between two nodes
• precedence networks - work elements are represented by boxes, linked by logical dependencies. (commonly termed
Activity on Node networks - AoN)
• hybrid networks - a combination of AoA and precedence.

The arrow networks tend to be more widely used, however precedence networks (introduced in the 1960’s) are
gaining in popularity.

A D

A simple precedence network

10
Meredith, J. and Mantel, S. 1989 Project Management - A Managerial Approach John Wiley and Sons, New York {p290-294]

1-15
 3

A C D
1 2 4 5

Activity-on-Arrow Networks 11

The combination of all activities, usually drawn as arcs or arrows, and events, usually drawn as nodes at the ends of
the arcs, define the activity precedence relationship. These networks are usually drawn from left to right with arrows
on the arcs showing the direction of flow. Before an event at a node can be realised, all preceding activities must be
completed.

(An alternative method is to represent the Activities-on-Nodes (AoN). Both methods are widely used and it is a matter of
personal preference (or available software package) as to which is best.)

A Path through a network is a series of connected activities (or intermediate events) between any two events in a
network. Critical Activities or Events are ones which, if delayed, will delay the completion date of the project.
These activities are said to have zero float. Therefore, a project’s Critical Path is the sequence of critical activities
(and critical events), that connect a project’s start and end events. The duration of critical work elements determines
the project’s duration.

7.2 Constructing an AoA Network

Consider the following information from a simplified action plan:

Sample Action Plan

Deliverables: Landscaping at AGSO site - Narrabundah
Measure(s) of accomplishment: Planting/ paving / rockwork complete - performance checks on watering systems / fountain

Key constraints and assumptions: Statue and fountain available as per order (18 March 98)

Estimated Immediate Estimated

Tasks Resources Predecessor Tasks Duration Assigned to:

a - - 5 -

b - - 4 -

c - a 6 -

d - b 2 -

e - b 5 -

f - c, d 8 -

11
A guide to the Project Managaement Body of Knowledge 1996 Project Management Institute Standards Committee Upper Darby USA [p64]

1-16
Let node 1 be the “Start Event”. Since activities a and b have no predecessor, their start point is node 1 and their
destination nodes will be 2 and 3 respectively.

Activity c follows activity a and activities d and e follow b, giving:

Now activity f must follow both c and d, but any given activity must have its source at only one node. Thus, both c
and d must conclude at the same node for precedence to f. So nodes 4 and 5 can be combined and renumbered to
give:

Since the action plan does not indicate any other activity, those activities with no successor can conclude at the same
node. Therefore, the network is now given by:

1-17
Dummy Nodes
With the AoA technique, two activities between the same nodes or events may sometimes occur. In such a case,
activities that follow may have one of the activities as a precedence, but not the other. From the diagram on the left
below, it is not obvious which precedence applies. This requires the use of dummy nodes as shown in the diagram on
the right. The dashed arrow between nodes shows that they are the same event, but one is a dummy.

The example below shows activity d preceded by c only; but e requires a and b only.

WRONG !!! RIGHT !!!

a
a e
d 1
b 1 b

e
c
c d
2

Such dummy nodes are only required for AoA, not AoN networks.

7.3 Calculating Activity Times

Consider the following project activity times and precedences:

Activit y Optimistic Time Most likely Time Pessimis tic Time Immediate Predecessor
(a) (m) (b) Activit ies
a 10 22 22 -
b 20 20 20 -
c 4 10 16 -
d 2 14 32 a
e 8 8 20 b, c
f 8 14 20 b, c
g 4 4 4 b, c
h 2 12 16 c
i 6 16 38 g, h
j 2 8 14 d, e

Now, for each activity, estimates have been made of the most likely time for completion (m), an optimistic time (a)
and a pessimistic time (b). The expected, or average time TE can then be found from:

TE = ( a + 4m + b ) / 6

1-18
This formula is based on the general beta statistical distribution , as opposed to the more common normal
distribution. This is to take into account non-symmetric situations where

m = a or m = b rather than m-a = b - m.

a TE m b

The variance in the distribution is given by

σ2 = [( b - a ) / 6]2
Estimates of a and b are made such that there is a very small probabaility that the time actually required (1:100) will
fall outside the range a - b. The precision of this range is obviously a function of the abilities of the estimator.
However, the TE is not particularly sensitive to errors that will result in estimation of a and b.

For our example the TE is given in the table below, along with the variance and standard deviation.

These activity times and variances are noted on the activity arrows of the network as shown below (Section 7.4
Critical Path and Time):
Activity Expected Time (TE) Variance Standard Deviation
2
(σ ) (σ)
a 20 4 2
b 20 0 0
c 10 4 2
d 15 25 5
e 10 4 2
f 14 4 2
g 4 0 0
h 11 5.4 2.32
i 18 28.4 5.33
j 8 4 2

d
2 5
(15, 25)
a (8 j
e ,4
, 4) , 4)
)
(20 (10
b f
1 3 7
(20, 0) (14, 4)
g
(10 c
,4
(4,
0) i .4)
) , 28
h (18
4 6
(11, 5.4)

1-19
7.4 Critical Path and Time
The Earliest Occurrence Time (EOT) is the earliest time that an event on a node can occur.

The Earliest Start Time (EST) is the earliest time an activity can start.

Given that an activity cannot start until all the preceding activities at its root node have been completed, the EST
equals the EOT of the root node.

Each of the paths through the network can be traced and for each node, the EOT can be noted. The EOT is the
longest path time from node 1. When tracing through, the dummy nodes must be included.
EOT = 20 EOT = 35
d
2 5
(15, 25)
a (8 j
e ,4
, 4) , 4)
)
(20 EOT = 20 (10
b f
EOT = 0 1 3 7 EOT = CRIT TIME = 43
(20, 0) (14, 4)
g
(10 c (4, i )
,4
)
0) 28.4
8,
h (1
4 6
(11, 5.4)
EOT = 10 EOT = 24

In this example there are 8 activity paths from node 1 to node 7.

a-d-j = 20 + 15 + 8 = 43 days c-dummy-e-j = 10 + 0 + 10 + 18 = 28 days

b-e-j = 20 + 10 + 8 = 38 days c-dummy-f = 10 + 0 + 14 = 24 days
b-f = 20 + 14 = 34 days c-dummy-g-i = 10 + 0 + 4 + 18 = 32 days
c-h-i = 10 + 1 + 18 = 39 days
b-g-i = 20 + 4 + 18 = 42 days

The longest overall path is a-d-j with 43 days. This is therefore the shortest possible time for the completion of the
network and thus is the critical path.

It is useful to note that the number of activities terminating at a node gives the number of paths that need to be
evaluated to determine the EOT at that node. This in turn gives the critical path to that node.

7.5 Float (Slack)

For all activities on the critical path, the earliest start time (EST) is also the latest start time (LST), if the project is to
meet the estimated completion date. However, for all other (non-critical) activities, the start time may float between
the EST and an LST, without affecting the completion date of the project.

Float = LST - EST

The LST is determined by carrying out a backwards pass, from the last node event to the first along each of the
paths. In the example under consideration, the critical time is 43 days:

Activity i requires 18 days to complete. Therefore activity i must be started no later than :

43 - 18 = 25 ie. the LST for activity i is day 25.

Since activity i cannot begin until event 5 has been completed, the Latest Occurrence Time (LOT) of node 5 is also
day 25. So activity i could be started on day 24 , at the earliest, and day 25, at the latest to ensure on-time
completion of the project.

1-20
There is one simple convention in determining the LST: each activity is treated as the only activity in the path that is
allowed to have slack. That is, all predecessors and successors meet the required EOT. The table of LOT, EOT, LST
and EST for the example under consideration, is shown below.

Event LOT EOT Float Activity LST EST Float

1 0 0 0 a 0 0 0
2 20 20 0 b 1 0 1
3 21 20 1 c 4 0 4
4 14 10 4 d 20 20 0
5 25 24 1 e 25 20 5
6 35 35 0 f 29 20 9
7 43 43 0 g 21 20 1
h 14 10 4
i 25 24 1
j 35 35 0

For complex networks this method of determining the EST and LST can be time consuming and slow. Many
software packages are available for this purpose.

7.6 Gantt Charts 12

As discussed previously, networks are a powerful technique in the scheduling of projects. However, they are not a
particularly useful means of communicating that schedule. Bar charts provide a much more effective means of
disseminating and updating the schedule information. One of the most common and easy-to-read bar charts is the
Gantt Chart.

The Gantt Chart shows planned and actual progress for a number of tasks or activities plotted against a horizontal
time-scale. The chart is simple to construct, easily modified or updated and provides a clear picture of the status of
the project. While Gantt charts do not show precedence, it is reasonably assumed that activities starting after the
completion of another activity are dependent upon the preceding one. In most instances dependency relationships
cannot be determined from the bar chart.

A modified PERT/CPM chart can be used as the basis for the Gantt chart, as shown below. The activity arcs are
extended to a length proportional to the task time. Nodes from which several activities emanate are repeated on the
Gantt chart - each activity must originate from an individual node although several activities can have a common
destination.

12
A guide to the Project Managaement Body of Knowledge 1996 Project Management Institute Standards Committee Upper Darby USA [p69]
1-21
From this chart, a Gantt chart is produced. The activities or tasks are listed in either numeric or alphabetic order,
usually in line with the Project Action Plan. Scheduled activity times are drawn as light lines or hollow bars. Heavy
lines or filled-in bars indicate actual progress. The initial Gantt chart and the Gantt chart on Day 22 of the project
are shown below.

A
c
t
i
v
i
t
y
a
b
c
d
e
f
g
h
i
j

0 10 20 30 40

Days

A
c
t
i
v
i
t
y

a
b
c
d
e
f
g
h
i
j

0 10 20 30 40
 ∧ Days

It is not necessary to create the modified PERT/CDM chart before preparing the Gantt chart. This can be drawn
directly from the network. Current software packages also allow precedence to be established and shown on the
Gantt chart.

PERT/CPM techniques and network and bar charts are complimentary tools in the management of project time.
Together they form the Project Master Schedule. This is the main document for monitoring and evaluating the
project’s progress.

1-22
8.0 Resource Management
In planning a project there are two main resources which need to be allocated - time and physical entities (manpower,
materials etc.) Time allocation has been covered in scheduling, and this section will deal primarily with the allocation
of other physical resources. However, time and physical resources are not independent resources. Changing the
schedule will invariably alter the resource requirements and similarly, altering the available resources will impinge on
the scheduling.

8.1 Critical Path Method (CPM)

Although CPM is similar to PERT, it varies in one major way. PERT involves a normal activity time (m); an
optimistic time (a); and a pessimistic time (b); allowing a probabilistic method of determining likely variation in
project time. With CPM, the activity time is related to the resource cost, allowing time/cost trade-offs. For each
activity, an estimated normal time is derived along with a “crash” time (a time to expedite the project). Associated
with each of these is a resource cost for the activity as shown below.
Activity Precedence Duration Cost ($)
Normal Crash Normal Crash

a - 3 2 40 80
b a 2 1 20 80
c a 2 2 20 20
d a 4 1 30 120
e b 3 1 10 80

Thus, the cost per unit time for crashing the activity can be generated and is often termed the Activity Slope for the
activity (tabulated below).

Activity Slope
(Cost/Duration)
$
a 40/1 = 40
b 60/1 = 60
c -
d 90/3 = 30
e 70/2 = 35

Assume that the project is to be “crashed” to reduce the completion date. The normal CPM/PERT network can be
drawn from the initial data.

1-23
The critical path for this network is a-b-e. To reduce the overall project time the critical path needs to be crashed.
The Activity Slope indicates that the cheapest activity to crash is e at $35/ day. Crashing e by 1 day gives a 7 day
project -

This process has created a second critical path - a-d-dummy. To further crash the project, d could be crashed,
however it is better to crash an activity common to both critical paths, in this case a.

a is now fully crashed. To reduce the time even further, e and d can be crashed by a day each.

b and d can now be crashed for further reductions.

The total project cost for each crash is tabulated below:

Project Duration Project Cost

(days) $
Normal (8) 120
7 155
6 195
5 260
4 350

1-24
The cost/time advantage of crashing activities can be plotted:

Such graphs are useful in determining which activity is the most cost effective to crash and by how much. For a large
project, the crashing exercise can be complex and is best tackled with the aid of a software package.

8.2 Resource Loading

During the planning phase, the project manager will need to know what resources are required and when they are
required. This is essential so that provision can be made to ensure that requirements can be met.

Returning to the previous example and the PERT network from page 19, the following resources are required:

Activity Resource A Resource B

(No. of units) (No. of units)
a 4 0
b 2 1
c 3 1
d 0 2
e 2 1
f 1 1
g 1 0
h 0 2
i 6 3
j 0 6

These are shown in parentheses just below the arc, with the use of A shown first and B shown second.

1-25
The loading diagrams for each resource provides a clear picture of the demand for each resource at each stage of the
project. The next section deals with techniques for ensuring that the required resource, in the required amount, is
available when and where it is needed.

8.3 Resource Levelling

Management of project resources would be a simple task if the demands remained constant or level.

Consider the following project network:

Activity Workers Duration

a 2 2

b 2 5

c 4 3

1-26
From this, the following time-based activity chart and resource chart can be drawn:

Activity c is the critical path and a and b have float. By moving b within its float, the resource load over time can be
altered and levelled.

In the example on page 1-28, e has 5 days float and f has 9 days float. By delaying both of these for 1 day, resource B
is levelled, but the level for resource A is adversely affected, as shown below.

1-27
Optimisation of the appropriate activities within their slack, to level demand on resources, is obviously a complex
task. Two basic techniques have been employed in various packages to assist in this exercise.

Heuristic Methods - employ rules of thumb which have historically produced better solution. For example -

1. Shortest task first Tasks are ordered in terms of duration, with the shortest first.

2. Most resources first The largest user of a specific resource is the activity which is tackled first.

3. Minimum slack first Activities are ordered by their level of float.

4. Most critical followers Tasks are arranged by the number of critical activities which follow them.

5. Most successors Tasks are arranged by the number of activities follow them.

Optimisation Methods - seek the best possible solution and are based on:

1. Linear programming

2. Enumeration techniques

9.0 Project Monitoring for Control

9.1 The Monitoring Process

The dynamic nature of projects requires a vigilant monitoring approach throughout the execution phase. Without
the information provided through the monitoring process, there is little hope of effective control of the project. This
then is the primary aim of monitoring:
1. to allow the project team to control the process.

Other, secondary uses of monitoring include:

2. auditing
3. establishing a history of the project for future ventures
4. keeping senior management informed

9.1.1 Response Time

Projects are unique and transient - there is no time for a paced learning curve. Once the execution phase of the
project has begun, information on its progress must be gathered and processed for control. The changing
environment on a project makes status information obsolete very quickly. Feedback cycles are typically very short - at
critical times they may reduce to twice daily; during normal running of the project they may extend to two weeks,
but rarely more. Traditional production monitoring systems are not designed for this flexibility - eg. a company’s
standard monthly accounting system may not provide financial data rapidly enough for corrective measures to be
implemented on a project.

9.1.2 What Information Should Be Collected?

It is relatively easy to specify the broad areas which need to be controlled during a project:
• Cost
• Duration
• Quality

It is much less easy to specify the precise characteristics in each of these areas which must be monitored to provide a
performance profile for the project and allow effective control.

In designing the monitoring system, the first step is to identify the measures which will best describe the project
status towards achieving the desired result. It is counterproductive to collect data “for its own sake”. Quite often the
most useful or important information is the least readily accessible.

The next step is to establish procedures for the timely gathering and dissemination of this information.
1-28
9.1.3 Data Collection

To some extent, the changing nature of a project results in an evolution of the monitoring and control process
throughout the life-cycle. However, an initial design of the monitoring should be part of a well-planned project.

The range of techniques for collecting data is as varied as the data itself, but there are a few common, forms -

• “Frequency counts. A simple tally of the occurrence of an event. This type of measure is often used for
‘complaints’, ‘number of times a project report is late’, ‘days without an accident’, ‘bugs in a computer program’
and similar items. The data are usually easy to collect and are often reported as events per unit time or events as a
percent of a standard number.

Number of bugs found during test of Datamix program

• Raw numbers. Dates, dollars, hours, physical amounts of resources used, and specifications are usually reported
in this way. These numbers are reported in a wide variety of ways, but often as direct comparisons with an
expected or standard number. Also, “variances’ are commonly reported as the ratios of actual to standard.
Comparisons or ratios can also be plotted as a time series to show changes ion system performance.

Percent of specified performance met during repeated trials

• Subjective numeric ratings. These numbers are subjective estimates, usually of a quality, made by knowledgeable
individuals or groups. They can be reported in most of the same ways that objective raw numbers are, but care
should be taken to make sure that the numbers are not manipulated in ways on ly suitable for quantitative
measures. Ordinal rankings of performance are included in this category.

• Indicators. When the PM cannot measure some aspect of system performance directly, it may be possible to
find an indirect measure or indicator. The speed with which change orders are processed and changes are
incorporated in to the project is often a good measure of team efficiency. Response to change may also be an
indicator of the quality of the communications of the project team. When using indicators to measure
performance, the PM must make sure that the linkage between the indicator and the desired performance
measure is as direct as possible.

• Verbal measures. Measures for such performance characteristics as “quality of team member cooperation,’
“morale of team members,” or “quality of interaction with the client’ frequently take the form of verbal
characterizations. As long as the set of characterizations is limited and the meanings of the individual term
consistently understood by all, these data serve their purposes reasonably well.”13
13
Meredith J. and Samuel J. Mantel, Jr, 1989, Project Management - a managerial approach 2nd Ed, John Wiley and Sons Inc, New York p378
1-29
9.2 Feedback (Reporting)
Project reports prepared during the execution phase reflect the monitoring need:
• Routine - reports raised after planned, periodic monitoring of the project.
• Exception -a report issued after monitoring either an exceptional change/decision or to provide data on which
to base an exceptional decision/change.
• Special analysis - a report on a special aspect of the project eg the response to the use of an alternative material
or process.

The form of report required should be established during monitoring design and will vary according to the type and
frequency of data being recorded. Common difficulties with project reports are:
• Too much detail - a costly and counter-productive exercise for all involved
• Relevancy - if the monitoring system is not presenting information directly related to the project’s plan, it is
worthless in terms of control.

9.3 Monitoring Overall Project Performance

It is just as important to track the performance of the overall project as it is to track the individual contributing
components (or actions / tasks).

Two obvious measures which can be monitored are:

• The timely achievement of milestones
• The maintenance of the predicted rate of expenditure

While both of these are valid, in isolation they can paint a deceptive picture. For example, at the halfway point in a
project, half the work may be completed but at twice the predicted cost. Alternately, half the expenditure may have
been realised for only a quarter of the work complete.

A performance measure which incorporates both time and cost, is Earned Value.

9.3.1 Earned Value Calculations

To obtain a clearer picture of a project’s performance you must compare the actual expenditure not to the schedule of
expenditure, but to some measure of the value of work done - the Earned Value.

1-30
Four variances are illustrated on the chart:

Time Variance = (Actual time for work complete) − (Time scheduled for value complete)

Schedule Variance = (Planned cost of work) − (Actual cost of work complete)

= Schedule Cost − Earned Value (Baseline)

Spending Variance = (Actual cost of work complete) − (Planned cost of work complete)
= Accrual − Schedule Cost (Baseline)

Total Variance = (Actual cost of work complete) − (Value of work complete)

= Accrual − (Earned Value)
= Spending Variance ∆ Schedule Variance

10.0 Risk Management

To this point, we have considered the methods, tools and techniques for managing three major components of a
project: organisation, cost and time. Inherent in each of these is a level of uncertainty. Since it is not possible to
totally eliminate the element of RISK from the project, (to do so could be more expensive that the possible impact
of the risk), it is therefore necessary to consider the direct management of these risks.

Definition: Risk: hazard; chance of bad consequence of loss; exposure to mischance.

On a project, some risks can lead to a chance of either profit or loss (business risks) or simply loss (insurable risks).

In terms of business risks, high risk projects generally offer the potential of high returns. The high risk project
generally has a large component of creativity and innovation, and perhaps a lengthy payback period.

Relationship of Risk and Return on Investment

Business risks may include : market response; inflation; weather; performance of technology; resource performance
etc.

Insurable Risks fall within four areas -

• direct property damage,
• legal liability,
• consequential loss, (related to direct damage)
• personal loss (injury to member of the team).

1-31
10.1 Risk in relation to Project Completion Date
One of the major questions posed at a Project Review is “What is the risk of not meeting the completion date?” To
answer this an analysis of the variability in the critical path activity times is necessary. Deriving the expected activity
times and their variance (v) is covered in Section 7.3. The mean activity time and its variation are known.

Assuming that the activities along the critical path are independent, then the overall variance (v) is the sum of the
individual variances
n
vc = ∑v
i =1
i
where n is the number of activities inthe critical path

The table from the example in Section 7.3 is reproduced for further analysis:

Now, a-d-j was identified as the critical path, therefore

Activity Expected Time (TE) Variance Standard Deviation

(V) (σ)
a 20 4 2
b 20 0 0
c 10 4 2
d 15 25 5
e 10 4 2
f 14 4 2
g 4 0 0
h 11 5.4 2.32
i 18 28.4 5.33
j 8 4 2

s = critical time = 43 days

σ 2 = vc = variance of critical path = 33 days
If it is further assumed that these activity times vary with a normal distribution, then it is possible to determine the
probability that a given completion date can be met.

1-32
A normalized, normal probability distribution may be drawn as:

The probability of an event

occuring is the area under the
curve.

The spread of the normalized probability curve needs to be distributedwith the known variance (standard deviation)
of the overall critical path time. Therefore, in this example;

one standard deviation, σ, is: √v = √33.

Thus if the maximum desired completion time D is 50 days, and the mean is 43 days, then the probability of
meeting this date is the area under the curve to 50 days.

If z is the number of standard deviations from the mean to D (50 days) , then z is given by

z = ( D - S ) / √v
= ( 50 - 43 ) / √33 = 1.22
This value for z can be used with the table “Cumulative Probabilities of the Normal Probability Distribution”, given
below to find the probability of the project finishing on time:

from the chart, for z = 1.22; P = 0.8888

ie. There is an 88% chance of finishing on day 50.

A more practical method may be to determine a reasonable probability, say 0.95 (95% chance of finishing),
determine the z value for this probability and then determine the completion date.

ie. for P = 0.95, z = 1.645 ∴ D = S + 5.745 (1.645)

= 43 + 9.45
= 52.45 days
ie There is a 95% probability of completing the project in 52.5 days.

Note: This analysis requires a good understanding of the potential variation in the task times. Without this accuracy, the
quoted times become almost random numbers.

10.2 Five Steps in Risk Management14

1. Identify the potential sources of risk on the project.
2. Determine their individual impact and select those with a significant impact for further analysis.
3. Assess the overall impact of the significant risks.
4. Determine how the likelihood or impact of the risk can be reduced.
5. Develop and implement a plan for controlling the risks and achieving the reductions.

10.2.1 Identifying the Risks

There are a variety of techniques used in the identification of risk. One of the simplest and most common is expert
judgement. Based on personal intuition and experience, this technique is limited by the size and scope of the project.
Win/lose Analysis focuses on events that might be detrimental and considers what we want to occur (but may not)
and what we don’t want to occur (but may). Brainstorming uses team interaction to enhance both of these
techniques
14
Turner, J. R. 1993 The Handbook of Project-Based Management McGraw-Hill UK p[237]
1-33
1-34
10.2.2 The Impact of Risk
The impact of a risk factor depends on its likelihood of occurring and the consequence if it does occur:15

Impact of risk = (Likelihood of risk) * (Consequence of risk)

Sometimes a third element comes into play - Public Perception.16

“To illustrate this concept, consider the question of whether building in the British Isles have earthquake protection.
The answer is : very few do. Multi-storey office blocks in London do not. The consequence of an earthquake in
London of Force 7 on the Richter Scale would be severe loss of life. However, the probability of such an earthquake
is so small, virtually zero, that it is considered unnecessary to take any precautions. However, one type of building
that does have earthquake protection is a nuclear power station. The likelihood of an earthquake has not changed,
but the consequences of that occurrence are now unacceptably high. The consequence of an earthquake of Force 7 in
the Heysham area would make Liverpool uninhabitable for 10,000 years (or that at least is the public perception).”

An improved equation -

Impact of risk = (Likelihood of risk) * (Consequence of risk) * (Public Perception)

Example: Owner’s Perception of Risk17

In the early 1980s, NIREX proposed storing medium level nuclear waste in a redundant mine
under ICI’s factory at Billingham. It may have been one of the safest proposals for storing medium
level waste. The project would cost ICI nothing, but earn them an income: an attractive project
with no risk attached. However, ICI would not allow the project to proceed because that was not
the way the local community viewed it, and ICI was concerned about local opinion. The ironic
thing was ICI used to operate one of the country’s largest private nuclear sources on the Billingham
site. It is almost certainly incorrect to say that the project would have ‘cost ICI nothing’. It was
causing a loss of goodwill in the local community, and so the ‘cost’ was whatever value the company
put on that goodwill. Clearly they did not think that ‘cost’ was worth the returns.

10.2.3 Reducing Risk

There are three basic approaches to reducing risk:

• avoidance: having identified the risk, you alter the plan to completely eliminate it.

• deflection: this involves passing the risk component to someone else.

- through insurance
- through bonding (a security held against the risk)
- through the contract.

• contingency: no immediate action is taken in relation to the risk, but plans are drawn up to deal with
it, if it should occur.

11.0 Project Termination

All projects must eventually terminate. This will usually occur by:

1. Extinction: The project has met all of its objectives and the result has been handed over to the
customer. Alternatively, the project may have been stopped prematurely for any of a
number of reasons - technical difficulty, assassination by senior management etc.

On extinction, the project need to be finalised and closed-out efficiently, with the resources
reallocated and a project report completed .

15
Turner, J. R. 1993 The Handbook of Project-Based Management McGraw-Hill UK p[242]
16
Turner, J. R. 1993 The Handbook of Project-Based Management McGraw-Hill UK p[242]
17
Turner, J. R. 1993 The Handbook of Project-Based Management McGraw-Hill UK p[250]
1-35
 2. Inclusion: A project may cease by being incorporated as an ongoing entity within the parent
organisation. For instance, a project to develop a new product may result in a new product
division being established. Thus, all personnel and resources transfer to an operation mode
of management. This may suit some individuals, but not others. The skills of the project
manager may not suit the day to day running of an operation.

3. Integration: The outcome of the project is integrated within the rest of the functional organisation of
the parent company. This will need careful technology transfer and tidying up of the loose
ends of the project. This may include: ensuring
- training is complete.
- all accounts and budgets are finalised and audited
- all drawings and documentation is complete and filed appropriately
- other functions, for instance marketing, accounts, finance etc. are aware of the new
product/system in place.

12.0 Project Report

The final task of the project manager is to compile the final project report. This is largely an historical report rather
than a strict evaluation and will provide feedback and data for future project evaluation.

The report should contain -

• Details of the “as-built” design - the final configuration.
• An overview of project performance. This will include a comparison of final costs and benefits; a record of
the technical achievements; a review of the successes and failures of the project.
• An assessment of administration performance.
• Details of the organisational structure used.
• A team report.
• A summary of project management techniques applied to this project.

Since the report is an invaluable source of information for future projects, the project manager should keep
comprehensive notes throughout the life of the project, to aid in the preparation of this document.

1-36