Project Administraffftion

Project Administration
This book is a part of the course by Jaipur National University, Jaipur.

This book contains the course content for Project Administration.
JNU, Jaipur
First Edition 2013
The content in the book is copyright of JNU. All rights reserved.

No part of the content may in any form or by any electronic, mechanical, photocopying, recording, or any other
means be reproduced, stored in a retrieval system or be broadcast or transmitted without the prior permission of
the publisher.
JNU makes reasonable endeavours to ensure content is current and accurate. JNU reserves the right to alter the
content whenever the need arises, and to vary it at any time without prior notice.
Index
I. Content....................................................................... II
II. List of Figures...........................................................VI
III. List of Tables......................................................... VII
IV. Abbreviations.......................................................VIII
V. Case Study.............................................................. 109
VI. Bibliography.......................................................... 114
VII. Answers to Self Assessment............................... 116
Book at a Glance
I/JNU OLE
Contents
Chapter I........................................................................................................................................................ 1
Introduction to Project Administration...................................................................................................... 1
Aim................................................................................................................................................................. 1
Objectives....................................................................................................................................................... 1
Learning outcome........................................................................................................................................... 1
1.1 Introduction............................................................................................................................................... 2
1.2 Defining Project and Project Management............................................................................................... 2
1.3 Objectives of a Project.............................................................................................................................. 2
1.4 Project Administration ............................................................................................................................. 2
1.5 Importance of Project Administration....................................................................................................... 3
1.5.1 Benefits of Project Administration........................................................................................... 3
1.6 Project Manager........................................................................................................................................ 3
1.7 Project Administrator................................................................................................................................ 3
1.8 The Project Life Cycle.............................................................................................................................. 4
1.9 Importance of the Project Life Cycle Phases............................................................................................ 5
1.10 Project Management Triangle................................................................................................................. 5
1.11 Project Documentation............................................................................................................................ 6
Summary........................................................................................................................................................ 7
References...................................................................................................................................................... 7
Recommended Reading................................................................................................................................ 7
Self Assessment.............................................................................................................................................. 8
Chapter II.................................................................................................................................................... 10
Contract Management................................................................................................................................ 10
Aim............................................................................................................................................................... 10
Objectives..................................................................................................................................................... 10
Learning outcome......................................................................................................................................... 10
2.1 Introduction..............................................................................................................................................11
2.2 Contract . .............................................................................................................................................11
2.3 Contract Management............................................................................................................................. 12
2.4 Aim of Contract Management................................................................................................................. 13
2.5 Successful Contract Management . ........................................................................................................ 13
2.6 Contract Team......................................................................................................................................... 13
2.7 Types of Contract.................................................................................................................................... 13
2.7.1 Compensation Based Contracts ............................................................................................. 14
2.7.1.1 Fixed-Price Contracts . ............................................................................................ 15
2.7.1.2 Schedule of Rates Contracts..................................................................................... 15
2.7.1.3 Cost-Plus Contracts.................................................................................................. 16
2.7.1.4 Guaranteed-Maximum-Price Contracts................................................................... 16
2.7.2 Contract Packaging Based Contracts...................................................................................... 16
2.7.2.1 Turn-key Contract.................................................................................................... 17
2.7.2.2 Design-Build Contract............................................................................................. 18
2.7.2.3 Construction Contracts . .......................................................................................... 19
2.7.2.4 Professional Services Contracts .............................................................................. 19
2.8 Choosing the Type of Contract............................................................................................................... 20
Summary...................................................................................................................................................... 21
References.................................................................................................................................................... 21
Recommended Reading.............................................................................................................................. 21
Self Assessment............................................................................................................................................ 22
Chapter III................................................................................................................................................... 24
Contract Management Activities............................................................................................................... 24
Aim............................................................................................................................................................... 24
II/JNU OLE
Objectives..................................................................................................................................................... 24
3.1 Introduction............................................................................................................................................. 25
3.2 Contract Management Activities............................................................................................................. 25
3.3 Contract Organisation and Planning ...................................................................................................... 26
3.3.1 Contract Organisation ............................................................................................................ 26
3.3.2 Contract Planning ................................................................................................................. 27
3.3.3 Decision: Make or Buy........................................................................................................... 27
3.3.4 Contract Packaging ................................................................................................................ 28
3.4 Contract Specification . ......................................................................................................................... 28
3.5 Obtaining and Evaluating Contract Bids............................................................................................... 29
3.5.1 Invitation to Bid...................................................................................................................... 29
3.5.1.1 Advertisement.......................................................................................................... 29
3.5.1.2 Direct Communication ............................................................................................ 31
3.5.2 Receiving and Opening Bids.................................................................................................. 31
3.5.3 Contractor Evaluation and Selection...................................................................................... 32
3.6 Contract Finalisation and Award............................................................................................................. 33
3.7 Contract Administration......................................................................................................................... 33
3.7.1 Contract Administration Planning.......................................................................................... 34
3.7.2 Contract Administration Process............................................................................................ 34
3.7.3 Project Audit Process.............................................................................................................. 34
3.8 Contact Closure....................................................................................................................................... 35
Summary...................................................................................................................................................... 36
References.................................................................................................................................................... 36
Self Assessment............................................................................................................................................ 37
Chapter IV................................................................................................................................................... 39
Risk Management....................................................................................................................................... 39
Aim............................................................................................................................................................... 39
Objectives..................................................................................................................................................... 39
4.1 Introduction . .......................................................................................................................................... 40
4.2 Risk......................................................................................................................................................... 40
4.2.1 Theoretically Balanced Project............................................................................................... 40
4.3 Risk Management................................................................................................................................... 41
4.4 Principles of Risk Management.............................................................................................................. 43
4.5 Types of Risks......................................................................................................................................... 43
4.5.1 Macro Risk Levels.................................................................................................................. 44
4.6 Risk Management Process...................................................................................................................... 45
4.6.1 Establishing the Context......................................................................................................... 46
4.6.2 Risk Identification................................................................................................................... 46
4.6.3 Risk Analysis.......................................................................................................................... 48
4.6.4 Risk Evaluation....................................................................................................................... 53
4.6.5 Risk Reporting........................................................................................................................ 53
4.6.6 Risk Mitigation/Treatment...................................................................................................... 54
4.6.6.1 Potential Risk Treatments........................................................................................ 55
4.6.7 Risk Monitoring...................................................................................................................... 56
4.6.7.1 Risk Monitoring and Control: Inputs ...................................................................... 57
4.6.7.2 Tools and Techniques for Risk Monitoring and Control.......................................... 58
4.6.7.3 Outputs from Risk Monitoring and Control............................................................. 58
4.7 Roles and Responsibilities...................................................................................................................... 59
4.7.1 Management Plan................................................................................................................... 59
4.7.2 Role in Process Tasks.............................................................................................................. 60
4.8 Sample Risk List..................................................................................................................................... 60
III/JNU OLE
4.9 Risk Management Checklist................................................................................................................... 63
Summary...................................................................................................................................................... 65
References.................................................................................................................................................... 65
Self Assessment............................................................................................................................................ 67
Chapter V..................................................................................................................................................... 69
Project Closure............................................................................................................................................ 69
Aim............................................................................................................................................................... 69
Objectives..................................................................................................................................................... 69
5.1 Introduction............................................................................................................................................. 70
5.2 Project Life Cycle Structure.................................................................................................................... 70
5.3 Project Closure........................................................................................................................................ 71
5.4 Project Management Framework: Constraints........................................................................................ 71
5.5 Reasons for Project Closure.................................................................................................................... 72
5.6 Project Termination . .............................................................................................................................. 73
5.6.1 Methods of Project Termination ............................................................................................ 73
5.7 Benefits of Complete Project Closure..................................................................................................... 73
5.8 Closure Planning . .................................................................................................................................. 74
5.9 Project Closure Process ......................................................................................................................... 75
5.9.1 Ensure an Orderly Close ........................................................................................................ 75
5.9.2 Identify Follow-on Actions and Plan the Post Project Review . ............................................ 75
5.9.3 Evaluate the Project ............................................................................................................... 77
5.10 Closing Unsuccessful Project .............................................................................................................. 78
5.11 Project Closure Report ......................................................................................................................... 78
5.12 Common Project Closing Issues .......................................................................................................... 79
5.13 Common Project Closing Challenges .................................................................................................. 80
5.14 Importance of Formal Project Termination Procedures........................................................................ 81
5.15 Project Closure Checklist...................................................................................................................... 81
5.16 Project End Checklist - 11 Important Steps ......................................................................................... 83
5.17 Template: Project Closure Report......................................................................................................... 83
Summary...................................................................................................................................................... 90
References.................................................................................................................................................... 90
Self Assessment............................................................................................................................................ 91
Chapter VI................................................................................................................................................... 93
Project Management Software.................................................................................................................. 93
Aim............................................................................................................................................................... 93
Objectives..................................................................................................................................................... 93
6.1 Introduction............................................................................................................................................. 94
6.2 Project Management Software................................................................................................................ 94
6.2.1 Project Management Software: Features ............................................................................... 95
6.3 Implementation of Project Management Software................................................................................. 95
6.4 Benefits of Project Management Software ............................................................................................ 95
6.5 Project Management Software : Tasks . ................................................................................................. 96
6.5.1 Scheduling ............................................................................................................................. 96
6.5.2 Calculating Critical Path . ...................................................................................................... 97
6.5.3 Reporting................................................................................................................................ 97
6.5.4 Budgeting................................................................................................................................ 97
6.5.5 Asset Allocation...................................................................................................................... 98
6.6 Project Management Software: Approaches . ....................................................................................... 98
6.6.1 Desktop .................................................................................................................................. 98
IV/JNU OLE
6.6.2 Web based .............................................................................................................................. 98
6.6.3 Personal . ................................................................................................................................ 98
6.6.4 Single user ............................................................................................................................. 98
6.6.5 Collaborative . ........................................................................................................................ 99
6.6.6 Integrated ............................................................................................................................... 99
6.6.7 Non-specialised Tools . .......................................................................................................... 99
6.7 Top Project Management Software Packages........................................................................................ 99
6.8 Features of Common Project Management Softwares.......................................................................... 100
6.8.1 Microsoft Project ................................................................................................................. 100
6.8.2 Primavera.............................................................................................................................. 100
6.8.3 OmniPlan.............................................................................................................................. 101
6.8.4 Project Administrator............................................................................................................ 101
6.9 Criticisms of Project Management Software........................................................................................ 103
6.10 Future Development .......................................................................................................................... 104
Summary.................................................................................................................................................... 105
References.................................................................................................................................................. 105
Recommended Reading............................................................................................................................ 105
Self Assessment.......................................................................................................................................... 106
V/JNU OLE
List of Figures
Fig. 1.1 Project objectives............................................................................................................................... 2
Fig. 1.2 Project life cycle................................................................................................................................ 4
Fig. 1.3 Project management triangle............................................................................................................. 5
Fig. 1.4 Project reporting................................................................................................................................ 6
Fig. 2.1 Components of contract management..............................................................................................11
Fig. 2.2 Contract........................................................................................................................................... 12
Fig. 2.3 Types of contracting methods.......................................................................................................... 14
Fig. 2.4 Contracting methods (based on the method of compensation given to the contractor).................. 15
Fig. 2.5 Contracting methods (based on the way of contract packaging)..................................................... 17
Fig. 3.1 Contract management activities....................................................................................................... 26
Fig. 3.2 Steps in bidding process.................................................................................................................. 29
Fig. 3.3 An example of invitation bid........................................................................................................... 30
Fig. 3.4 Contract price bid............................................................................................................................ 32
Fig. 3.5 Project audit process........................................................................................................................ 34
Fig. 3.6 Contract closure............................................................................................................................... 35
Fig. 4.1(a) Example of ideal project plan ........................................................................................................
Fig. 4.1(b) Example of bad project plan....................................................................................................... 41
Fig. 4.2 Theoretical balanced project............................................................................................................ 42
Fig. 4.3 Relationship between constraint and uncertainty in project risk..................................................... 43
Fig. 4.4 External and internal project risks................................................................................................... 44
Fig. 4.5 Business risks.................................................................................................................................. 45
Fig. 4.6 Risk management process............................................................................................................... 47
Fig. 4.7 Relationships between probability and project stages..................................................................... 50
Fig. 4.8 Risk quantification matrix............................................................................................................... 52
Fig. 4.9 Relationship between impact and probability................................................................................. 52
Fig. 4.10 Risk and cost for project life cycle................................................................................................ 56
Fig. 5.1 Project life cycle structure............................................................................................................... 71
Fig. 5.2 Framework of project management................................................................................................. 72
Fig. 5.3 Framework of project management constraints............................................................................... 73
Fig. 6.1 Project workforce management ...................................................................................................... 97
Fig. 6.2 Project administrator .................................................................................................................... 103
Fig. 6.3 Project administrator menu............................................................................................................ 104
VI/JNU OLE
Contents
Table 4.1 Risk statement............................................................................................................................... 47
Table 4.2 Risk description............................................................................................................................. 48
Table 4.3 Example of risk analysis............................................................................................................... 49
Table 4.4 Risk matrix for grading risks........................................................................................................ 50
Table 4.5 Risk matrix for grading risks for large/complex projects............................................................. 50
Table 4.6 Risk probability/impact matrix for the city of Philadelphia Pole Geodatabase Project................ 53
Table 4.7 Types of role in risk management tasks........................................................................................ 60
Table 4.8 Checklist 1 - framework for project plan...................................................................................... 63
Table 4.9 Checklist 2 - ongoing risk management monitoring for projects.................................................. 64
Table 5.1 Project closure checklist................................................................................................................ 82
VII/JNU OLE
Abbreviations
CPM - Critical Path Method
ISO - International Organisation for Standardization
LAN - Local Area Network
PC - Personal Computers
PER - Project Evaluation Review
PIR - Post Implementation Review
PPR - Post Project Review
VBA - Visual Basic for Applications
VIII/JNU OLE
Chapter I
Introduction to Project Administration
Aim
The aim of this chapter is to:
• define project and project management
• explain the objectives of a project
• understand the need for project documentation
• describe the role of project manager and project administrator
Objectives
The objectives of this chapter are to:
• describe the concept of project and project administration
• explain the phases of project life cycle
• understand the particular functions of the project team
Learning outcome
At the end of this chapter, the students will be able to:
• define project
• understand the basics of project administration
• examine the responsibilities of each member of the project team
• get an overview of project administration
1/JNU OLE
1.1 Introduction
The economy of India has been growing rapidly over the last few years. Many industries have surfaced in various
sectors leading to a kind of market boom. Huge amount of money is being invested in various projects from sources
across the globe. In this perspective, it has become very important for the managers to efficiently manage projects
in order to maximise returns and encourage more investment.
1.2 Defining Project and Project Management

• Project: A project is a set of activities arranged in an ordered network forachieving the desired goals. A project
consists of a temporary endeavour undertaken to create a unique product, service or result.
• Project management: It is an art of controlling the cost, time, manpower, hardware and software resources
involved in a project.
1.3 Objectives of a Project

• Project objectives can be formulated as SMART:
S - Specific
M - Measurable
A - Attainable
R - Resourced
T - Time-bound
Fig. 1.1 Project objectives
1.4 Project Administration

• Project administration refers to the support, planning, documentation, time recording, cost monitoring, billing
and evaluation done during a project.
• It is the effective running and maintenance of the project resources. Various activities involved in project
administration include managing human, material, financial and logistical resources of a project.
• Project administration delivers not only key performance indicators, but also a current overview of the project
status, progress, costs and budgets.
• It is a key link in the chain of disciplines required for project success, and like any chain, one weak link can
spell disaster.
2/JNU OLE
1.5 Importance of Project Administration
Project administration is necessary to:
• avoid wastage, as a project requires huge investments
• keep in check the loss in any project, as it will have direct and indirect impact on the society
• prevent failure in projects
• adjust with the changes of the project activity in future
• get acquainted with the changing technology during project execution
• control the consequences of negativity in problems related to the project, which could be very serious
• control the effects of changing economic conditions on the project
1.5.1 Benefits of Project Administration

• Project administration allows orderly and accurate purchase and procurement of equipment, payment of bills,
and preparation of financial reports.
• It facilitates making timely requests for resources in order to avoid unnecessary breaks in the implementation
of the project.
• It allots sufficient time for carrying out technical and scientific tasks in the project.
1.6 Project Manager

• Project manager is responsible for implementing the proposal as planned and for solving possible problems that
may arise. He has the full responsibility and authority in successfully completing a project.
• Selection of project manager should be based on his or her leadership skills, commitment to the project,
availability, and the ability to facilitate smooth implementation of the project.
• Project manager oversees the hiring process and work of all other contractors involved in the project.
• He or she represents company’s interests in controlling costs and balancing the tendency of engineers and
contractors to direct the project to their advantage.
• The success of a project depends on the skills and character of project manager. For example, contract project
manager knows how to work with engineers, contractors, and vendors; and who has worked on similar
projects.
1.7 Project Administrator

• A project administrator is an official, who has the power to receive and handle funds. He checks the day-to-day
operation during a project.
• They have full authority towards managing project resources.
• A project administrator is responsible for owning the project management processes. This includes understanding
project goals, deadlines, and financial boundaries.
• They can best allocate resources, and manage benchmarking, scheduling project deadlines, and general
coordination.
• The most common fields that project administrators work in are construction, real estate, information technology,
business accounting and so on..
• The project administrator usually reports to a project manager or director.
3/JNU OLE
1.8 The Project Life Cycle

• The project life cycle refers to a logical sequence of activities to accomplish the project’s goals or objectives.
• All projects have to go through some basic steps in the process of conceptualising, designing, developing and
putting in operation the project’s deliverables or outputs.
• A life cycle of project consists of:
Fig. 1.2 Project life cycle

Initiation
The scope of the project is defined along with the approach to be taken to deliver the desired outputs. Here, the
outputs and critical success factors are defined. The project manager is appointed, who then selects the team members
based on their skills and experience.
Planning
The second phase should include a detailed identification and assignment of each task until the end of the project.
It is characterised by breaking down the project into smaller parts/tasks. It should also include a risk analysis and
a definition of criteria for the successful completion of each deliverable.
Execution and controlling

The most important task in this phase is to ensure project activities are properly executed and controlled. During the
execution phase, the planned solution is implemented to solve the problem specified in the project's requirements.
Closure
In this last stage, the project manager must ensure that the project is completed according to the desired outputs
and within scheduled time. The closure phase is characterised by a written formal project review report containing
the following components:
a formal acceptance of the final product by the client
Weighted critical measurements (matching the initial requirements specified by the client with the final
delivered product)
4/JNU OLE
rewarding the team
a list of lessons learned
releasing project resources
a formal project closure notification to higher management
1.9 Importance of the Project Life Cycle Phases

• Project activities must be grouped into phases because, by doing so, the project manager and the core team can
efficiently plan and organise resources for each activity, and also objectively measure achievement of goals and
justify their decisions to move ahead or correct the errors, or terminate the project.
• It is of great importance to organise project phases into industry-specific project cycles because:
each industry sector has specific requirements, tasks, and procedures when it comes to projects
different industry sectors have different needs for life cycle management methodology
1.10 Project Management Triangle

• Like any human undertaking, projects need to be performed and delivered under certain constraints.
• Traditionally, these constraints have been listed as "scope," "time," and "cost".
• These are also referred to as the "Project Management Triangle", where each side represents a constraint. One
side of the triangle cannot be changed without affecting the others.
• A further refinement of the constraints separates product "quality" or "performance" from scope, and turns
quality into a fourth constraint.
• The time constraint refers to the amount of time available to complete a project.
• The cost constraint refers to the budgeted amount available for the project.
• The scope constraint refers to what must be done to produce the project's end result.
• These three constraints often compete with each other: increased scope typically means increased time and
increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could
mean increased time and reduced scope.
• The discipline of project management is about providing the tools and techniques that enable the project team
(not just the project manager) to organise their work to meet these constraints.
Fig. 1.3 Project management triangle

(Source: http://www.beaconstrategy.com/project.html)
5/JNU OLE
1.11 Project Documentation

• Project documentation is used to define the way in which a project will be managed and the governance
surrounding it.
• During the life cycle of a typical project, a project manager can produce different types of documents to facilitate
the planning, tracking and reporting of the project.
• Documents range from feasibility studies, resource plans, financial plans and project plans, to supplier contracts,
post-implementation reviews, change request forms and project status reports.
• Progress reporting is a key element of project management. Reports should be issued by the project manager
and circulated to all stakeholders on a regular basis.
Fig. 1.4 Project reporting

(Source:http://knol.google.com/k/trudy-robinson/project-status-report-a-ynopsis/28bdmh8n1uiju/11#)
6/JNU OLE
Summary
• A project is a set of activities arranged in an ordered network for achieving the desired goals.
• A project consists of a temporary endeavour undertaken to create a unique product, service or result. Upon
completion of all these activities, the goals of the project are expected to be achieved.
• Project administration allows orderly and accurate purchase and procurement of equipment, payment of bills, and
preparation of financial reports. It helps in avoiding unnecessary breaks in the implementation of the project.
• A project administrator is an organisational unit or official, who has the power to receive and handle funds. He
checks the day-to-day operation of a project.
• Project activities must be grouped into phases and is known as the project life cycle. It refers to a logical
sequence of activities to accomplish the project’s goals or objectives. The four phases of a project lifecycle
include¬–initiation, planning, execution & controlling and closure. Project documentation is used to define the
way in which a project will be managed and the governance surrounding it.
• Documents range from feasibility studies, resource plans, financial plans and project plans, to supplier contracts,
post-implementation reviews, change request forms and project status reports.
References
• John M. Nicholas and Herman Steyn (2008). Project Management for Business, Engineering and Technology,
Butterworth-Heinemann Publication, 3rd edition.
• M. Williams (2008). The Principles of Project Management, Site Point Publications.
• Westland (2006). The Project Management Lifecycle, Kogan Page Limited.
Recommended Reading
• Stanley E. Portny (2010). Project Management for Dummies. Kindle Publication, 3rd edition.
• Harold Kerzner (2009). Project Management – A Systems Approach to Planning, Scheduling and Controlling.
New York, Van Nostrand Rienhold, 6th edition.
• Robert L. Kimmons, James H. Loweree (1989). Project Management: A Reference for Professionals. Dekker
Publications, New York.
7/JNU OLE
Self Assessment
1. Which is the final stage of project life cycle?

a. Initiation
b. Closure
c. Execution
d. Planning
2. __________ consists of a temporary endeavour undertaken to create a unique product, service or result.
a. Project
b. Contract
c. Tender
d. Notice
3. ___________is characterised by breaking down the project into smaller parts/tasks.

a. Initiation
b. Closure
c. Execution
d. Planning
4. _______ phase is characterised by a written formal project review report.

a. Initiation
b. Closure
c. Execution
d. Planning
5. Who is hired during initiation phase of a project life cycle?

a. Project manager
b. Project administrator
c. Contractor
d. A team
6. Which of the following is false?

a. A project is a set of activities arranged in an ordered network for achieving the desired goals.
b. A project consists of a permanent endeavour undertaken to create a unique product, service or result.
c. Upon completion of all the project activities, the goals of the project are expected to be achieved.
d. Project activities must be grouped into phases.
8/JNU OLE
7. Which of the following is false?
a. A project administrator is an organisational unit or official, who has the power to receive and handle
funds.
b. Project administrators are responsible for managingoverall project resources.
c. A project administrator is responsible for owning the project management processes.
d. The project manager or director usually reports to a project administrator.
8. Which is not one of the three constraints of Project Management Triangle?

a. Scope
b. Time
c. Employees
d. Cost
9. ___________ is the person responsible for implementing the proposal as planned and solving possible problems
that may arise.
a. Project manager
c. Stakeholder
d. Project sponsor
10. Who checks the day-to-day operation of a project?

a. Project manager
c. Stakeholder
d. Project sponsor
9/JNU OLE
Chapter II
Contract Management
Aim
• define contract
• explain about contract management
• enlist and explain various contract types
Objectives
• describe contract and contract management
• elucidate the intend of contract management
• know about advantages and disadvantages of various contract types
Learning outcome
• understand the need of contracts and its management
• identify various contract types according to their application
• recognise advantages and disadvantages of each contract type
• learn about opting the right contract type
10/JNU OLE
2.1 Introduction
Conventional business wisdom suggests that no business arrangement should be entered into unless a signed
contract is in place. Our society depends upon free exchange in the marketplace at every stage. The interactions
in the market all the times depend upon voluntary agreements between individuals or other "legal persons". Such
voluntary agreements can never become binding without a legal contract.
Contracts are signed between engineers, planners, companies and professionals for implementation of a project. The
contract management process is growing in importance as outsourcing continues to increase and suppliers become
virtual extensions of organisation’s competence and capability. Contract management have become an important
part of business.
There are three main components of contract management - people, process and technology. In order to award
and successfully manage effective contracts, organisations must have disciplined, capable, and updated contract
management processes in place.
PEOPLE
PROCESS TECHNOLOGY
Fig. 2.1 Components of contract management
(Source: http://www.matrikon.com/power/wind.aspx)
2.2 Contract
• A contract is a legally written or oral binding agreement between the parties identified in the agreement to fulfil
all the terms and conditions outlined in the agreement.
• Contracts are one of the most important documents in an enterprise.
• Contracting refers to the activities required for acquiring services of outside contractors to perform part or all
of the project tasks.
• Contracts are used for many different purposes from procurement to sales to employment and real estate.
Contracting is used by companies for operational as well as project activities.
• A good contract is:
precise
clear
well-documented
focused on the deliverables/outputs
11/JNU OLE
Fig. 2.2 Contract

(Source: http://www.ebizcounsel.com/)
2.3 Contract Management

• Contract management is the process which ensures that both parties to a contract fully meet their respective
obligations as efficiently and effectively as possible, in order to meet the business and operational objectives
required from the contract and in particular to provide value for money.
• It also involves building a good working relationship between customer and provider.
• They can be broadly grouped into three categories:
Service delivery management ensures that the service is being delivered as agreed, to the required level
of performance and quality.
Relationship management keeps the relationship between the two parties open and constructive, aiming
to resolve or ease tensions and identify problems early.
Contract administration handles the formal governance of the contract and changes to the contract
documentation.
• Project contractors are more focused on maximising return on each project contract they undertake. They are
likely make greater use of their legal rights to settle disagreements and problems encountered during execution
of the project.
• A company may not have either the resource or the expertise to execute its projects in reasonable time and cost
and with satisfactory quality. Example, a person running a restaurant is likely to know a lot about cooking and
serving food, but he or she is not expected to know much about interior decoration, or design of central air-
conditioning system for the restaurant. If this person decides to expand and set up another restaurant in a new
locality, it is quite likely that he may require external help for jobs like designing layout, interior, and exterior
of the restaurant, equipping the restaurant and the kitchen, designing and installing the auxiliary systems like
music, lighting, and air-conditioning.
• In such cases, contracting will solve the problem for day-to-day oversight of the construction site, and management
of vendors and traders and lead to smooth transaction and management of project.
• Contract helps in strengthening of the on-going relationship between the parties. Thus, projects rely much more
on use of contractors than operations.
12/JNU OLE
2.4 Aim of Contract Management
• The central aim of contract management is to obtain the services as agreed in the contract and achieve value
for money.
• This means optimising the efficiency, effectiveness and economy of the service or relationship described by the
contract, balancing costs against risks and actively managing the customer–supplier relationship.
• Contract management may also involve aiming for continuous improvement in performance over the life of
the contract.
2.5 Successful Contract Management

Contract management is said to be successful when:
• arrangements for service delivery is satisfactory to both customer and provider
• expected business benefits and value for money are being realised
• the provider is co-operative and responsive
• the customer knows its obligations under the contract
• disputes are rare
• there are no surprises for either party
2.6 Contract Team

• Contract team plays an important part when changes in project after the award require negotiation with
contractors.
• It may also provide advice and support to the project in the technical matters handled by them–for example,
preparation of project specification and requesting changes in the project.
• In addition to the commercial contract group, the project manager must identify a contract administrator for
each of the contract to handle the contract administration and closure activities.
• The contract administrator may be assisted by other project team members in his work.
2.7 Types of Contract

Contracts are divided into two groups based on the method of:
• agreeing on compensation to the contractor
• contract packaging
13/JNU OLE
Fig. 2.3 Types of contracting methods
2.7.1 Compensation Based Contracts

The methods of payment to the contractor vary according to the work. Payment is usually made against the certification
of completed works by the contract administrator. The four main types of payment are:
• Lump sum: A pre-agreed sum that the contractor/consultant/sub-contractor will be paid to carry out either a
stage or the whole of the works required under the contract (subject to various provisions, including variations
for which the contractor may receive additional payment).
• Measurement: The work is measured and valued according to a schedule or formula.
• Prime cost: Payment is made for the costs of the labour and materials used.
• Cost plus: Payment is done by prime cost, plus an added percentage for profit.
Based primarily on the method of agreeing on compensation to the contractor, the most common contract types for
projects are as follows:
• Fixed-price contract
• Schedule of rates contract
• Cost-plus contract
• Guaranteed-maximum-price contract
14/JNU OLE
Fig. 2.4 Contracting methods (based on the method of compensation given to the contractor)
2.7.1.1 Fixed-Price Contracts

• A fixed-price contract is an agreement to build the project for a certain price, regardless of the cost to the
contractor.
• Fixed price contracts are also suitable for those contracts where the contractor is responsible for both design
and construction, and therefore the design of the final project output cannot be specified in detail at the time of
awarding the contract.
• With a fixed-price contract, the contractor usually covers any extra costs that occur if the project takes longer
or if materials are more expensive than the estimates.
• A fixed-price contract can include incentives for the contractor to finish the work faster or at cheaper rate.
Advantages
• The contractor takes most of the financial risk in the construction part of the project.
• The contractor is motivated to do the construction work economically and quickly, so the project is not likely
to drag out for a long time.
Disadvantages
• The contractors may bid higher prices to cover their risks of actual cost exceeding their estimates.
• The contractor can make the greatest possible profit by constructing the building for the least possible money.
• Changes made after the contract is signed, may add to the cost.
• One cannot make this type of contract until the design and construction drawings are complete.
• It is hard to use this type of contract if the plan is to build project in phases, because the different phases may
overlap, making it hard to divide each phase into a separate contract.
2.7.1.2 Schedule of Rates Contracts

• Scheduled of rate contract is based on pre-determined rates for various component elements of the contract.
For example, fabrication contract for a steel structure may be based on rates per kilogram weight structure, and
that for excavation may be on the basis of total volume of excavation work done.
• The separate rates are agreed for each item of work that is required to be performed by the contractor. The rates
are worked out on the basis of estimate of total quantity of work involved in the contract, but the payment is
made on the basis of quantity of actual work performed.
15/JNU OLE
Advantage
• It allows the payment of the actual work done by the contractor at the rates included by the contractor at the
bidding time.
Disadvantage
• The only disadvantage of this type of contracts is that, it is not suitable for contracts where there is no (detailed)
design available at the bidding time, either because the employer/contracting authority did not have time to issue
it, or because the employer/contracting authority does not have the expertise to issue such a design or wants to
allow the bidders to come with their own, innovative solutions for building the object of the contract.
2.7.1.3 Cost-Plus Contracts

• A cost-plus contract is an agreement to pay a contractor the actual cost of constructing a building, plus a
contractor’s fee.
• This fee may be either a set amount or a percentage of the actual cost.
• In cost-plus contracting, it’s important to choose a contractor who has experience in the concerned type of
project to be assured that he will know how to build it for the lowest possible cost.
Advantages
• It saves time, especially at the beginning of the project.
• It is easy to make design changes during construction, because there is no need to change contract.
• The contractor will be willing to work for a lower price, since he is not taking the financial risk.
• There is no pressure for choosing the contractor offering lowest price, but an opportunity to hire the best qualified
contractor.
Disadvantages
• The final cost of building a project is not known until it is finished.
• Cost of unexpected construction problems has to be considered.
2.7.1.4 Guaranteed-Maximum-Price Contracts

• Similar to a cost-plus contract, except that the contractor promises that the project will not cost more than a
specific maximum amount.
• This contract may start out as a cost-plus contract and change when the design of the project is complete enough
that one can make a close estimate of the total cost.
Advantages
• limited cost
• contractor takes the financial risk
• starts execution before planning is completely finished
Disadvantages
• unusual
• it may be hard to find contractors willing to bid on it
2.7.2 Contract Packaging Based Contracts

• Contact packaging is used when it is decided to the project execution components are to be contracted out. The
16/JNU OLE
total work to be contracted out must be divided in contract packages.
• A contract package is the collection of all the work elements to be performed by a contractor as a part of a single
contract element. The total work to be contracted out may be performed as a single large contract, or as separate
multiple work packages forming separate contract packages.
• The choice of number of contract packages in a project and the way these are divided is based on three sets of
considerations – nature of project work, internal resources of the owner organisation, and types of contractors
available.
• These three sets of considerations interact to influence the time, cost, and quality performance of the project.
The final decision is aimed at achieving the optimum balance of the three.
Based primarily on the method of contract packaging, the most common contracting methods for projects are as
follows:
• Turn-key contract
• Design build contract
• Construction contract
• Professional services contract

Fig. 2.5 Contracting methods (based on the way of contract packaging)
2.7.2.1 Turn-key Contract

• A turn-key contract is a business arrangement in which a project is delivered in a completed state.
• Entire responsibility of project execution is entrusted to a single contractor.
• Rather than contracting with an owner to develop a project in stages, the developer is hired to finish the entire
project without owner input.
• The developer is separate from the final owner or operator, and the project is turned over only once it is fully
operational. In effect, the developer is finishing the project and “turning the key” over to the new owner.
• It must be on a fixed-price or guaranteed-maximum-price basis.
• It must include appropriate clause for performance guarantee.
• Since the contractor of a turnkey contract is expected to execute the complete project, the scope of contract
covers all areas of the project such as engineering design, supply, construction and testing.
• However, turn-key contracts may also be entered for clearly definable sub-projects within a project. For example,
in project for a manufacturing plant, one may enter into a turn-key contract for separate sub-project consisting
of state-of-the-art warehouse with automated material storage and handling systems.
17/JNU OLE
• Inspection of the contractor’s work at each major stage is necessary to ensure that the job is executed as per
the requirements.
• A turnkey contract can be a good contracting method when project involves high technology, the know-how is
not available with project owner and the contractor is fully conversant with the technology.
• There may be some project that involves integration of many areas, of which, project owner may be capable of
handling some and may depend on others for the rest of the tasks.
• A turnkey contract may also be used in the residential building industry. With a turnkey agreement, a builder or
developer completes both the construction and the finishing work before turning it over to the homeowner. The
homeowner is often offered a chance to select finishes, including curtains, paint colours and so on.
Advantages
• Offers many advantages over traditional building contracts. Because the developer still owns the building until
the project is complete, he has financial motivation to complete the job as quickly and efficiently as possible.
• Provides more time for an owner to seek financing and investors before he is required to pay for a completed
project. These agreements also save inexperienced owners from making difficult construction decisions, leaving
these decisions in the hands of the developer or builder.
Disadvantages
• Lack of control that the owner maintains over design and construction decisions.
• Most difficult to compare with each other because the contractor is responsible for so many different parts of
project and each bidder wants to do the project.
2.7.2.2 Design-Build Contract

• A design-build contract is a single agreement with one company to design and build a project.
• One company is chosen to both design and build the project.
• The project owner hires an architect. Once the architect has finished the design phase, the project is put out for bid
to general contracting companies. The contractor with the lowest bid is awarded the project, and is responsible
for completing the job according to the plans created by the architect.
• With a design-build contract, the owner awards the entire project to a single company. It is typically awarded to
a contractor, though architects or engineers may be awarded a design-build contract in some special cases.
• Once the contract is signed, the contractor is responsible for all design and construction work required for
completing the project. This system allows the owner to deal with a single source throughout the duration of
the job, rather than coordinating between various parties.
For example: When a design-build contract is awarded to a builder, he must hire all architects and engineers
required to complete design work. The owner is still given the right to approve or reject design options,
but is no longer responsible for coordinating or managing the design team. Once the owner approves the
design, the same contractor then oversees the construction process, hiring subcontractors as needed. Most
design-build contracts are awarded through negotiation rather than through a bid process.
• These are mainly used in construction and renovation projects.
Advantages
• Owner’s administrative and management responsibilities are reduced.
• Team-oriented atmosphere is maintained and reduction in claims and legal problems over the course of the
project.
• Can have more accurate budgets and estimates, as well as a faster project completion time.
• Saves time, since the same company is both designing and building the project.
18/JNU OLE
• Contracting process is easier than with other contracting methods as there is only one major contract.
• Communication is easier.
Disadvantages
• Lack of checks and balances associated with the delivery system.
• Cannot really compare the bids directly with each other. Since each bidder is offering a different design. This
makes it impossible to choose the best contractor on the basis of price alone.
• Increase the construction cost, such as low operation and maintenance costs because the contractor profits from
designing a building that is cheap to construct, and since he is designing the building, he may not include costly
features in the design .For example, an engineer working independently from the contractor is more likely to
work for the best interests.
• Bidders tend to bid high in order to protect themselves because without a completed design, bidders cannot
estimate very accurately the cost of building project. Thus, one may end up paying more for the project with
this contracting method.
• A lack of experience with this process on the owner's part may lead to project delays or increased expenses in
some situations.
2.7.2.3 Construction Contracts

• The construction contract is a legally binding agreement between two parties on the details and cost of a
construction project.
• Covers very expensive, complex projects and simple renovations.
• There are two types of clients that use construction contracts: residential and commercial.
• Each client has different requirements that determine what should be included in the construction contract.
• A residential construction contract includes three basic elements: project scope, schedule of work and payment
details. The property owner who has requested the work and the project manager for the construction company
must sign the contract.
• The project scope is a statement of exactly what type of construction work is included in the contract. This
section should give detailed schematics, artist’s rendering, and any specific instructions. Both parties must agree
on this section and accept the exact representation of the required work.
• A schedule of work indicates the start date, milestones, and project completion date. The process for inspection
and quality assurance should be provided here.
• The payment details section includes the total project cost and payment dates. All construction projects are paid
on a percentage of completion bases. A deposit of no more than five percent of the total costs is provided at the
start of the project. The next payment is made when the predefined section of work is completed.
• Commercial construction contracts vary slightly from this format, as they must include more details. In addition
to the standard items provided above, a commercial construction contract has–procurement process details,
specifications about legislative coverage, contingency plans and dispute resolution instructions.
• The principle signatory document lists all the people who are involved in the project, their role and reporting
structure. This document is especially important in a large project, as it ensures that all parties have agreed to
the authorisation for changes, payment and design elements.
2.7.2.4 Professional Services Contracts

• Most construction projects require the professional services of project managers, planners, engineers, lawyers
or other consultants.
• These services generally involve the contractor’s time and talents in areas such as management, design, analysis,
planning or evaluation.
19/JNU OLE
2.8 Choosing the Type of Contract

The type of contract selected is based on the following:
• overall degree of cost and schedule risk
• type and complexity of requirement (technical risk)
• extent of price competition
• cost/price analysis
• urgency of requirement
• performance period
• contractor’s responsibility (and risk)
• extent of subcontracting (the amount of work that the contractor will outsource)
20/JNU OLE
Summary
• A contract is a legally written or oral binding agreement between the parties identified in the agreement to fulfil
all the terms and conditions outlined in the agreement. These are one of the most important documents in an
enterprise.
• A good contract is precise, clear, well-documented, focused on the deliverables/outputs.
• Contracting refers to the activities required for acquiring services of outside contractors to perform part or all
of the project tasks.
• Contract management is the process which ensures that both parties to a contract fully meet their respective
obligations as efficiently and effectively as possible, in order to meet the business and operational objectives
required from the contract and in particular to provide value for money. The central aim of contract management
is to obtain the services as agreed in the contract and achieve value for money.
• Contracts are divided into two groups based on the method of agreeing on compensation to the contractor and
contract packaging
• The compensation based contracts are - fixed-price, schedule of rates, cost-plus, guaranteed-maximum-price
contracts.
• Contract packaging based contracts are - turn-key contract, design build contract, construction contract,
professional services contract
References
• Contract Management. Available at: < http://www.wisegeek.com/what-is-contract-management.htm> Last
accessed on 12th January, 2011.
• Project Management. Available at http://project-management-knowledge.com. Last assessed on January 11,
2010.
• Dennis Lock (1998) Gower Handbook of Project Management. Gower Publishing, Hampshire. 2nd edition.
• Harold Kerzner (2009) Project Management–A Systems Approach to Planning, Scheduling and Controlling.
Van Nostrand Rienhold, New York, 6th edition.
• K. Nagarajan, 2004. Project Management. New Age International, New Delhi, 2nd edition.
Recommended Reading
• J. Rodney Turner (2003) Contracting for Project Management. Gower Publishing Company, 176 pages.
• John Butler (1904) Engineering Contracts and Specifications. Johnson Engineering News Publishing co., 560
pages.
• Arthur A. Bel (2007) HVAC Equations, Data, and Rules of Thumb. McGraw-Hill Professional, 290 pages.
• Anuj Saxena (2008) Enterprise Contract Management: A Practical Guide to Successfully Implementing an
ECM Solution. J Ross Publishing, 344 pages.
21/JNU OLE
Self Assessment
1. A ___________ is a legally written or oral binding agreement between the parties identified in the agreement
to fulfil all the terms and conditions outlined in the agreement.
a. contract
b. project
c. tender
d. document
2. Which of the following is not an element of a good contract?

a. Preciseness
b. Vagueness
c. Well-documention
d. Focus on the deliverables/outputs
3. Which of the following is not a type of contract?

a. Schedule of rates
b. Make-or-buy
c. Cost-plus
d. Lump sum
4. A _______ contract is an agreement to build the project for a certain price, regardless of the cost to the
contractor.
a. fixed-price
b. cost plus
c. schedule of rates
d. turnkey
5. A _______ contract is an agreement to pay a contractor the actual cost of constructing a building, plus a
contractor’s fee.
a. fixed-price
b. cost plus
d. turnkey
6. _____________contract must include appropriate clause for performance guarantee.

a. Fixed-price
b. Cost plus
c. Schedule of rates
d. Turnkey
22/JNU OLE
7. Which contract is preferred when project involves high application of technology?
a. Fixed-price contract
b. Cost plus contract
c. Schedule of rates contract
d. Turnkey contract
8. In which situation successful contract management is not possible?

a. Arrangements for service delivery are satisfactory to both customer and provider.
b. Expected business benefits and value for money are being realised.
c. The provider is non co-operative and responsive.
d. The customer knows its obligations under the contract.
9. On which of the following the type of contract selection is not based?

a. Overall degree of cost and schedule risk
b. Type and complexity of requirement (technical risk)
c. Extent of price competition
d. Risk analysis
10. A ________ contract is a business arrangement in which a project is delivered in a completed state.
a. fixed-price
b. cost plus
d. turnkey
23/JNU OLE
Chapter III
Contract Management Activities
Aim
• explain the process of contract management
• enlist and explain contract management activities
• describe contract administration
Objectives
• describe contract management
• explain the contract management activities
• explain the method of inviting a bid
Learning outcome
• understand various contract management activites
• recognise the process of obtaining and evaluating contract bids
• learn about contract organisation and planning
• understand about contract specification
24/JNU OLE
3.1 Introduction
In modern business, contracts plays a vital role in every organisation with the increased demands from work force
managers, IT managers, project managers, negotiators, legal departments and employees, mis-management of
contracts may easily happen.
Contracts are the support system of every organisation – they secure key staff, guarantee third-party supply and
tie clients into profitable deals. But contracts are also a real problem area. The sheer number and complexity of
documents can cause headaches across the business because despite having a huge investment, contract management
is typically poor. Most of the times, the incompetency to track payments, terms renewal, budgets and volume
discounts leads to increased cost.
Contracts must be adequately managed from start to finish ensuring funds are spent wisely. Thorough assessment
of contracts is needed to identify wasteful or inefficient contracts. Contract management is the process that enables
both parties to a contract to meet their obligations in order to deliver the objectives required from the contract. It also
involves building a good working relationship between customer and provider. It continues throughout the life of a
contract and involves managing proactively to anticipate future needs as well as reacting to situations that arise.
3.2 Contract Management Activities

The contract management activities are divided into following seven steps:
• Contract organisation and planning: It involves organisation, planning and packaging of a contract according
to the situation and demand.
• Developing contract specifications: Once the project planning is done, development and finalisation of contract
specifications, including the initial terms and conditions of the contract, can be started.
• Obtaining contractor bids/proposals: Based on contract specifications, bids are invited from prospective
contractors for undertaking the contract work.
• Bid evaluation: The bids received are then evaluated for their financial and technical attractiveness.
• Negotiation and award of contract: If necessary, discussions and negotiations are held with one or more
bidders and the final terms of contract are finalised. These agreed terms are incorporated in a written contract
document, which is issued to the selected contractor.
• Contract administration: The contractor executes the contract as per the agreed terms and conditions. During
contract execution work, the project team needs to monitor, control, coordinate and support the work. These
activities are described as contract administration.
• Contract closure: Ones the contract work is complete or is terminated in between for some reason, the contract
must be closed to tie up all loose ends and to document the learning from each contract.
25/JNU OLE
Fig. 3.1 Contract management activities
3.3 Contract Organisation and Planning

It involves contract organisation, planning, make or buy decision and packaging.
3.3.1 Contract Organisation

Contract planning and organisation is concerned with determining:
• What part of the total contract execution work is to be contracted out?
• What types of contracts should be used, what systems and processes to be adopted for awarding, administering
and closing the contracts?
• Who is responsible for performing various contract activities?
An important requirement of successful contract management is professional handling of the commercial and legal
aspects of the relationship with the contracts. The terms and conditions of the contract need to be carefully decided,
negotiated, and drafted during the entire process of finalising and awarding of contracts.
26/JNU OLE
3.3.2 Contract Planning
The contract management plan sets out how this is to be achieved, by addressing following issues:
• Types of contracts to be used. Choice of contract type depends on the nature of service/product purchased and
choices on the division of risk between the owner and contractor.
• Who will estimate the expected contract price?
• Who will develop the scope of work statement for the contract?
• Use of standardised procurement documents and any special documents needed.
• Integration of procurement lead times into the project schedule.
• Incorporating contractual delivery dates into contracts that coordinate with the project schedule.
• Use of performance bonds and/or insurance contracts to meet the project’s risk management objectives, including
liability and insurance conditions and minimum limits to be met by the contractor.
• Establishing evaluation criteria to assess the selection of contractors.
• Definition of the procurement procedures for - preparation of procurement documents, advertising, bidder
conferences, any bidder prequalification, receipt of proposals/bids, bidder interviews, selection, contract price
negotiation, contract award and handling of protests. (In many instances, the procedures used for project
procurements will be those the agency already has in place.)
3.3.3 Decision: Make or Buy

The project manager must decide what parts of the project execution activities will be handled internally (make)
and what will be contracted out (buy).
• On one end, the complete project including design, execution, testing and commissioning may be contracted.
For example, a trading company may give a contract for installation of a diesel generator based standby power
supply system.
• The other end of make or buy decision spectrum is where the whole work is divided in number of packages and
most of the work on each package is done internally.
• For example, the standby power supply project cited above may be divided in number of packages such as
diesel engine, alternator, foundation structure, fuel tank, water cooling system, control panel, cabling and civil
construction work. The company may execute this work internally.
• In between these two, company may contract out some of the work packages. For example, a manufacturing
company may have all the resources for the standby power system except for foundation structure and civil
work, which they may contract out.
• It is preferable to perform the work internally in the following situations:
the overall cost of in-house work is likely to be lower than contracting out
suitable external supplier for doing the work is not available
surplus in-house capacity is available for the particular type of work
company already has the basic set up for doing the job internally and no extra costs will be incurred while
creating the necessary supporting facilities
• There is need to maintain confidentiality of design, implementation techniques, or other information likely to
be accessible to the contractor during project execution.
• There is need to exercise direct control over the execution to ensure quality and speed.
• It is not possible to specify project requirements in sufficient detail and the project specification are likely to
undergo substantial changes during the process of progressive elaboration.
• Project implementation requires close integration and/or understanding of the existing operations of the
company.
• It is preferable to contract out the work when:
getting the cost of work done through the contractors is lower than the cost of doing it in-house
27/JNU OLE
the work is of standard nature for which capable contractors are readily available
where internal capacity for the work is not available. This can happen for two reasons. First, internal resources
are available, but cannot be spared from operational activities and other projects. The resources required
are of specialised nature with limited use in the company and therefore it is not worthwhile to acquire these
resources on permanent basis
company will have to create additional set up for the project, resulting in extra overhead costs. For example,
a company may find it economical to undertake a project at a location where it already has a set-up, but
will have to incur extra expense for a similar project at another location where no such set up is available.
the contractor has specialised skills, knowledge, or other resources which cannot be acquired by the company
easily. For example, large, fast-moving-consumer-goods companies spend large amount of money every
year for advertising, rather than creating their advertisements in-house because of the creative skill available
with advertising companies
there is no fear of leaking out confidential information due to use of contractors
3.3.4 Contract Packaging

• Once decision is taken on the project execution, the total work to be contracted out must be divided in contract
package.
• A contract package is the collection of all the work elements to be performed by a contractor as a part of a
single contract element.
• The contracted work may be performed as a single large contract, or as separate multiple work packages forming
separate contract packages.
• The choice of number of contract packages in a project and the way these are divided is based on three sets of
considerations – nature of project work, internal resources of the owner organisation, and types of contractors
available.
• These three sets of considerations interact to influence the time, cost, and quality performance of the project.
The final decision is aimed at achieving the optimum balance of the three.
3.4 Contract Specification

• These are the legal document produced by the relevant exchange that sets out the details of a future or options
contract, for example trading times, delivery procedures, quantities of underlying per contract etc. The use of
contract specifications leads to standardised products and thus maintains liquidity.
• The specifications contain technical description of the work as well as information on other major factors
affecting contract performance.
• For example, the location of a construction site and the nature of site facilities to be provided by the project
owner will have substantial impact on cost and duration of the contract performance and must be included in
the contract specification.
• Preparation of contract specification is usually the responsibility of the contract administrator. However, the
contract group may provide help and guidance on the commercial considerations impacting the specification.
• Statement of work is a narrative description of the work to be accomplished and/or the resources to be
supplied.
• Specifications are written, pictorial, or graphic information that describe, define, or specify the goods or services
to be procured. There are three types of specifications:
Design specifications: These are the details about what is to be done in terms of physical characteristics.
Performance specifications: These specify measurable capabilities the end products must achieve in terms
of operational characteristics.
Functional specifications: This is when seller describes the end use of the item to stimulate competition
among commercial items, at a lower overall cost.
28/JNU OLE
• For example, construction specifications will usually provide a number of lists as well, including the materials
that are to be used, where they are to be used, and how much should be used.
• In contracts for professional services, where it is not possible to determine with reasonable degree of certainty
the scope of contract or the specification of the contract output, the contract specification are replaced by a
request for proposal (RFP) or tender document.
• The request for proposal gives some information on the objective to be achieved by the contract and major
factors affecting contract performance.
• Once the specifications or the request for proposal are finalised these are passed on to contract group for obtaining
bids from prospective contractors, evaluating them, and awarding the contract.
3.5 Obtaining and Evaluating Contract Bids

It involves 3 steps:
• Invitation to bid
• Receiving and opening bids
• Contractor evaluation and selection
Fig. 3.2 Steps in bidding process

3.5.1 Invitation to Bid
• The bid is essentially an offer that is made for the acquisition of goods, services, or assets.
• The contract group is responsible for soliciting bid or offers against the specifications, receiving bid from them,
and evaluating the bid to assess their comparative attractiveness for the company.
• Each of these steps can be performed in several different ways depending on nature of contract and company
policies.
• Two most common ways of soliciting responses or from prospective contractors is to use some form of
advertisement, and direct communication with a selected list of contractors.
3.5.1.1 Advertisement
Company may release advertisement in a suitable publication requesting prospective contractors to give their offers.
Generally, the advertisement carries only a brief description of the work to be contracted out, and the contractors
are invited to obtain detailed contract specifications from the company and bid for the contract.
• Different companies may use different terms for bid. One fairly common practice is to use the term “bid”
for responses which are straight forward, and in very large and complex contracts, and professional services
contracts, contractor responses are often called “offer”.
• The advertisement can be released in printed publication and/or in the electronic media. Usually, it is done by
29/JNU OLE
placing an “Invitation to Bid” in appropriate publication.

• The invitation to bid is an official notice containing a description of the proposed work and stating the time and
place for submitting bids.
• Solicitation of bids by advertisement is costly and time consuming, but it results in much wider response.
• In general, advertisements are preferred in the following situations:
The value of contract is high.
A wider competition among contractors is desired.
There is a need to offer equal opportunity to all reasonably suitable contractors who may be possibly
interested in bidding for the contract.
Suitable list suppliers cannot be made without advertising.
It is a requirement imposed by law or some project stakeholder.
Fig. 3.3 An example of invitation bid

(Source: http://www.nhai.org/Doc/arc2004/Ahmedabad_Bypass/Tender-E.jpg)
30/JNU OLE
3.5.1.2 Direct Communication
• Direct communication to a list of contractors implies the existence of a list of contractors suitable to perform
the contract.
• The ways of compiling and preparing such a list includes issue of advertisement inviting contractors to get listed
as approved contractors in the company.
• The contractor lists maintained by companies contains names, addressees and some other related information
in brief.
• These lists are of two types, simple lists and registered contractor’s list.
• A simple list contains names of any and every contractor that the company gets to know about, and who is in
a particular type of business.
• The registered list is a more selective one. Contractors are included in this only when they show a desire to do
business with the company and are considered to have sufficient resource and capability to undertake a particular
type and size of contract. The assessment of contractor’s capability for inclusion in the contractor’s list is done
on the basis of information furnished by them.
• The advantages of contractor’s list method are:
economical and fast
when the lists are properly compiled, it ensures that only good contractors are able to bid
reduces the time and effort of evaluating too many worthless bids
• The limitation of contractor’s list method is that there is a possibility that some good contractors may not get
the chance to bid at all. This limitation of list method can be overcome by releasing advertisement to invite
contractors to register with the company rather than make a bid.
3.5.2 Receiving and Opening Bids

• The prospective contractors interested in making a bid must collect detailed bid documents from the company
and submit their bids.
• The invitation to bid specifies a last date for receiving the bid and bids received after this date are not valid.
• There are several alternative methods of receiving and opening the contractors bid that attempt to achieve
different level of transparency, and equality between contractors.
• Three main methods of receiving and opening bids are:
Sealed bids are submitted by the contractor to a designated buyer in the contract group, who may open the
bids as received. This method is the fastest and easiest for the company. However it affords minimum control
over foul play by the buyer, he or she can favour a contractor by passing on to him information about other
bids received. Using this information, contractor can then make a bid which is better than others.
Sealed bids are submitted by the contractor to the contract group. Provision is made so that all the bids
received are collected at one place and which cannot be opened or tempered till a specified bid opening time.
All the bids received till the specified time and date are opened in presence of a committee and initiated by
all committee members so that bids cannot be added or changed after the bid opening. Probability of foul
play here is reduced as because of bid opening in presence of a committee rather than a single person.
Same as the second method described above, with the difference that bids are opened in presence of
representatives of all the bids. The prices quoted by each contractor and any other important information are
read out during the bid opening the process. Presence of contractors’ representatives and disclosure of prices
creates additional transparency, further controlling the possibility of malpractices by the contract group.
A fourth method is to receive verbal bids on telephone or across the table. But this method is an exception
to be used in case of great urgency only.
31/JNU OLE
• In last few years, with the increasing use of the internet, a system of reverse auction is also becoming
popular.
• In this system, the contractors give their bids in an auction like environment where they give successively lower
price bids.
• The last bid which is not mended by another lower bid is accepted and the contract is awarded to that bidder.
• This system can be used only for simple contracts where the contract requirement can be specified clearly and
ability of contractors, participating in the auction, to perform the contract can be established in advance.
• If any changes are made to the bid document after issue, it must be notified to everyone who has received a
bid document. So it is important to keep an accurate list of the names and mailing addresses of all interested
contractors.
• At times, bidders may seek additional information and clarification on the project requirements and bid evaluation
process.
• To ensure that all bidders have the same information, bidder conferences may be arranged for releasing such
additional information and clarifications.
3.5.3 Contractor Evaluation and Selection

• Contractor evaluation and source selection involves the receipt of bids or proposals and the application of the
evaluation criteria to select a contractor. Each competing contractor is evaluated on quality, price and service.
• The main bid evaluation criteria include the following:
price (important of all)
overall or life-cycle cost (purchase cost plus operating cost) - understanding of need, technical capability,
management approach, financial capability, buyer organisation policies
• The end result of the evaluation process is a single best bid or a few best bids ranked as per their
attractiveness.
• Based on this, the company may straightaway award contract to the best bidder, or may enter into further
negotiation and clarifications with one or more bidders prior to finalisation of the successful bidder and details
terms and conditions of the contract, or may have further discussions with the contractors to get clarification
and confirmation on some important details not included in bid documents or contractor’s offer.
Fig. 3.4 Contract price bid

(Source: http://www.altruists.org/ideas/economics/altruistic/measuring_value/self-evaluation/)
32/JNU OLE
3.6 Contract Finalisation and Award
• The objective of award cycle is to negotiate a contract type and price that will result in reasonable contractor
risk and provide the contractor with the greatest incentive for efficient and economic performance.
• A contract negotiation is any discussion, either in person or through electronic means, that has as its primary
goal to come to a written agreement concerning a business matter. It handles issues such as cost, timeframe,
and whether there are any special considerations to take into account.
• Contract provisions that should be prepared for inclusion in proposals and contracts, are the following:
Scope of services and description of deliverables: a detailed description of the work the contractor.
A specific schedule for inspections, progress reports, and payments including details of what the contractor
must do to get each payment.
Changes and extras: procedures for changing or adding project tasks and for inspecting the work.
Explanation of the lines of authority and responsibility in the project team, job description for each of the
main people working on the project.
Owner obligation and supplied items: the information, facilities and other facilities that will be provided
by the project owner.
Confidential information: suitable clauses should be inserted to ensure that the contractor maintains the
confidentiality of sensitive information made available during the course of contract execution.
All documents referred to in the contract, such as maps, specifications, or parts lists
Time of completion and schedule of major milestones
A list of insurance and bonding requirements
Indemnity, including patent indemnity
Delays
Contract administration
Terms of payment
Rates and taxes
Termination and arbitration
Project closure requirements
• The final result is a signed contract.
• Bid protest: A bid protest is a procedure in which an interested party files protest against the awarding of a
government contract. Bid protests must follow a very specific procedure, and the government is obligated to
respond to them as long as they are procedurally correct.
3.7 Contract Administration

• Contract administration is the process of ensuring that the contractors’ performance meets contractual requirements.
On larger projects with multiple product and service providers, a key aspect of contract administration is managing
the interfaces among the various providers.
• The main contract administration activities include:
contract variations, including change control
cost monitoring
ordering procedures, e.g. ordering of hardware
payment procedures
management reporting
• These procedures are documented in the contract management plan.
33/JNU OLE
3.7.1 Contract Administration Planning

• Contract administration plan is to make certain the contractor meets its contractual obligations, the agency
adheres to its contractual obligations, and the company’s legal rights are protected. It is the role of contract
administrator.
• It is important that the contract management plan clearly identifies the roles and procedures to be followed by
the project staff responsible for managing the project (delivering the project scope on time and within budget)
versus the project staff responsible for administering project contracts (making certain contract parties meet
their contractual obligations and protecting the organisation’s legal rights).
3.7.2 Contract Administration Process

Contract administration starts immediately on award of the contract. The processes of contract administration are
described in following sections:
• holding a pre-execution meeting
• inspection of the work often
• developing schedules
• keeping records of all actions and decisions
• compliance with all contract terms
• final project audit
3.7.3 Project Audit Process

The project audit process consists of:
• initial enquiry
• reporting schedule
• final report
Fig. 3.5 Project audit process

Initial inquiry
• The process of auditing any project starts out with a formal notification being sent to the project members,
informing them of the impending audit.
34/JNU OLE
• The notification will also inform the project members of the audit team’s objective and what compliance issues
the team will be examining.
• After sending project members notification of the impending audit, the audit team will schedule and conduct a
face-to-face meeting with the project head and any administrators.
• The audit team will examine the project’s records and data files ahead of the full audit.
Reporting schedule
• After the formality of the initial inquiry is over, the audit team begins a full-fledged inquiry into the project.
• The team will attempt to glean a further idea of how the project is functioning by going over the project’s
background documents and conducting interviews with the project head and the project’s sponsor.
• The audit team will also conduct a series of interviews with members of the project, mapping out their individual
roles in the project, to get a more detailed idea of the project’s hierarchy and the validity of each member’s
role.
• During the inquiry and reporting phase of the audit, the audit team will periodically report its finding back to
the project’s sponsor.
• The audit team will also examine the project members’ efficiency in following their set timelines and will record
any inconsistencies in the project’s goals and individual project member’s performance.
Final report
• After sufficient data has been gleaned from the project’s data files and group member interviews and the audit
team has a firm idea of how the project is supposed to be carried out, the audit team will create a formal draft
of its report.
• After the management team presiding over the audit team has reviewed the formal report and decided whether to
recommend any amendments or further inquires into the project, the audit team will construct the final draft.
• The final draft of the audit report will contain a summary, list background and key issues raised, and provide an
assessment of the quality of the project members’ performance in carrying out its said goals.
3.8 Contact Closure

• Contract closure involves both product verification and administrative closure.
• The contract terms and conditions may prescribe specific procedure for contract closure.
• Early termination of a contract is a special case of contract closure.
• Closing contractual activities requires the project manager to oversee final settlement of project contracts,
acceptance of contract deliverables, collection of contract documents and records (such as as-built drawings,
operations etc.), final payments, and resolving disputes.
Fig. 3.6 Contract closure

(Source: http://www.jowewo.com/info/project.html)
35/JNU OLE
Summary
• Contract management is a very important function for success of a project.
• The central aim of contract management is to obtain the services as agreed in the contract and achieve value
for money.
• This means optimising the efficiency, effectiveness and economy of the service or relationship described by the
contract, balancing costs against risks and actively managing the customer–provider relationship.
• Contract management may also involve aiming for continuous improvement in performance over the life of
the contract.
• The methods and procedures of project contracting includes preparing contract specifications, obtaining and
evaluating contract bids, contractor selection, and provisions of contract agreement.
• Supervision, control and other actions is essential to ensure to meet contractual requirements.
• The methods of contract closure include covering final settlement of project contracts, acceptance of contract
deliverables, collection of contract documents and records, and approval of final payments.
References
• What is contract management? Available at http://www.wisegeek.com/what-is-contract-management.htm. Last
accessed on January 12, 2011.
• Success Planning in Project Management. Available at http://project-management-knowledge.com/. Last accessed
on January 12, 2011.
• Dennis Lock, 1998. Gower Handbook of Project Management. Gower Publishing, Hampshire. 2nd edition.
• Harold Kerzner (2009). Project Management – A Systems Approach to Planning, Scheduling and Controlling,
Van Nostrand Rienhold, New York, 6th edition.
• K. Nagarajan (2004). Project Management. New Delhi, New Age International, 2nd edition.
Recommended Reading
• J. Rodney Turner (2003). Contracting for Project Management, Gower Publishing Company. 176 pages.
• John Butler (1904). Engineering Contracts and Specifications, Johnson Engineering News Publishing co. 560
pages.
• Arthur A. Bel (2007). HVAC Equations, Data, and Rules of Thumb. McGraw-Hill Professional. 290 pages.
• Anuj Saxena (2008). Enterprise Contract Management: A Practical Guide to Successfully Implementing an
ECM Solution, J Ross Publishing. 344 pages.
36/JNU OLE
Self Assessment
1. A ____________is the collection of all the work elements to be performed by a contractor as a part of a single
contract element.
a. contract package
b. contract specification
c. contract
d. tender
2. A ________ is a procedure in which an interested party files protest against the awarding of a government
contract.
a. bid protest
b. invitation to bid
c. bid evaluation
d. negotiation
3. In which of the following is advertisement is used for soliciting responses from prospective contractors?
a. Bid protest
b. Invitation to bid
c. Bid evaluation
d. Negotiation
4. Price is the main criteria in ___________.

a. bid protest
b. invitation to bid
c. bid evaluation
d. negotiation
5. ____________ involves both product verification and administrative closure.

a. Contract organisation
b. Contract planning
c. Contract closure
d. Contract packaging
6. The method of _________ includes covering final settlement of project contracts, acceptance of contract
deliverables, collection of contract documents and records and approval of final payments.
a. Contract organisation
b. Contract planning
c. Contract closure
d. Contract packaging
37/JNU OLE
7. Which is not the part of contract administration?

a. Holding a post-execution meeting
b. Inspection of the work
c. Developing schedules
d. Keeping records of all actions and decisions
8. _________ is an official notice containing a description of the proposed work and stating the time and place
for submitting bids.
a. Invitation to bid
b. Evaluation of bid
c. Bid protest
d. Closing of bid
9. State which of the following is false?

a. The bid is essentially an offer that is made for the acquisition of goods, services, or assets.
b. The project administrator is responsible for soliciting bid or offers against the specifications, receiving bid
from them, and evaluating the bid to assess their comparative attractiveness for the company.
c. Common way of soliciting responses from prospective contractors is to use some form of advertisement.
d. Common way of soliciting responses from prospective contractors is to use some direct communication
with a random list of contractors.
10. Which of the following is involved in the methods and procedures of project contracting?
a. Preparing contract specifications
b. Obtaining and evaluating contract bids
c. Contractor selection
d. Mitigation of risks
38/JNU OLE
Chapter IV
Risk Management
Aim
• describe about project risk and risk management
• enlist and explain risk management activities
• identify risk factors
Objectives
• understand the concept of risk management
• elucidate about theoretically balanced project
• explain risk factors
• describe about risk mitigation
Learning outcome
• understand the concept of risk planning and types of risks in project management
• learn about risk management process
• know how to overcome the risks and lead the project successfully
• identify the risk, evaluate and monitor the project risks properly
39/JNU OLE
4.1 Introduction
One tends to stay away from those things that involve high risk. When risk cannot be avoided, one looks for ways
to reduce the risk or the impact of risk. But even with careful planning and preparation, risks cannot be completely
eliminated because they cannot be identified beforehand. The opportunity to succeed also carries the opportunity
to fail. It is necessary to learn to balance the possible negative consequences of risk with the potential benefits of
its associated opportunity.
4.2 Risk
• Risk is defined as uncertainty of outcome, whether positive opportunity or negative threat.
• It is the combination of the probability of an event and its consequences. It is something that may happen and
if it does, will have an adverse impact on the project.
• Risk is a major factor to be considered during the management of a project. In the area of contract management,
the term ‘management of risk’ incorporates all the activities required to identify and control risks that may have
an impact on a contract being fulfilled.
• Risk may be defined as the possibility to suffer damage or loss. The possibility is characterised by the factors:
probability that loss or damage will occur
expected time of occurrence
magnitude of the negative impact
Fig. 4.1(a) Example of ideal project plan Fig. 4.1(b) Example of bad project plan
(Source: http://www.coleyconsulting.co.uk/projplan.htm)
4.2.1 Theoretically Balanced Project

There are five intrinsically linked factors in estimating a project:
• Total time elapsed to produce the specified product.
• Effort required producing the product.
• Cost that a client is ready to spend.
• Resources required for the project–skills and availability.
• Specifications for the product; the features, functionality and user experience.
40/JNU OLE
Specification
Cost
Effort
Time Resources
Fig. 4.2 Theoretical balanced project

(Source: http://blog.sciodev.com/2010/04/06/the-5-variables-of-project-estimation/)
4.3 Risk Management

• Risk management is the systematic process of planning for, identifying, analysing, responding to and monitoring
project risk.
• It is the process of managing an organisation’s risk exposure to achieve its objectives in a manner consistent
with public interest, human safety, environmental factors and the law.
• Effective risk management involves the entire project team, as well as outside experts in critical risk areas
(e.g., technology, manufacturing, logistics, etc.), because risks can be in any area of the project and will often
be interrelated.
• Risk management should include hardware, software, integration issues and the human element.
• Chief Executive of Euro Log Ltd, UK Larry Krantz, states that, “A risk is a combination of constraint and
uncertainty.”
• Uncertainty is defined as an absence of information, knowledge or understanding regarding the outcome of an
action, decision or event.
• Risk is actually a measure of the amount of uncertainty that exists. Figure given below shows relationship
between constraint and uncertainty in project risk.
41/JNU OLE
Minimizing Risk in
Projects
C
o
n
s
t
r
a
i
n
t
Uncertainty
Fig. 4.3 Relationship between constraint and uncertainty in project risk
(Source: http://www.netcomuk.co.uk/~rtusler/project/principl.html)
• The illustration plots uncertainty against constraint. The curved line indicates the ‘acceptable level of risk’,
whatever that may be in the individual case. The risk may be reduced to an acceptable level by reducing either
or both, uncertainty and constraint.
• In practice, few have the opportunity to reduce constraint, so focus is mostly on the reduction of uncertainty. It
is also worth noting from the diagram that total elimination of risk is rarely achieved. So it has to be considered
to manage remaining risk most effectively.
• The risks in an organisation and its operations can result from factors both, external and internal to the
organisation.
• The diagram given below summarises examples of key risks in these areas and shows that some specific risks
can have both, external and internal drivers and therefore may overlap the two areas.
42/JNU OLE
External Factors
Leg
l ier isla
Supp tion
n ternal Factor
ry
I
Po
ust
Re sou
liti
hip
s
Ind
rs rces
cs
de
L ea
es
Technology nci
Environment
ete
processes
mp
Business
Co
Syst
Pr
e ms
od
uc
ts y
olog
De
rs
n
Tech
tito
mo
gra
pe
m
ph
Co
y
Eco
nom kets
y Mar
Fig. 4.4 External and internal project risks

(Source: http://www.strategicplantool.com/Assess_Current_Position.htm)
4.4 Principles of Risk Management

The International Organisation for Standardization (ISO) identifies the following principles of risk management.
Risk management should be:
• an integral part of organisational processes
• part of decision making
• explicitly address uncertainty
• able to create value
• systematic and structured
• based on the best available information
• able take into account human factors
• transparent and inclusive
• dynamic, iterative and responsive to change
• capable of continual improvement and enhancement
4.5 Types of Risks

Depending upon the level of risk, these are classified as: macro and micro.
43/JNU OLE
4.5.1 Macro Risk Levels

On a macro (large scale) level there are two main types of risk, these are systematic risk and unsystematic risk.
• Systematic risk is the one that cannot be reduced or predicted in any manner and it is almost impossible to
protect against this type of risk. Example: interest rate increase or government legislation change. The smartest
way to account for this risk is to simply plan for investment to be affected by it.
• Unsystematic risk is the one that is specific to asset features and can usually be eliminated through a process
called diversification. Examples: employee strikes or changes in management decisions.
4.5.2 Micro Risk Levels

Following are included in micro (small scale) types of risks:
Business risk
• It is the uncertainty of income caused by the nature of business measured by a ratio of operating earnings
(income flows of the firm).
• This means that the less certain one is about the income flows of a firm, the less certain the income will flow
back to the investor.
Fig. 4.5 Business risks
• The sources of business risk mainly arises from a company products/services, ownership support, industry
environment, market position, management quality etc.
• An example of business risk could include a ‘garbage’ company that typically would experience stable income
and growth over time and would have a low business risk compared to a steel company where sales and earnings
fluctuate according to need for steel products and typically would have a higher business risk.
44/JNU OLE
Financial risk
• It is the risk borne by equity holders due to a firm’s use of debt.
• If the company raises capital by borrowing money, it must pay back this money at some future date plus the
financing charges (interest, etc., charged for borrowing the money).
• This increases the degree of uncertainty about the company because it must have enough income to pay back
this amount at some time in the future.
Exchange rate risk

• The uncertainty of returns for investors that acquire foreign investments and wish to convert them back to their
home currency.
• This is particularly important for investors that have a large amount of over-seas investment and wish to sell
and convert their profit to their home currency.
• If exchange rate risk is high - even though a substantial profit may have been made overseas, the value of the
home currency may be less than the overseas currency and may erode a significant amount of the investments
earnings.
Political risk
• It is the risk of investing funds in country where a major change in the political or economic environment could
occur.
• This could devalue investment and reduce its overall return.
• This type of risk is usually restricted to emerging or developing countries that do not have stable economic or
political arenas.
Market risk
• The price fluctuations or volatility increases and decreases in the day-to-day market.
• This type of risk mainly applies to stocks and tends to perform well in increasing market and poorly in a
decreasing market.
4.6 Risk Management Process

• The risk management process steps are a generic guide for any organisation, regardless of the type of business,
activity or function. The steps include:
establishing the context
identification
analysis
reporting
treatment
monitoring
45/JNU OLE
• The processes are iterative throughout the life of the project and should be built into the project management
planning and activities.
Fig. 4.6 Risk management process

4.6.1 Establishing the Context
• The context for the risk management process is the business environment in which the project is being
implemented.
• This context includes political organisational and strategic sources of risk.
• The project scope, including outcomes/benefits, customers, outputs, work and resources, also forms part of the
context and can help in highlighting potential sources of risk.
• Establishing the context involves:
Identification of risk in a selected domain of interest
Planning the remainder of the process
Mapping out the following; social scope of risk management, identity and objectives of stakeholders, asis
upon which risks will be evaluated, constraints
Defining a framework for the activity and an agenda for identification
Developing an analysis of risks involved in the process
Mitigation or solution of risks using available technological, human and organisational resources
4.6.2 Risk Identification

• Risk identification involves identifying potential project risks and documenting their characteristics.
• Risk identification usually is done initially by involving key stakeholders, including committee members. Risk
identification continues throughout the life of the project.
• The following methods are often used to identify possible risks:
brainstorming
evaluations or inputs from project stakeholders
periodic reviews of project data
questionnaires based on taxonomy, the classification of product areas and disciplines
interviews based on taxonomy
46/JNU OLE
analysis of the work breakdown structure
analysis of historical data
• When identifying a risk it is essential to do so in a clear and concise statement. It should include three
components:
Condition: A sentence or phrase briefly describing the situation or circumstances that may have caused
concern, anxiety or uncertainty.
Consequence: A sentence describing the key negative outcomes that may result from the condition.
Context: Additional information about the risk to ensure others can understand its nature, especially after
the passage of time.
• Risk identification sets out to identify an organisation’s exposure to uncertainty.
• This requires an intimate knowledge of the organisation, the market in which it operates, the legal, social,
political and cultural environment in which it exists, as well as the development of a sound understanding of
its strategic and operational objectives, including factors critical to its success and the threats and opportunities
related to the achievement of these objectives.
The following is an example of a risk statement.
Condition End users submit requirements changes even though we’re in the design phase
and the requirements have been base lined.
Consequence Changes could extend system design cycle and reduce available coding time.
Probability and impact 80%. $2 million
Mitigation actions Who, what and when?
Table 4.1 Risk statement
Risk description
• The objective of risk description is to display the identified risks in a structured format, for example, by using
a table.
• The risk description table can be used to facilitate the description and assessment. The use of a well designed
structure is necessary to ensure a comprehensive risk identification, description and assessment process.
• Risks also can be categorised, for example in terms of type (i.e., corporate risks, business risks, project risks
and system risks). These categories can be broken down into other categories, including diseases, economic,
environmental, financial, human, information and physical security, natural hazards, occupational health and
safety, public liability etc., establishing categories can assist in ensuring all relevant risks are identified.
Name of risk According to the risk

Scope of risk Qualitative description of the events, their size, type, number and dependencies
Nature of risk For example, strategic, operational, financial, knowledge or compliance
Stakeholders Stakeholders and their expectations
Quantification of risk Significance and probability
Risk tolerance/appetite • Loss potential and financial impact of risk.
• Value at risk
• Probability and size of potential losses/gains
• Objective(s) for control of the risk and desired level of performance
47/JNU OLE
Risk treatment and • Primary means by which the risk is currently managed
control mechanisms • Levels of confidence in existing control
• Identification of protocols for monitoring and review
Potential action for Recommendations to reduce risk
improvement
Strategy and policy Identification of function responsible for developing strategy and policy
developments
Table 4.2 Risk description
Risk estimation
• Risk estimation can be quantitative, semi-quantitative or qualitative in terms of the probability of occurrence
and the possible consequence.
• By considering the consequence and probability of each of the risks set out in the table, it should be possible
to prioritise the key risks that need to be analysed in more detail.
4.6.3 Risk Analysis

• Risk analysis decides whether the level of each risk is acceptable or not and, if not, what actions can be taken
to make it more acceptable.
• This is the process of examining each risk to refine the risk description, isolate the cause, quantify the probability
of occurrence and determine the nature and impact of possible effects.
• The result of this process is a list of risks rated and prioritised according to their probability of occurrence,
severity of impact and relationship with other risk areas.
Probability of risk
• A risk is an event that “may” occur. The probability of it occurring can range anywhere from just above 0% to
just below 100%.
• It can’t be exactly 100%, because then it would be a certainty, not a risk. And it can’t be exactly 0% or it
wouldn’t be a risk.
• The relationship of risks and their probability across the project life-cycle process is illustrated in the following
figure.
48/JNU OLE
Fig. 4.7 Relationships between probability and project stages
• Risks can be analysed according to the likelihood they will be realised and the level of seriousness/impact they
will have if they do occur.
• From this classification, a priority listing for evaluation and action can be developed, separating the acceptable
risks from the unacceptable ones.
• Examples of possible risks might include a loss of funding (the effect of which is a lack of resources), an influenza
epidemic (crucial project team members may fall sick) or that crucial stakeholders are not interested in the project
(the effect of which is they do not provide important input into the project or take responsibility for it).
• Table 4.3 below illustrates, at a simple level, how this analysis can be done using the examples above. Assessing
the likelihood and seriousness of risks to a project provides a good indication of the project risk exposure.
Risk Likelihood Seriousness

Low Medium High Low Medium High
Loss of X X
funding
Influenza X X
epidemic
Lack of X X
stakeholder
commitment
Table 4.3 Example of risk analysis

• In practice, it is often difficult to analyse the likelihood/seriousness of risks quantifiably and that is why a
qualitative word scale is used often. Risks analysed in table above can be graded easily using the risk matrix
in table 4.4 below:
49/JNU OLE
Seriousness
Low Medium High
(Insignificant (Reasonable adverse (Will have
adverse impact, note impact, needs significant adverse
only) monitoring ) impact)
Low E D C
Likelihood (Unlikely to occur
during project)
Medium D C B
(May occur at some
stage in project)
High C B A
(Probably will occur
during project)
Table 4.4 Risk matrix for grading risks

Example
• Low likelihood/low seriousness equates to an E grading for overall risk exposure.
• High likelihood/medium seriousness equates to a B grading for the risk exposure.
• In the case of large and/or complex projects, the matrix should be expanded to ensure an A grade is automatically
assigned to any risks defined as extremely high in seriousness; that is, any risk which, if realised, will cause
the project to fail.
• An example of an extreme risk to the project might be unexpected legislative changes. Table 4.5 below details
such risk matrix.
• The resulting Grades of risk help the Steering Committee and Project Team to focus on treating the most
important risks.
Seriousness
Low Medium High Extreme
(Major adverse
impact on
project or
Likelihood business owner
operations)
Low E D C A
Medium D C B A
High C B A A
Table 4.5 Risk matrix for grading risks for large/complex projects
Risk quantification
• Risk need to be quantified in two dimensions. The impact and probability of the risk needs to be assessed. For
simplicity, rate each on a 1 to 4 scale. The larger the number, the larger the impact or probability. By using a
matrix, a priority can be established.
• If probability is high and impact is low, it is a medium risk. On the other hand, if impact is high and probability
50/JNU OLE
low, it is high priority.
Fig. 4.8 Risk quantification matrix
Risk ranking: severity of risk

• The combined effect of impact and probability equals overall severity of each risk.
• A risk, by its very nature, always has a negative impact. However, the size of the impact varies in terms of cost
and impact on health, human life or some other critical factor.
• The chart allows to rate potential risks on the two dimensions–probability and impact. The probability that a
risk will occur is represented on one axis of the chart–and the impact of the risk, if it occurs, on the other.
• The graph gives a quick, clear view of the priority that is needed to give to each.
• One can decide what resources will be allocated to manage that particular risk. The basic form of the risk impact/
probability chart is shown below.
Fig. 4.9 Relationship between impact and probability

(Source: http://www.mindtools.com/pages/article/newPPM_78.htm)
51/JNU OLE
The corners of the chart have these following characteristics:

• Low impact/low probability: Risks in the bottom left corner are low level and one can often ignore them.
• Low impact/high probability: Risks in the top left corner are of moderate importance – if these things happen,
one can cope with them and move on.
• High impact/low probability: Risks in the bottom right corner are of high importance if they do occur, but
they’re very unlikely to happen. For these, however, one should do what one can to reduce the impact they’ll
have if they do occur and one should have contingency plans in place just in case they do.
• High impact/high probability: Risks towards the top right corner are of critical importance. These are top
priorities and are risks that one must pay close attention to.
Example: Risk plan for city of Philadelphia Pole Geodatabase Project

For the City of Philadelphia Pole Geodatabase Project, a compiled a list of twenty significant risks is categorised
into the attacked risk probability/impact matrix.
Software/Hardware problems or changes

• Personal conflicts between consultant members or between consultant and city members
• Conflicting projects at consultant fight for resources
• City members have insufficient knowledge to master training for future Geodatabase work
• City resource issues cause delays in consultant work / meeting scheduling
• Poor cost estimates lead to over budget
• Poor time estimates lead to over run
• Final geodatabase design not accepted by city
• Unexpected office closures
• Erroneous or late to obtain Shapefile data from city
• Lack of key stakeholder support
• Fitness of use shows that new geodatabase is not an improvement over existing Shapefiles
• Rules or requirements changed by city during the project
• Consultant members do not have sufficient experience to complete project
• Consultant members quit, fired or on unexpected leave
• City reluctant to change for new geodatabase
• Poor communication between consultant and city
• City IT structure does not meet geodatabase requirements
• VBA scripts don’t migrate data accurately
• City human resource unavailability
From this activity, two risks stood out as the most important to plan to monitor. Budget and time overruns are a real
likelihood given the nature of this project, but impacts can be mitigated with extensive pre-planning as well as by
performing routine updates of resource allocation and future trends. Project scope requirements changes can occur,
though their negative impacts can be diminished with research, knowledge and most important, communication
between the consultant and City of Philadelphia.
52/JNU OLE
Risk Probability/Impact Matrix
Probability High 1 6, 7
Medium 3, 17, 20
Low 9 2, 4, 5, 10, 14, 15, 16, 18 8, 11, 12, 13, 19
Low Medium High
Impact
Table 4.6 Risk probability/impact matrix for the city of Philadelphia Pole Geodatabase Project
(Risk numbers correspond to those provided in Table 4.6)
4.6.4 Risk Evaluation
• Once risks have been analysed and graded in terms of likelihood and seriousness, they have to be evaluated.
• The risk evaluation process includes:
ranking the risks according to management priorities, by risk category and rated by likelihood and possible
cost or consequence
determining inherent levels of risk
• Risk analysis helps those people involved with a project to evaluate and prioritise the most significant risks for
careful management.
• Risk evaluation involves assessing the risks in order to prioritise those risks that should be addressed by treatment
or mitigation plans.
• Risk evaluation involves monitoring and understanding the factors that can reduce project success and determining
what is an acceptable or unacceptable risk based on agreed criteria.
• Risks can result in four types of consequences:
benefits are delayed or reduced
timeframes are extended
costs are advanced or increased
output quality (fitness-for-purpose) is reduced
• Once this evaluation has been undertaken, then decisions can be made. For example, if a risk is acceptable in
terms of extended timeframes, the project is not tied strictly to set deadlines, but is not acceptable if it reduces
the planned benefits or affects output quality.
• If on the other hand, a project has fixed deadlines, the decision might be made that the level of risk is acceptable
in terms of reducing the quality of the outputs, with a view to enhancing quality after the initial deadline has
been achieved.
• Once priorities are agreed upon, mitigation strategies must be developed and implemented for all unacceptable
risks.
4.6.5 Risk Reporting

• Risk reporting is absolutely essential for the projects. It consists of recording, maintaining and reporting risk
management plans, assessments and handling information.
• It also includes providing a knowledge base for better risk management in later stages of the project and in
other projects.
• Reporting should include as a minimum the following information:
risk management plans
project metrics to be used for risk management
identified risks and their descriptions
the probability, severity of impact and prioritisation of all known risks
53/JNU OLE
description of risk handling options selected for implementation

project performance assessment results, including deviations from the baseline plans
a record of all changes to the above documentation, including newly identified risks, plan changes and so
on
4.6.6 Risk Mitigation/Treatment

• Risk treatment is the process of selecting and implementing measures to modify the risk.
• Risk treatment includes as its major element, risk control/mitigation, but extends further to, for example, risk
avoidance, risk transfer, risk financing, etc.
• Any system of risk treatment should provide as a minimum:
effective and efficient operation of the organisation
effective internal controls
compliance with laws and regulations
• Risk mitigation actions or treatment reduce the chance that a risk will be realised and/or reduce the seriousness
of a risk that is realised.
• There are two broad types of risk mitigation or treatment activities:
Preventative: Planned actions to reduce the likelihood a risk will occur and the seriousness if it does occur.
In other words, what can be done now? For example, if a risk were identified that the project’s major clients
will not have the technical expertise to utilise adequately the technology being implemented in the project,
an appropriate preventative action should be taken to provide technical training.
Contingency: Planned actions to reduce the seriousness of the risk if it does occur. In other words, what
should be done if? For example, a possible action in response to the previous risk might be that ongoing
technical support and advice is provided to the client.
• Risk mitigation or treatment actions should be cost efficient and effective in that they help reduce the risk
exposure of the project.
• For serious risks, an extremely effective risk mitigation strategy can be justified more easily in terms of its
cost.
• One method of obtaining financial protection against the impact of risks is through risk financing which includes
insurance.
54/JNU OLE
• However, it should be recognised that some losses will be uninsurable e.g., the uninsured costs associated with
work-related health, safety or environmental incidents, which may include damage to employee morale and
the organisation’s reputation.
• Recovery actions are those subsequent actions that allow moving on after a risk has occurred. They include
management of residual risks.
• Hopefully, the seriousness of a risk’s impact on the project shall have been reduced due to the planned
contingencies being implemented. In other words - what should be done and when.
• A good example is disaster recovery planning in the case of a new IT system or, in the case of the previous
example, the client organisation hired people with technical expertise as the ongoing IT support did not provide
a final solution.
Fig. 4.10 Risk and cost for project life cycle

(Source:http://www.informaworld.com/smpp/section?content=a786946923&fulltext=713240928#referencs)
4.6.6.1 Potential Risk Treatments

Risk response strategies and actions include:
Avoidance
• This includes not performing an activity that could carry risk.
• The team changes the project plan to eliminate the risk or to protect the project objectives from its impact.
• The team might achieve this by changing scope, adding time or adding resources (thus relaxing the so-called
“triple constraint”).
• An example would be not buying a property or business in order to not take on the legal liability that comes
with it.
• But, avoidance of risks also means losing out on the potential gain that accepting (retaining) the risk may have
allowed.
Transference or sharing
55/JNU OLE
• Briefly defined as, “sharing with another party the burden of loss or the benefit of gain, from a risk and the
measures to reduce a risk.”
• The team transfers the financial impact of risk by contracting out some aspect of the work.
• Transference reduces the risk only if the contractor is more capable of taking steps to reduce the risk and does
so.
Reduction or optimisation
• Risk reduction or “optimisation” involves reducing the severity of the loss or the likelihood of the loss from
occurring.
• The team seeks to reduce the probability or consequences of a risk event to an acceptable threshold. They
accomplish this via many different means that are specific to the project and the risk. Mitigation steps, although
costly and time consuming, may still be preferable for going forward with the unmitigated risk.
• For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire. This method may cause
a greater loss by water damage and therefore may not be suitable. Halon fire suppression systems may mitigate
that risk, but the cost may be prohibitive as a strategy
Retention or acceptance
• This involves accepting the loss or benefit of gain, from a risk when it occurs.
• Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater
over time than the total losses sustained. All risks that are not avoided or transferred are retained by default.
• The project manager and the project team decide to accept certain risks. They do not change the project plan to
deal with a risk or identify any response strategy other than agreeing to address the risk if and when it occurs.
4.6.7 Risk Monitoring

• Risk monitoring is the process of continually tracking risks and the effectiveness of risk handling options to
ensure risk conditions do not get out of control.
• Risk control involves:
choosing alternative response strategies
implementing a contingency plan
taking corrective actions
re-planning the project
• This is done by knowing the baseline risk management plans, understanding the risks and evaluating project
performance against the established plans and expected results throughout the acquisition process.
• Risk management is not a one-off activity. Continual monitoring also enables the identification of new risks that
may become apparent over time. It also discovers the interrelationships between various risks.
• The monitoring process provides feedback into all other activities to improve the ongoing, iterative risk
management process for the current and future projects. It keeps track of the identified risks, residual risks and
new risks.
• Risk monitoring and control continues for the life of the project. The list of project risks changes as the project
matures, new risks develop or anticipated risks disappear.
• Periodic project risk reviews repeat the tasks of identification, analysis and response planning. Risk ratings and
prioritisation commonly change during the project lifecycle.
• The project manager regularly schedules project risk reviews. If an unanticipated risk emerges or a risk’s impact
is greater than expected, the planned response may not be adequate. The project manager must perform additional
56/JNU OLE
response planning to control the risk.
• The functional manager assigned to each risk reports periodically to the project manager and the risk team leader
on the effectiveness of the plan, any unanticipated effects and any mid-course corrections.
• Risk response planning focuses on the high-risk items evaluated in the qualitative and/or quantitative risk
analysis. It identifies and assigns parties to take responsibility for each risk response.
• Any monitoring and review process should also determine whether:
the measures adopted have resulted in what was intended
the procedures adopted and information gathered for undertaking the assessment were appropriate
improved knowledge would have helped to reach better decisions and identify what lessons could be learned
for future assessments and management of risks
4.6.7.1 Risk Monitoring and Control: Inputs

The following are the inputs of risk monitoring and control:
Risk management plan

• This plan has key inputs that include the assignment of people, including the risk owners, time and other
resources to project risk management.
Risk register
• contains the comprehensive risk listing for the project
• listing the key inputs into risk monitoring
• useful tool for outlining all the risks identified before and during the project, for keeping a record of their
grading in terms of likelihood and seriousness and a record of the proposed mitigation strategies, costs and
responsibilities
• forms the basis for the risk management plan
• In small projects, the risk register is the risk management plan. In large and/or more complex projects, a more
detailed risk management plan should be developed for approval by the Steering Committee.
• The risk register should cover:
a unique identifier for each risk
a description of each risk and how it will affect the project
an assessment of the likelihood it will occur and the possible seriousness if it does occur (low, medium,
high)
a grading of each risk according to a risk assessment table
a description of the mitigation strategies, which can include preventative (to reduce the likelihood) and
contingency actions (to reduce the seriousness)
the person who has been allocated the responsibility
in large and/or more complex projects, cost of each mitigation strategy
Approved change requests

• Necessary adjustments to work methods, contracts, project scope and project schedule.
• Changes can impact existing risk and give rise to new risk.
• Need to be reviewed from the perspective of whether they will affect risk ratings and responses of existing risks
and or if new risks are a result.
Work performance information

• Status of the scheduled activities being performed to accomplish the project work.
57/JNU OLE
• One can identify if new risk are appearing or if identified risks are dropping.
Performance reports
• Painting a picture of the project’s performance with respect to cost, scope, schedule, resources, quality and
risk.
• Comparing actual performance against baseline plans may unveil risks which may cause problems in the
future.
• Performance reports using bar charts, S-curves, tables and histograms, to organise and summarise information
such as earned value analysis and project work progress.
4.6.7.2 Tools and Techniques for Risk Monitoring and Control

The tools and techniques for risk monitoring and control are:
• Risk reassessment
project risk reviews at all team meetings
major reviews at major milestones
risk ratings and prioritisation may change during the life of the project
changes may require additional qualitative or quantitative risk analysis
• Risk audits
Examine and document the effectiveness of the risk.
Response planning in controlling risk and the effectiveness of the risk owner.
• Variance and Trend Analysis
Used for monitoring overall project cost.
Significant deviations indicate that updated risk identification and analysis should be performed.
Technical performance measurement.
• Reserve Analysis
As execution progresses, some risk events may happen with positive or negative impact on cost or schedule
contingency reserves.
Reserve analysis compares available reserves with amount of risk remaining at the time and determines
whether reserves are sufficient.
• Status meetings
Risk management can be addressed regularly by including the subject in project meetings.
4.6.7.3 Outputs from Risk Monitoring and Control

The outputs from Risk Monitoring and Control are:
Risk register updates

Risk register is updated to include;
• outcomes of risk reassessments, audits and risk reviews
• update may affect risk probability, impact, rank, response, etc.
• actual outcome of risks and of risk responses that becomes part of the project file to be utilised on future
projects
Corrective action
• Corrective action consists of performing the contingency plan or workaround.
• Workarounds are previously unplanned responses to emerging risks and must be properly documented and
incorporated into the project plan and risk response plan.
58/JNU OLE
Recommended preventive actions
• Used to direct project towards compliance with the project management plan.
Project change requests

• Implementing contingency plans or workarounds frequently results in a requirement to change the project plan
to respond to risks.
• The result is issuance of a change request that is managed by overall change control.
Organisational process assets updates

• Information gained through the risk management processes are collected and kept for use by future projects.
• Templates for risk management plan, probability-impact matrix, risk register, lessons learned.
Project management plan updates

• Updates to the project management plan as a result of approval of requested changes.
4.7 Roles and Responsibilities

• The project sponsor has ultimate accountability for risk management.
• They ensure that there are adequate resources for managing the project’s risks and there is adequate active
participation in the risk management process by a wide cross-section of stakeholders.
• They also ensure that any corporate or agency/organisation risks, identified during the project, are escalated for
the attention of those people responsible for their management.
• They also monitor the progress and effectiveness of the risk.
4.7.1 Management Plan

• The Steering Committee oversees the risk management plan and its periodic review.
• It is accountable for ensuring that an effective risk management plan is in place throughout the life of the project
and that appropriate mitigation strategies are being implemented for all high-level risks.
The project manager is responsible for monitoring and managing all aspects of the risk management process
under the direction of the project sponsor/Steering Committee, which include:
developing the risk register and risk management plan
continual monitoring of the project to identify any new or changed risks
implementing the planned mitigation strategies
supervising the effectiveness of the risk management plan
regular reporting on the status of risks to the project sponsor and the Steering Committee
• In large projects, the project manager may choose to assign risk management activities to a separate risk manager,
but the project manager should still retain the responsibility.
• It should be noted that large projects are a risk and the need for the project manager to reassign this integral
aspect of project management may be an indication that the project should be re-scoped or divided into several
sub-projects, overseen by a project director.
• It is also important to remember that the person directly responsible for risk management does not generally
conduct all risk management assessments themselves, but facilitates the analysis by involving relevant people,
particularly key stakeholders and by providing appropriate mechanism for discussion and documentation.
59/JNU OLE
• Other project team members are some of the people who can assist with the identification, analysis and evaluation
of risks and can assist in the development of the risk management plan. They can also be responsible for risk
mitigation actions.
• Project stakeholders, Steering Committee, reference groups, external consultants and importantly, the business
owner(s) should provide input into the risk management plan, especially assessment of potential risks and risk
mitigation actions. They may also be allocated responsibility for some risk mitigation actions.
• It is important to remember risk management cannot be the responsibility of one person entirely and that it is
a communal activity involving a range of people associated with the project.
4.7.2 Role in Process Tasks

• Role of different agencies involved in managing project, in risk management tasks is shown in the table
below:
Role
Sponsor District Project Assistant Functional Task
Division Manager Project Manager Manager
Chief for manager/
Program Project
and Project Management
Management Support Unit
Risk S S R S S S
management
Risk S S A S R R
identification
Qualitative R S S S
risk analysis
Quantitative A S R R
risk analysis
(performed
only as part
of Value
Analysis)
Risk S S R, A S
response
planning
Risk R R R, A S R R
Monitoring
and control
Table 4.7 Types of role in risk management tasks

Legend: R = responsible, S = support, A = approve
4.8 Sample Risk List

• The task of risk identification produces a project risk list.
• The project team then puts the risks into categories and assigns each risk to a team member.
• The project team members may use this sample risk checklist to develop a specific project risk list. This list is
not meant to be all-inclusive; it is just a guide.
• Team members add other risks areas from previous project results and as they arise during the project.
• Such sources might include the following:
final project reports
60/JNU OLE
risk response plans
organised lessons learned
the experience of project stakeholders or others in the organisation
published information such as commercial databases or academic studies
• 0Technical risks inlcudes:
incomplete design
incomplete environmental analysis or an error
unexpected geotechnical issues
change requests because of errors
inaccurate assumptions on technical issues in planning stage
surveys late and/or surveys in error
materials/geotechnical/foundation in error
structural designs incomplete or in error
hazardous waste site analysis incomplete or in error
consultant design not up to department standards
• External risks include:
landowners unwilling to sell
priorities change on existing program
inconsistent cost, time, scope and quality objectives
local communities pose objections
funding changes for fiscal year
political factors change
stakeholders request late changes
new stakeholders emerge and demand new work
threat of lawsuits
stakeholders choose time and/or cost over quality
• Environmental risks include:
permits or agency actions delayed or take longer than expected
environmental regulations change
reviewing agency requires higher-level review than assumed
lack of specialised staff (biology, anthropology, archaeology)
historic site, endangered species, wetlands present
environmental impact assessment required
controversy on environmental grounds expected
environmental analysis on new alignments is required
project in an area of high sensitivity for palaeontology
project in the coastal zone
project on a scenic highway
project near a wild and scenic river
project in a floodplain or a regulatory floodway
water quality issues
hazardous waste preliminary site investigation required
• Organisational risks include:
inexperienced staff assigned
61/JNU OLE
losing critical staff at crucial point of the project

insufficient time to plan
unanticipated project manger workload
delay getting approvals, decisions
functional units not available, overloaded
lack of understanding of complex internal funding procedures
not enough time to plan
priorities change on existing program
new priority project inserted into program
inconsistent cost, time, scope and quality objectives
• Project management risks include:
project purpose and need is poorly defined
project scope definition is poor or incomplete
project scope, schedule, objectives, cost and deliverables are not clearly defined or understood
no control over staff priorities
too many projects
consultant or contractor delays
estimating and/or scheduling errors
unplanned work that must be accommodated
communication breakdown with project team
pressure to deliver project on an accelerated schedule
lack of coordination/communication
lack of upper management support
change in key staffing throughout the project
inexperienced workforce/inadequate staff/resource availability
local agency issues
public awareness/support
agreements
• Right of way risks include:
utility relocation may not happen in time
freeway agreements
railroad involvement
objections to right of way appraisal take more time and/or money
• Construction risks include:
inaccurate contract time estimates
permit work windows
buried man-made objects/unidentified hazardous waste
regulatory risks
water quality regulations change
new permits or new information required
reviewing agency requires higher-level review than assumed
62/JNU OLE
4.9 Risk Management Checklist
• To ensure effective monitoring of their risk management efforts, project managers should establish systematic
reviews and specifically include them in the project schedule, assess the effectiveness of actions taken and
identify the status of actions to be taken.
• Below are the two checklists:
Checklist 1 provides a framework of project plan.
Checklist 2, ongoing risk management monitoring for projects, provides a useful framework for ongoing
risk management monitoring of individual projects.
Checklist 1: Framework for project plan
Project:
Responsible official:
Mission Articulate clearly the mission or goal/vision for the project
Objectives Ensure that the project is feasible and will achieve the project mission. Clearly define
what you hope to achieve by executing the project and make sure project objectives
are clear and measurable.
Scope Ensure that an adequate scope statement is prepared that documents all the work of
the project.
Deliverables Ensure that all deliverables are clearly defined and measurable.
Milestones/costs Ensure that realistic milestones are established and costs are properly supported.
Compliance Ensure that the project meets legislative requirements and that all relevant laws and
regulations have been reviewed and considered.
Stakeholders Identify team members, project sponsor and other stakeholders. Encourage senior
management support and buy-in from all stakeholders.
Roles and responsibilities Clarify and document roles and responsibilities of the project manager and other
team members.
Work breakdown Make sure that key project steps and responsibilities are specified for management
structure and staff.
Assumptions Articulate clearly any important assumptions about the project.
Communications Establish main channels of communications and plan for ways of dealing with
problems.
Risks Identify high-level risks and project constraints and prepare a risk management
strategy to deal with them.
Documentation Ensure that project documentation will be kept and is up-to-date.
Boundaries Document specific items that are not within the scope of the project and any outside
constraints to achieving goals and objectives.
Decision-making process Ensure that the decision-making process or processes for the project are
documented.
Signatures Key staff signature sign off.
Table 4.8 Checklist 1 - framework for project plan
63/JNU OLE
Checklist 2: ongoing risk management monitoring for projects
Review period: _______*

Section 1: Progress and performance indicators
Project Progress/ Status of indicator Are additional Notes
implementation or performance actions needed?
outcome objective indicator
Project
implementation or
outcome objective
A
B
C
D
Section 2: Reassessment of risks
Identified risk Actions to be taken Status and Are additional Notes
effectiveness of actions needed?
actions
1
2
3
4
Table 4.9 Checklist 2 - ongoing risk management monitoring for projects
*Managers should establish time frames for periodic reviews in addition to ongoing monitoring of program data.
64/JNU OLE
Summary
• Risk is defined as uncertainty of outcome, whether positive opportunity or negative threat. It is the combination
of the probability of an event and its consequences. It is something that may happen and if it does, will have
an adverse impact on the project.
• It is a major factor to be considered during the management of a project. In the area of contract management,
the term ‘management of risk’ incorporates all the activities required to identify and control risks that may have
an impact on a contract being fulfilled.
• Risk management is the systematic process of planning for, identifying, analysing, responding to and monitoring
project risk.
• It involves processes, tools and techniques that will help the project manager maximize the probability and
consequences of positive events and minimize the probability and consequences of adverse events.
• The purpose of risk management is to ensure levels of risk and uncertainty are properly managed, so that the
project is completed successfully.
• Major elements of risk management process are identifying, assessing, analysing and evaluating risks, action
to mitigate risks, monitoring and control on ongoing basis. Use of concept of probability made for quantifying
risk. Use of check lists provided in the end aims at helping in identification, analysis and mitigation of risk
thereby better management of risk.
• Effective risk management involves the entire project team, as well as outside experts in critical risk areas (e.g.,
technology, manufacturing, logistics, etc.)
• The risk management process includes several steps such as– establishing the context, identification, analysis,
reporting, treatment and monitoring.
• The project scope, including outcomes/benefits, customers, outputs, work and resources, also forms part of the
context and can help highlight potential sources of risk.
• Risk identification usually is done initially by involving key stakeholders, including committee members. Risk
identification continues throughout the life of the project.
• Risk analysis decides whether the level of each risk is acceptable or not and, if not, what actions can be taken
to make it more acceptable. This is the process of examining each risk to refine the risk description, isolate the
cause, quantify the probability of occurrence and determine the nature and impact of possible effects.
• The task of risk identification produces a project risk list.
• The project team puts the risks into categories and assigns each risk to a team member. The project team members
may use this sample risk checklist to develop a specific project risk list.
• To ensure effective monitoring of their risk management efforts, project managers should establish systematic
reviews and specifically include them in the project schedule, assess the effectiveness of actions taken and
identify the status of actions to be taken.
References
• Risk Management. Available at: < http://en.wikipedia.org/wiki/Risk_management> Last assessed 11th January,
2011.
• Risk Management. Available at: < http://www.stsc.hill.af.mil/resources/tech_docs/gsam4/chap5.pdf> Last
assessed 11th January, 2011.
• Risk monitoring and Control. Available at: < http://faculty.kfupm.edu.sa/CEM/alkhalil/PDF_CEM_516/L07%20
Risk%20Monitoring%20&%20%20Control.pdf> Last assessed 11th January, 2011.
• Risk Monitoring and Control. Available at: < http://www.anticlue.net/archives/000821.htm> Last assessed 11th
January, 2011.
• Risk Monitoring and Control: Inputs. Available at: < http://www.super-business.net/Project-Management/
Knowledge/2467.html> Last assessed 11th January, 2011.
65/JNU OLE
• Understanding Public Sector Procurement Processes: A Supplier’s Guide to the Procurement of ICT Goods
and Services, Booklet 6. Available at: <http://www.icn.govt.nz/contentimages/ict%20procurement%20-%20
booklet%206.pdf> Last assessed 11th January, 2011.
Recommended Reading
• M. Frenkel, U. Hommel, G. Dufey, M. Rudolf (2005). Risk Management: Challenge and Opportunity. 838
pages
• Marco Alexander Caiza Andresen (2007). The Process of Risk Management for Projects, GRIN Verlag. 36
pages.
• Reto R. Gallati (2003). Risk Management and Capital Adequacy. McGraw-Hill Professional. 550 pages.
66/JNU OLE
Self Assessment
1. Which of these is not the factor considered in estimation of a project?

a. Total elapsed time
b. Effort
c. Resources
d. Non-specifications
2. Risk management should ______________.

a. explicitly address uncertainty
b. be systematic and structured
c. be based on the oldest information
d. take into account human factors
3. ____________is the one that cannot be reduced or predicted in any manner and it is almost impossible to protect
against this type of risk.
a. Business risk
b. Market risk
c. Systematic risk
d. Political risk
4. Which risk is borne by equity holders due to a firm’s use of debt?

a. Business risk
b. Market risk
c. Financial risk
d. Political risk
5. What decides whether the level of each risk is acceptable or not and, if not, what actions can be taken to make
it more acceptable?
a. Risk identification
b. Risk estimation
c. Risk evaluation
d. Risk description
6. Which of the statement about probability of risk is incorrect?

a. The probability of risk occurring can range anywhere from just above 0% to just below 100%.
b. The probability of risk can be exactly 100%.
c. The probability of risk can’t be exactly 0%.
d. The effect of probability effects severity of each risk.
67/JNU OLE
7. Which of these cannot highlight potential sources of risk?

a. Project scope
b. Outcomes/benefits of risk
c. Tender notice
d. Resource
8. Retention does not include which of the following?

a. Accepting the loss or benefit of gain, from a risk when it occurs.
b. Viable strategy for small risks where the cost of insuring against the risk would be greater over time than
the total losses sustained. All risks that are not avoided or transferred are retained by default.
c. The project manager and the project team decide to accept certain risks.
d. The project manager and the project team change the project plan to deal with a risk.
9. Primary means by which the risk is currently managed is ______________.

a. retention of risk
b. reatment of risk
c. evaluation of risk
d. identification of risk
10. A sentence describing the key negative outcomes that may result from the condition is _________.
a. context
b. condition
c. consequence
d. commitment
68/JNU OLE
Chapter V
Project Closure
Aim
• explain the procedure of project closure
• enlist and explain methods of project termination
• elucidate project life cycle structure
• enlist the benefits of project closure
Objectives
• define project closure and explain its procedure
• understand the features of project closure
• elucidate checklist for closing process
• explain the different methods of project closure
Learning outcome
• learn about reasons behind closing a project
• identify the structure of project life cycle
• understand various methods of project termination
• learn to prepare a project closing report
69/JNU OLE
5.1 Introduction
All things, good and bad, eventually come to an end. Similarly, all projects must come to an end, one way or
another. While some projects may come to an untimely end through cancellation, most projects reach their planned
conclusion. In an industry, we seem to have exquisitely intricate plans for starting new things: projects, applications,
users, policies. Yet we seem to always forget to plan for their eventual end: the closure of projects, the removal of
applications, the retirement of servers and the departure of users. Why do we find it so hard to achieve closure?
The lack of closure can be costly.
Projects are designed to produce a specific, unique outcome and when that outcome is delivered, the project should
end. This “end” can be a process in and of itself, normally referred to as project closure.
5.2 Project Life Cycle Structure

Projects vary in size and complexity. No matter how large or small, simple or complex, all projects can be mapped
to the following life cycle structure:
• starting the project
• organising and preparing
• carrying out the work
• closing the project
Starting Organizing and Carrying out the work Closing

the preparing the
project project
Cost/Staffing
Cost and staffing TIME

Level Curve
Hiltrud Grisot d’ Alliance, PMP, Project management Consultant WWW.HAD-PM.COM
Fig. 5.1 Project life cycle structure

(Source: http://hda-pm.com/knowledgeBase/basics/88004-LifeCycle.html)
• Cost and staffing level are low at the start, at peak as the work is carried out and drop rapidly as the project
draws to a close.
• Stakeholder influences, risk and uncertainty are greatest at the start of the project. These factors decrease over
the life of the project.
70/JNU OLE
• Ability to influence the final characteristics of the project’s product, without significantly impacting cost, is
highest at the start of the project and decreases as the project progresses toward completion.
5.3 Project Closure

• Project closure phase is the last phase of the project life cycle. It is just as important as the other project phases
of initiating, planning and monitoring.
• Project closure is the formal ‘ending’ or termination of a project.
• Usually it will occur once all of the work of the project is finished, all of the outputs have been delivered and
accepted by the business owner(s) and the target outcomes have been generated or secured.
• The steps involved in closing a project should be planned and documented at the beginning of the project, but
the process may vary from project to project.
• The initiation of the project closure phase is determined by the completion of all project objectives and acceptance
of the end product by the customer.
• The diagram below shows the main parts of a project management framework. It can be seen from the framework
that project closure is the last process of a project.
Fig. 5.2 Framework of project management

(Source: http://commons.wikimedia.org/wiki/File:Project_Management_(phases).png)
• A project involves a group of inter-related activities that are planned and then executed in a certain sequence to
create a unique product or service, within a specific timeframe, to realise the outcomes/benefits.
• It means that all projects have an ‘end’ date by which time all of the inter-related activities are completed.
• Projects that are not formally closed often ‘drift on’. Usually it is a sign that there has been a loss of control
of the project and symptoms, such as continually changing scope, a continued demand for resources and an
indeterminate final delivery date, are displayed.
5.4 Project Management Framework: Constraints

• Project management is the application of knowledge, skills, tools and techniques to project activities to meet
the project requirements.
• Project management is accomplished through the appropriate application and integration of 5 process groups:
initiating, planning, executing, monitoring and controlling and closing.
• The project manager is responsible for accomplishing the project objectives.
• Managing a project typically includes:
identifying requirements
71/JNU OLE
addressing the various needs, concerns and expectations of the stakeholders as the project is planned and
carried out
Constraints - balancing the competing constraints including Scope, Quality, Schedule, Budget, Resources
and Risk.
Scope
Less More
Quality If any one

Less More
factor
Schedule
Project Success
Less More
changes,
at least
Budget one other
Less More
factor is
Resources likely to be
Less More
affected!
Risk Less More
Hiltrud Grisot d’ Alliance, PMP, Project management Consultant WWW. HAD-PM.COM
Fig. 5.3 Framework of project management constraints

(Source: http://hda-pm.com/knowledgebase/basics/88003-Framework.html)
5.5 Reasons for Project Closure

• A project can be terminated in two ways, naturally and unnaturally.
• Natural project closure occurs when all the project requirements have been met.
• Unnatural project closure occurs when performance is inadequate, the project’s requirements have changed or
some assumptions are proven to be false and are no longer valid,
• The most frequent causes of unnatural closure are insufficient time and inadequate project funding.
Why does project closure matter?

A project has a beginning and an end. But without a formal closure process, project teams can fail to recognise the
end and then the project can drag on sometimes at great expense. Project closure ensures that:
• outcomes match the stated goals of the project
• customers and stakeholders are happy with the results
• critical knowledge is captured
• the team feels a sense of completion
• project resources are released for new projects
72/JNU OLE
Which projects need closure?
• Every project requires closure. For large or complex projects, it’s a good idea to close out each major project
phase (for example, design, code and test, or training) individually.
• The closure process can also help by identifying lessons learned on projects that are cancelled or deferred before
completion.
5.6 Project Termination

• In many cases, the duration of the contract will be shorter than the duration of the project, especially if the client
has only outsourced a specific phase or a portion of the project work.
• A contract may end early because of mutual agreement between the parties or because of a breach of the contract
terms.
• To clarify, a contract can end in one of three ways:
Successful performance: Successful performance is what we think of as “the work is done.” All the work
specified in the contract was performed by the seller and formally accepted by the buyer.
Mutual agreement: If there is mutual agreement, the contract is terminated because both the buyer and
seller involved in the project agree that the project work should not continue.
Breach: If a project contract is terminated due to breach, a party involved in the project work has failed to
obey its side of the contract.
• Terminating a project satisfactorily is nearly as difficult as starting a project because panic sets in towards the
end of the second term as client realises, in many cases, the vast amount of work yet to be completed .
• Therefore, it is important that the project has been taken to a logical termination point and reported fully and
correctly to that point.
5.6.1 Methods of Project Termination

There are six methods of project termination as indicated in brief below:
• Completion: Successful performance; getting the work done; Project success - Project has achieved its goals
or objectives, a new project is undertaken.
• Cancelled: Due to poor performance, bad utilisation of resource, or re-alignment with organisational goals.
Starvation or lack of proper resources; Project failure - Project has not achieved its goals or objectives, too
complex project, political decision by company failed.
• Displacement: Project becomes obsolete due to another project.
• Collapse: Project ends due to external factors, such as natural disasters, corporate mergers and so on.
• Absorption: The project becomes a permanent part of the sponsoring organisation (a new department or division).
Key personnel are transferred to continue their work in completely new environment. Project is picked up by
parent company or with wider organisation but project is decomposed into separate areas of functionality which
are dispersed.
• Deterioration: A “slow death,” neglect. The sponsoring organisation gradually reduces its support and budget
for the project.
5.7 Benefits of Complete Project Closure

• It improves the morale and confidence of the project team.
• The team members feel a sense of achievement. Therefore, performance in future projects can improve.
• Customer satisfaction is also increased. The company receives experience in controlling project costs.
• Staff members can learn from the project’s lessons and they will be able to continually improve the company’s
processes.
73/JNU OLE
5.8 Closure Planning

• Planning for the closure of a project is important. Essentially, successful project finalisation involves
following:
formal acceptance of project outputs by the business owner(s)
an internal review of project outputs and outcomes/benefits against the project business plan
disbanding the team
‘tying up loose ends’
• The extent to which procedures for closure are formalised depends on the nature and size of the project. The
Steering Committee, or project sponsor, in the case of a small project, is responsible for formally closing a
project.
• The project sponsor, in consultation with the project manager, may propose the timing for closing the project. It
is important to ensure that all project activities are satisfactorily completed. As the end of the project approaches,
it may help to produce ongoing checklists of outstanding work.
• Other means to ensure outstanding work is not forgotten include controlling work at a greater level of detail,
holding more frequent project team meetings and/or creating a special taskforce for completing outstanding
work.
• The project business plan will help the Steering Committee and/or project sponsor to determine when the project
will be closed, but there can be a problem when the realisation of the outcomes/benefits is spread over a period
of time, e.g., a year or more.
• The project team usually disbands once the outputs have been delivered and accepted and there is often no
project budget once the team has disbanded. In this case, a decision will need to be made as to whom and how
the residual tasks are performed, e.g., arranging and managing the post-project review/evaluation.
• Project closure, or ‘close-out’, essentially involves winding up the project. This includes:
ensuring that records are compiled and retained for a specified time
determining whether all of the project completion criteria have been met
identifying any outstanding project activities, risks or issues
handing over all project deliverables and documentation to the customer
cancelling supplier contracts and releasing project resources to the business
communicating the closure of the project to all stakeholders and interested parties
• The final stages of a broadly successful project can be most rewarding. It is at this stage that people can finally
see the realisation of plans and objectives. At the same time though, the ‘tying up of loose ends’ can be tedious
and people can be more motivated to work on new projects.
• However, it is important that a project is satisfactorily closed, based on the following general approaches:
Acceptance of project outputs/deliverables by the business owner(s)

Be it a technical system, a building or a set of policies, the outputs of the project should be successfully
transferred to the project’s business owner(s).
It should be planned well in advance and preferably, in the initial project plans. It is important to ensure the
business owner(s) will accept the handover date when they are given formal responsibility for the outputs/
deliverables.
Additionally, the project team should ensure that the design of the product is adequately recorded.
Disbanding the project team and ‘tying up loose ends’

• It is important to ensure that all project activities are satisfactorily completed or responsibility for any outstanding
activities (loose ends) has been re-assigned.
• In a large and/or complex project, an external post-completion review/audit, before formal closure by the
Steering Committee, often occurs.
74/JNU OLE
Following points should be considered:
• Project staff: What steps are being taken to manage the movement of project staff from the project to other
roles, including the timing of their move and the capture of their project knowledge? There should be plans for
releasing resources before the project is to be finalised and project teams should be gradually wound down. It
should be done compassionately, as people often have put a great deal of effort into the project and it will create
bad feelings for both, this project and the next one if they feel they are treated unfairly at this stage.
• Issues management: Identify any outstanding issues and who will continue to resolve the issues.
• Risk management: Identify any risks that will be transferred to an operational area and who will take on
responsibility for monitoring them.
• Financial management: Outline the final financial position and what will happen to any excess funds or how
any deficit will be funded.
• Asset management: Describe any assets that were required by the project and who will manage them on
completion of the project.
• Records management: Identify what arrangements have been put in place for the storage, security and backup
of hard copy and soft (electronic) copy records and project documents.
5.9 Project Closure Process

• Most of the work involved in this phase is concerned with the preparation of information by the project manager
for the project board to enable them to make the decision to close the project, or not. The authority for closure
can only be given by the project board.
• All the processes involved in closing a project may be done in parallel - or at least with considerable overlap.
• The objectives of the actions involved here are to:
ensure an orderly close
identify follow on actions and plan the post project review
evaluate the project
5.9.1 Ensure an Orderly Close

• One of the defining features of a project is that it is finite - it has a start and an end. If the project loses this
distinctiveness, it loses some of its effectiveness over purely operational management approaches.
• Therefore, every project must be brought to an orderly close, ensuring that the customer is satisfied with the
outcome and demonstrating this by providing a ‘customer acceptance’ sign-off.
• It is important to assure that arrangements are in place for ongoing support and maintenance must be achieved
together with a proper audit trail for project documentation, should it be needed in the future.
5.9.2 Identify Follow-on Actions and Plan the Post Project Review
• This involves essentially picking up and documenting any loose ends that remain at the conclusion of the project
and planning for a future review of the project.
• The follow-on actions will be presented to the project board as recommendations. The project board will be
responsible for directing these recommendations to the appropriate audience for attention.
• It is also at this point that a post project review plan will be created which will be used to set up a future review
of whether the business benefits identified at the outset of the project have been achieved.
• It is not a project activity to carry out the postproject review, only to plan it. This plan will make use of the
information contained in the Business Case. The plan should include:
A date for the Post Project Review (PPR).
What benefit achievements are to be measured?
When benefit achievement can be measured?
75/JNU OLE
How the achievement can be measured?

The pre-delivery situation against which achievement is to be compared (baselines)
Who is needed to carry out the measurements (individuals or skill types)?
Project completion celebration

• Whether a formal product launch or an informal gathering for those involved in the project, a project
completion celebration is a good way to mark the end of what may have been a significant period for the project
participants.
• A team dinner, outing, gift certificates, or other rewards are minor costs that generate a large return in terms of
morale and job satisfaction.
Recognition and reward

• Team members who have worked hard, they deserve some real recognition and rewards. Their project manager
has the best understanding of who pulled the project out of each tight spot, which members have transformed
themselves with new skills and who might be ready for a new level of responsibility.
• This puts project manager in the perfect position to remind the team’s superiors of what each team member has
brought to the project.
Shut down the project office

• If project team used a project management office or a dedicated work area, probably arrangements for returning
that space to general use have to be made. For example, following actions may be needed:
return rented furniture or PCs
reassign temporary staff
close down LAN and e-mail accounts
• When organising the shutdown process for the project office, it can be helpful to review the original setup
procedures.
Project manager
Role of the project manager during closure includes:
• verifying project scope and stakeholder acceptance
• formally terminating activities of the project
• closing project finances, administration and contracts
• articulating and completing a handover strategy
• reporting to donors
• promoting learning
The project manager should ensure that:

• Lessons learned have been documented.
• Lessons learned form an integral part of the project closure phase. It helps answer the following typical question
during project closure.
• Did the delivered product/solution meet the project requirements and objectives?
• Was the customer satisfied?
• Was project schedule met?
• Was the project completed within budgeted cost?
• Were the risks identified and mitigated?
• What could be done to improve the process?
76/JNU OLE
Some of the most valuable knowledge one can capture is in the form of lessons learned. One can gather this
information from several sources:
• Schedule a meeting with the project’s sponsor and key stakeholders to get their final signoff on the project and
to capture their thoughts. A formal signoff documents that the sponsor is satisfied, objectives have been met
and the project is truly complete.
• Survey team members about what worked and what didn’t.
• Ask consultants and vendors for objective feedback, both about the organisation and about the project’s
execution.
• Provide a summary of results to team members, either as a presentation at a meeting or as a formal document.
• An ‘end project report’ has been prepared for sign-off by the project board.
The project manager undertake following activities:

• review final metrics
• spot and highlight project highs and lows
• acknowledge the contributions of team members
• share the key lessons learned
• discuss related projects for the future (such as software upgrades, new features and other opportunities for
ongoing improvement)
Project library
To store all key documents those are accessible to future project teams. Possible document categories include:
• project planning documents
• status reports
• design documents
test cases and test results
issues and resolutions
risk documentation
change requests
presentations
important communications (both those sent and those received)
time and expense reports
contracts and invoices
• Ideally, the project library is set up at the beginning of the project and team members add documents as they
produce them.
• It’s a good idea to maintain the library in an electronic format that is backed up at regular intervals—something
as simple as a set of folders on the LAN or as robust as a knowledge management system.
5.9.3 Evaluate the Project

• A Project Evaluation Review (PER) should be carried out. This is an internal project evaluation that aims to
assess how successful the project has been, not how successful the end product is and to capture any lessons
learned for the benefit of future projects.
• This assessment will result in the production of two documents:
The End Project Report
The Lesson Learned Report
77/JNU OLE
5.10 Closing Unsuccessful Project

• It is important to recognise that projects can be closed at any point during their project life cycle. Closing a
successfully completed project can be challenging at the best of times, but closing (or stopping) a project that
probably did not achieve its objectives can be seriously difficult, especially if considerable resources have
already been expended on it.
• Many unsuccessful projects that have not been completed at the appropriate time are left to ‘drag on’. The
project sponsor/Steering Committee is ultimately responsible for closing down a project, whether it is successful
(complete) or unsuccessful (incomplete).
• Signs of an unsuccessful project that may need to be closed before being completed include:
Impetus for the project has disappeared or is greatly reduced

project team is unable consistently to meet major project milestones
the activities involved with the project do not match with the stated objectives
clients is not accepting the outputs from the project
major project risks are realised and are unmanageable
key project team members leave the project
• Sometimes, the project manager often will not be able to indicate if their project is in need of closure. Essentially,
the steps a Steering Committee should take for closing an incomplete project include:
If there are serious problems with the project, informally discuss the pros and cons of closing it with members
of the Steering Committee.
Facilitate an independent project review - i.e., obtain another opinion from someone without any stake in
the project.
Discuss the ramifications for closing the project with those who will be affected by the decision - ensure
that any decision to close the project will not be untenable for any major players, especially executive
management.
Formally discuss the closure of the project in a Steering Committee meeting—any decision to close or
continue with the project should be justified formally and the reasons for it should be documented.
Facilitate activities involved with wrapping up project activities and removing resources
Facilitate a formal external project review so that lessons can be learnt for future situations
For the Project Manager and Team responsible, the decision to close an incomplete project can be distressing
and demoralising. They should remember that the reasons for project failure can be complex and varied
and that responsibility rarely rests entirely with one or two individuals. In this situation, it is important to
ensure that project resources are appropriately redeployed.
• There should also be debriefing sessions for all those people involved with the project and the group as a whole.
In some cases, it may be useful to replace the Project Manager and/or other members of the Project Team with
new people who can close down the project as quickly as possible.
5.11 Project Closure Report

• The Project Closure Report is written for a broad audience including senior management (IT & Business), project
participants, stakeholders, users, steering committees, application and technical support staff, etc.
• Project closure begins with wrapping up administrative documentation and providing a support plan for product
maintenance.
• Much of a project’s documentation is created over the life of the project. Document collection and update
procedures are probably already well established.
• This is the project manager’s report to the project board on how well the project has performed against its project
initiation document, including the original planned cost, timetable and desired deliverables and the revised
business case and final version of the project plan.
78/JNU OLE
• It should include:
Achievement of the project’s objectives, summarizing whether the project was successful or not.
Performance against the planned target time and cost.
The effect on the original project plan and business case of any changes that were approved.
Final analysis on change issues received during the project.
The total impact of approved changes.
A description of any abnormal events causing deviations from plans.
An assessment of technical methods and tools used.
Recommendations for future enhancement or modification of the project management method.
Useful measurements on how much effort was required to create the various products.
Notes on effective and ineffective quality reviews and other tests, including reasons why they worked well
or badly.
Lessons learned during the project:

• Information required in a project closure report includes:
Final updated project status report showing the original project plan and the actual project performance at
completion- tasks, schedules, resources, etc.
Description of the final products/services delivered by the project.
Lessons learned from the project - technical, business process, management, etc. What worked well and
what didn’t. Things that will be of value on future projects and things to avoid.
Specific feedback to/from any of the constituencies involved with the project.
Pointers to further documentation - project history, user documentation, system documentation, etc.
• Using this report, project closure can be performed by:
identifying the project completion criteria
listing any outstanding activities or deliverables
creating a plan for passing deliverables to your customer
planning the handover of project documentation
ceasing supplier contracts and agreements
releasing projects resources to the business
communicating the closure of the project
• The project closure report is unique because:
it has formatted tables and sections
lists all of the key activities needed to close a project
contains step-by-step instructions to help to complete it
includes lots of practical examples, tips and hints
is pre-completed to save you time and effort
5.12 Common Project Closing Issues

Project closure process should consider following issues:
• Completing the work: An orderly closeout requires that some kind of checklist of tasks and issues be prepared
and used as a control mechanism.
• Handing over: The activity of handover includes not only the transfer of the physical deliverables, but also the
training of users, the sharing of technical designs and important design concepts, the provision of drawings and
specifications and much more besides.
• Gaining acceptance for the product: Gaining acceptance is not as simple or straightforward as it might
79/JNU OLE
appear at first. A major activity here involves having the customer who is signing the acceptance now accept
full responsibility for managing the new product or service. This customer may:
lack confidence
be getting negative feedback from users
realise that what has been delivered is not what is really needed because of their inability to define the scope
correctly during project initiation
• Lessons learned: The object of the lessons learned review is to reflect on the events that took place in the course
of the project and to consider what might have been done differently to improve the results obtained.
• Documenting: Completing the documentation and archiving the project records are probably the most
monotonous and least exciting parts of the project closeout management.
• Team dispersing: The final element of project closeout management is disbanding the project team and ending
relationships in an orderly way.
• Payment: Getting paid, drives out many closeout actions. Unresolved issues and incomplete tasks that frustrate
customers and end users drag on, meanwhile, the project manager hopes.
• Acrimony: Acceptance becomes acrimonious, with the project team doing the minimum they have to, to get
the signature - the customer signing an acceptance only grudgingly.
• Extra costs: Closeout activities cost money. The project team is busy on the next urgent project and there just
never seems to be the time to fit the meeting into a crowded schedule.
• Archiving: The task of completing project records is assigned a low priority.
• Lessons learned: Lessons learned may be noted, discussed and documented, but they aren’t learned.
• Knowledge management: Knowledge management is a hot management topic these days. It is about capturing
and leveraging an organisation’s knowledge to achieve or maintain competitive advantage. Learning lessons
on a project is much more about the knowledge than it is about information and hence can be characterised as
knowledge management. The learning lessons element of project closeout management needs to be seen not
as a part of the bundle of activities associated with completing the project, but as an input to the knowledge
management process. As organisations seek to reduce the social and economic impact of poor project performance,
project closeout management will emerge as the gateway to an organisation’s knowledge about what constitutes
excellence in project management practice.
5.13 Common Project Closing Challenges

The proper ending of a project is the most neglected project management process. To understand why it is so and
to better prepare for this important activity, here is a review of the common challenges that project managers and
organisations have:
• Rush to next project: Due to the pace of business in today’s times, there is often zero downtime between
project assignments and in many cases, the next project is getting started before one have completely ended the
previous one. This mode of operation often results in an incomplete project closure, especially if the project is
completely in-house.
• No accountability: If there is no one to (or department) make sure that the project closing activities are occurring
or if it is not part of evaluation, it is very easy to let this go.
• Not seen as “value-add” activity: If a project manager does not see the organisation putting a priority on
project, those activities which are less likely to follow can be closed.
• Lack of transition plan: Quite simply, there was not enough attention paid at a detailed level to how the project
would end and how the deliverables would be handed off to the eventual owners.
80/JNU OLE
5.14 Importance of Formal Project Termination Procedures
• As projects are near completion, there is a natural tendency to minimise costs by transferring people as soon
as possible and by closing out work orders. This is the stage where it becomes the responsibility of the project
manager to devise project termination activities into the project work-plan. These should be seen as vital parts
of the project and not just an afterthought.
• If however, the value of effective project termination activities is not banked then the opportunity to tie up the
loose ends, do staff evaluations and document vital learning is lost. Thus it should be ensured that final reports
are well written and an effective transfer of raw materials to other programs takes place on time. For this purpose,
many projects may even require one to two months after work completion simply for administrative reporting
and final cost summary.
• Just like every other phase, the project termination can also be summarised with the help of a few guidelines. The
first one pertains to the ‘project audit’ which includes the status, forecasts, risk assessments and recommendations
for the project. The next activity concerns the ‘evaluation’ phase which deals with the scope accomplished,
technical objectives met and projection of historical data. Other close-out items may consist of final measurements,
final reports, client feedback and testimonials.
• Project termination can not even be disregarded for an unsuccessful project. Even in such a case, there are
key learnings, team evaluations and other wrap-up activities to make the most of what has been done in the
project.
5.15 Project Closure Checklist

Table given below provides a comprehensive project closure checklist starting from scope of project to lessons
learnt. The table provides valuable guidelines for preparing exhaustive checklist for any projects.
Project Closure Checklist Status
Scope, Objectives, Time and Budget

The project schedule has been tracked to completion: All work planned in the project schedule
has been completed, with actual work entered into the schedule against planned work for all
tasks.
The project budget has been tracked to completion: All expenses and capital purchases
allocated to the project.
All change requests approved in the project have been completed.
Any outstanding work that is not going to be completed by the project is recorded in the
outstanding work definition document and is signed off by the project sponsor.
All remaining enhancements and suggestions for further work which are deemed outside the
scope of the project have been recorded and delivered to the project sponsor.
The project objectives have been reviewed by the steering committee and completion of the
project in reference to these agreed.
81/JNU OLE
All user acceptance testing criteria have been met and all components of the project
implemented, with final acceptance of the project signed off by the customer.
Resources are no longer working on the project, no further deliverables are being created and
no further costs will be incurred.
Documentation and Archiving
Documentation of the solutions delivered by the project has been completed and
distributed to the appropriate areas of the business and support functions.
A historical store of all project records including documentation has been created and
storage of project records have been arranged in accordance with statutory and CSU
guidelines.
Handover
All equipment used by the project has been accounted for. Any equipment rented or
loaned has been returned.
Responsibilities for operating the delivered solution have been handed over to the
relevant divisions of the organisation.
Support arrangements have been implemented, including support contracts.
Any current warranty arrangements for items produced by the project have been
handed over to the appropriate division of the organisation.
A benefits realisation register has been created and a follow-up plan to measure
benefits has been put in place.
Human Resource
Human resource requirements have been fulfilled for personnel on the project (e.g.,
performance appraisals, timesheets).
Project personnel have been advised of any obligations (e.g., confidentiality, privacy,
security) that remain in force following the completion of the project.
Project personnel reassignment has been planned, organised, communicated and in
action to ensure smooth transition to their next assignment.
End of project celebration for the team has been held.
Contractual and Financial
All deliveries to the project specified in the contract have been made in accordance
with the terms of the contract.
All financial payments specified in the contracts have been made or, where they
pertain to current warranty arrangements, have been re-assigned to the appropriate
division of the organisation.
All contractual obligations of the project have been fulfilled or, where agreed to kept
open. These have been handed over to the appropriate division of the organisation and
formal acceptance of this has been obtained from the project sponsor.
Supplier performance reports have been completed, evaluating the deliverables
supplied for use in future selection processes.
Post Implementation Review (PIR)
PIR workshops/interviews have been held to gather information about the project.
Customer assessment of the project has been received.
The project team has reviewed (as part of the PIR) the project effectiveness and
identified successes to retain and improvements required.
Lessons learned from the PIR have been documented.

Table 5.1 Project closure checklist
82/JNU OLE
5.16 Project End Checklist - 11 Important Steps
The 11 steps included in the project end checklist will ensure that a complete project close is performed and leave
the stakeholders with a positive lasting impression of project management abilities.
• gain client acceptance
• transition deliverables to owner
• close out contract obligations
• capture lessons learned
• update organisation’s central information repository
• issue final financials
• close accounts and charge codes
• update resource schedules
• conduct performance evaluation
• market project accomplishments
• ask for referrals/references
5.17 Template: Project Closure Report
Project Closure Report
________________________________________
Project Name:
Department:
Focus Area:
Product/Process:
________________________________________
83/JNU OLE
Prepared by
Document Owner(s) Project/Organisation Role
Project Closure Report Version Control
Version Date Author Change Description
Note: For standard sections of the project closure report template that have been excluded from the present
document, the section headings have been moved to the ‘Project Closure Report Sections Omitted’ list at the end.
Table of Contents
1 Project Closure Report Purpose 1

2 Project Closure Report Goals 1
3 Project Closure Report Summary 1
3.1 Project Background Overview 1
3.2 Project Highlights and Best Practices 2
3.3 Project Closure Synopsis 2
4 Project Metrics Performance 2
4.1 Goals and Objectives Performance 3
4.2 Success Criteria Performance 3
4.3 Milestone and Deliverables Performance 3
4.4 Schedule Performance 3
4.5 Budget Performance 3
4.6 Metrics Performance Recommendations 4
5 Project Closure Tasks 4
5.1 Resource Management 4
5.2 Issue Management 4
5.3 Risk Management 5
5.4 Quality Management 5
5.5 Communication Management 5
5.6 Customer Expectation Management 5
5.7 Asset Management 5
5.8 Lessons Learned 6
5.9 Postproject Tasks 6
5.10 Project Closure Recommendations 6
6 Project Closure Report Approvals 6
7 Appendices 7
7.1 Project Closure Report Sections Omitted 7
84/JNU OLE
Project Closure Report Goals
[Replace this text with your own statement of goals, or use the following sample.]
This project closure report is created to accomplish the following goals:

• Review and validate the milestones and success of the project.
• Confirm outstanding issues, risks and recommendations.
• Outline tasks and activities required to close the project.
• Identify project highlights and best practices for future projects.
Project Closure Report Summary
Project Background Overview
[Replace this text with a brief description of the project background.]

• What were the original goals, objectives and success criteria?
• Refer to project overview statement and/or project charter for this information.
Project Highlights and Best Practices

Project Highlights:
• [Highlight]
• [Highlight]
Best Practices:
• [Best practice]
• [Best practice]
Project Metrics Performance
Project Closure Synopsis
[Replace this text with a brief description of why the project is being closed.]
• Is it being closed because all project objectives and deliverables have been met?
• Or is it being closed for other reasons (loss of funding, shift in strategy, etc.)?
Goals and Objectives Performance

[Replace this text with a comparison of actual project performance to project objectives.]
Success Criteria Performance
[Replace this text with details of project performance in terms of targeted success criteria.]
• Were all criteria achieved? To what level of success?
• If some criteria were not achieved, what were the reasons?
Is achievement anticipated at a later date?
• Who is responsible for measuring continued progress?
85/JNU OLE
Milestones and Deliverables Performance
[Replace this text with an outline of actual performance of project milestones and corresponding
deliverables.]
• Were all deliverables achieved with high quality and customer acceptance?
• If not, what were the reasons?
• Is achievement anticipated at a later date?
Schedule Performance
Project Schedule Overview:

• [Replace this text with the overview.]
Project Schedule Control Process:

• [Replace this text with the control process.]
Project Schedule Corrective Actions:

• [Replace this text with the corrective actions.]
Project Schedule Integration with Managing Project:

• [Replace this text with the integration.]
Budget Performance
Project Budget Overview:

• [Replace this text with the overview.]
Project Budget Corrective Actions:

• [Replace this text with the corrective actions.]
Metrics Performance Recommendations

• [Replace this text with an outline of metrics performance recommendations for the future.]
86/JNU OLE
Project Closure Tasks
Resource Management
• [Replace this text with an explanation of how resources were managed.]
• What resource needs changed during the project?
• Outline the steps to be taken in shifting project resources to other projects.
• Explain how project knowledge (IP) from project team members will be captured and retained for
future projects.
Issue Management
[Replace this text with a list of any issues still outstanding at the end of the project.]
• Will each issue be resolved?
• Who will continue to report on each issue’s progress?
Risk Management
Project Risks Mitigated:
[Replace this text with the risks mitigated.]
Outstanding Project Risks:

[Replace this text with the outstanding risks.]
Quality Management
[Replace this text with a description of how quality management processes were used and integrated into the
project and how quality control measures provided quality assurance.]
Communication Management
[Replace this text with an outline of the project communication process.]

• How effective was the process?
• What changes were made during the project?
Customer Expectation Management

[Replace this text with a brief description of how customer expectations were managed.]
• Did these expectations vary during the course of the project? If so, how?
87/JNU OLE
Asset Management
[Replace this text with a list of assets remaining at the end of the project.]
• How will those assets be dispositional?
• Who will manage the disposition process?
Lessons Learned
[Replace this text with a list of successes and shortcomings to remember for the future.]
• Which activities and processes worked well?
• Which could have been improved and how?
Post project Tasks
[Replace this text with a list of outstanding issues for this project.]
• What actions are not yet completed? Who is responsible for them?
• Which success criteria are not yet met? Which deliverables are not yet achieved?
• Which training requirements are still outstanding?
• This information can be summarized from details in the preceding sections.
Project Closure Recommendations
[Replace this text with a list of recommendations arising from review of closure tasks.]
• The main recommendation would usually be to gain project closure approval from the Project Sponsor,
including agreement that the project has fulfilled all of the requirements as documented and that the Project
Sponsor is satisfied that all outstanding items have been satisfactorily addressed.
88/JNU OLE
Project Closure Report Approvals
Prepared by __________________________________
([Job Title])
Approved by __________________________________
([Job Title])
__________________________________
([Job Title])
__________________________________
([Job Title])
Approval Date __________________________________
________________________________________
Appendices
________________________________________
89/JNU OLE
Summary
• Project closure phase is the last phase of the project life cycle. It is just as important as the other project phases
of initiating, planning and monitoring. It is the formal ‘ending’ or termination of a project.
• Usually it will occur once all of the work of the project is finished, all of the outputs have been delivered and
accepted by the business owner(s) and the target outcomes have been generated or secured.
• The steps involved in closing a project should be planned and documented at the beginning of the project, but
the process may vary from project to project.
• Formal project closure ensures that the team has met its objectives, satisfied the customer, gained important
knowledge and been rewarded for their efforts.
• Terminating a project satisfactorily is nearly as difficult as starting a project because panic sets in towards the
end of the second term as client realises, in many cases, the vast amount of work still before him .
• It is important to recognise that projects can be closed at any point during their project life cycle. Closing a
successfully completed project can be challenging at the best of times, but closing (or stopping) a project that
probably did not achieve its objectives can be seriously difficult, especially if considerable resources have
already been expended on it.
• Therefore, every project must be brought to an orderly close, ensuring that the customer is satisfied with the
outcome and demonstrating this by providing a ‘customer acceptance’ sign-off.
• Assurance that arrangements are in place for ongoing support and maintenance must be achieved together with
a proper audit trail for project documentation, should it be needed in the future.
• A project checklist should be maintained to keep a record of all the tasks performed and to ensure that no
important job is skipped. A detailed project report should be prepared with details from the initiation, execution
and closure phase. This report is a documentation of project experiences, facts, lessons learned and so on.
References
• Project Closure & Termination Phase. Available at: <http://www.suite101.com/content/project-closure-a129630>
Last accessed 12th January, 2011.
• Project Closure and Termination Phase: Activity Checklist for Proper Project Completion. Available at: <http://
www.suite101.com/content/project-closure-a129630#ixzz1AtWq30O1> Last accessed 12th January, 2011.
• Project Closure. Available at: http://e-articles.info/e/a/title/Project-closure> Last accessed 12th January, 2011.
• Project Life Cycle - Project Cycle Management. Available at: <http//www.visitask.com/project-life-cycle.asp>
Last accessed 12th January 2011.
• Project Management, Lecture 11- Project Closure. Available at: <http://www.halifax.ac/Download/PgD%20
SBIT/PgD%20SBIT%20New/712_PM/PM%20-%20Lecture%2011%20-%20Project%20Closure.pdf> Last
accessed 12th January, 2011.
Recommended Reading
• Joseph Phillips (2010). IT Project Management: On Track from Start to Finish. McGraw Hill Professional, 3rd
edition, 640 pages.
• Stanley E. Portny (2010) Project Management for Dummies. Kindle Publication, 3rd edition.
90/JNU OLE
Self Assessment
1. Which of these is not a constraint for project management?

a. Scope
b. Quantity
c. Schedule
d. Budget
2. Project management is accomplished through the appropriate application and integration of five process groups,
of which, ________ is the final stage.
a. project initiating
b. project execution
c. project monitoring
d. project closing
3. What does project closure ensure?

a. Outcomes match the stated goals of the project.
b. Customers and stakeholders are happy with the results.
c. The team feels a sense of completion.
d. Project resources are not released for new projects.
4. Which of the statements about project closure is incorrect?

a. A project can be terminated two ways, naturally and unnaturally.
b. Natural project closure occurs when the project requirements have all been met.
c. Unnatural project closure occurs when performance is inadequate, the project’s requirements have changed
or some assumptions are proven to be false and are no longer valid,
d. The most frequent causes of natural closure are insufficient time and inadequate project funding.
5. There are six methods of project termination. Which of the following is not one of them?
a. Dispersion
b. Completion
c. Cancelled
d. Absorption
6. Which of these is not the common project closing challenge?

a. Rush to next project
b. Accountability
c. Not seen as “value-add” activity
d. Lack of transition plan
91/JNU OLE
7. What is the problem in gaining acceptance for product?

a. Confidence
b. Difficulty in getting positive feedback from users
c. Inability to define the scope correctly during project initiation
d. Lack of confidence
8. Which one is not a method of project termination

a. Deterioration
b. Absorption
c. Breach
d. Collapse
9. Which of these is not an objective of the project closure actions?

a. Ensure an orderly close
b. Identify follow on actions
c. Plan the pre project review
d. Evaluate the project
10. Which of these is not the role of project manager?

a. Verify project scope and stakeholder acceptance
b. Terminate activities of the project without information
c. Close project finances, administration and contracts
d. Articulate and complete a handover strategy
92/JNU OLE
Chapter VI
Project Management Software
Aim
• explain about project management software
• enlist various project management softwares
• describe about implementing these softwares
Objectives
• describe project management software
• understand the features of these softwares
• know about critical path method
Learning outcome
At the end of this chapter, students will be able to:
• understand the concept of project management software
• learn about applications of these softwares
• know how application of technology can lead the project successfully
• identify the features and tasks of project management software
93/JNU OLE
6.1 Introduction
When the size of project increases it becomes difficult and at times even impossible, to manage projects effectively
using manual techniques. Implementing technology is a key part of improving an organisation’s project management
capability.
Beyond the traditional functionality of early project scheduling tools, project management software has now evolved
to include quite sophisticated multi-project functionality that supports standardised project operations across an
entire portfolio of projects.
This type of technology provides a number of benefits in its ability to automate the processes and improving both
productivity and delivery effectiveness. It also allows managing complex projects, do things that can’t be done easily
on a piece of paper such as analyse and search data across projects. The technology allows enhanced knowledge
sharing, virtual teaming, information exchange and automating workflow.
Technology thus provides a range of benefits such as;

• faster, better informed decisions
• strategic cross project resource management
• proper alignment of people and projects with strategic objectives
• integrated workflow and advanced collaboration
• automated tracking and reporting
Technology should be seen as an enabler of capability, reliant on people and process to support project. However,
while project management software will help organisations manage projects faster, more easily and potentially more
cheaply, it does not provide best practice capability in itself. Because project management software is tangible and
easier to visualise as a component of organisational project management, it is often seen as representing the same.
Indeed different types of tools and/or functionality should be implemented at different levels of organisational
project management maturity.
6.2 Project Management Software

• Project management is the art of managing and defining a project plan. This requires stringent organisation
skills and oversight on tasks, resources and delivery dates.
• Complex projects can take many years to complete. By their very nature, these projects are expensive and
time-consuming, which requires strict organisational skills to ensure delivery of the final objective. Project
management software is a tool to assist in the management and communication of the risks and tasks necessary
to complete a project.
• Project management software is a term covering many types of software, including scheduling, resource
allocation, collaboration software, communication and documentation systems, which are used to deal with
the complexity of large projects. These applications allow organisations to plan, resource, manage and report,
project cost, work and time.
• Project management software encapsulates the work flow management of a project plan into a software
application that can be used as a tool to explain the objectives, delivery milestone dates and dependencies
within a project.
• A project plan requires resource management and resource allocation to be successful. Resource levelling is a
term used in project management to ensure that the project resources have been estimated sufficiently. In project
management software, resources allocation reports give the project manager a tool to ensure that resource demand
does not exceed the resources available for the project.
94/JNU OLE
6.2.1 Project Management Software: Features
Project management software has following main five features:
• project management
• resource management
• planning and scheduling
• output analysis
• program management
6.3 Implementation of Project Management Software

Project management has evolved over the years. Moreover, with the invention of project management software,
many of the responsibilities associated with project management can be conveniently handled from a computer.
• Documentation: Paperwork for a project and having them proofread prior to sending it is time-consuming.
Conversely, many project management programs come complete with customisable document templates and
offer the option to send such documents via e-mail.
• Resource allocation: Every company has a limited amount of resources which can be applied to a project at
any given time. Knowing this, project management software allows project team members to keep track of the
resources being used at any given time.
• Multi-tasking: The tasks involved in fulfilling a project can be tedious and demanding. Thus, it goes without
saying that undertaking multiple projects simultaneously makes it more complicated to maintain accountability
of the status of tasks needed for successful projection completion.
• Leaving the office: With project management software, long gone is the necessity to be confined to an office
in order to update the system and other project team members. Capable of sending correspondence to personal
digital assistants, project management software affords project team members the ability to receive important
updates via cell-phone.
• Cost: In a side-by-side comparison of 10 project management programs on TopTenReviews.com, the prices for
the software ranged from $300 to $850.
6.4 Benefits of Project Management Software

There are many benefits of project management software that can help to enhance several aspects of a business’s
day-to-day operations. These are:
• Management: Team leaders and individual team members can use this software to manage every facet of the
project. For example, they can assign tasks to each other, prioritise those tasks and create personalized “to-do”
lists. It can:
manage events which depend on each other in different ways
be able to schedule the various members of the project team, including specific tasks for each member
be able to predict and deal with uncertainties and emergency situations which may arise during the
project
make certain that tasks are finished on time and new tasks are assigned
• Accountability: Team members are forced to be more accountable for their tasks because their daily progress
is tracked by the software and can be viewed by the group. If one member fails to meet a deadline, another can
fill the void.
• Transparency: Project management software offers transparency because every action related to the project is
recorded in the system. This provides an objective overview of the project from its launch till the completion.
• Tracking: The tracking feature common to project management software allows project members to track
progress, milestones, deadlines and cost. Priorities and resources can be adjusted accordingly throughout the
project.
95/JNU OLE
• Communication: Project management software facilitates communication among project team members
regardless of their geographical location. At any time, members can log in to the system to communicate with
each other.
Earn r
e abo
Valu d L ost
e c
Col f
(Sta laborat m e -Of nt
tus, io Ti me
Issu n a n age paid)
es) M , Un
d
(Pai
Pr e
(Ac oject T n d anc )
tual ra Att e roll
Vs. cking e and s, Pay
Plan
ned Tim or Law
b
) (La
(Pro P
ject roject n n ing entory)
initi Plan l a v
atio n o r ce P kill In
n, P ing rk f
Wo anning
, S
lan, l
Pro
ject
Sco
pe) c ity P e m ent
p a g
Ma
nag (Ca M ana
eme rc e
nt o rkfo
W
Fig. 6.1 Project workforce management

(Source: http://www.tenrox.com/en/enterprise-project-management/)
6.5 Project Management Software : Tasks

The tasks of project management software are as described below.
6.5.1 Scheduling
• One of the most common tasks is to schedule a series of events and the complexity of this task can vary,
considerably depending on how the tool is used.
• Some common challenges include:
events which depend on one another in different ways
scheduling people to work on and resources required by the various tasks
dealing with uncertainties in the estimates of the duration of each task
arranging tasks to meet a plethora of deadlines
juggling multiple projects simultaneously to meet a variety of requirements
96/JNU OLE
6.5.2 Calculating Critical Path
• In 1957, DuPont developed a project management method designed to address the challenge of shutting down
chemical plants for maintenance and then restarting the plants once the maintenance had been completed. Given
the complexity of the process, they developed the Critical Path Method (CPM) for managing such projects.
• A benefit of project management software is the ease of creating a visualisation of a critical path. In project
management terminology, a critical path is the process by which tasks and milestones feed into future tasks.
This critical path is defined in the software through dependencies and linkage from one milestone to another.
• The critical path method is an algorithm for scheduling a set of project activities. It is an important tool for
effective project management.
• The essential technique for using critical path method is to construct a model of the project that includes the
following:
A list of all activities required to complete the project (typically categorised within a work breakdown
structure).
The time (duration) that each activity will take to completion.
The dependencies between the activities.
• Critical path method provides the following benefits:
a graphical view of the project
predicts the time required to complete the project
shows which activities are critical to maintaining the schedule and which are not
• Using these values, it calculates the longest path of planned activities to the end of the project and the earliest
and latest that each activity can start and finish without making the project longer.
• This process determines which activities are “critical” (i.e., on the longest path) and which have “total float”
(i.e., can be delayed without making the project longer). In project management, a critical path is the sequence
of project network activities which add up to the longest overall duration.
• This determines the shortest time possible to complete the project. Any delay of an activity on the critical path
directly impacts the planned project completion date (i.e., there is no float on the critical path).
6.5.3 Reporting
• Reporting is a way of communicating information about a project to the different participants so that the
participants share a common view and understanding of the status of the project.
• Project planning software needs to provide a lot of information to various people, to justify the time spent using
it.
• Typical requirements might include:
tasks lists for people and allocation schedules for resources
overview information on how long tasks will take to complete
early warning of any risks to the project
information on workload, for planning holidays
historical information on how projects have progressed and in particular, how actual and planned performance
is related
6.5.4 Budgeting
• Project management software tracks the amount of time that personnel spend on a task and the amount and
types of physical resources required completing each task.
• The software can therefore calculate the costs incurred to date for each project. Similarly, project management
software can show the differences between the forecasted costs and the actual costs of the project at any point
in the project up to the current date.
97/JNU OLE
6.5.5 Asset Allocation

• Project management software provides a method of load balancing or ensuring that limited resources are
assigned as needed.
• For each task assigned in the schedule, the user can designate the personnel, equipment and other resources
required to complete the task. This allows the user to see and prevent conflicts or overlap in the schedule where
any given resource would be overloaded.
6.6 Project Management Software: Approaches

The first project management software tools were mainly on mainframe computers. During 1970s and 1980s project
management software suitable for mini-computers developed. Slowly the trend shifted towards micro-computer
based systems. The different approaches to project management software are briefly described underneath.
6.6.1 Desktop
• Project management software can be implemented as a program which runs on the desktop of each user.
• This typically gives the most responsive and graphically-intense style of interface.
• Desktop applications typically store their data in a file, although some have the ability to collaborate with other
users or to store their data in a central database.
• Even a file-based project plan can be shared between users if it’s on a networked drive and no two people want
to access it at once.
• Desktop applications can be written to run in a heterogeneous environment of multiple operating systems,
although it’s unusual.
• Many such programs only run on a particular system, typically Microsoft Windows.
6.6.2 Web based

• Project management software can be implemented as a web application, accessed through an intranet or extranet
using a web browser.
• This has all the usual advantages and disadvantages of web applications, such as follows:
can be accessed from any type of computer without installing software
ease of access-control
multi-user
only one software installation/version to maintain
typically slower to respond than desktop applications
more limited graphic capability than desktop applications
6.6.3 Personal
• A personal project management application is one used at home, typically to manage a lifestyle or home
projects.
6.6.4 Single user

• A single-user system is programmed with the assumption that only one person will ever need to edit the project
plan at a time.
• This may be used in small companies or ones where only a few people are involved in top-down project planning.
Desktop applications generally fall into this category.
98/JNU OLE
6.6.5 Collaborative
• A collaborative system is designed to support multiple users modifying different sections of the plan at once,
for example, updating the areas they personally are responsible for such that those estimates get integrated into
the overall plan.
• Web-based tools, including extranets, generally fall into this category, but have the limitation that they can only
be used when the user has live internet access.
• To address this limitation, client-server-based software tools exist that provide a Rich Client that runs on users’
desktop computer and replicate project and task information to other project team members through a central
server when users connect periodically to the network.
6.6.6 Integrated
• An integrated system combines project management or project planning, with many other aspects of company
life. For example, PHProjekt projects have bug tracking issues assigned to each project, the list of project
customers becomes a customer relationship management module and each person on the project plan has their
own task lists, calendars and messaging functionality associated with their projects.
• Similarly, specialised tools like SourceForge integrate project management software with source control software
and bug-tracking software, so that each piece of information can be integrated into the same system.
6.6.7 Non-specialised Tools

• While specialised software may be common and heavily promoted by each vendor, there is a vast range of other
softwares (and non-software) tools used to plan and schedule projects.
Calendaring software can often handle scheduling as easily as dedicated software.
Spreadsheets are very versatile and can be used to calculate things not anticipated by the designers.
6.7 Top Project Management Software Packages
The following list of project management software packages was selected based on a combination of ranking votes
and frequency of visits.
• Microsoft Project is the most popular among the currently available project management software.
• Primavera is a project management software program that is mostly used for bigger projects such as construction
or renovations.
• OmniPlan is another easy-to-use software program designed to assist managers in creating logical and manageable
projects.
• Project Administrator ™ is a project management software tool that complements a scheduling tool such as
Microsoft Project.
• AceProject - Project Management: Offers web-based project management, bug tracking and timesheet
software
• ActiveProject® Project Management: It is web based project management and collaboration software
• BiLL -The Simplified Project Management Tool: It manages projects from anywhere, allows checking the
progress of projects in real time, evaluate the cost-effectiveness of projects with a single click
• BillQuick: An affordable, easy to use time tracking, project management and billing solution. BillQuick handles
any billing arrangement: T&M, Fixed Fee, Recurring, Retainers and more.
• BugBox -Deliver Projects on Time: It helps in delivering projects on time.
• BUGTrack : BUGTrack is reliable, convenient, secure and completely web-based issue tracking system.
• Celoxis Project Management: Celoxis offers project management, document management, workforce
99/JNU OLE
management, time/expense, client collaboration, custom forms, knowledge management and certified email.
• Copper Project: Copper Project is a web-based project management tool that allows teams to manage themselves
more effectively. It is designed especially for team-based consultancies including software developers, design
studios and other internet-connected businesses.
• CS Project: It is a project scheduling and management software for manufacturing and mining.
• Elementool Bug Tracking: Elementool enables software developers to track new bugs, prioritise and assign
bugs to team members, generate bug reports, send email messages between users, attach files, type notes in a
message board, etc.
6.8 Features of Common Project Management Softwares

The common project management softwares are:
6.8.1 Microsoft Project

• Microsoft Project is the most popular among the currently available project management software.
• The advantage that MS Project has over other software is the fact that most companies use Microsoft Windows
based infrastructure.
• It is a project management software program developed and sold by Microsoft which is designed to assist
project managers in developing plans, assigning resources to tasks, tracking progress, managing budgets and
analysing workloads.
• The application creates critical path schedules, although critical chain and event chain methodology third-party
add-ons are available.
• Schedules can be resource levelled and chains are visualised in a Gantt chart.
• Additionally, Project can recognise different classes of users.
• These different classes of users can have differing access levels to projects, views and other data.
• Custom objects such as calendars, views, tables, filters and fields are stored in an enterprise global which is
shared by all users.
• Microsoft has revolutionized project management software.
• With Microsoft Project 2010 Professional version, the manager has a clearer view of milestones, tasks and
phases.
• According to Microsoft.com, you can quickly compare budget versus actual versus forecasted values to measure
an initiative’s progress with the flexibility of setting multiple baselines.
• This is very pertinent to a project manager in order for him to evaluate financial as well as risk management
and it can be done using a click of the mouse.
• Some important capabilities of Microsoft project include:
support for collaboration
portfolio view
task linking
resource pooling
6.8.2 Primavera
• Primavera is a project management software program that is mostly used for bigger projects such as construction
or renovations; however, this software is user friendly and can be used for minor projects as well.
• Primavera has many easy-to-use features. In addition, these simple features can be quickly implemented into
the project for fast and effective results.
100/JNU OLE
6.8.3 OmniPlan
• OmniPlan is another easy-to-use software program designed to assist managers in creating logical and manageable
projects.
• OmniPlan helps to manage complex projects without requiring you to learn a complex software program.
This means that all project team members can start managing and scheduling their project objectives almost
immediately. This ensures an effective way to meet or precede the deadline.
6.8.4 Project Administrator

• Project Administrator ™ is a project management software tool that complements a scheduling tool such as
Microsoft Project.
• Project Administrator combines all the bits and pieces of information gathered in a project, into a single project
management software tool.
• It allows logging issues, risks, action items, glossary, benefits, scope changes, budget and expenditure, benefits,
roles and responsibilities, phases and even diary notes into one database. It can be even linked to Microsoft
Project.
• It is not only suitable for IT project management. It can be used for Engineering project management and
construction project management.
• It is fast and easy to install. There is no need to get an IT person to do the work. It can just be downloaded and
installed.
• Project Administrator can run on a single PC or over a network with multi users. It has a built-in security system
to ensure control over who can see which project and what they can see within the project.
• The project runs on Microsoft Access from Access 2002 to Access 2010.
101/JNU OLE
Fig. 6.2 Project administrator

(Source: http://www.projectperfect.com.au/project-administrator-software.php)
102/JNU OLE
Home
– Project Overview
Project
Program
Phases
Quality Assurance
Budget
Benchmarks
Benefits
Project Roles
Distribution List
– Daily Management
Issues
Action Items
Risks
Assumptions
Dairy Notes
Project Docu-
ments
Time Sheets
Progress Report
Change Control
Schedule
Expenditure
All Tasks
All Milestones
Meetings
– Phase Planning
Roles
Phase Tasks
Phase Milestones
– Library
Reference Docs
Checklists
Glossary
Inspections
Function Points
Fig. 6.3 Project administrator menu

(Source: http://www.projectperfect.com.au/project-administrator-software-more.php)
The screen shot above shows the parts of a project that Project Administrator can help with. It is arranged into four
streams:
• Project Overview: Setting up a project and creating the structure of the project - Planning the project and how
it will be undertaken.
• Daily Management: Managing the project on a day to day basis including managing issues
• Phase Planning: If one wants to view it by phase.
• Library: Storing useful information in a library to be used across all projects
6.9 Criticisms of Project Management Software

The following may apply in general or to specific products or to some specific functions within the products.
• May not be derived from a sound project management method.
• May be inconsistent with the type of project management method.
103/JNU OLE
• Focuses primarily on the planning phase and does not offer enough functionality for project tracking, control
and in particular plan-adjustment. Good management software should not only facilitate this, but assist with
impact assessment and communication of plan changes.
• Does not make a clear distinction between the planning phase and post planning phase, leading to user confusion
and frustration when the software does not behave as expected. For example, shortening the duration of a task
when an additional human resource is assigned to it while the project is still being planned.
• Offer complicated features to meet the needs of project management or project scheduling professionals, which
must be understood in order to effectively use the product. Additional features may be so complicated as to be
of no use to anyone. Complex task prioritisation and resource levelling algorithms for example can produce
results that make no intuitive sense and over allocation is often more simply resolved manually.
• Some people may achieve better results using simpler technique, (e.g. pen and paper), yet feel pressured into
using project management software by company policy (discussion).
• Similar to PowerPoint, project management software might shield the manager from important interpersonal
contact.
• New types of software are challenging the traditional definition of project management. Frequently, users of
project management software are not actually managing a discrete project.
6.10 Future Development

• IT is moving so fast that it is very hard to say what will happen in the future. All software applications are web-
based. The advances in the personal desktop system and increase connectivity to the internet have enlarged the
possibilities of people joining the project team.
• Project members will now spread all over the work working in different time zones resulting in greater efficiency
of the project design and implementation. Members will come from not only in the same company but sub-
contractor or out-sourced company.
• Project management software will continue to enhance functionalities, which allow for manager’s greater control
of project. To choose a project management system, managers should choose the software wisely basing their
decision on the adaptability to the environment and scalability to increase or decrease the scope.
104/JNU OLE
Summary
• Technology should be seen as an enabler of capability, reliant on people and process to support project. However,
while project management software will help organisations manage projects faster, more easily and potentially
more cheaply, it does not provide best practice capability in itself.
• Complex projects can take many years to complete. By their very nature, these projects are expensive and
time-consuming, which requires strict organisational skills to ensure delivery of the final objective. Project
management software is a tool to assist in the management and communication of the risks and tasks necessary
to complete a project.
• Project management software is a term covering many types of software, including scheduling, resource
allocation, collaboration software, communication and documentation systems, which are used to deal with
the complexity of large projects. These applications allow organisations to plan, resource, manage and report,
project cost, work and time.
• Project management software encapsulates the work flow management of a project plan into a software
application that can be used as a tool to explain the objectives, delivery milestone dates and dependencies
within a project.
• The software can therefore calculate the costs incurred to date for each project. Similarly, project management
software can show the differences between the forecasted costs and the actual costs of the project at any point
in the project up to the current date.
• Thus, software can be used to assist the project team and other stakeholders in their project execution and
management tasks. There are major tasks of project management software and features of project management
software.
• Project management software will continue to enhance functionalities, which allow for manager’s greater control
of project. To choose a Project management system, managers should choose the software wisely basing their
decision on the adaptability to the environment and scalability to increase or decrease the scope.
References
• Benefits of Project Management Software, Available at: <http://civilengineerblog.com/benefits-project-
management-software/> Last accessed 12th January 2011.
• CPM - Critical Path Method. Available at: <http://www.netmba.com/strategy/> Last accessed 12th January
2011.
• Project Management Software. Available at: <http://en.wikipedia.org/wiki/Project_management_software>
Last accessed 12th January 2011.
• Project Management Software Directory. Available at: <http://infogoal.com/pmc/pmcswr.htm> Last accessed
12th January 2011.
• The Advantages of Project Management Software. Available at: <http://www.ehow.com/facts_5315849_
advantages-project-management-software.html#ixzz1B08Bdwtx> Last accessed 12th January 2011.
Recommended Reading
• Project Management Institute (2003). A Guide to the Project Management Body of Knowledge. Project
Management Institute. ISBN 1-930699-45-X. 3rd edition.
• Kerzner, Harold (2003). Project Management: A Systems Approach to Planning, Scheduling and Controlling.
ISBN 0-471-22577-0. 8th edition.
• Robert L. Kimmons, James H. Loweree (1989). Project Management: A Reference for Professionals, Dekker
105/JNU OLE
Self Assessment
1. Project management doe not require stringent organisation skills and oversight on _______
a. tasks
b. resources
c. delivery dates
d. qualification of staff
2. Paperwork for a project and having them proofread prior to sending them is __________.
a. time-consuming
b. easy
c. fast
d. trouble-free
3. _____________ is a way of communicating information about a project to the different participants so that the
participants share a common view and understanding of the status of the project.
a. Reporting
b. Budgeting
c. Asset allocation
d. Documentation
4. _________ enables software developers to track new bugs, prioritise and assign bugs to team members, generate
bug reports, send email messages between users, attach files, type notes in a message board, etc.
a. Celoxis
b. BiLL
c. AceProject
d. Elementool
5. __________ offers web-based project management, bug tracking and timesheet software.
a. Celoxis
b. BiLL
c. AceProject
d. Elementool
6. ___________ is a web-based project management tool that is designed especially for team-based consultancies
including software developers, design studios and other internet-connected businesses.
a. Copper Project
b. Celoxis
c. BiLL
d. AceProject
106/JNU OLE
7. Which is the category of project management software?
a. Project management
b. Resource management
c. Planning and scheduling
d. Recruitment
8. Which of the following is a disadvantage of web-based approach of program management software?

a. It can be accessed from any type of computer without installing software
b. Does not provide ease of access-control
c. multi-user
d. More limited graphic capability than desktop applications.
9. Which software program is designed to assist managers in creating logical and manageable projects?
a. OmniPlan
b. Copper Project
c. Celoxis
d. BiLL
10. Which is not one of the tasks of project management software?

a. Scheduling
b. Calculating Critical Path
c. Reporting
d. Allocation
107/JNU OLE
Case Study I
The Delhi Metro Project: Effective Project Management in the Indian Public Sector
The Delhi Metro project gave Delhi a world-class mass rapid transit system. More importantly, it stood out from
most other public sector projects in India in that it was completed on schedule and within the budgeted cost. The
case describes the organization and planning of the project and highlights the steps taken by the DMRC (Delhi Metro
Rail Corporation Ltd.) to ensure the successful completion of the project. It also explains how the DMRC managed
the various stakeholders like the central and state governments, the contractors, and the citizens of Delhi, to ensure
that the project was implemented smoothly.
Delhi Metro Project

In order to implement the Delhi Metro project, the Government of India and the GNCTD (Government of National
Capital Territory of Delhi (India) set up a 50:50 joint venture company called the Delhi Metro Rail Corporation
Ltd. (DMRC). The company was incorporated under the Companies Act in May 1995. The DMRC was to complete
Phase I of the project within 10 years, i.e., by the end of 2005.
Funding the project

Globally, most urban MRTS (Mass Rapid Transit System) projects were financially unviable because the fares could
not be fixed solely on a commercial basis. If the fares were fixed too high, the passenger numbers would remain
low, thereby defeating the very purpose of setting up the system. Therefore, the concerned governments generally
bore the capital costs of an MRTS system. In the case of the Delhi Metro project too, the Government of India and
the GNCTD bore the capital costs. The total cost of the first phase of the project was initially estimated at Rs. 60
billion, at April 1996 prices. Later in 2002, with the cost of the project rising by approximately 10% per year, the
estimate was revised to Rs. 89.27 billion.
The project team

With the funding for the project being finalized, the next step was to constitute a project team. Sreedharan was
appointed as project manager and managing director of the DMRC in November 1997.
Planning the project

In India, major infrastructure projects are often stalled because of a lack of funds, political interference, lack of
professionalism and accountability, property disputes, corruption, etc. Therefore, even before the commencement
of the project, the DMRC attempted to put in place effective systems to ensure the smooth progress of the project.
Funding was not an issue in the case of the Delhi Metro project because it was settled even before the project
commenced. In order to steer clear of political interference, the DMRC sought autonomy on all major matters and
the Government of India promised to give it this autonomy.
Project implementation
Construction work on the project was commenced on October 1, 1998. The entire project was divided into three
lines.
Managing the stakeholders in the project

Effective project management involved not only completing the project on schedule and within the budget, but also
managing the project's stakeholders. The stakeholders included the governments, the contractors, the funding agencies,
and the general public. Despite assurances that the DMRC would enjoy autonomy, it faced political pressure not
only in its recruitment processes, promotions, and contract awarding but also in land acquisition.
Project Evaluation
The successful completion of the project effectively silenced the critics who had been doubtful about the ability
of an Indian public sector organization to complete any project, let alone one as complex and costly as the Delhi
Metro, on time and within the budget.
108/JNU OLE
Outlook
The Delhi Metro was expected to play a major role in relieving the transport problems faced by the city's residents.
Moreover, with the GoI planning extensions to the Metro, it appeared that the benefits of an efficient transport system
would be enjoyed by people living in a wider geographical area than originally planned. The GoI and the GNTCD
prepared a comprehensive plan to extend the Delhi Metro to 244 km by 2021 in three subsequent phases.
Questions:
1. Who had set up the Delhi Metro Project?
Answers
In order to implement the Delhi Metro project, the Government of India and the GNCTD (Government of National
Capital Territory of Delhi (India) set up a 50:50 joint venture company called the Delhi Metro Rail Corporation
Ltd. (DMRC). The company was incorporated under the Companies Act in May 1995. The DMRC was to complete
Phase I of the project within 10 years, i.e., by the end of 2005.
2. What were the major problems faced in Delhi Metro Project?

Answer
The Delhi Metro project faced many problems such as political interference, lack of professionalism and
accountability, property disputes, corruption, managing the project's stakeholders etc. Therefore, even before the
commencement of the project, the DMRC attempted to put in place effective systems to ensure the smooth progress
of the project. Funding was not an issue in the case of the Delhi Metro project because it was settled even before
the project commenced. In order to steer clear of political interference, the DMRC sought autonomy on all major
matters and the Government of India promised to give it this autonomy.
3. How the funds were raised for the Delhi Metro Project?
Answer
In the case of the Delhi Metro project too, the Government of India and the GNCTD bore the capital costs. The total
cost of the first phase of the project was initially estimated at Rs. 60 billion, at April 1996 prices. Later in 2002, with
the cost of the project rising by approximately 10% per year, the estimate was revised to Rs. 89.27 billion.
4. How the stakeholders in the project were managed?

Answer
Effective project management involved not only completing the project on schedule and within the budget, but
also managing the project's stakeholders. The stakeholders included the governments, the contractors, the funding
agencies, and the general public. Despite assurances that the DMRC would enjoy autonomy, it faced political pressure
not only in its recruitment processes, promotions, and contract awarding but also in land acquisition.
109/JNU OLE
Case Study II
Volvo Group
The Volvo Group is a leading supplier of commercial and consumer transport solutions and customer financial
services. The Volvo Group produces commercial vehicles—such as Renault and Mack trucks and Volvo buses—and
construction equipment. It also includes companies responsible for marine and aeronautical technologies, logistics,
and financial services. With headquarters in Goteborg, Sweden, the Group has more than 90,000 global employees,
production facilities in 19 countries, and sales activities in 180 countries. It had 2009 revenues of about SEK218
billion (U.S. $29 billion).
Volvo IT, a global company that is part of the Group, develops new technologies and business solutions for Volvo
companies, and it works for external clients. Volvo IT provides solutions that manage many different types of
projects. The Volvo Group has sophisticated, well-developed project management processes that provide control
and visibility. To support those processes,
Volvo IT was using Microsoft Office Project Server 2003 and Microsoft Office Project Server 2007. Although
the Volvo Group was generally satisfied with the Microsoft software, Office Project Server 2007 did not have the
flexibility to adapt to the Group’s time-reporting processes. For that reason, only about half of the Group’s 2,200
users had upgraded to Office Project Server 2007.
The Volvo Group was interested in improving its resource management. Some internal software applications did
not interact successfully with Project Server 2003 and Office Project Server 2007, which sometimes resulted in
employees having to enter duplicate information. The group also wanted to streamline some of its project management
procedures. For example, managers sometimes struggled to successfully publish information in simple and clear
reports. Some employees had problems with the speed of the Web client.
Finally, the Volvo Group was always seeking to use employees’ time in meetings most effectively. Thus, the Volvo
Group wanted project management software that could more flexibly work with its time-reporting processes and
support efforts to improve resource management, portfolio management, and employee effectiveness.
The Volvo Group participated in the Technology Adoption Program for Microsoft Project 2010 so that it would be
able to provide pre-release feedback on process flexibility. Microsoft Project Server 2010 would offer better ways of
planning resource deployment, more features in its Web client, and close interoperation with Microsoft SharePoint
Server 2010.
In February 2010, the Volvo Group implemented a pilot project with 50 users. It worked with Teamsquare, a Microsoft
Certified Partner based in France, which specialises in project management.
Volvo IT runs Project Server 2010 on a mixture of virtual servers and quad-core physical servers featuring 4 gigabytes
of RAM. All employees can perform their work with the Web client, Microsoft Project Web App. Because users can
edit project data through Project Web App, the Volvo Group is significantly reducing the number of project managers
who need Microsoft Project Professional 2010. And also, it responds more quickly to user commands.
For the project managers who are responsible for completing project plans, reporting is important. Those managers
can use the new Timeline view in Project Professional 2010 to easily create a high-level view of a project plan. They
can drag tasks into the timeline and paste the timeline into presentations or e-mail messages. Furthermore, Volvo IT
has made several customizations to help Project Server 2010 interact with other software packages.
110/JNU OLE
Benefits
The Volvo Group uses Microsoft Project Server 2010 to make better capacity-planning decisions. It also saves time
for employees through automated processes and a simple user interface, gains more visibility into projects, and
improves resource management.
• Time savings: By automating more of the collection and dissemination of project management data, Project
Server 2010 is saving employee’s time. At the same time, the reduced risk of mistakes has improved quality. Most
important, Project Server 2010 performs the data collection function that too often takes place in meetings.
• Simple user interface: Volvo Group employees appreciate the simple user interface of Project Server 2010.
The rich feature set in Project Web App makes it easier for managers to perform their work.
• Quicker Routes to Visibility and Control: The result of these improvements in information and communication
is a better understanding of projects, and thus more control over them. This gives us the opportunity to shape
future contracting and distribution strategies.
• Clarified, Transparent Resource Management: With Project Server 2010, the Volvo Group gains a better view of
its resourcing needs. With that anticipation, the Group can better manage staff and contractors. For example, if you
have to stop a project, Project Server 2010 makes it much easier to reassign people, because you know where they are
and what they’re doing. Furthermore, the Volvo Group can more effectively communicate with members of the team.
Questions:
1. How Microsoft Project Server 2010 benefited the Volvo Group?
2. What were the disadvantages of Microsoft Office Project Server 2003 and Microsoft Office Project Server 2007
faced by Volvo IT?
3. How Microsoft Project Server 2010 helped the Volvo Group in improving its resource management?
111/JNU OLE
Case Study III

Integrated Project Management System
Indian Railways is the largest rail network in Asia and is the world's second largest under one management, with
a workforce of 2 million. The Indian Railways is one of the largest railway systems in the world under a single
management. It runs 11,000 trains every day. Spread across 67 divisions, it covers 104,000 km of rail track, has over
7,000 railway stations and ferries around 17 million passengers daily. Planning the movement of trains, deciding on
precedence and crossings, forecasting train arrivals and providing this information to all the concerned within the
system, is a critical element of day-to-day operations for the railways, in order to achieve efficiency, ensure safety,
and provide customer satisfaction.
The Ahmedabad Division manages various construction projects for the region. They needed an integrated application
that can help them manage the project estimation, tendering, procurement and tender evaluation process. The
application managed project monitoring, financing and bill tracking and integration with billing and accounting
systems. The application generates various project status reports for submission to other authorities and for internal
MIS (Management Information system).
Indusa is a Chicago-based IT consulting company providing services since 1989. Indusa has a strong presence in the
US market and operates in all the 50 states. It has strength of around more than 150 full time software engineering
professionals, with multi-disciplinary skills in business analysis, consulting and application development and
management and a track record of completing several projects across a diverse range of technology platforms.
Indusa's global IT services, business solutions, and subject matter expertise backed with on-time, within budget
delivery, perfect quality, greater efficiency and tremendous responsiveness gives the confidence of an outsourcing
partner one can rely on. With two decades of industry experience and unmatched technical expertise and insights,
it gives the strategic advantage needed.
The company designed, developed, and implemented an Integrated Project Management System (IPMS)
application. Integrated Project Management (IPM) is a methodology that incorporates a singular centralised
data structure to support not only reporting criteria but also an actual decision-support process. It relies
on an Integrated Project Team made up of the complete range of stake holders and provides for the added
value practices.
A project can be completed on schedule under cost and still not deliver what was originally prescribed. Integrated
Project Management System includes technical performance and accounting data that are the 'missing links' in many
project management systems. Without these key elements, the project manager may not get what is expected.
IPMS provides project management, facilities tendering/bidding process, procurement assistance, tender evaluation,
contract management including project tracking and billing and it produces custom reports. Another important part
of the application is managing and tracking actual project expenses, approving bills and overall project accounting.
The technologies used are: VB 6.0, MS Access 2000, Adobe Photoshop 5.0, and Crystal Reports 8.0.
Questions:
1. Why the Ahmedabad Division of Indian railways needed an integrated application?
2. Who helped Ahmedabad Division of Indian railways in project management and how?
3. Which technologies were used for project management?
112/JNU OLE
Bibliography
References
• Benefits of Project Management Software, Available at: <http://civilengineerblog.com/benefits-project-

management-software/> Last accessed 12th January 2011.
• Contract Management. Available at: < http://www.wisegeek.com/what-is-contract-management.htm>
Last accessed on 12th January, 2011.
• CPM - Critical Path Method. Available at: <http://www.netmba.com/strategy/> Last accessed 12th
January 2011.
• Dennis Lock (1998) Gower Handbook of Project Management. Gower Publishing, Hampshire. 2nd
edition.
• Harold Kerzner (2009) Project Management–A Systems Approach to Planning, Scheduling and
Controlling. Van Nostrand Rienhold, New York, 6th edition.
• John M. Nicholas and Herman Steyn (2008). Project Management for Business, Engineering and
Technology, Butterworth-Heinemann Publication, 3rd edition.
• K. Nagarajan, 2004. Project Management. New Age International, New Delhi, 2nd edition.
• M. Williams (2008). The Principles of Project Management, Site Point Publications.
• Project Closure & Termination Phase. Available at: <http://www.suite101.com/content/project-closure-
a129630> Last accessed 12th January, 2011.
• Project Closure and Termination Phase: Activity Checklist for Proper Project Completion. Available
at: <http://www.suite101.com/content/project-closure-a129630#ixzz1AtWq30O1> Last accessed 12th
January, 2011.
• Project Closure. Available at: http://e-articles.info/e/a/title/Project-closure> Last accessed 12th January,
2011.
• Project Life Cycle - Project Cycle Management. Available at: <http//www.visitask.com/project-life-
cycle.asp> Last accessed 12th January 2011.
• Project Management Software Directory. Available at: <http://infogoal.com/pmc/pmcswr.htm> Last
accessed 12th January 2011.
• Project Management Software. Available at: <http://en.wikipedia.org/wiki/Project_management_
software> Last accessed 12th January 2011.
• Project Management, Lecture 11- Project Closure. Available at: <http://www.halifax.ac/Download/
PgD%20SBIT/PgD%20SBIT%20New/712_PM/PM%20-%20Lecture%2011%20-%20Project%20
Closure.pdf> Last accessed 12th January, 2011.
• Project Management. Available at http://project-management-knowledge.com. Last assessed on January
11, 2010.
• Risk Management. Available at: < http://en.wikipedia.org/wiki/Risk_management> Last assessed 11th January,
2011.
• Risk Management. Available at: < http://www.stsc.hill.af.mil/resources/tech_docs/gsam4/chap5.pdf> Last
assessed 11th January, 2011.
• Risk monitoring and Control. Available at: < http://faculty.kfupm.edu.sa/CEM/alkhalil/PDF_CEM_516/L07%20
Risk%20Monitoring%20&%20%20Control.pdf> Last assessed 11th January, 2011.
• Risk Monitoring and Control. Available at: < http://www.anticlue.net/archives/000821.htm> Last assessed 11th
January, 2011.
• Risk Monitoring and Control: Inputs. Available at: < http://www.super-business.net/Project-Management/
Knowledge/2467.html> Last assessed 11th January, 2011.
113/JNU OLE
• The Advantages of Project Management Software. Available at: <http://www.ehow.com/facts_5315849_

advantages-project-management-software.html#ixzz1B08Bdwtx> Last accessed 12th January 2011.
• Understanding Public Sector Procurement Processes: A Supplier’s Guide to the Procurement of ICT Goods
and Services, Booklet 6. Available at: <http://www.icn.govt.nz/contentimages/ict%20procurement%20-%20
booklet%206.pdf> Last assessed 11th January, 2011.
• Westland (2006). The Project Management Lifecycle, Kogan Page Limited.
Recommended Reading
• Anuj Saxena (2008) Enterprise Contract Management: A Practical Guide to Successfully Implementing an
ECM Solution. J Ross Publishing, 344 pages.
• Arthur A. Bel (2007) HVAC Equations, Data, and Rules of Thumb. McGraw-Hill Professional, 290 pages.
• Dennis Lock, 1998. Gower Handbook of Project Management. Gower Publishing, Hampshire. 2nd
edition.
• J. Rodney Turner (2003) Contracting for Project Management. Gower Publishing Company, 176 pages.
• John Butler (1904) Engineering Contracts and Specifications. Johnson Engineering News Publishing co., 560
pages.
• Joseph Phillips (2010). IT Project Management: On Track from Start to Finish. McGraw Hill Professional, 3rd
edition, 640 pages.
• K. Nagarajan (2004). Project Management. New Delhi, New Age International, 2nd edition.
• Kerzner, Harold (2003). Project Management: A Systems Approach to Planning, Scheduling and Controlling.
ISBN 0-471-22577-0. 8th edition.
• M. Frenkel, U. Hommel, G. Dufey, M. Rudolf (2005). Risk Management: Challenge and Opportunity.
838 pages
• Marco Alexander Caiza Andresen (2007). The Process of Risk Management for Projects, GRIN Verlag.
36 pages.
• Project Management Institute (2003). A Guide to the Project Management Body of Knowledge. Project
Management Institute. ISBN 1-930699-45-X. 3rd edition.
• Reto R. Gallati (2003). Risk Management and Capital Adequacy. McGraw-Hill Professional. 550 pages.
• Robert L. Kimmons, James H. Loweree (1989). Project Management: A Reference for Professionals. Dekker
• Stanley E. Portny (2010) Project Management for Dummies. Kindle Publication, 3rd edition.
• Success Planning in Project Management. Available at http://project-management-knowledge.com/. Last accessed
on January 12, 2011.
• What is contract management? Available at http://www.wisegeek.com/what-is-contract-management.htm. Last
accessed on January 12, 2011.
114/JNU OLE
Self Assessment Answers
Chapter I
1. b
2. a
3. d
4. b
5. a
6. b
7. d
8. c
9. a
10. b
Chapter II
1. a
2. b
3. b
4. a
5. b
6. d
7. d
8. c
9. d
10. d
Chapter III
1. a
2. a
3. b
4. c
5. c
6. c
7. a
8. a
9. d
10. d
115/JNU OLE
Chapter IV
1. d
2. c
3. c
4. c
5. c
6. b
7. c
8. d
9. b
10. c
Chapter V
1. b
2. d
3. d
4. d
5. a
6. b
7. d
8. c
9. c
10. b
Chapter VI
1. d
2. a
3. a
4. d
5. c
6. a
7. d
8. d
9. a
10. d
116/JNU OLE

Project Administraffftion

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Administraffftion

Uploaded by

Copyright:

Available Formats

Project Administration

This book is a part of the course by Jaipur National University, Jaipur.

The content in the book is copyright of JNU. All rights reserved.

II. List of Figures...........................................................VI

III. List of Tables......................................................... VII

V. Case Study.............................................................. 109

VI. Bibliography.......................................................... 114

VII. Answers to Self Assessment............................... 116

• define project and project management

• explain the objectives of a project

• understand the need for project documentation

• describe the role of project manager and project administrator

The objectives of this chapter are to:

• describe the concept of project and project administration

• explain the phases of project life cycle

• understand the particular functions of the project team

• understand the basics of project administration

• examine the responsibilities of each member of the project team

• get an overview of project administration

1.2 Defining Project and Project Management

1.3 Objectives of a Project

Fig. 1.1 Project objectives

1.4 Project Administration

1.5.1 Benefits of Project Administration

1.6 Project Manager

1.7 Project Administrator

1.8 The Project Life Cycle

Fig. 1.2 Project life cycle

Execution and controlling

1.9 Importance of the Project Life Cycle Phases

1.10 Project Management Triangle

Fig. 1.3 Project management triangle

1.11 Project Documentation

Fig. 1.4 Project reporting

1. Which is the final stage of project life cycle?

3. ___________is characterised by breaking down the project into smaller parts/tasks.

4. _______ phase is characterised by a written formal project review report.

5. Who is hired during initiation phase of a project life cycle?

6. Which of the following is false?

8. Which is not one of the three constraints of Project Management Triangle?

10. Who checks the day-to-day operation of a project?

• explain about contract management

• enlist and explain various contract types

• describe contract and contract management

• elucidate the intend of contract management

• know about advantages and disadvantages of various contract types

• understand the need of contracts and its management

• identify various contract types according to their application

• recognise advantages and disadvantages of each contract type

• learn about opting the right contract type

Fig. 2.2 Contract

2.3 Contract Management

2.5 Successful Contract Management

2.6 Contract Team

2.7 Types of Contract

Fig. 2.3 Types of contracting methods

2.7.1 Compensation Based Contracts

2.7.1.1 Fixed-Price Contracts

2.7.1.2 Schedule of Rates Contracts

2.7.1.3 Cost-Plus Contracts

2.7.1.4 Guaranteed-Maximum-Price Contracts

2.7.2 Contract Packaging Based Contracts

• Professional services contract

2.7.2.1 Turn-key Contract