SCDL Project Management Text Book

PROJECT MANAGEMENT
OPERATIONS
(FOR PRIVATE CIRCULATION ONLY)

2010
PROGRAMME COORDINATOR
Prof. Viraj Atre
COURSE DESIGN AND REVIEW COMMITTEE

Prof. Dr. Shailesh Kasande
Prof. Ashok Chaudhari
Prof. Ranjan Joshi
Prof. D.H. Joshi
Prof. Manisha Ketkar
Prof. Sudhir Deshpande
Prof. Madhup Gandhi
Prof. Safia Farooqui
Prof. Rajiv Shirke
Prof. Viraj Atre
COURSE WRITERS
Madhup Gandhi
Sonali Gandhi
EDITORS
Ms. Deepashri Karandikar
Ms. Pieu Biswas
Published by Symbiosis Centre for Distance Learning (SCDL), Pune

July, 2007 (Revision 01, 2013)
Copyright 2013 Symbiosis Open Education Society

All rights reserved. No part of this book may be reproduced, transmitted or utilised in any form or by any
means, electronic or mechanical, including photocopying, recording or by any information storage or retrieval
system without written permission from the publisher.
Acknowledgement
Every attempt has been made to trace the copyright holders of materials reproduced in this book. Should any
infringement have occurred, SCDL apologises for the same and will be pleased to make necessary corrections
in future editions of this book.
PREFACE
We are glad to write this SLM on "Project Management" for the students of SCDL. With economic
growth and globalization, the businesses are expanding. This results in new projects as well as expansion
of projects being undertaken by the industry and infrastructure projects being implemented by the
Government. The growth in software industry requiring implementation of software projects and ever
used market research projects has resulted in increasing the demand for project managers. In fact,
project management is required in every facet of life; right from construction of house to completion
of education, at each step, we are required to do project management. If done in a systematic manner,
the probability of success of project improves and results can be better. To manage these projects, the
requirement of project managers is enormous for planning organizing and implementing in the field
of construction, engineering, software industry as well as consultancy services.
Even in banks, project managers are required for project evaluations. It may be hard to imagine living
without the project management knowledge. We could not just think of isolating ourselves from the
project management in any organization. To help the professionals manage the projects in effective
way, this SLM covers the basic fundamentals of project management.
Each unit contains detailed presentation of concepts and generalisation. Each topic has been
supplemented with clear explanatory diagrams to give the students a clear understanding of the topic.
This book mentions the objective, the summary followed by key words and a list of questions for
self-assessment. It also includes Activity questions for self learning. Special stress has been laid on
the simplicity of language in all its explanation.
We sincerely hope that this SLM will be interesting and useful and will help students and readers
to learn this subject in a more meaningful and useful manner. We take this opportunity to sincerely
extend thanks to the SCDL staff for believing in us and giving us an opportunity to write this book.
Finally, our heartfelt thanks to our parents for their valuable encouragement and inspiration. Last but
not the least, lots of thanks to our daughter Palak and Son Chirag for bearing with us and sacrificing
their entertainment and outings during the time the SLM was being written. Thanks to all those, who
directly or indirectly helped us in completing our work.
M.K. Gandhi
Sonali M. Gandhi
iii
ABOUT THE AUTHOR

M.K. Gandhi completed his B.E. Electronics and telecommunication Engineering education at
M.A.N.I.T. College under the University of Bhopal. He has also successfully completed his Post
MBA in Materials and Logistics management from Symbiosis Institute of Business Management,
Pune.
He has more than 18 years experience in Supply Chain Management, Operations Management,
Project Management and International Business during his working with MNCs in India as well as
abroad. He has conducted more than 100 training programs for executives in the corporate world
in various fields. He has a rich teaching experience in SCM, Project Management, International
Business and Operations Management and has been associated with more than 25 Institutes in India.
He is famous among students for his unique style of teaching.
He has authored many books on various subjects such as Distribution Management, Retail
Management, Operations management, Supply chain Management and Project Management.
Sonali M. Gandhi completed her B. C. S. from University of Pune with Distinction. She has also
successfully completed her MBA in Retail management. She has over 4 years of experience in the
field of International Business and more than 5 years of teaching experience in Project Management,
Statistics, Quantitative Techniques, Operations Research and Information Technology. Her unique
way of making the difficult subject easy to understand has made her immensely popular in all the
institutes she is associated with.
iv
CONTENTS
Unit No.
1
TITLE
Introduction to Projects
Page No.
1-24
1.1 Introduction
1.2 Defining Project
1.3 Types of Projects
1.4 Characteristics of Projects
1.5 Understanding Project Management
1.6 History of Project Management
Summary
Key Words
Self-Assessment Questions
Answers to Check your Progress
Suggested Reading
2
Project Management Process
25-50
2.1 Project Management An Introduction

2.2 Importance of Project Management
2.3 Characteristics of Project Management
2.4 Phases and Steps in Project Management
2.5 Project Management Life Cycle
2.6 Project Management Methodology
Summary
Key Words
Suggested Reading
3
Project Financing and Evaluation

3.1 Project Finance
3.2 Project Cost Benefit Analysis
3.3 Project Funding
3.4 Feasibility Study
3.5 PEST Analysis
3.6 PESTEL Analysis of Macro Environment
Summary
Key Words
Suggested Reading
51-76
Unit No.
4
6.1 Project Life Cycle

6.2 Project Definition Phase
6.3 Project Planning Phase
6.4 Project Execution Phase
6.5 Project Closeout Phase
6.6 Project Planning and Control System
6.7 Statement of Work
6.8 Work Breakdown Structure
6.9 Responsibility Matrix
Summary
Key Words
Suggested Reading
vi
Page No.
TITLE
Project Estimation and Economic Analysis
4.1 Estimation of Time and Cost in Project
4.2 Economic Analysis of Projects
4.3 Return on Investment
4.4 Time Value of Money
4.5 Internal Rate of Return
4.6 Net Present Value
4.7 Economic Value Added
4.8 Payback Period
Summary
Key Words
Suggested Reading
Organising Projects
5.1 Introduction to Organisational Structures
5.2 Types of Organisational Structures
5.3 Project Management Office
5.3.1 Types of Project Management Offices
5.4 Responsibilities of Project Manager
5.5 Project Teams
5.6 Conflict Management
Summary
Key Words
Suggested Reading
Project Planning
77-102
103-128
129-158
Unit No.
7
TITLE
Page No.
Networks for Project Management
159-188
7.1 Project Scheduling

7.2 Project Networks
7.3 Critical Path Method
7.4 Critical Path Calculations
7.5 Project Floats
7.6 Program Evaluation and Review Technique (PERT)
Summary
Key Words
Suggested Reading
8
Resource Levelling and Project Crashing
189-216
8.1 Project Resources

8.2 Resource Constraints
8.3 Resource Aggregation
8.4 Resource Levelling and Smoothing
8.5 Resource Scheduling
8.6 Project Crashing
8.7 Crashing Process
8.8 Time-Cost Relationship
8.9 Project Crashing Example
Summary
Key Words
Suggested Reading
9
Project Implementation and Monitoring
217-242
9.1 Project Management Process

9.2 Activity Scheduling
9.4 Cost Scheduling
9.5 Earned Value Analysis
9.6 Estimation of Cost per Activity/ Task
Summary
Key Words
Suggested Reading
vii
Unit No.
10
11
12
TITLE
Controlling Projects
10.1 Project Control Process
10.2 Schedule Management
10.3 Resource Management
10.4 Cost Management
10.5 Quality Management
10.6 Issue Management
10.7 Change Management
10.8 Risk Management
10.9 Communication Management
10.10 Execution of Communication Plan/Distribution of Information
10.11 Reporting Project's Performance
10.12 Reviewing the Project Execution and Control Phase
10.13 Closing Processes
Summary
Key Words
Suggested Reading
Projects Contracts Management
11.1 Understanding Contracts
11.2 Project Contract Process
11.3 Project Contract Terms
11.4 Contract Administration
11.5 Types of Contracts
Summary
Key Words
Suggested Reading
Management Risk in Projects
12.1 Understanding Project Risks
12.2 Risk Management Process
12.3 Risk Identification
12.4 Risk Assessment
12.5 Risk Mitigation
12.6 Risk Management Planning
12.7 Risk Communication
12.8 Tools for Risk Management
Summary
Key Words
Suggested Reading
viii
Page No.
243-270
271-300
301-328
Unit No.
13
14
15
TITLE
Project Quality Management
Page No.
329-356
13.1 Understanding Project Quality Management

13.2 Quality Definition
13.3 Quality Control
13.4 Quality Assurance
13.5 Quality Improvement
13.6 Achievement of Quality in Projects
13.7 Quality Standards
Summary
Key Words
Suggested Reading
Software Project Management
14.1 Software Project Management Process
14.2 Software Development Process
14.3 Software Development Models
14.4 Software Project Planning, Monitoring and Control
14.5 Software Development Cycle
14.6 Software Project Implementation
14.7 Software Testing
14.7.1 Types of Software Testing
14.8 Software Deployment
14.9 Software Maintenance
Summary
Key Words
Suggested Reading
Issues in Project Management
15.1 Best Practices in Projects
15.2 Cross-Cultural Issues in Projects
15.3 Challenges in International Project Disputes
15.4 Resolving Conflicts in Projects
15.5 Cross-Cultural Communication
15.6 Project Management Software
15.7 Project Portfolio Management
15.8 Project Workforce Management
15.9 Subcontracts and Collaboration in Projects
Summary
Key Words
Suggested Reading
References
357-384
385-412
413
ix
Introduction to Proj ects
UNIT
Structure: 1..:y1
1.1 Introduction
1.2
Defining Project
1.3 Types of Projects

1.4 Characteristics of Projects
1.5 Understanding Project Management
1.6 History of Project Management
Summary
Key Words
Suggested Reading
Notes
Obj ectives
After going through this unit, you will be able to:
Explain the concept and meaning of project
Describe the characteristics of project
Assess the historical development of projects
Explain the types of projects
Discuss the concept of project management
1.1 INTRODUCTION
Everyone talks about project management, but what exactly is it? Isn't
project management just organising little work to get the big work done? Isn't
project management really just a series of events to create something, by some
point, way off in some hazy future? Not really.
To define what project management is we first need to define what projects
are. A project, technically, is a short-term endeavour to create a unique product
or service. A project, in practical terms, is an assignment or undertaking to
create a deliverable that satisfies the mission of the project customers.
An important factor of the project is more than 50% of the projects fail
because of poor definition. This stage actually lays the foundation for a sound
working of the project and its eventual success.
What should a definition (Scope) cover and articulate?
1.
Project objectives: The definition should clearly outline the major

objectives of the project. Factors such as targets, time plan and cost
limitations should get clearly defined. E.g., 'I will be better than the
competitor' is no objective. I will be 20% better than the competitor.' is a
better statement or 'I will improve my profitability.' is no good but 'I will
improve the profitability by 15% in the current year' is a good statement.
2.
Deliverables (these could be stage wise): They can be different at

different stages. A clear plan is a deliverable in the planning stage whereas
having the system loaded on the whole network is a deliverable at the end
of the software introduction plan.
3.
Milestones or important points in the project life cycle: Completion of

specific activity at a predetermined time plan. E.g., complete the factory
building in 6 months. The milestones should also specify the responsible
functions or persons who would reach that milestone.
4.
Technical specifications and requirements: Detailed specifications of

the product, of the project should be fully and properly spelt out. It should
match the customer expectations and specifications completely. It should
also conform to time and cost plans.
Project Management Operations
5.
Limits and exclusions: Clear definition of the limits of the scope of the
project. A failure here can set a false level of expectations as also openended project with respect to costs and time overruns. Care should also be
taken to define what the project will not attempt to achieve
6.
Customer reviews: The team should clearly define the process of

periodic customer reviews and update. Customer liaison is one of the
most important communication links of any project.
Notes
Also, the project manager has to ensure that the projective objectives are
clear sub-sets of the company mission statement and strategy plan. If it is not
the same, then they should either be aligned or the project should be abandoned.
The project has to help the company achieve its objectives set in the strategic
plans.
A typical project scope document should look like the example below:
Title: Manufacturing unit for production of motors.
Deliverables: This should capture the customer specifications with respect to
cost, time and technical specs.
For example,
1.
Land development and complete roads
2.
Complete factory shade measuring 2000 sq. metre
3.
Utilities building measuring 500 sq. metre
4.
Stores and logistics building measuring 1000 sq. metre
5.
Security complex measuring 200 sq. metre
Milestones:
1.
Completion of land development and internal roads
2.
Completion of factory shade
3.
Completion of utilities and stores
4.
Completion of security complex
Technical specifications:
1.
Land development within a level difference of 50 cm
2.
Civil structures should be of fabricated steel
3.
Flooring should be of Tremix grade 250
4.
Roads should be made of bitumen and capable of taking loads
Limits and exclusions:

1.
Buildings should conform to earthquake resistance level of 4 g.
2.
Landscaping should be part of the development work.
3.
Piping and electrical work is not included in the factory and other building.
3 111
Notes
Establishing the Priorities for Project

Normally all the projects have three priorities irrespective of nature and
location of projects. These are technical specifications or scope, time duration
and costs. All these three factors are part of the agreement with the customer and
therefore are important factors with respect to its success. During the life cycle
of the project these factors do undergo many changes due to various reasons.
Every change in any one of the factors will invariably affect the other two.
One of the most important tasks of the PM is to monitor the progress with
respect to these three factors. Depending on the criticality of the factor and
situation he has to decide as which has to be strictly as per the plan and which
one could be allowed to be deviated if the need be. For example, the project for
introduction of new software will always have priority for timely introduction
of the same, above the cost and quality because of the competition. He has to
take a call on which one is to be constrained, which one should be enhanced and
which one should be left as it is. This will help manager to create a structured
decision priority matrix which will serve as a tool for mentoring the progress.
Work Break down Structure
This is the process of converting all the deliverables into subtasks at lower
levels to a stage where the tasks cannot be further broken down to any further
smaller subset. This process helps manager and the teams establish and achieve
the following major initiatives or facilities.
a.
Capture all the activities in fine details and define the scope of each activity.
b.
Define individual cost, time and specs for each activity.
c.
Define the relation of each activity with the rest.
d.
Assign the responsibility of each activity to various functions in the

organisation.
e.
Assign responsible person for each activity.
f.
Set up monitoring mechanism.
g.
Integrate each activity with the project structure.
h.
Set up priorities for each activity.
Such structure also tells manager the total requirement of all resources
with respect to their relations to the schedules and thus enables him to define
the crunch time zones and solutions thereof.
Responsibility Matrix
The WBD structure mentioned above gives rise to relation of each task
in the project to functions and individuals in the organisation. It brings out few
things clearly. How many and which functions and people are required for each
task and how long is one such output. The second one is, in how many tasks of
the project, each function and individual are involved and the respective time
duration. The matrix clearly tells the crowding of many tasks in one time zone
for each individual as also the possible idle time zones. This could be further
utilised to reschedule certain activities for resource optimisation and balancing.

Estimation of project Time and Costs
This is the most daunting and challenging task for success of project.
It can be defined as the process of forecasting the requirement of time and
financial resources for the completion of project. This can be done by either
following top-down approach or the bottom-up approach.
Top-down Approach Here the total time and costs mentioned for the whole
project is taken as reference and the same is broken down to the individual task
level.
Bottom-up Approach Here the individual tasks' needs of costs and time are
defined and added up to arrive at the top level estimate.
1.2 DEFINING PROJECT

Project has a wider meaning. An accomplishment is said to be complete
after carrying out set of activities. It is a non-routine activity and therefore every
project is unique.
Definition
1.
It is an organised unit dedicated to the attainment of pre-defined goals

within the specified time and specified resources with a pre-defined plan
and programme.
2.
It is any scheme or a smaller scheme which is part of a larger scheme

which can stand on its own and can be evaluated as an independent unit.
Project management is as old as mankind. Pyramids which are more than

4000 years old or the old cities of Mohenjo-Daro are living examples of it. It is
no more restricted to construction or erection activities but encompasses every
facet of business and even day to day life.
The new-age business environment of globalisation and Internet has further
increased the scope of project management application virtually everywhere.
This is simply because of high level of competition driving the businesses to
be "Right first time" every time. Some examples of project are: building road,
development of new product, introduction of new system, organising event,
getting married, doing MBA, etc.
Project requires special management processes, organisation structure,
techniques and the people who are familiar with PM techniques. It also requires
special ways to handle the human resources.
Thus, "A project is a set of activities to create something that is outside
of your day-to-day operations". A project creates a unique deliverable. For
example, if your organisation develops game software, the actual creation
and development of the code is a project. The manufacturing of the CDs, the
Internet delivery, and the technical support you provide to your customers is
part of maintenance and operations.
Notes
LI _
Notes
The difference is that one set of activities creates a unique deliverable

while the other centres on organisational process, day-to-day business, and
support of the organisation's mission. This is true in disciplines other than IT:
consider designing a car versus manufacturing a car, writing a book versus
printing a book, building a skyscraper versus maintaining a skyscraper.
Projects have budgets, deadlines, and an agreed set of requirements for
the deliverable to be accepted by the customer.
Project management is the only way which can get us from right here, our
current state, to our desired future state. Project management is about planning,
doing, and ensuring that we've followed our plan. Here's a key thought: the
only way we can do project management, effective project management, is to
know where our desired future state exists.
Effective project management is built on a solid foundation of planning.
The project team then must execute the work, according to the plan and the
project manager must control the work to ensure that the project plan was
followed. Project management, quite simply, is knowing where we're going,
planning on how we'll get there, and then delivering on the promises within the
plan.
All projects have constraints. Have you every inherited a project that had
to be done by a given deadline? Remember the Y2K scare that turned out to
be the Y2-OK yawn a few years ago? It was real tough to move that deadline.
January 1, 2000 was coming, ready or not.
Or have you ever managed a project that had a preset budget? Regardless
of how long it took your project could not, must not, spend more than
$750,000,or else, a pre-set budget may be calculated on how much cash is in
the bank account, the expected return on the project investment, or some other
magic formula like the time value of money. The point is a pre-set budget is
constraint.
We may also have worked with a customer who said, "I don't care how
much it costs or how long it takes. I need the product to do this." These steep
requirements are part of the project scope and in order for the project to be
successful the project scope has to be met.
Thus, there are triple constraints of project management: time, cost, and
scope. The triple constraints of project management are collectively called
"The Iron Triangle." Imagine an equilateral triangle. The bottom of the triangle
represents scope, another side represents cost, and the last side represents time.
In order for the project to be successful the project must remain an
equilateral triangle. In other words, you can have a gigantic scope, and puny
budget, or a weak schedule. For a project to be successful each side of the Iron
Triangle must remain in proportion to the other sides. If your customer wants
a scope that's so big and their budget is very small, the project will not be
completed successfully.
The same is true with the schedule. There must be enough time to plan
and execute the project in order to achieve the project's scope. Unrealistic
expectations on the schedule usually lead to waste, rework, frustrations and a
decline in morale. In some instances this may also lead to cheap tequila.
As the Project Management profession progresses into the 21st century
we are going to have to move to a new level in the project management body of
knowledge and develop extensions that define the differences in requirements
and approach for different kinds of projects such as construction, new product
development, and information systems. We will have to define the unique
characteristics of different types of projects as well as establish a typology
or taxonomy of different kinds of projects. The cl4ssification is based on the
product or deliverable of a project. The different characteristics of project are
as follows:
Degree of uncertainty and risk (construction vs. new product development)
Level of sophistication of workers (construction vs. information systems)
Level of detail in plans (days or hours for maintenance vs. months for
research)
Degree of new technology involved (research vs. administrative projects)
Degree of time pressure (maintenance or big event vs. construction)
The essential characteristics of the basic differences between types

of projects and how the project management approach must vary for each
different project type. This will serve as a starting point for developing more
specific bodies of project management knowledge, especially how the project
management approach must differ for the different project types.
Check your Progress 1
Fill in the blanks.

endeavour to create a unique
1.
Project, technically, is a
product or service.
can be defined as the process of forecasting the

requirement of time and financial resources for the completion of
project.
Project is an organised unit dedicated to the attainment of

goals within the specified time and specified
and
resources with a pre-defined
Notes
Notes
1.3 TYPES OF PROJECTS

How should we categorise different types of projects? The dictionary
defines typology as the study of types as in systematic classification. It defines
taxonomy as the science, laws, or principles of classification. It defines
classification as the systematic grouping into categories by shared characteristics
or traits. The project management profession needs a classification system for
different types of projects so that we may communicate effectively across the
entire spectrum of projects and across the entire world.
There are many different potential purposes for a system of classification.
One useful objective for a list of different types of projects is to segment the
market for marketing purposes. Another is to define the different management
approaches needed for different projects. The system of classification might
change based on the purpose. Another purpose would be to select the right
project manager based on the requirements of a specific project.
Shenhar and Wideman in several papers have proposed a system of
classification based on three variables of: (1) Degree of uncertainty at initiation,
(2) Complexity based on degree of interconnectedness, and (3) Pace based on
the need for speed in the available time frame for the project. In a paper they
added the dimension of an intellectual product (white collar) versus a craft
product (blue collar).
Parameters for Categorising Projects
There are a four basic ways in which we can set up a classification system
of projects as follows: (1) Geographical location, (2) Industrial sector (Standard
Industrial Classification System), (3) Stage of the project life cycle, and (4)
Product of the project (construction of a building or development of a new
product). The most important and the most useful breakdown is by type of
product or deliverable that the project is producing such as building a building,
developing a new product, developing new computer software program or
performing a maintenance turnaround or outage on a chemical plant or electric
generating station.
Each of these types of projects has more in common with other similar
projects producing the same type of product than with other types of projects.
Conversely, there is much less commonality between different types of projects
in the same industrial sector or company.
For example, there is much more commonality between projects for
developing a new software system in a construction company and a bank than
there is between three projects in the same bank for constructing a new building,
developing a new product and developing a new computer software system.
Major Types of Projects based on Product of Project

Here is a list of nine different types of projects based on the product they
produce.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Product of Project (Examples)

Installing a new accounting system
A building or a road
A new computer program
Architectural or engineering plans
A telephone system or IT system
Olympiads or a move into a new
building
Maintenance of Process Industries Petro-chemical plant or electric
generating station
New Product Development
Anew drug or aerospace/defence
_product
A feasibility study or investigating a
Research
chemical
???
Other
Type of Project
Administrative
Construction
Computer Software Development
Design of Plans
Equipment or System Installation
Event or Relocation
Major Variables or Parameters or Attributes

The following is a list of different characteristics that relate to different
projects. It was developed by analysing the nature of the nine different types
above.
Range*
HML
HML
Craft (blue collar) vs. Intellectual
(white collar)
HML
4. Importance of time (Pace)
HML
5. Importance of cost
HML
6. Level of new technology
7. Series of projects or one of a H M L
kind
External contract or internal work
8. Form of commitment
HML
9. Level of detail in plans
* H = High; M = Medium; L = Low
Variable
1. Stability of scope
2. Degree of uncertainty or risk
3. Type of worker
Introduction to Proj ects
otes
Notes
401
State True or False.

1.
Petro chemical plant or electric generating system is a new product

development project.
Installing an accounting system is an administrative project.
ActwaY
Activity 1
List down the different types of projects that you have come across in your
career.
1.4 CHARACTERISTICS OF PROJECTS

The following characteristics are the characteristics of a project:
1.
A clearly defined objective.
2.
It has a life cycle.
3.
It has time limit.
4.
It is a complex mesh of multiple simultaneous activities.
5.
It is a team work.
6.
It involves lot of sub-contracting or outsourcing.
7.
It always involves risk and uncertainty.
8.
It is customer specific and is meant to address some specific demand of

the customer.
9.
It is dynamic in nature.
10.
It involves and requires detailed forecasting.
11.
It has to have a good monitoring and control mechanism
Project is undertaken only after exhausting all other alternatives to achieve

the same objective in the same or better way. It has to be the most optimum
solution to achieve the desired result.
Let us now look at the attributes or characteristics that are common to
each of the nine basic types of project listed above.
1.
Administrative: Administrative projects involve intellectual workers.

The scope may change as the project proceeds.
2.
Construction: Construction is a contract business where the scope is laid

out in detail before the project starts and the level of risk is relatively
small for the size of investment. The workers are almost entirely craft
or blue collar. In most cases, time pressures are moderate and cost is a
very important variable. The processes of construction are typically well
known and the foremen are very experienced.
3.
Computer software development: Software projects are notorious for

changing the scope radically during the project, which introduces high
risk. Programmers are famous for individualistic behaviour.
4.
Design of plans: The design of any kind of plan is an intellectual

endeavour. By the exploratory nature of design the scope may not be well
defined at the beginning because the client may not have yet decided just
what they want. Quality is of a higher priority than either time or cost.
5.
Equipment or system installation: Scope is well defined and speed is

essential.
Note's
Risk should be low if the project was well planned.

6.
Event: This is a one of a kind project where scope may change during the
project and uncertainty is high. Time is critical to meet a specific date. It
is probably a complex project.
7.
Maintenance of process industries: Turnarounds and outages are short,

perhaps nine week projects, in which downtime can cost as much as a
million dollars per day and speed is critical. Uncertainty is high because
the scope is not fully known until the plant is disassembled. A large
number of different craft workers are involved. They often work three
shifts per day and plans are detailed in hours.
8.
New product development: Developing a new product is a risky business.

Time to market is much more important than cost of the project. Quality
is also critical and the scope may change up or down during the project.
9.
Research: Research projects are usually long term where quality takes
precedence over time. It is an intellectual process where scope may not
be defined at all in the beginning.
Required Project Management Approach

Let us now look at the different approaches that are necessary to manage
each of the nine basic types of project.
1.
Administrative: Teambuilding and refinement of objectives are important

on administrative projects where some or all of the team may be parttimers.
2.
Construction: Construction projects generally run smoothly since the

staff are all experienced and know their jobs. Control of labour hours and
cost control is important for the contractor on lump sum type contracts.
3.
Computer software development: Tight project control is necessary on

software projects in which other factors may be quite loose. The project
manager needs to be ready to adapt to changing requirements from the
client.
11
Notes
4.
Design of plans: Because the scope and activities necessary for

development of plans may be fuzzy it is all the more important to have a
detailed project management system to adapt to changes as they occur.
5.
Equipment or system installation: This is a case of thinking through all

contingencies ahead of time and being sure that all involved are heading
in the right direction.
6.
Event: Detailed planning and good teambuilding are important in these

complex projects where timing is critical.
7.
Maintenance of process industries: With hundreds of workers involved

in three shifts per day where a reduction of one day can be worth a million
dollars, detailed planning and control is essential.
8.
New product development: The business of managing a diverse group

of various technical specialists in a matrix organisation to meet quality
and time objectives on a complex project is demanding. Good project
management is essential.
9.
Research: Project management can be relaxed on long lead-time research

projects but it is all the more necessary to set goals, and to measure
progress against those goals.
Other Variables Common to all Types of Projects (Secondary Factors)

The following factors are important in projects but are not specific to any
one of our list of project types. They could relate to any of the types. These
factors could be used in other types of project classification.
1.
2.
3.
4.
5.
6.
Size
Duration (Length of project time)
Industrial sector
Geographic location
Number of workers involved
Cost (large, medium or small)
Complexity
7.
8.
Urgency
9.
Organisational design
Type Projects by
Product
1.Administrative
2.Construction
3.Software
4. Design
5.Maintenance
6.Event
7.Equipment
8.New Product
9.Research
12
Type of
Worker
White
Blue
High Tech
White
Blue
White
Blue
White
High Tech
Degree of
Uncertainty
Low
Low
High
Medium
High
Low
Low
High
High
Time
Pressure
Low
Low
Medium
Medium
High
Medium
Low
High
Low
Stability
of Scope
High
High
Low
Medium
Low
High
High
Low
Low
Level of
Technology
Low
Low
High
High
Low
Medium
Low
High
High
Importance
of Cost
Low
High
Low
Medium
Low
Medium
Low
Low
Low
Notes
mtmtv Activity 2
Visit any nearby project site and list down the characteristics of the project.
1.5 UNDERSTANDING PROJECT MANAGEMENT

We like photography. We like to look at pictures, take pictures, and mess
with filters, lenses and light meters. In order to really capture a good photo,
we have to see the developed photo in our mind's eye. We have to look at our
environment and see how it'd look once the film's been developed or the image
is printed on our colour printer. We have to see into the future in order to capture
the present in our camera. We must have vision. Being a project manager really
isn't that different. A project manager must have vision for what the project is to
be created. The project manager inherits the vision from the key stakeholders,
the project sponsor or even management. In order to plan for the project work
the project manager must envision what the end result of the project will be.
Like taking a photo, a good photo, the project manager has to study, observe,
and see the end result of the efforts before the work begins.
Another way to look at the Iron Triangle is to imagine the photographer's
tripod. If we have to work with a tripod (with a camera on top) we know the
secret is to have the tripod balanced and level. In fact, some camera tripods
have a level built into the head so we know when it is level. A level tripod
ensures that the photo's horizon is flat.
Now imagine that one leg of the tripod equates to scope, another to time,
and the last is cost. We agree that the tripod has to he balanced to take a good
picture, just like a project has to have balance to be successful. If any leg of the
tripod is extended more than the others the tripod is off-balance just like our
projects.
Some tripods are nice and heavy. A heavy tripod helps when we are taking
a photo in the middle of a river or we are fighting a wind storm. The trouble
with heavy tripods is someone has to carry them. What some photographers do
is carry a light tripod and then suspend their camera bag under the tripod to fend
off any shakes.
In project management what's keep our project sturdy? Imagine that the
area within the three legs of the tripod represents quality. If any leg of the tripod
is out of balance then quality is likely to suffer. Quality is in proportion to the
amount of time, cost and scope available for the project deliverables. When one
angle of the project suffers so does quality.
What good is a project's deliverable if the project is finished on time, but
the product or service doesn't work as promised? Or if the project manager has
spent all of the money but didn't create all the promised deliverables? Quality
is affected by the balance of time, cost and scope.
Notes
Following this snappy analogy of photography, what kind of camera

would you like to put on top of your tripod? Would we take a digital SLR
capable of 12 mega pixels, and a few gigs of memory for our digital photos.
Or we could rely on a manual 35mm camera, with slide film, and a nice set of
filters.
But wouldn't we have better photos with the 12 mega pixel digital
camera? Not necessarily. Just because we have a fantastic camera doesn't mean
your photos will be fantastic. It's not the camera that takes the pictures, it's the
photographer.
The camera, in our project management analogy, is the mechanics of
project management. The person behind the camera is the project manager.
Just as the photographer has to know how to adjust the camera to capture the
perfect photo, so does the project manager adjust the controls within project
management to deliver on the project's demands.
Good photographers and good project managers have much in common:
experience, a foundation in the fundamentals, and a willingness to learn. At the
core is an ability to capture a vision and then process that vision for others to
see.
Projects tell a story
Projects, like a good story, have a beginning, middle, and a satisfying end.
Let us think back to any project we have managed or worked on. Can you recall
the beginning, middle, and a Hollywood ending?
The story for all projects is that, they move through five process groups to
get from start to finish. Within each process group there are key activities which
help a project move along.
Initiate a project
This process group starts all the fun. In this group the business need for
the project is identified, some initial solutions may be proposed, and the project
manager is selected.
The most important document to come out of this group is the project
charter. The project charter authorises the project work and assigns the project
manager the power to complete the project on behalf of the project sponsor.
The project sponsor is typically someone high enough in the organisational
hierarchy to have power over the resources that need to be involved in the
project.
Planning the project
In order to plan, the project manager must know what the project will
create. The project manager and the project stakeholders, the people that have a
stake in the project outcome have to determine what the desired future state is.
A dreamy wish list won't work. The project demands exact requirements. If you
don't know what the project should create how will you ever get there?
Once the project requirements have been agreed upon then the project
manager, the project team, and in some instances the project stakeholders will
create a plan on how to achieve the project objectives. This isn't a one-time
process. Planning is an iterative process that happens throughout the project
duration. Planning is cornerstone of project management if you skip planning
or do it half-heartedly, the project is doomed.
Executing the project
"Plan your work and then work on your plan." This is the working part.
The executing process group is the project team executing the project work
according to plan and the project manager working with any vendors that may
be involved in the execution or support of the deliverables needed for the project
completion.
Controlling the project
Controlling isn't about micromanaging; it's about compliance with the
project plan. There's balance between execution and control. The project
manager works with the project team, not over them, to ensure that they 're
doing the work as it was planned, and if not, then the project manager makes
corrective actions to get the project back in alignment with the project plan.
Controlling is also about balancing the time, cost, and scope constraints
as the project moves along. The project manager has to measure, compare, and
adjust controls within the project to ensure project success. If we do not measure
we cannot improve.
Closing the project
This process group centres on closing out the project accounts, completing
final, formal acceptance of the project deliverables, finalising any time, cost, or
quality reports, completing the project's lessons learned documentation, and
finalising any financial or procurement audits. The project manager may have to
complete a review of each team member, a review of the vendors, and a review
of their own actions in the project.
Project closure also involves some rewards and recognition. For some,
this means bonuses, vacation time, or other rewards. If this isn't appropriate
or available in the organisation, the project manager should at least verbally
reward the project team for their hard work and a job well-done.
Putting it all together
As you know projects are short-term endeavours to create a unique
product or service. Projects are out of the normal duties you do as part of
your operations. Projects are constrained by time, cost and scope and other
constraints such as regulations, resources, or even vendors.
The Iron Triangle of project management points that all projects are
constrained by time, cost, and scope. If one angle of the project is out the whole
project suffers.
Notes
Notes
Projects, and technically even project phases, move through five process
groups: initiating, planning, executing, controlling and closing. Each process
group has key activities that lend to a successful project. The most important
group is planning. Without planning the project is destined for failure.
What we've discussed in this introduction to project management is a
good foundation for how projects are to operate, their constraints, and some
challenges every project manager faces. On top of this strong foundation, there
are nine knowledge areas which also affect a project's success:
1.
Project Scope Management
2.
Project Time Management
3.
Project Cost Management
4.
5.
Human Resources Management
6.
Communications Management
7.
Project Risk Management
8.
Project Procurement Management
9.
Project Integration Management
Projects are successful based on the ability of the project manager to lead,
manage and motivate the project team to complete the project plan. The project
plan supports the vision the project manager has inherited from the project
stakeholders. If the project manager and the project stakeholder don't have the
same vision of the desired future state, the project is doomed.
Projects fail at the beginning, not at the end
Project management in the modern sense began in the early 1960s, although
it has its roots much further back in the latter years of the 19th century. The need
for project management was driven by businesses that realised the benefits of
organising work around projects and the critical need to communicate and coordinate work across departments and professions.
Here is the main definition of what project management is:
1.
Project management is no small task.
2.
Project management has a definite beginning and end. It is not a continuous

process.
3.
Project management uses various tools to measure accomplishments and

track project tasks. These include Work Breakdown Structures, Gantt
charts and PERT charts.
4.
Projects frequently need resources on an ad-hoc basis as opposed to

organisations that have only dedicated full-time positions.
5.
Project management reduces risk and increases the chance of success.

Multiple Choice Multiple Response.
1.
The key activities of the project are:
i.
ii.
Engineering
Managing Resources
iii.
iv.
v.
Skill Development
Training to Staff
Knowledge Management
1.6 HISTORY OF PROJECT MANAGEMENT'

In this brief history of project management we chart all the major
developments and events in the discipline as far back as there are records.
Although there has been some form of project management since early
civilisation, project management in the modern sense began in the 1950s.
2570 BC: The Great Pyramid of Giza Completed
The Pharaohs built the pyramids and today archaeologists still argue
about how they achieved this feat. Ancient records show there were managers
for each of the four faces of the Great Pyramid, responsible for overseeing their
completion. We do know there was some degree of planning, execution and
control involved in managing this project.
208 BC: Construction of the Great Wall of China
Later still, another of the Seven Wonders of the World was built. Since the
Qin Dynasty (221BC-206BC), construction of the Great Wall had been a large
project. According to historical data, the labour force was organised into three
groups: soldiers, common people and criminals. The Emperor Qin Shihuang
ordered millions of people to finish this project.
1910-1915: The Gantt Chart developed by Henry Gantt (1861-1919)
One of the forefathers of project management, Henry Gantt is best-known
for creating his self-named scheduling diagram, the Gantt chart. It was a radical
idea and an innovation of worldwide importance in the 1920s. One of its first
uses was on the Hoover Dam project started in 1931. Gantt charts are still in use
today and form an important part of the project managers' toolkit.
1956: The American Association of Cost Engineers (now AACE
International) formed
Early practitioners of project management and the associated specialties
of planning and scheduling, cost estimating, cost and schedule control formed
the AACE in 1956. It has remained the leading professional society for cost
estimators, cost engineers, schedulers, project managers and project control
Notes
Notes
specialists since then. AACE continued its pioneering work in 2006 releasing
the first integrated process for portfolio, programme and project management
with their Total Cost Management Framework.
1957: The Critical Path Method (CPM) invented by the Dupont Corporation
Developed by Dupont, CPM is a technique used to predict project duration
by analysing which sequence of activities has the least amount of scheduling
flexibility. Dupont designed it to address the complex process of shutting
down chemical plants for maintenance and then with maintenance completed
restarting them. The technique was so successful it saved the corporation $1
million in the first year of its implementation.
1958: The Program Evaluation Review Technique (PERT) Invented for the
US Navy's Polaris Project
The United States Department of Defence's US Navy Special Projects
Office developed PERT as part of the Polaris mobile submarine launched
ballistic missile project during the cold war. PERT is a method for analysing the
tasks involved in completing a project, especially the time needed to complete
each task and identifying the minimum time needed to complete the total
project.
1962: United States Department of Defence Mandate the Work Breakdown
Structure (WBS) Approach
The United States Department of Defence (DOD) created the WBS concept
as part of the Polaris mobile submarine launched ballistic missile project. After
completing the project, the DOD published the work breakdown structure it
used and mandated that this procedure be followed in future projects of this
scope and size. WBS is an exhaustive, hierarchical tree structure of deliverables
and tasks that need to be performed to complete a project. Later adopted by the
private sector, the WBS remains one of the most common and effective project
management tools.
1965: The International Project Management Association (IPMA) Founded
IPMA was the world's first project management association, started
in Vienna by a group as a forum for project managers to network and share
information. Registered in Switzerland, the association is a federation of about
50 national and internationally oriented project management associations.
Its vision is to promote project management and to lead development of the
profession. Since its birth in 1965, IPMA has grown and spread worldwide with
over 40,000 members in more than 40 countries.
1969: Project Management Institute (PMI) launched to promote the Project
Management Profession
Five volunteers founded PMI as a non-profit professional organisation
dedicated to advance the practice, science and profession ofproject management.
The Commonwealth of Pennsylvania, USA issued Articles of Incorporation for
PMI in 1969 which signified its official start. During that same year, PMI held
its first symposium in Atlanta, Georgia and had an attendance of 83 people.

Since then, the PMI has become best known as the publisher of "A Guide to
the Project Management Body of Knowledge (PMBOK)," considered one of
the most essential tools in the project management profession today. The PMI
offers two levels of project management certification, Certified Associate in
Project Management (CAPM) and Project Management Professional (PMP).
1975: PROMPTII Method created by Simpact Systems Limited
PROMPTII was developed in response to an outcry that computer projects
were overrunning on time estimated for completion,and original budgets as set
out in feasibility studies. It was not unusual to experience factors of double,
triple or even ten times the original estimates. PROMPTII was an attempt to
set down guidelines for the stage flow of a computer project. In 1979, the UK
Government's Central Computing and Telecommunications Agency (CCTA)
adopted the method for all information systems projects.
1975: The Mythical Man-Month: Essays on Software Engineering by Fred
Brooks
Inhis book on software engineering and project management, Fred Brooks 's
central theme is that "Adding manpower to a late software project makes it later."
This idea is known as Brooks's law. The extra human communications needed to
add another member to a programming team is more than anyone ever expects.
It naturally depends on the experience and sophistication of the programmers
involved and the quality of available documentation. Nevertheless, no matter
how much experience they have, the extra time discussing the assignment,
commitments and technical details as well as evaluating the results becomes
exponential as more people are added. These observations are from Brooks's
experiences while managing development of OS/360 at IBM.
1984: Theory of Constraints (TOC) introduced by Dr. Eliyahu M. Goldratt
in his Novel "The Goal"
TOC is an overall management philosophy that is geared to help
organisations continually achieve their goal. The title comes from the view that
any manageable system is limited in achieving mpre of its goal by a small
number of constraints, and there is always at least one constraint. The TOC
process seeks to identify the constraint and restructure the rest of the organisation
around it by using Five Focusing Steps. The methods and algorithms from TOC
went on to form the basis of Critical Chain Project Management.
1986 Scrum named as a Project Management Style
Scrum is an agile software development model based on multiple small
teams working in an intensive and interdependent manner. In their paper "The
New Product Development Game" (Harvard Business Review, 1986), Takeuchi
and Nonaka named Scrum as a project management style. Later they elaborated
on it in The Knowledge Creating Company (Oxford University Press, 1995).
Although Scrum was intended for management of software development
projects, it can be used to run software maintenance teams, or as a general
project and programme management approach.
Notes
Notes
1987: A Guide to the Project Management Body of Knowledge (PMBOK

Guide) Published by PMI
First published by the PMI as a white paper in 1987, the PMBOK Guide
was an attempt to document and standardise accepted project management
information and practices. The first edition was published in 1996, followed by
a second in 2000, and third in 2004. The guide is one of the most essential tools
in the project management profession today and has become the global standard
for the industry.
1989: Earned Value Management (EVM) Leadership elevated to UnderSecretary of Defence for Acquisition
Although the earned value concept has been around on factory floors since
the early 1900s, it only came to prominence as a project management technique
in the late 1980s and early 1990s. In 1989, EVM leadership was elevated to the
Under-secretary of Defence for Acquisition, thus making EVM an essential part
of programme management and procurement. In 1991, Secretary of Defence,
Dick Cheney cancelled the Navy A-12 Avenger II Programme because of
performance problems detected by EVM. The PMBOK Guide of 1987 has an
outline of Earned Value Management (EVM) subsequently expanded on in later
editions.
1989: PRINCE Method Developed From PROMPTII
Published by the UK Government agency CCTA, Projects IN Controlled
Environments (PRINCE) became the UK standard for all government
information systems projects. A feature in the original method, not seen in
other methods, was the idea of "assuring progress" from three separate but
linked perspectives. However, the PRINCE method developed a reputation as
being too unwieldy, too rigid and applicable only to large projects, leading to a
revision in 1996.
1994: CHAOS Report first published
The Standish Group collects information on project failures in the IT
industry with the objective of making the industry more successful, showing
ways to improve its success rates and increase the value of IT investments. The
CHAOS report is a biennial publication.
1996: PRINCE2 Published by CCTA
An upgrade to PRINCE was considered to be in order and the development
was contracted out, but assured by a virtual committee spread among 150
European organisations. Originally developed for IS and IT projects to reduce
cost and time overruns; the second revision was made more generic an applicable
to any project type.
1997: Critical Chain Project Management (CCPM) invented
Developed by Eliyahu M. Goldratt, Critical Chain Project Management is
based on methods and algorithms drawn from his Theory of Constraints (TOC)
introduced in his 1984 novel titled The Goal. A Critical Chain project network
20
will keep the resources levelly loaded, but will need them to be flexible in their
start times and to switch quickly between tasks and task chains to keep the
whole project on schedule.
1998: PMBOK becomes a Standard
The American National Standards Institute (ANSI) recognises PMBOK
as a standard in 1998, and later that year by the Institute of Electrical and
Electronics Engineers (IEEE).
2006: "Total Cost Management Framework" released by AACE
International
Total cost management is the name given by AACE International to a
process for applying the skills and knowledge of cost engineering. It is also
the first integrated process or method for portfolio, programme and project
management. AACE first introduced the idea in the 1990s and published the
full presentation of the process in the "Total Cost Management Framework".
2008: 4th Edition of PMBOK Guide released
The fourth edition of the guide continues the PMI tradition of excellence in
project management with a standard that is easier to understand and implement,
with improved consistency and greater clarification. The updated version has
two new processes not in the previous versions.
2009: Major PRINCE2 Revision by Office of Government Commerce
(OGC)
A major revision has seen the method made simpler and more easily
customisable, a common request from users. The updated version has seven
basic principles (not in the previous version) that contribute to project success.
Overall the updated method aims to give project managers a better set of tools
to deliver projects on time, within budget and to the right quality.
What's Next?
With globalisation come ever bigger challenges and the need for
increased speed to market with products and services. Projects become larger,
more complex and increasingly difficult to manage. Teams are more diverse
and spread across the world. The economic crisis pushes work offshore to low
cost countries, which itself presents several issues. The world is changing and
project management will need to change with it.
No doubt new techniques and better practices will arise as we push the
boundaries of what is possible and new challenges arise. Human need drives
us forward to a better future and with it will come improvements in the way we
manage projects. When and where these developments will happen is uncertain,
but they will happen.
i-Notes
Notes
Here's to the next hundred Sears!

Total Cost Management
Framework
DoD Mandate WBS
Theory of Constraints
Approach
PMBOK Guide 4th
Serum a PM Style
FPMAFouneltd
Edition
PMIFounded
.4- Gantt Chart Developed
PMBOK Guide
PRINCE2
Revision
PRINCE Method
1910 1920 1930 1940 1950 1960 1970 1980 1990 2000 2010
AACE Formed
Hoover Dam Project
CPM Invented
- PERT Invented
First CHAOS Report

PROMPTU Method
PRINCE2 Method
_ The Mythical ManMonth Essays CCPM Invented
PMBOK Becomes an
ANSI Standard
Fig. 1.1: Project Management Timeline

Fill in the blanks.
1.
The full form of PMBOK is
pffers two levels of project management

The
certification, Certified Associate in Project Management (CAPM)
and Project Management Professional (PMP).
Summary
A project, technically, is a short-term endeavour to create a unique product

or service. A project, in practical terms, is an assignment or undertaking
to create a deliverable that satisfies the mission of the project customers.
An important factor of the project is that more than 50% of the projects
fail because of poor definition. This stage actually lays the foundation for
a sound working of the project and its eventual success.
The new age business environment of globalisation and Internet has

further increased the scope of project management application virtually
everywhere. This is simply because of high level of competition driving
the businesses to be "Right first time" every time.
Project requires special management processes, organisation structure,

techniques and the people who are familiar with PM techniques. It also
requires special ways to handle the human resources.
There are a four basic ways in which we can set up a classification system
of projects as follows: (1) Geographical location, (2) Industrial sector
(Standard Industrial Classification System), (3) Stage of the project
life cycle and (4) Product of the project (construction of a building or
development of a new product). The most important and the most useful
breakdown is by type ofproduct or deliverable that the project is producing
such as building a building, developing a new product, developing new
computer software program or performing a maintenance turnaround or
outage on a chemical plant or electric generating station.
The Iron Triangle of project management posits that all projects are
constrained by time, cost and scope. If one angle of the project is hit the
whole project suffers.
Projects, and technically even project phases, move through five process
groups: initiating, planning, executing, controlling and closing. Each
process group has key activities that lend to a successful project. The most
important group is planning. Without planning the project is destined for
failure.
Keywords
Project: A unique set of activities aimed towards achieving an objective

within given time and estimated cost.
Work breakdown structure: The process of converting all the

deliverables into subtasks at lower levels to a stage where the tasks cannot
be further broken down to any further smaller subset.
Project management: A process which has a definite beginning and

end, uses various tools to measure accomplishments and track project
tasks, need resources on an ad-hoc basis as opposed to organisations that
have only dedicated full-time positions and reduces risk and increases the
chance of success.
1.
What is a project? Explain the different types of projects.
2.
What is the importance of understanding the' project? What are the

different characteristics of projects?
3.
"If the scope of project is not defined properly, it will fail." Do you agree?
What is the scope of project management?
4.
Explain the historical development of project management.
5.
Why projects fail? Explain the steps that can be taken to avoid failure of
projects.
Notes

Fill in the blanks.
1.
Project, technically, is a short-term endeavour to create a unique product

or service.
2.
Estimation of project can be defined as the process of forecasting the

requirement of time and financial resources for the completion of project.
3.
Project is an organised unit dedicated to the attainment of pre-defined

goals within the specified time and specified resources with a pre-defined
plan and programme.

False
J-
2. True
1.
The key activities ,z4 the project are:

i.
Engineering
ii.
Managing Resources

Fill in the blanks.
1.
The full form of PMBOK is Project Management Book of Knowledge.
2.
The PMI offers two levels of project management certification, Certified

Associate in Project Management (CAPM) and Project Management
Professional (PMP).
Suggested Reading
1.
Prasanna, Chandra. 2002. Project Management. New Delhi: Tata

McGraw-Hill.
2.
Project Management Handbook. The Project Management Body of

Knowledge (PMBOK).
3.
Project Management International (PMI) Magazine. PMBOK

Structure: tit 4.
2.1 Project Management An Introduction
UNIT
2.2 Importance of Project Management

2.3 Characteristics of Project Management
2.4 Phases and Steps in Project Management
2.5 Project Management Life Cycle
2.6 Project Management Methodology
Summary
Key Words
Suggested Reading
25
Notes
Objectives
Describe the concept of project management
Identify the importance of project management
Explain the phases in project management
Discuss the characteristics of project management
List the steps in project management
Analysethe project life cycle
Explain the project methodology
2,1 PROJECT MANAGEMENT AN INTRODCUTION

Project management is about creating an environment and conditions in
which a defined goal or objective can be achieved in a controlled manner by a
team of people.
Project management is often summarisedin a triangle. The three most
important factors are time, cost and scope, commonly called the triple constraint.
These form the verticeswith quality as a central theme.
Time
Quality
Scope
Cost
1.
Projects must be delivered on time.
2.
Projects must be within cost.
3.
Projects must be within scope.
4.
Projects must meet customer quality requirements.
More recently, this has given way to a project management diamond, with
time, cost, scope and quality the four vertices and customer expectations as a
central theme. No two customers' expectations are the same so you must ask
what their expectations are.
Time
Quality
Expectations
Cost
Scope
The triangle illustrates the relationship between three primary forces

in a project. Time is the time available to deliver the project, cost represents
the amount of money or resources available and quality represents the fit-topurpose that the project must achieve to be a success.
The normal situation is that one of these factors is fixed and the other
two will vary in inverse proportion to each other. For example, time is often
fixed and the quality of the end-product will depend on the cost or resources
available. Similarly, if you are working to a fixed level of quality then the cost
of the project will largely be dependent upon the time available (if you have
longer you can do it with fewer people).
The astute reader will be wondering what happens when two of the points
are fixed. This is when it really gets interesting. Normally this occurs when the
costs are fixed and there is a definite deadline for delivery, an all too familiar set
of circumstances. Then, if the scope starts to creep you are left with only one
choice, cut functionality. This is more common than you might think, in fact it's
more common than not.
Cutting functionality may seem a drastic measure, but an experienced
project manager will happily whittle away functionality. As long as the core
requirements remain, everything will be fine. Additional functionality can
always go into "the next release," but if you don't deliver the core functionality,
there won't be a next release.
A really experienced project manager might even pad his project with a
little superfluous functionality that could be sacrificed when the crunch comes
(but you didn't hear it from me!).
A phenomenon known as "scope creep" can be linked to the triangle too.
Scope creep is the almost unstoppable tendency, a project has to accumulate
new functionality. Some scope creep is inevitable since, early on; your project
will be poorly defined and will need to evolve. A large amount of scope creep
however can be disastrous.
When the scope starts to creep, new functionality must be added to cover
the increased scope. This is represented by the quality arm of the triangle,
representing the ability of the product to fulfil users' requirements. More
requirements fulfilled equal a better quality product.
emotes
11,11
In this situation you have three, and only three options:
Add time delay the project to give you more time to add the functionality
Add cost recruit, hire or acquire more people to do the extra work
Cut quality trade off some non-essential requirements for the new
requirements
If the art of management lies in making decisions, then the art of project
management lies in making decisions quickly! When faced with scope creep
you cannot ignore it. You need to tackle it in one of the ways described above
(more later) and the sooner the better. Delaying raises the risk of your project
failing.
A poor project manager will see the scope triangle as a strait-jacket by
which their project is irrevocably constrained. A better project manager will
make better use of one or more of the axes and will shift the emphasis in the
project to one of the other axes. The best project managers will juggle all three
like hot potatoes and will make decisions every day which effectively trade-off
time vs. quality vs. resources. ,
Many things can go wrong in project management. These things are often
called barriers. Here are some possible barriers:
Poor communication
Disagreement
Misunderstandings
Bad weather
Union strikes
Personality conflicts
Poor management
A good project management discipline will not eliminate all risks, issues
and surprises, but will provide standard processes and procedures to deal with
them and help prevent the following:
Projects finishing late, exceeding budget or not meeting customer

expectations.
Inconsistency between the processes and procedures used by projects

managers, leading to some being favoured more than others.
Successful projects, despite a lack of planning, achieved through high

stress levels, goodwill and significant amounts of overtime.
Project management seen as not adding value and as a waste of time and
money.
Unforeseen internal and/or external events impacting the project.
2.2 IMPORTANCE OF PROJECT MANAGEMENT

Project management as a management discipline underpins much
economic activity. In industries as diverse as pharmaceuticals, software and
aerospace, projects drive business. And in the public sector, it is effective
project management that translates politicians' promises of new roads, schools
and hospitals into gleaming new constructions that improve everyday life.
So you'd imagine that it would be possible to place some sort of figure
on the importance of project management to the UK economy. How much GDP
does it drive? In which sectors of the economy? And as the economy evolves,
how fast is project management's prominence increasing?
Think again. A data from Government's Office of National Statistics
reveals the official input-output tables that record and analyse the makeup of
economic activity within the country go into no finer detail than at the level of
individual industries. We know that the GDP of the nation's economy in 2002
amounted to some 1044bn, up 5% from 994bn the year before. We know
which industries contributed the most to that overall GDP figure, and which
contributed least. But we know nothing at least in terms of officially tabulated
government statistics about the extent of project management's contribution to
that GDP.
So what exactly is the contribution of project management to a modern
developed economy like the UK's?
A statistic and a caution
American researchers employed by the Project Management Institute have
an answer of sorts. On the basis of data released by the Bureau of Economic
Analysis, part of the US Department of Commerce, it was estimated that the US
public and private sectors combined spend some $2.3trn on projects every year,
an amount equivalent to a quarter of America's GDP. Construction, RandD,
software development, organisational change, IT systems - add it all together
and that's the price tag. Extrapolating further, they estimated that project-related
spending accounted for almost $10trn of the world's global GDP.
On that basis, given the UK GDP of 1044bn in 2002, project-related
expenditure of a quarter of GDP yields a GDP figure of 261bn. This, of course,
relies on the UK economy being structurally similar enough to the American
economy for the American estimate of project management's contribution
to GDP to hold true. While there are undoubted differences between the two
economies, they are unlikely to be significant enough to materially affect
the extrapolated UK figure. A 10% deviation either way, for example, would
indicate a range of (say) 235bn to 287bn.
There is, however, one slight problem to address when considering project
Notes
Noses
management vis-a-vis GDP estimates. And it is here that a note of caution must
be injected.
Take two hypothetical projects, identical in all respects except the calibre
of their project management. One project comes in on budget, having used the
planned resources. The other dramatically exceeds its budget, using far more
resources than planned. Which has the greater contribution to GDP? The latter.
Overtime payments, additional employees, replacements for materials wasted
or otherwise found faulty perversely, these additional expenditures contribute
positively to GDP, not negatively.
As a result, while GDP based estimates of the value of prof ect management
to the UK economy are useful starting points, a more rounded insight into
the value of project management to the UK economy must come from more
qualitative data.
Project Management and Innovation
Almost by definition, innovation relies onproj ect management. Irrespective
of whether the innovation concerns a new product, or a new process, or indeed a
contribution to pure science, better project management, on the whole, will see
a successful outcome reached more quickly, having consumed fewer resources.
And innovation is important to the UK economy. As a succession of
reports from the UK government's Department of Trade and Industry (DTI)
has highlighted over the years, innovative businesses are more successful, and
innovative industries grow faster, export more, are more competitive, more
productive, and have a better long-term future.
Stating the benefits of innovation is one thing defining innovation itself,
or quantifying it, is another.As successive generations of statisticians have
found, the measurement of innovation is almost as slippery a concept as the
measurement of project management.
An interesting table (see Table 1) from the current DTI innovation report
breaks down the innovation carried out by a number of manufacturing industries
based on one widely used proxy measure RandD spending, commonly reported
by companies in their annual accounts.
Even so, this almost certainly understates the true level of innovation
activity, especially with respect to process innovation. The engineering
departments and process improvement groups of manufacturing companies
routinely make process improvements that go unrecorded as RandD, for
example.
Industry
RandD as percentage of value

added (average 1991-2000)
Electrical and optical

of which computers and office
equipment
communication equipment, TV,
radio
Chemicals and man-made fibres
12.9
- of which pharmaceuticals
Plastic and rubber products
Food, drink and tobacco
Textiles
Textiles
Manufacturing total/average
18.5
44.2
0.8
1.1
0.4
7.0
Notes mime
6.6
5.5
Table 1: RandD inputs by manufacturing sector - DTI Innovation Report,

Competing in the global economy: the innovation challenge (December 2003).
Crown copyright 2004.
Overall, 7% of value added in manufacturing industry is project-based
innovation. More, of course, taking into account the argument that some
process-oriented improvement projects are overlooked. While some industries
fall far below this level such as textiles, where just 0.4% of value added takes the
form of innovation others massively exceed it. The pharmaceutical industry, for
example, sees 44.2% of value added generated through innovation. Put another
way, almost half the value added by the industry owes its immediate provenance
to projects a figure is sure to increase once the planning, construction and
commission of the new equipment and facilities required to bring successful
innovations to market is accounted for.
A publication makes the case even more tellingly. Productivity in the
UK: 3, the Regional Dimension (published by HM Treasury, November 2001).
The report emphasises that the invention and application of new technologies,
products and production processes is a key driver of productivity growth, which
has accounted for no less than two-thirds of overall UK economic growth over
the past 50 years. Without effective project management even using the more
primitive project management methodologies of yesteryear this would not have
been possible.
Project management also underpins the regional economies. It is the speed
and efficiency with which innovations are spread and adapted that differentiate
regional performance, concludes the report. GDP per head, for example, is 40%
lower in the North East than in London. But under-performing regions have
significant barriers in adapting and absorbing innovations, in particular lacking
the highly skilled workers and productive firms that invest in RandD. High
levels of innovation in a local economy have a multiplier effect in stimulating a
more enterprising indigenous business base and a more enterprising society in
the wider sense. In the UK overall, the report finds, there is a strong statistical
31
Notes
correlation between the regional pattern of RandD (both public and private
sector) and regional economic performance. Again, it is project management
that underpins that RandD, and manages the process of turning ideas into
actionable innovations.
Project Management and Project-Intensive Industries
Every business undertakes projects of some sort. But some undertake far
more than others. Similarly, some industries are more project-intensive than
others. Aerospace and defence, for example, are extremely project-intensive,
working for years on long-term contracts or development projects that will
eventually bring forth a new jet aircraft, missile system, ship or piece of
electronic wizardry. Likewise, almost by definition, construction is another
industry that exhibits a high degree of project activity.
Food, retailing and textiles, on the other hand, are less project-intensive.
Even so, care must be taken. While corner shops may not be prone to launching
new projects, the major supermarkets are, each year sees a number of new
distribution depots, IT systems, retail outlets and the like.
The corner shop should not be overlooked altogether, though. Taken
together, the UK's 3.7 million SMEs account for approximately 40% of the
UK's GDP, and have combined sales revenues of 1 tm. Employing over 12
million people in the UK, they account for 85% of the 2.3 million extra jobs
created by new businesses in the period 1995-99, and over 50% of the 3.5
million jobs gained from expansion of existing firms over the same period.
Impressive though these figures are it is highly probable that enhanced
project management capabilities would have seen an even greater transformation.
That, in essence, is the scale of the opportunity facing the UK, and indeed many
other developed economies.
Richard Pharro, managing director of accreditation and examination
body APMG, which commissioned this research, comments: "At last we are
beginning to see research which proves how important project management
is to the UK and global economies. All kinds and sizes of organisations in
both the public and private sectors should sit up and take note of this because
without well-trained and capable project managers the percentage of GDP
spent through projects is inflated due to many exceeding their budget through
poor management. Furthermore, considering the impact that successful project
management has on fast-growing SMEs, we hope to see more project managers
getting the recognition they deserve in helping to make these organisations even
more innovative and successful."
Project management is a not-so-hi-tech concept that enables managers to
guide a project from point "A" to point "B" and do so in a way that demonstrates
efficiency, cost-savings and plain 'of ingenuity. That being said, the benefits
of project management are ten-fold: the manager actually gets to manage as
they lead their team and institute a strategy that will see said project reach
fruition. The client benefits because they are allowed to provide feedback, while
relishing in the knowledge that their input really means something. And finally,
the workers benefit because without the workers/team the project wouldn't get
finished. Additionally, the team members are able to take a stake in something,
work with it and see said project through from start to finish.
The benefits of project management contain all the elements of what
is a truly symbiotic relationship between manager, client and worker bee. In
fact, it's this very application of knowledge, skills, tools and techniques that
ultimately will meet or exceed a stakeholder's needs and/or expectations on any
given project.
Now that we've laid out the ground-rules, it's a lot easier to visualize
what some of the benefits of project management are. With apologies to David
Letterman, I've put together my own top-ten list of the benefits of project
management:
1.
Better efficiency in delivering services: Project management provides a

"roadmap" that is easily followed and leads to project completion. Once
you know where to avoid the bumps and pots holes it stands to reason that
you're going to be working smarter and not harder and longer.
2.
Improved/increased/enhanced customer ,satisfaction: Whenever you

get a project done on time and under budget, the client walks away happy.
And a happy client is one you'll see again. Smart project management
provides the tools that enable this client/manager relationship to continue.
3.
Enhanced effectiveness in delivering services: The same project

management strategies that allowed you to successfully complete one
project will serve you many times over.
4.
Improved growth and development within your team: Positive results

not only command respect but more often than not inspire your team to
continue to look for ways to perform more efficiently.
5.
Greater standing and competitive edge: This is not only a good benefit
of project management within the workplace but outside of it as well;
word travels fast and there is nothing like superior performance to secure
your place in the marketplace.
6.
Opportunities to expand your services: A by-product of greater

standing. Great performance leads to more opportunities to succeed.
7.
Better Flexibility: Perhaps one of the greatest benefits of project

management is that it allows for flexibility. Sure project management
allows you to map out the strategy you want to take to see your project
completed. But the beauty of such organization is that if you discover
a smarter direction to take, you can take it. For many small-to-midsize
companies, this alone is worth the price of admission.
8.
Increased risk assessment: When all the players are lined up and your
strategy is in place potential risks will jump out and slap you in the face.
And that's the way it should be. Project management provides a red flag
at the right time: before you start working on project completion.
'
NOtes
Notes
9.
Increase in Quality: Goes hand-in-hand with enhanced effectiveness.
10.
Increase in Quantity: Often the result of better efficiency, a simple

reminder regarding the benefits of project management.
By implementing fundamental project management strategies, you will

narrow your focus, reach desired goals and achieve said goals with specific time
and cost perimeters.
Project management is everything as soon as more than one person is
involved in doing something. Every team need a leader or your project will be
a disaster.
Imagine if there was no project management when people were building
a house. The house would be shaky and the people would not deliver the house
within the delays and costs. It's the same thing for any project. You must have
some kind of project manageMent to deliver any project, small or big.
So the advantages of project management (assuming it's well done) is
that the project will be done according to the requirements, finished on time and
within the allowed budget.
I don't see real disadvantages of project management really but project
management tasks must be light and efficient, however it's going to be seen as
an overhead to the project.
Project Management has lots of advantages, including:
-
Shorter implementation time
Improved product quality

Improved team productivity
Better documentation
Disadvantages
None, except when it's a very, very small project then project management
risks to be an overhead that is not paying.

Fill in the blanks.
1.
Time, cost and scope inproject management are called
In the phenomenon called

functionality.
, a project has to accumulate new

1.
Aerospace and defense are less project intensive industries.
2.
Textile is a highly project intensive industry.

_-Activity Activity 1
Visit any nearby organisationand find the projects undertaken by them. List
the factors that they considered for the success of the project.
2.3 CHARACTERISTICS OF PROJECT MANAGEMENT

Project management is a complex process which can be successfully
accomplished if we understand the characteristics of project management which
are as follows:
Resource requirement: During the course of executing the project, it is

seen that the resource requirement increase from start to an intermediate
stage of the project. It further increases at rapid rate and becomes
constant while the project is during its 95% progress stage. Thereafter,
the resources requirement decreases to zero, i.e., when the project comes
to finish. Refer to the characteristic chart.
Funds: The requirement of funds to complete execution of the project

also follows the same trends as that of the resources. The two are more or
less proportional. Refer to the characteristic chart.
Probability of completion: The probability of completing the project can

be estimated based upon the normal distribution curve. In the initial stage
of the project the probability of completing the project is low though not
zero. It gradually increases and as the project approaches the end, the
probability of completing the project tends to become 100%. Refer to the
characteristic chart.
Risk: The risks involved in the project effecting its completion time are
high at the initial stages and low at the later stages of the project. Refer to
the characteristic chart.
Design changes: The project during the course of its progress may be
subjected to changes because of some external factors. The influence of
such external factors on the project may result in changes in the design of
the project though not very often. It is observed that such changes.
Importance of project management

Projects may be completed with one or more of the following:
Stretched deadlines
Over-stressed team
Wasted resources
Unmet customers' functional requirements
Overshot budget
Notes
Notes
A good project management methodology provides a framework for the

process.
It provides guidelines for the execution of the project that greatly increases
the chances of the'project being successful, and therefore provides value to the
project.
Some of the steps of a good project management are:
Define the project.
Reduce it to a set of manageable tasks.
Obtain appropriate and necessary resources.
Build a team to perform the project work.
Plan the work and allocate the resources to the tasks.
2.4 PHASES AND STEPS IN PROJECT MANAGEMENT

A project goes through six phases during its life:
1.
Project Definition: Defining the goals, objectives and critical success

factors for the project.
2.
Project Initiation: Everything that is needed to set-up the project before

work can start.
3.
Project Planning: Detailed plans of how the work will be carried out
including time, cost and resource estimates.
4.
Project Execution: Doing the work to deliver the product, service or

desired outcome.
5.
Project Monitoring and Control: Ensuring that a project stays on track

and taking corrective action to ensure it does.
6.
Project Closure: Formal acceptance of the deliverables and disbanding

of all the elements that were required to run the project.
Steps in Project Management

For every project to be successful there should be complete agreement
about what the clients/end-users/stakeholders want and what you are trying to
achieve through the project. It is best if this is achieved in the analysis stage
itself, so the project can set off in the right direction without any doubt about
matching the deed to the need. The following are the steps for an optimal
business requirement analysis for any project to be successful.
Step I: Know Your Stakeholders
Learn all about the sponsors/clients/stakeholders/end-users of the project.
It is essential to identify the sponsors who may have authority to change any
decision. What their views and needs are will have a strong influence on the
process. Also you should know about the intended end-users. Their input is
essential. Stakeholders and end-users may be from within the company or
outsiders.
Step II: Know Stakeholders' Requirements
Notes
You should compile an exhaustive list of the requirements of each of

stakeholder and end-user. You should compile all their requirements to
get an overall picture.
Give an exact picture of the limits and extent of the project to keep the
requirements within the range and pertaining to the project alone.
You can hold individual interviews as well as group discussions

(requirements workshops) to discuss the requirements.
There are other techniques for eliciting the requirements like use cases,
prototyping, data flow diagrams, and competitor analysis. It is essential
that the exact requirements of the stakeholders are established.
Build a prototype of the project to give an exact idea of the final results of
the product or project to stakeholders.
Step III:Classify the Requirements

With so many requirements on the agenda, it will make better sense to
group the requirements under various categories. There can be three or four
types, such as:
What requirements identify with functions and components the end-users

are expecting?
What requirements identify with the operational activities that need to be

done?
What requirements identify with the technical details needed for smooth
functioning?
What may be needed for the successful completion of the project?
Step IV: Analyse the Requirements

Now it is necessary to go in depth about the nature of the requirements.
You should determine whether the compiled list of requirements are clear
in their purpose and are pertaining to the project or the process. Is there any
ambiguity inherent? Are there any contradictory interests to other issues? Is
implementation of each requirement feasible?
List all the requirements with regard to priOrity and relevance to the
project.
Also try to predict the impact of any changes proposed.
Solve the ambiguous and conflicting details that have come up.
The final list of requirements must be clear, unambiguous, concise,

feasible, and relevant to the project.
Step V:Document the Requirements

Once the requirements are completely known and the stakeholders/endusers are clear about what they want from the project, what they are going to
achieve, and they have seen the prototype and are satisfied, it is time to create a
III,
.'
-.
Notes
document that will combine all the details and get it signed by all stakeholders/
end-users and the project manager. This will be the rulebook for the project.All
stakeholders, end-users, project personnel, and developers should be given a
copy to apprise them of the project goals.
An efficientlydone business requirements analysis will enable you to
pinpoint exactly what is wanted from the project and how you can achieve it.
Once this is done, there will be no ambiguity about the diverse requirements/
specifications connected with the project and there will be a focused and wellplanned execution of the project with no chance for a scope or function creep.
-
Cheek your Progress 2

Fill in the blanks.
1.
ensures that a project stays on track and taking corrective

action to ensure it does.
requires formal acceptance of the deliverables and
disbanding of all the elements that were required to run the project.
/5 PROJECT MANAGEMENT LIFE CYCLE

The Project Management Life Cycle has four phases: Initiation, Planning,
Execution and Closure. Each project life cycle phase is described below, along
with the tasks needed to complete it.
Initiation
Develop a Business Case
Undertake a Feasibility Study
Establish the Project
ChartAppoint the Project Team
Set up the Project Office
Perform Phase Review
38
Notes
Create a Project Plan
Create a Resource Plan
Create a Financial Plan
Create a Quality Plan
Create a Risk Plan
Create an Acceptance Plan
Create a Communications Plan
Create a Procurement Plan
Contract the Suppliers
Define the Tender Process
Issue a Statement of Work
Issue a Request for Information
Issue a Request for Proposal
Create Supplier Contract
Perform Phase Review
AP
Execution
Build Deliverable
Monitor and Control
Perform Time Management
Perform Cost Management

Perform Quality Management
Perform Change Management

Perform Risk Management
Perform Issue Management
Perform Procurement Management
Perform Acceptance Management
Perform CommunicationsManagement
39
Closure
Perform
Project Closure
Review Project Completion
The Project Management process is unique, because
it:
Applies to all project types and industries
Is used to manage projects of any size
Gives you the complete set of project templates
Explains every step in the project lifecycle in depth!
The Project Management processhelps:
Project Managers to deliver projects Consultants
to manage client projects Trainers to teach project
management Students to learn how to manage
projects Project Offices to monitor and control
projects Senior Managers to improve the success of
projects.
Fig.2.1: Project Management Life Cycle

Apartfrom the commercially available methodologies such as Prince
2 and Rational Unified Process, there are many methodologies developed
to suit individual organisations. This white paper sets out to provide a
better understanding of methodologies, and how they can be developed and
implemented.
Another view of project management life cycle is as follows:

1.
2.
3.
Notes
Conception stage: Project idea is conceived to a level where it is possible

to take a call on working on the same
a.
Project basics such as type of product/service/output as the endresult.
b.
Financial feasibility including IRR, investments, nature of resources,

rough timeframe, nature of legal, procedural and permissionoriented requirements and fundamental acceptance for the project
profile from the customer.
Design stage: Detailed designing of various aspects of project are carried

out to the last nut and bolt.
a.
Splitting of the project into logical and functional modules (mini

projects in themselves)
b.
Defining clear interfaces between the modules.
c.
Individual specifics of each module Objectives, time and cost

targets, milestones, etc.
d.
Resource needs (inclusive of HR) for each module and allocation of

the same.
e.
Execution plan of each module and integration of the same with the
rest.
f.
Identifying the risk elements and provision for addressing them.
g.
Evaluation of impact of risks and probable solutions to mitigate the

same.
h.
Clear definition of approach and path for execution.
i.
Identification of most critical factors for the success.
j.
Control plan for monitoring the progress.
k.
Clear definition of process for customer interface.
1.
Define organisationstructure.
Implementation stage: Execution as per the design.

a.
Resource provision, allocation and distribution.
b.
Role definition and explanation to the team members.
c.
Launching of startup through complete, transparent communication

formal and informal.
d.
Launching of functional activities as per the plan.
e.
Clear plans to implement and monitor the activities as per the plan.
Launch effective process to identify and rectify the deviations.
g.
Impact analysis of every deviation.
41
Notes
h.
Close interaction with customer to ensure that the project is as per

the need and integration of the desired changes.
i.
Taking the project towards logical conclusion.
Commissioning stage:It is commissioned and put to use. This signifies

the end of project life cycle.
4.
a.
Ensure completion of each activity.
b.
Analysis for deviations and corrections of the same or the integration

of the same.
c.
Trial run of the live process with the help of customer for monitoring
the results as compared to the original expectations.
d.
Monitoring the efficiency and effectiveness of each sub-process

with respect to output quality, resource consumption and required
time as also integration of the same with whole process.
e.
Customer approval for the whole thing.
f.
Formal closure of the project.
Fill in the blanks.

I.
The
2.
Project idea is conceived to a level where it is possible to take a call

stage.
on working on the same, in the
4AdivIIN
signifies the end of the project life cycle.
Activity 2
Visit a nearby project site and list down the steps taken by them for successful
. ._project management.
2.6 PROJECT MANAGEMENT METHODOLOGY

It is important to differentiate between a project management methodology
and an applications deVelopment methodology or software development
methodology. Aproject management methodology covers all the things a
project manager needs to do regardless of whether the project is a software
development, package selection, or relocation of his department. PMBOK
(Project Management Book of Knowledge - the PMI Bible) covers nine areas
of project management. They are:
42
i.
Cost Management
ii.
Risk Management
iii.
Scope Management
iv.
Resource Management
v.
Communications Management
vi.
Quality Management
vii.
Time Management
Notes
viii. Procurement Management

ix.
Integration Management
You will notice there is nothing mentioned about requirements or testing

or vendor selection. That is part of an Applications Development Methodology
or Software Development Methodology.
Distinction between Methodologies
1.
A project management methodology says projects should be broken down

into phases and there should be a plan in place before each phase begins.
An application development methodology says what the phases are, and
what activities should be undertaken in each phase.
2.
A project management methodology defines roles and responsibilities.

An application development methodology defines what the roles and
responsibilities are in the development phase.
3.
A project management methodology says a budget should be put in place

and managed.An application development methodology says what the
account codes for a development in your organisation should be.
The project management methodology is the framework. An applications

development methodology is the meat on the bones. The true test of what is a
project management methodology is to ask the question. "Could you put other
meat on the same bones?" For example, you might have a package selection
methodology which could plug into the project management methodology and
fit just as well. The difference is that it is a different set of activities, roles,
responsibilities, risks, etc
Why is it important to draw the distinction?
It is important because any organisation should have a consistent project
management methodology in place which is common to all types of project.
In this way, people can move comfortably from applications development, to
infrastructure roll out, to software selection to even relocating to new buildings
using the same approach.
Training people in project management can take place prior to them
learning how to do a development, or select software or even to do some ad
hoc project that does not have adefined methodology. People need to know
they should manage scope, and how to do it. They need to know how to set up
a budget and manage it. They need to know how to doa risk assessment and
manage risks.
43
Notes
A Methodology is not a Template

Another area of confusion is that people get mixed up between templates
and methodologies. When you ask people if they have a methodology, they say
"Yes. We have some templates."
A typical evolution is for an organisation that has no common way of
doing things is to develop templates in order to get some consistency in how
things are presented. In fact you are saying, "Here is a checklist of things you
need to consider". The next stage is to add some instructions in the template
which explain what each section means.Altematively, they might create a
template user guide. Finally they may develop a process or methodology which
tells people how to get the information that ends up in the template.
There is often confusion between templates and process.
Process is a way of doing things by doing a number of activities in a

certain sequence.
Templates are used for the collection of the output of the process.
Activity 2
Activity 3
Activity 4
Document
Template
Justbecause you have templates, it doesn't mean people know how to

gather the information that goes in the template. A template may have a
heading called "Security". The actual process may be something like:
Discuss the project with the applications security manager and identify
what actions will be required to meet corporate standards
Review how the project will be affected by the new security standard
being introduced by architecture. This is best done in a workshop with
the following people. Talk with network administration and identify any
network security implications.
If only a template is available, the person filling in the template might

know nothing of the activities above. The entry might read "Not applicable
to this project". This is the difference between a template and a process or
methodology.
44
What should a methodology cover?

The following topics should be covered in any methodology:
Breakdown
Overview
Activities
Inputs and Outputs
Instructions
Participants
Supporting materials
QA
Timing
Governance
How is the overall project broken down into smaller

components such as phases?
What is the purpose, objectives, deliverables and
typical timeframes for each component?
What are the main activities?
What are the inputs or prerequisites for each activity?
What are the outputs or deliverable of each activity?
How do you carry out each activity?
Who should be involved in each activity?
Tools, checklists, templates and other material that
can assist the activity.
How do you manage quality at either the phase or
activity level?
How to estimate the time for each activity?
What authority is applicable? This may include
approvals, gates to be passed, mandatory activities
and sign-offs.
Using a Methodology
Any methodology is not the way all projects will operate. It is a best tit.
There will be variations for very good reasons. That is not to say it is variable
at the whim of each team. There needs to be some guidance provided as to what
is the sensible and pragmatic approach for each project. Gartner research found
that a methodology applied loosely could improve productivity by 30%. Applied
rigidly it improved product by only 10%. It should be a help to the project, not
a hindrance. If you want to have your organisation use a methodology, there
needs to be some champion who people have access to for help.
Objections to using a Methodology
The following are some objections that are encountered, and how to
address each objection:
It stifles my creativity?
Creativity should not mean "I will make it up as I go along". It should

mean "I have a mechanism to recogniseproblems and use my creativity to
solve them". In a project creativity needs to take place within a controlled
environment. Unless there is a structure in place, the hundreds of evolving
details and problems cannot be managed.
I have my own methodology
Any of us who have worked in a number of organisations usually do.

The reason to use the company's methodology is that everyone else is
geared up to operate within that methodology. It will cause confusion to
everybody but you if you use your own process.
Notes
Notes
My methodology is better
A company should have an area responsible for reviewing and improving

methodologies. That is the venue to promote a new methodology.
The methodology is not applicable to my project

If not why not. What components are applicable, and how can other
processes be included to link those together. Going back to the project
management methodology, what new activities, roles, etc. need to be developed.
The methodology (or template) has too much information
Treat it as a checklist. If something is not applicable, justify why and

make a comment.It might be a situation like the security issue mentioned
earlier where the person just does not understand the process properly.
There is too much paperwork
A couple of points here.
Firstly ask what information is being duplicated? Sometimes a slight

rearrangement of information may result in a "refer to document x"
solution, or a cut and paste.
Secondly, it is cheaper and easier to throw away paper rather than code.
Programmers love to get their hands on the keyboards, but it is more

efficient to build something on paper before you build it in code.
Thirdly, examine each document and see if it is really needed.
Implementing a Methodology
A methodology is not a series of templates. It is a process that needs to be
adapted to suit each situation. There needs to be someone who teams can talk
with someone who will mentor the teams in the use of the methodology.
They should have a full-time methodology coordinator who trains, works
with teams, and builds their feedback into the methodology.
Feedback is also important. The methodology will not stand still. It will
evolve and become more applicable to the organisation. As such, there needs to
be a mechanism in place to cater for "learning from experience".
Take it step by step. A massive change to the way people work is not as
likely to succeed as incremental change. If your goal is to have people produce
a plan for every phase, start by having them produce some sort of standard plan
for the whole project. If you decide to introduce three gates for approval of
funds, introduce them one at a time. You will probably
find after the first gate is in place, your experiences will indicate that you
need to slightly change the process for the other two gates.
Availability is another issue. Asking people to read a 400 page manual will
not work. Giving them some Iligh-level training, and presenting information in
a format where they can find the bit that is relevant to what they are doing right
now has more chance of success. A well-structured, web-based presentation is
46
a must. People need to be able to drill down in a few clicks to find out what is
relevant to them at the moment. Training them on the layout of a methodology
website is likely to have more impact than training them on the detail of the
methodology. Putting some templates in place is a nice first step, but it is not
a methodology. Make sure you understand the difference between templates
and process. Also understand the difference between a project management
methodology and other methodologies. To a lot of people methodology is a
dirty word. It means bureaucracy, paperwork and constriction. You need to
overcome this by providing support and flexibility in how it is applied.
Notes

1.
Methodology and template are one and the same.
2.
A project management methodology defines roles and responsibilities.
SULL.1
5Mrani
Project management is about creating an environment and conditions in

which a defined goal or objective can be achieved in a controlled manner
by a team of people.
Project management is often summarisedin a triangle. The three most

important factors are time, cost and scope, commonly called the triple
constraint.
Many things can go wrong in project management. These things are often
called barriers. Here are some possible barriers: poor communication,
disagreement, misunderstandings, bad weather, union strikes, personality
conflicts, poor management, poorly defined goals and objectives.
and surprises, but will provide standard processes and procedures to deal
with them.
Proper project management results into better efficiency in delivering

services, improved/increased/enhanced customer satisfaction, enhanced
effectiveness in delivering services, improved growth and development
within your team, greater standing and competitive edge, opportunities
to expand your services, better flexibility, increased risk assessment,
increase in quality, increase in quantity.
Project management is a complex process which can be successfully

accomplished if we understand the characteristics of project management
which are resource requirement, funds and probability of completion,
riskand design changes.
Some of the steps of a good project management are define the project,
reduce it to a set of manageable tasks, obtain appropriate and necessary
"
resources, build a team to perform the project work, plan the work and
allocate the resources to the tasks.
A project goes through six phases during its life: project definition,
project initiation, project planning, project execution, project monitoring
and control, project closure.
The Project Management Life Cycle has four phases: Initiation, Planning,
Execution and Closure.
It is important to differentiate between a project management

methodology and an applications development methodology or software
development methodology. Aproject management methodology covers
all the things a project manager needs to do regardless of whether the
project is a software development, package selection, or relocation of his
department. PMBOK covers nine areas of project management. They are
Cost Management, Risk Management, Scope Management, Resource
Management, Communications Management, Quality Management, Time
Management, Procurement Management and Integration Management.
16. Keywords
Triple constraint: The most important factors in project management are time, cost and scope.
Project management methodology: It covers all the things a project

manager needs to do regardless of whether the project is a software
development, package selection, or relocation of his department.
Project management life cycle: The four phases: Initiation,Planning,

Execution and Closure.
Self-Assessment,Questions
1.
What is project management? What is the importance of project

management?
2.
Explain the benefits of proper project management with suitable examples.
3.
What are the phases in project management? Explain their importance.
4.
What are the steps in project management? Explain their importance.
5.
What is project life cycle? Explain the concept of project life cycle for
proper project management.
6.
What is project management methodology? How is it different from

applications development methodology or software development
methodology?
7.
What are the advantages of applying project management methodology?
Notes

Fill in the blanks.
1.
Time, cost and scope in project management are called triple constraint.
2.
In the phenomenon called scope creep, a project has to accumulate new

functionality.

1.
False
2.
False

Fill in the blanks.
1.
Project monitoring and controlensures that a project stays on track and

taking corrective action to ensure it does.
2.
Project closurerequires formal acceptance of the deliverables and

disbanding of all the elements that were requited to run the project.

Fill in the blanks.
1.
The commissioning stagesignifies the end of the project life cycle.
2.
Project idea is conceived to a level where it is possible to take a call on

working on the same, in the conceptionstage.

1.
False
2.
True
Suggested Reading
1. Project Management Handbook. The Project Management Body of
Knowledge (PMBOK).
49

Structure: le
3.1 Project Finance
UNIT
3.2 Project Cost Benefit Analysis

3.3 Project Funding
3.4 Feasibility Study
3.5 PEST Analysis
3.6 PESTEL Analysis of Macro Environment
Summary
Key Words
Suggested Reading
51
Notes
Objectives
Describe the concept of project financing
Analyse the approaches to infrastructure investment
Explain the concept of cost benefit analysis for the project
Analyse project feasibility
Evaluate the project for political, social, economic, environmental,

technical and legal feasibility
3.1 PROJECT FINANCE

Project finance is the long-term financing of infrastructure and industrial
projects based upon the projected cash flows of the project rather than the balance
sheets of the project sponsors. Usually, a project financing structure involves a
number of equity investors, known as sponsors, as well as a syndicate of banks
that provide loans to the operation. The loans are most commonly non-recourse
loans, which are secured by the project assets and paid entirely from project
cash flow, rather than from the general assets or creditworthiness of the project
sponsors, a decision in part supported by financial modelling. The financing is
typically secured by all of the project assets, including the revenue-producing
contracts. Project lenders are given a lien on all of these assets, and are able to
assume control of a project if the project company has difficulties complying
with the loan terms.
Generally, a special purpose entity is created for each project, thereby
shielding other assets owned by a project sponsor from the detrimental effects
of a project failure. As a special purpose entity, the project company has no
assets other than the project. Capital contribution commitments by the owners
of the project company are sometimes necessary to ensure that the project is
financially sound. Project finance is often more complicated than alternative
financing methods. Traditionally, project financing has been most commonly
used in the mining, transportation, telecommunication and public utility
industries. More recently, particularly in Europe, project financing principles
have been applied to public infrastructure under publicprivate partnerships
(PPP) or, in the UK, Private Finance Initiative (PFI) transactions.
Risk identification and allocation is a key component of project finance.
A project may be subject to a number of technical, environmental, economic
and political risks, particularly in developing countries and emerging markets.
Financial institutions and project sponsors may conclude that the risks inherent
in project development and operation are unacceptable (not financeable). To
cope with these risks, project sponsors in these industries (such as power plants
or railway lines) are generally completed by a number of specialist companies
5A
operating in a contractual network with each other that allocates risk in a way
that allows financing to take place. The various patterns of implementation are
sometimes referred to as "project delivery methods".
The financing of these projects must also be distributed among multiple
parties, so as to distribute the risk associated with the project while simultaneously
ensuring profits for each party involved.
A riskier or more expensive project may require limited recourse financing
secured by a surety from sponsors. A complex project finance structure may
incorporate corporate finance, securitisation, options, insurance provisions or
other types of collateral enhancement to mitigate unallocated risk.
Project finance shares many characteristics with maritime finance and
aircraft finance; however, the latter two are more specialised fields.
Basic scheme
Typical Structure of a Project Finance Scheme
Fig.3.1: Hypothetical Project Finance Scheme

Acme Coal Co. imports coal. Energen Inc. supplies energy to consumers.
The two companies agree to build a power plant to accomplish their respective
goals. Typically, the first step would be to sign a memorandum of understanding
to set out the intentions of the two parties. This would be followed by an
agreement to form a joint venture.
Acme Coal and Energen form an Special Purpose Corporation (SPC)
called Power Holdings Inc. and divide the shares between them according
to their contributions. Acme Coal, being more established, contributes more
capital and takes 70% of the shares. Energen is a smaller company and takes the
remaining 30%. The new company has no assets.
Notei
Notes
Power Holdings then signs a construction contract with Acme Construction

to build a power plant. Acme Construction is an affiliate of Acme Coal and the
only company with the know-how to construct a power plant in accordance
with Acme's delivery specification.
A power plant can cost hundreds of millions, of dollars. To pay Acme
Construction, Power Holdings receives financing from a development bank and
a commercial bank. These banks provide a guarantee to Acme Construction's
financier that the company can pay for the completion of construction. Payment
for construction is generally paid as such: 10% up front, 10% midway through
construction, 10% shortly before completion, and 70% upon transfer of title
to Power Holdings, which becomes the owner of the power plant. Acme Coal
and Energen form Power' Manage Inc., another SPC, to manage the facility.
The ultimate purpose of the two SPCs (Power Holding and Power Manage) is
primarily to protect Acme Coal and Energen. If a disaster happens at the plant,
prospective plaintiffs cannot sue Acme Coal or Energen and target their assets
because neither company Owns or operates the plant.
A Sale and Purchase Agreement (SPA) between Power Manage and Acme
Coal supplies raw materials to the power plant. Electricity is then delivered to
Energen using a wholesale delivery contract. The cash flow of both Acme Coal
and Energen from this transaction will be used to repay the financiers.
Complicating factors
The above is a simple explanation which does not cover the mining, shipping
and delivery contracts involved in importing the coal (which in itself could be
more complex than the financing scheme), nor the contracts for delivering the
power to consumers. In developing countries, it is not unusual for one or more
government entities to be the primary consumers of the project, undertaking
the "last mile distribution" to the consuming population. The relevant purchase
agreements between the government agencies and the project may contain
clauses guaranteeing a minimum off take and thereby guarantee a certain level
of revenues. In other sectors including road transportation, the government may
toll the roads and collect the revenues, while providing a guaranteed annual sum
(along with clearly specified upside and downside conditions) to the project.
This serves to minimise or eliminate the risks associated with traffic demand for
the project investors and the lenders.
Minority owners of a project may wish to use "off-balance sheet" financing,
in which they disclose their participation in the project as an investment, and
excludes the debt from financial statements by disclosing it as a footnote related
to the investment. In the United States, this eligibility is determined by the
Financial Accounting Standards Board. Many projects in developing countries
must also be covered with war risk insurance, which covers acts of hostile attack,
derelict mines and torpedoes, and civil unrest which are not generally included
in "standard" insurance policies. Today, some altered policies include terrorism
54
are called Terrorism Insurance or Political Risk Insurance. In many cases, an

outside insurer will issue a performance bond to guarantee timely completion
of the project by the contractor.
Notes
Publicly funded projects may also use additional financing methods such
as tax increment financing or Private Finance Initiative (PFI). Such projects
are often governed by a Capital Improvement Plan which adds certain auditing
capabilities and restrictions to the process.
3.2 PROJECT COST
ANAL SIS
The Cost Benefit Analysis (CBA) is an economic assessment tool/

technique for comparing the anticipated benefits of proposed investments/
projects with the corresponding costs to help users identify the alternative with
the maximum net benefit (benefits minus costs). The more the benefits exceed
the costs, the more the end-users (society) will benefit from the project activity
or policy decision.
In this context, the CBA can be used not only during the development of
Business Case for the identification of the most preferable solution option, but
also during the inception and prioritising stage in order to give a higher priority
to the investments/projects which prove to be more profitable efficient not only
in monetary but also in socio-economic terms.
It should be noted, that wherever possible the CBA should be undertaken
from a national perspective rather than government or departmental perspective.
This is often termed "economic CBA" and is preferred because the actions
of one agency or department can impose costs or benefits on individuals or
the nation as a whole (e.g. increasing the size of a programme operated by
a particular department may assist the operation of the department but may
nonetheless require a large increase in income tax on individuals). In other
words, economic CBA seeks to capture all benefits and costs regardless of to
whom they accrue. Of course, in case of investments or projects where costs
and benefits are limited to impacts on an individual agency or department
(e.g., purchase of new notebooks for a department, lease or buy decision for an
agency building), a "financial CBA" should be used. That is to consider only
the benefits and costs to an individual agency or department.
The elaboration of a CBA is usually a complicated and sophisticated task
that should be carried out by specialised professionals or assigned to external
advisors, since it involves advanced calculations and financial analysis, which
require a relevant background knowledge and familiarisation with investment
appraisal techniques. Especially in cases of large investments/projects,
where the CBA may be a prerequisite in order to apply for EU funding (e.g.,
investments for waste treatment, water supply and depuration, transport, etc.),
the CBA should be conducted very carefully and by specialised experts in order
to justify the request for co-financing and receive the relative approval.
I_
uI-
1156..
Notes
The most important parts of a CBA are the following:
Determining the lifetime of the investment/project (period of analysis)
Identifying all relevant costs and benefits of a given investment/proposal/

option
Valuing all relevant costs and benefits of a given investment/proposal/

option (assigning monetary values)
Preparing the cash flows for the analysis period
Discounting of cash flows to present values
Calculating the Net Present Value (NPV)
Evaluation of alternative options and selection of the preferred option

Fill in the blanks.
1. Risk identification and allocation is a key component of
Project finance is the long term financing of infrastructure and
of
industrial projects based upon the projected
the project.
1
p.AcwitY Activity 1
Consider any project you have done or you want to do. Do the cost benefit
analysis for the same.
\._
3.3 PROJECT FUNDING

The way of financing investments of the public infrastructure is a very
important issue. In the past, many project ideas ended up in a drawer or in the
bin for the simple reason of lack of public funds.
Therefore, it is recommended that the design team of the project in
cooperation with the project owner should examine all possible alternatives
of financing the investment/project, e.g., possibilities of private financing and
operation of an investment.
For carrying out infrastructure investments to meet public needs, there are
basically following options:
a.
The traditional public-financed approach
b.
The alternative private-financed approach
As the consequence of funding constraints, the public administration

in developed countries followed a new policy to move from the classical
system for the delivery of (traditionally public) services and investment in the
infrastructure to a system where the (traditionally public) services are offered
to the public and related investments implemented by the private sector. Where
possible and deemed appropriate the state limits its participation in financing
investments and offering services and creates, to a large extent, "pluralistic
markets" consisting of public, private and "non-profit" organisations producing
and offering respective services to the public. The competition between the
service providers is supposed to bring about better and more cost-efficient
solutions. The basic principles of such change are:
The state remains responsible for delivery of public services or for the
public infrastructure responsibility for provision.
Financing the infrastructure can be partly or fully shifted to private

sources (private firms and financial institutions).
Potential suppliers of any ownership type have the right to compete for
the opportunity to deliver/produce the services to the public and to build
and maintain the necessary infrastructure.
1.
The traditional approach to infrastructure investments
MA:es _
Traditionally, investment into the public infrastructure is done by using

public funds. Like a caring father, "the state" plans, designs, builds, runs,
maintains, and, if necessary, replaces facilities of the physical and social
infrastructure. Among these services are public utilities (supply of water,
sewerage, electricity, communication), roads, public transport (by air,
rail, boat, bus), education (kindergarten, primary, secondary, and tertiary
education and research facilities), health care facilities (hospitals, Physical
Therapy Assistance [PTA], rescue services), cultural and recreational
facilities (museums, theatres, parks, television, radio), public security
services (police, jails), consumer protection (product information and
expertise in cases of disputes with a supplier), social security (pensions,
health insurance, nursing care insurance, welfare).
The general idea is public funds, basically tax payers' money, is used for
building and maintaining the infrastructure. "Father State" then provides
the services of the infrastructure to the public sometimes at cost, but
often subsidized, or even free of charge. Citizens could feel in the role of
beneficiaries. The main advantage of the traditional approach is that it can
be used as an efficient development tool. A good infrastructure attracts
businesses, people, generates jobs, taxes and, if used as a development
tool, can avoid "desertification" of rural areas and problematic degrees of
urbanization.
However, the traditional approach has, among others, the following
disadvantages:
Free or subsidised services lead to careless use of services and to

deformation of the needs profiles. For example: cheap subsidised
57
tap water of drinking quality may entail waste and misuse for all
sort of purposes (car wash, irrigation, cleaning walkways, etc.) and,
hence, lead to over-sized water works.
Notes
2.
The lack of competition prevents innovation and cost-efficient

operation of the infrastructure. For example only the exposure
to competition of formerly state controlled telecommunication
services accelerated innovative services at better prices.
Slow improvement of the infrastructure due to limited public funds.
Under monopoly conditions, without competition and with

subsidised services the infrastructure does not generate enough
refund for reinvestment. If this situation persists for long, the
degradation of the infrastructure or its collapse is inevitable and
alternative solutions have to be found.
Alternative approach to infrastructure investment

During the last decades, new models for infrastructure investment have
been developed. Many such models, under different names, can be found
these days in developed and also in developing countries. The European
Union uses the term Public-Private Partnership (PPP). Such models shift
most of the roles and responsibilities for infrastructure investment from
the public sector to the private sector. The assumption of this new approach
is that the private sector can plan, finance, build, operate, maintain, and
replace facilities in a more efficient way than the public sector, thus
providing better infrastructure services to the public. However, better
services might have, this goes without saying, their price.
At present we witness an ongoing trend towards private service production

and mixed or private financing by public providers in the fields of energy supply,
water supply, waste treatment. Security services and operations of prisons are
already privatized or in the pmcess of privatization. The state is on its retreat in
virtually all sectors of the physical and social infrastructure. As a consequence,
the citizen has mutated from a beneficiary to a customer sometimes to his
advantage, sometimes not.
Positive effects appear,1 when, due to competition, better services are
rendered at lower prices. Telecommunication services are a shining example.
However, the customers face negative consequences when, after involvement
of the private sector, a monopoly persists in the market. In these cases, prices
can be fixed at maximum level, even though the services are poor. Some
recently privatized railway companies in Western Europe give evidence for
this phenomenon. If public utilities still enjoy a monopoly position and are
prevented from external competition, services are cut in unprofitable areas,
whilst overall prices go up.
With private production and private financing, profit becomes a key
concern of the investment. One of the inevitable consequences is the risk
of cherry picking profitable projects for private investors and less gainful
investments for implementation by the public administration. It has to be taken

in mind that the private sector has to make profit and has to pay interest to banks
financing the investment. This extra cost has to be compensated by savings
elsewhere. Some of these savings may come from better management and
higher efficiency claimed by the private sector. But why must management and
efficiency be less efficient in the public sector? Thus, and even if the financial
deal between the private and the public sector is concealed to the beneficiary
customer, there is always the question whether or not new private arrangements
are a better deal for the general public.
Notes
Decisions about private investments in the public infrastructure (utilities)

are in the first instance apolitical issue. Contracts with private investors who build
(and maybe operate) facilities of the infrastructure are long-term commitments
for typically 25-30 years. The cost-benefit-analysis and the risk management of
these instruments have to be based on forecasts for the development of many
economic parameters such as birth/mortality rate, migration rate, tax income
in the territory, unemployment rate, inflation rate, etc. Predictions for these
parameters can only be assumptions. Hence, the risks for the profitability of
a private investment are high and need to be covered, either by large margins,
comfortable price adjustment clauses, or by latent cuts into the services.
Infrastructure contracts with the private sector are normally high-value
contracts, very often concluded with international partners or consortiums.
Therefore, such contracts are generally more complicated than traditional
procurement contracts and require highly specialised economists and lawyers.
Risk sharing and risk management is a very important issue. A public
administration may have difficulties to install a project design team, to appoint
a negotiation group with expertise in this field, and to find persons who will
execute the contract management issues properly. Where such human resources
and skills do not exist public administrations may seek advice from consulting
firms specialised in this area, but such expertise is very expensive. Thus
transaction costs to create and execute the contract may prevail over benefits
from private involvement.
Much more than any other contract, a PPP contract has to pre-empt different
worst-case scenarios over a long period of time. It has to make provisions for all
sorts of thinkable developments.
According to the existing European Union Green Paper on Public Private
Partnerships and Community Law on Public Contracts and Concessions,
published by the Commission on the 30th of April 2004 the public-private
partnership (PPP) is not defined at community level. In general, the term refers
to forms of cooperation between public authorities and the business community
which aim to ensure the funding, construction, renovation, management or
maintenance of an infrastructure or the provision of a service.
The following elements have normally to be addressed in PPPs:
The relatively long duration of the relationship, involving different aspects

of the cooperation between the public partner and the private partner for
59 , _
a planned project; '
The method of funding the project, in part from the private sector,
sometimes by means of complex arrangements between the various
players. Nonetheless, public funds in some cases rather substantial may
be added to the private funds.
The roles of the partners who participate at different stages in the project
(design, completion, implementation, funding); the public partner
concentrates primarily on defining the objectives to be attained in terms
of public needs and outputs, quality of services provided and pricing
policy, and takes responsibility for monitoring the compliance with these
objectives.
However, a PPP does not necessarily mean that the private partner
assumes all the risks, or even the major share of the risks linked to the project,
the precise distribution of risks is determined case by case, according to the
respective ability of the concerned parties to assess, control and cope with this
risk.
The funding can be distinguished as follows:
PPPs of a purely contractual nature, in which the partnership between the

public and the private sector is based solely on contractual links, and
PPPs of an institutional nature, involving cooperation between the public

and the private sector within a distinct entity.
Frequent PPP contract forms are:
Design-Build-Operate (DBO) contracts, e.g., for waste water treatment;
Design-Build-Operate-Finance (DBOF) contracts, e.g., for designing,

building/ rehabilitating, operating, and financing an airport;
Concession contracts, e.g., for designing, financing, building, operating,
maintaining a toll road/bridge/tunnel.
Acts w Activity 2
List the options available for carrying out infrastructure investments to meet
public needs.
3.4 FEASIBILITY STUDY

A Feasibility Study is the analysis of a business problem to determine if it
can be solved effectively. The operational (will it work?), economical (costs and
benefits) and technical (can it be built?) aspects are part of the study. Results of
the study determine whether the solution is feasible in all the above aspects and
thus should be implemented.
It should be noted that the economic feasibility of an option or a project
is typically assessed through a Cost Benefit Analysis, which can be performed
60
either in the framework of a feasibility study or as a separate study and then

incorporate its results in the overall feasibility study.
Notes
Conducting a feasibility study is usually a complicated task that should

be undertaken by specialized professionals or assigned to external consultants
with relevant experience in conducting such studies, as well as with relevant
background to the scopes under consideration. Feasibility studies for large scale
projects are usually conducted by a team of experts in order to cover all aspects
of solution's feasibility. For example, in case of a bridge construction project,
it is necessary to appoint an architect or civil engineer in the feasibility study
team in order to examine the technical feasibility of the proposed solution,
an economist or financial analyst to examine the economic feasibility, an
environmental expert to assess the environmental impacts of each solution and
a transport specialist to examine the operational efficiency (e.g., forecasted
vehicle load, impact on traffic) of the constructed bilidge.
Especially in cases of large investments/projects, which are proposed for
receiving EU funding (e.g., investments co-financed by the Cohesion Fund or
ISPA) the feasibility study is a prerequisite of the application folder and should
be conducted very carefully and by specialised experts in order to justify the
request for co-financing and receive the relative approval.
Feasibility study is usually undertaken as part of the overall business
case process to add more rigour to the solution options presented in the
business case. For this reason, the topics defined in ,both the business case and
feasibility study documents are quite similar. However, the feasibility study
may be conducted prior to the business case in order to minimise the alternative
solutions by excluding those which are either infeasible or they proved to be the
least feasible. In this case the results of the feasibility study should be included
in the business case document either under the relevant heading or as an annex
(if they are too analytical and extended).
Even though the feasibility study is usually' outsourced to specialized
consultants, the project designers should be accustomed with the basic topics
included in a feasibility study in order to be in a position to provide the
appropriate input to the external consultants, as well as to interpret the results
in order to use them in the presentation of the business case.
The topics that are usually included in a feasibility study and some basic
guidance on how to deal with each topic are presented below.
Typical Contents of a Feasibility Study
Executive Summary: Outline the problem or. opportunity, the project
requirements, the feasibility assessment results and the overall outcome.
Problem Statement: Firstly, describe the business environment which contains
the business problem (or opportunity) by taking into account the external
environment (e.g. products and services available, technology and commercial or
operational trends, statutory or legislative changes), the business vision, strategy
61
or objectives, the business organization (e.g., units relevant to this project,

internal communication lines), and the business processes (e.g., procurement,
supply chain management, IT systems, HR management, strategic planning,
finance/accounting, manufacturing/logistics, engineering). Then provide a
full description of the core problem (or opportunity), refer to the reasons why
the problem exists (or provide support evidence that the opportunity exists),
describe the impact it is having on the business (or the positive impact that the
realisation of the opportunity will have), and state the timeframes within which
it must be resolved (or for which the opportunity will likely exist).
Requirements Statement: List the key business drivers for this project (e.g.,
changes to legislative framework, a particular citizens' need that must be covered
within a certain period, limited timeframe for the absorption of EU funds).
For each business problem (or opportunity) describe the detailed business
requirements (e.g. training of employees in the new procedures, establishment
of a new business unit, 20% increase in the existing connections to the water
supply network, upgrade of existing IT networks)
Feasibility Assessment: Provide a detailed description of each solution
option. Assess the feasibility (or likelihood) of each solution option to meet
the requirements defined above. To assess the overall feasibility of each option,
break the solution down into components and rate the feasibility of each
component. To ensure that the feasibility ratings are accurate, use all appropriate
methods possible to identify the likely feasibility of the solution. For example,
if adopting new technology, develop a small prototype, then test it to see if
the resultant benefits match those expected from the exercise, or if considering
changes in business processes then perform staff surveys and interviews, or if
considering to purchase, rent or lease a new product/service undertake market
surveys. Then describe the actual result of the assessment in comparison with
the expected result. Finally, describe also the risks and assumptions associated
with the feasibility of each option.
Feasibility Ranking: List the criteria used to rank the alternative options (e.g.,
technical feasibility/implementability, environmental impacts/sustainability,
economic viability, social acceptance) and describe the scoring/weighting
mechanism used to produce the overall result.
Feasibility Result: Based on the feasibility ranking, identify which option has
achieved the highest total score and thus is the most feasible for implementation.
Summarise the key reasons why this option is most likely to meet the business
requirements.
In order to give an example of the use of a feasibility study in practice,
we will examine the case that a municipality is thinking to create a green park
for its citizens and wants to identify which of the two available places will be
the best for its location. The following example summarises the basic contents
of the feasibility study which was carried out by a private consulting company
on behalf of the municipality. It should be noted that the example is very
simplified and represents only a snapshot of a feasibility study in order to serve
the purposes of this guide and be understandable for people who don't have the
expertise in elaborating feasibility studies.
Summarised contents of a feasibility study for the selection of the best

location of a green park.
Notes
Executive Summary: The scope of the study is to examine the feasibility of

creating a municipal green park at two different sites in order to decide which
of the two options is preferable.
Problem statement: The large increase of the municipality's population in
combination with the consequent increase of the residence and commercial
buildings have limited the open spaces where the citizens could spend a few
hours of calmness and their kids could find a place to play and have fun. The
municipality's objective is to create a green park to cover this emerging need,
but it is not sure about which of the two available sites (Site A is located very
close to the centre of the town and Site B is located a few km out of town at the
foot of a small hill) to select.
Requirements Statement: Creation of a green park that will include a variety
of trees, a small lake (30 sqm surface), walking and jogging paths (aprox. 800
m long), a caf with capacity for 80 people and a 200 sqm playground for the
kids. The cost of built should be no more than 700.000.
Feasibility Assessment: In order to assess the feasibility of each option the main
characteristics for each site were analytically described accurate topographical
site, dimension in sqm, proximity (to the centre of the town, the nearest bus
station, the nearest motorway), adequacy of water reserves.
Site A: The whole area is municipality's property. Land surface 780 sqm, 800
meters and 10 minutes walking from city centre, the area is served regularly by
city bus with frequency of lines 5' to 10', duration 4 minutes and ticket cost CO,
60. The main problem of the area is the high noise levels, since it is located near
the centre of the town and next to the busiest road.
Site B: The 2/3 of the area is owned by the municipality and the other 1/3 is
private property of several individuals. Land surface 1,050 sqm, 6 km from
the city centre, the area is nearby the highway that connects the town with
the airport and has a parking space for 100 cars. It is also served regularly by
the city bus with frequency of lines 15', duration 10' and ticket cost 1,00.
The area has significant resources of water and the greatest percentage of its
surface is covered with trees. However, the place is having a big problem with
mosquitoes, since it is located near a small stream.
Feasibility Ranking: The two basic categories of criteria that were used
to evaluate the alternative choices were: a) Benefit of Implementation (all
factors that contribute in the success of the choice) and b) Requirements of
Implementation (restrictions and cost). The criteria used for each category were:
The criteria for the benefit of implementation were proximity to the town
centre, accessibility, services provided by public transport, position in relation
to inhabited areas, accessibility cost.
The criteria for the Requirements of Implementation were legal restrictions,
specific physical restrictions (water reserves, noise), cost of land acquisition,
63
sufficiency of networks (electricity, telecom), and landscape morphology

Each of the above criteria were scored/weighted by two parameters:
Significance:
Grade 3: High significance Grade 2: Medium significance Grade 1: Low
significance
Intensity:
High (it corresponds in grade 5 in a scale from 1 to 5), Low (it corresponds
in grade 1 in a scale from 1 to 5) Intermediate grades
The scoring of the comparative evaluation is being presented in the
following tables.
Table A: Ranking of the Benefit of Implementation Criteria
Evaluation 'Significance Intesity
Site A
Criteria
Degree
.
2
Proximity
to the town
centre
1
Score Documentation
AB
10 4 Site A: 800m from
town centre, Site
B:5 km. Quite big
difference in the
distance.
3 12 9 Site A: 10' on foot, Site
B: You can't go on foot
but you could drive
(available parking)
IC1_ 6
6 B ath sites are serviced
bythe same public
Site B
,c,_
Accessibility
Services
provided
by public
transport
Position in
relatiaiito
inhabited
areas
a O
Accessibility
cost
4 GI
40
27
i(1_
TOTAL
transport.
Site A: Near to town
centre with population
of SO.D00. SiteB:5 km
away from inhabited
areas
Site A: No cost if you
walk or 60.60 if you
take the bus. SiteB: 61
by bus or 60. SO by
car (fuel cost). Site A
receives a higher score
because it lias lower
accessibility cost.
Table B: Ranking of the Requirements of Implementation criteria

Evaluation
Criteria
Notes
Significance Intensity SiteB

Degree
Site A
Score Documentation
A B
4
2 Site B requires
alienation of land from
individuals, where Site
A is totally owned by
dieMunicipality Site A
receives a higher score
because it lias fewer
legal restrictions.
6 12 Site A: Has no adequate
water resources and
problem with high
noise levels
Site B: Has mosquitoes'
problem but this
problem can easily be
solved, so it receives
higher score.
11
,1 15 6 No cost of land
SiteA: acquisition
(Municipality's
property)
Site B: 100.00 to
buy the land from the
individuals
6 15 Site A: The landscape
needs many
interventions to be
transformed into a
green park, Site B: The
morphology of the area
is identical for a green
park, since it is located
near a hill with many
trees and is also crossed
by a small stream.
6
6 Both Sites have
no problem with
the established
electricity and
telecommunication
networks.
37 39
Legal
restrictions
4 O
Specific
restrictions
(1_
Cost of land
acquisition
Landscape
morphology
Sufficiency
of networks
4 4
TOTAL
65
Notes
Feasibility Result: According to the results of the feasibility assessment model,

Site A scored 77 points in the two categories of criteria, while Site B scored 66
points. Therefore, the option to create a green park in the centre of the town (Site
A) proves to be more feasible than the option to create it a few km away (Site
B). The main reasons that Site A predominates Site B in terms of feasibility is
that it is located in the town centre (i.e., it is easier and more accessible) and it
doesn't involve any acquisition of land (i.e., no cost for land acquisition and no
legal restrictions).
The conclusions of the feasibility study should outline in depth the various
alternatives examined and the implications and strengths and weaknesses of
each. The project designers need to study carefully the feasibility study and
challenge its underlying assumptions. Don't expect one alternative to "jump
off the page" as being the best one. Feasibility studies do not suddenly become
positive or negative. As you gather information and investigate alternatives,
neither a positive nor negative outcome may emerge. The study will help you
assess the trade-off between the risks and rewards of moving forward with the
project. Remember, it is not the purpose of the feasibility study or the role of the
project designer/ consultant to decide whether or not to proceed with a project
idea, it is the role of the decision makers.
- MOW
t Activity 3
\,...Conduct feasibility study of any infrastructural project.

1 3.5 PEST ANALYSIS
PEST analysis stands for "Political, Economic, Social, and Technological
analysis" and describes a framework of macro-environmental factors used in the
environmental scanning component of strategic management. Some analysts
added Legal and rearranged the mnemonic to SLEPT; inserting Environmental
factors expanded it to PESTEL or PESTLE, which is popular in the UK. The
model has recently been further extended to STEEPLE and STEEPLED, adding
education and demographic factors. It is a part of the external analysis when
conducting a strategic analysis or doing market research, and gives an overview
of the different macro environmental factors that the company has to take into
consideration. It is a useful strategic tool for understanding market growth or
decline, business position, potential and direction for operations.
The growing importance of environmental or ecological factors in the first
decade of the 21st century have given rise to green business and encouraged
widespread use of an updated version of the PEST framework. STEER analysis
systematically considers Socio-cultural, Technological, Economic, Ecological,
and Regulatory factors.
Political factors are how and to what degree a government intervenes in the
economy. Specifically, political factors include areas such as tax policy, labour
66
law, environmental law, trade restrictions, tariffs and political stability. Political
factors may also include goods and services which the government wants to
provide or be provided (merit goods) and those that the government does not
want to be provided (demerit goods or merit bads). Furthermore, governments
have great influence on the health, education and infrastructure of a nation.
Economic factors include economic growth, interest rates, exchange rates

and inflation rate. These factors have major impacts on how businesses
operate and make decisions. For example, interest rates affect a firm's
cost of capital and therefore to what extent a business grows and expands.
Exchange rates affect the costs of exporting goods and the supply and
price of imported goods in an economy
Social factors include the cultural aspects and include health

consciousness, population growth rate, age distribution, career attitudes
and emphasis on safety. Trends in social factors affect the demand for a
company's products and how that company operates. For example, an
aging population may imply a smaller and less-willing workforce (thus
increasing the cost of labour). Furthermore, companies may change
various management strategies to adapt to these social trends (such as
recruiting older workers).
Technological factors include ecological and environmental aspects,

such as R&D activity, automation, technology incentives and the
rate of technological change. They can determine barriers to entry,
minimum efficient production level and influence outsourcing decisions.
Furthermore, technological shifts can affect costs, quality, and lead to
innovation.
Environmental factors include weather, climate, and climate change,

which may especially affect industries such, as tourism, farming, and
insurance. Furthermore, growing awareness to climate change is affecting
how companies operate and the products they offer, it is both creating
new markets and diminishing or destroying existing ones.
Legal factors include discrimination law, consumer law, antitrust law,

employment law, and health and safety law. These factors can affect how
a company operates, its costs, and the demand for its products.
Notes
Applicability of the Factors

The model's factors will vary in importance to a given company based
on its industry and the goods it produces. For example, consumer and B2B
companies tend to be more affected by the social factors, while a global defence
contractor would tend to be more affected by political factors. Additionally,
factors that are more likely to change in the future or more relevant to a given
company will carry greater importance. For example, a company who has
borrowed heavily will need to focus more on the economic factors (especially
interest rates).
Furthermore, conglomerate companies who produce a wide range of
products (such as Sony, Disney or BP) may find it more useful to analyse one
67
Notes
department of its company at a time with the PESTEL model, thus focusing on
the specific factors relevant to that one department. A company may also wish
to divide factors into geographical relevance, such as local, national and global
(also known as LONG PESTEL).
social forces
rseeffitcliticra
roAlir
1/4
txternal
analysis
objectives
Took dedicated
to external
analyses
ALL
Internal
analysis
objectives
Took dedicated
to internal
analyses
Assess ing
PESTEL analysis
resources
(Political,
Asesig the
Environmental,
nature of the
Socio-cultural,
,r
envi onment and
environment
Technological,
impacts
Econorrik andDrawing
Legal factors)
comparisons
SWOT analysis
Determining
external
opportunities and
threats
Resources audit
Analysis of best
practice
Determining
Internal strengths
and weaknesses
001ITICAl
SWOT analysIS
E C (1 kU M 1C
Government Type
Business Cycle Stage
Government Stability
Grown Inflation & Interest Rates
Freedom of Press. Rule of Levi,

Bureaucracy, corruption
Unemployment, Labor Supply,

Labor Costs
Ragu iation,De- ieguiatuan Trends
Disposable Incomenistribution
' SocialEmployment Legislaten
vor,v learnmerketIna.not
Globalization
Likely Political ghange
4. Economic Change
Population GroothiAge Profile
Impact or Emerging Technologies
Health, Education, Social Mobility
Impact CA Internet, and Reduced
Communical ran Costs

Employment Patterns, Attitudes
to Work
Fresh. Public Opinion, Altitudes
and Taboos
BAD Activity
Impact of Technology Transfer
Likely Technological Change
Lifestyle Choices
Likely Socio-Cultural Change
SOC10-CULTURAL
C 14NOLOG IC AL
Fig. 3.2: PEST Analysis Framework

68
Notes
Fill in the blanks.

1.
factors extend the PEST analysis to PESTLE analysis.
2.
analysis systematically considers Socio- cultural,

Technological, Economic, Ecological, and Regulatory factors.
Activity 4
Consider any project that you are working on or you would have worked for
and do the PEST analysis of the same.
3.6 PESTEL ANALYSIS OF THE MACRO ENVIRONMENT

There are many factors in the macro environment that will affect the
decisions of the managers of any organisation. Tax changes, new laws, trade
barriers, demographic change and government policy changes are all examples
of macro change. To help analyse these factors managers can categorise them
using the PESTEL model. This classification distinguishes between:
Political factors: These refer to government policy such as the degree of
intervention in the economy. What goods and services does a government want
to provide? To what extent does it believe in subsidising firms? What are its
priorities in terms of business support? Political decisions can impact on many
vital areas for business such as the education of the workforce, the health of the
nation and the quality of the infrastructure of the economy such as the road and
rail system.
Economic factors: These include interest rates, taxation changes, economic
growth, inflation and exchange rates. As you will see throughout the Foundations
of Economics book, economic change can have a major impact on a firm's
behaviour. For example:
Higher interest rates may deter investment because it costs more to

borrow.
A strong currency may make exporting more difficult because it may raise
the price in terms of foreign currency.
Inflation may provoke higher wage demands from employees and raise
costs.
Higher national income growth may boost demand for a firm's products.
Social factors: Changes in social trends can impact on the demand for a firm's
products and the availability and willingness of individuals to work. In the UK,
for example, the population has been ageing. This has increased the costs for
firms who are committed to pension payments for their employees because their
169
Notes
staff is living longer. It also means some firms such as Asda have started to recruit
older employees to tap into this growing labour pool. The ageing population
also has impact on demand. For example, demand for sheltered accommodation
and medicines have increased ,whereas demand for toys is falling.
Technological factors: New technologies create new products and new
processes. MP3 players, computer games, online gambling and high-definition
TVs are all new markets created by technological advances. Online shopping,
bar- coding and computer aided design are all improvements to the way we do
business as a result of better technology. Technology can reduce costs, improve
quality and lead to innovation. These developments can benefit consumers as
well as the organisations providing the products.
Environmental factors: Environmental factors include the weather and
climate change. Changes in temperature can impact many industries including
farming, tourism and insurance. With major climate changes occurring due to
global warming and with greater environmental awareness this external factor
is becoming a significant issue for firms to consider. The growing desire to
protect the environment is having an impact on many industries such as the
travel and transportation industries (for example, more taxes being placed on
air travel and the success of hybrid cars) and the general move towards more
environmentally friendly products and processes is affecting demand patterns
and creating business opportunities.
Legal factors: These are related to the legal environment in which firms operate.
In recent years, in the UK, there have been many significant legal changes that
have affected firms' behaviour. The introduction of age discrimination and
disability discrimination legislation, an increase in the minimum wage and
greater requirements for firms to recycle are examples of relatively recent laws
that affect an organisation's actions. Legal changes can affect a firm's costs
(e.g., if new systems and procedures have to be developed) and demand (e.g.,
if the law affects the likelihood of customers buying the good or using the
service).
Different categories of law include:
7.0
Consumer laws: These are designed to protect customers against unfair

practices such as misleading descriptions of the product.
Competition laws: These are aimed at protecting small firms against

bullying by larger firms and ensuring customers are not exploited by firms
with monopoly power.
Employment laws: These cover areas such as redundancy, dismissal,

working hours and minimum wages. They aim to protect employees
against the abuse of power by managers
Health and safety legislation: These laws are aimed at ensuring the
workplace is as safe as is reasonably practical. They cover issues such
as training, reporting accidents and the appropriate provision of safety
equipment.
Typical PESTEL factors to consider include:

Factor
Political
Economic
Social
Technological
Environmental
Legal
Notes
Could include:
E.g., EU enlargement, the euro, international trade, taxation
policy
E.g., interest rates, exchange rates, national income, inflation,
unemployment, stock market
E.g., ageing population, attitudes to work, income distribution
E.g. innovation, new product development, rate of
technological obsolescence
E.g., global warming, environmental issues
E.g., competition law, health and safety, employment law
By using the PESTEL framework we can analyse the many different

factors in a firm's macro environment. In some cases particular issues may
fit in several categories. For example, the creation of the Monetary Policy
Committee by the Labour Government in 1997 as a body that was independent
of government but had the ability to set interest rates was a political decision
but has economic consequences. Government economic policy can influence
investment in technology via taxes and tax credits. If a factor can appear in
several categories managers simply make a decision of where they think it best
belongs.
However, it is important not to just list PESTEL factors because this does
not in itself tell managers very much. What managers need to do is to think
about which factors are most likely to change and which ones will have the
greatest impact on them, i.e., each firm must identify the key factors in their
own environment. For some such as pharmaceutical companies government
regulation may be critical, for others, perhaps firms that have borrowed heavily,
interest rate changes may be a huge issue. Managers must decide on the relative
importance of various factors and one way of doing this is to rank or score the
likelihood of a change occurring and also rate the impact if it did. The higher
the likelihood of a change occurring and the greater the impact of any change,
the more significant this factor will be to the firm's planning.
It is also important when using PESTEL analysis to consider the level at
which it is applied. When analysing companies such as Sony, Chrysler, Coca
Cola, BP and Disney it is important to remember that they have many different
parts to their overall business they include many different divisions and in some
cases many different brands. Whilst it may be useful to consider the whole
business when using PESTEL in that it may highlight some important factors,
managers may want to narrow it down to a particular part of the business (e.g. a
specific division of Sony); this may be more useful because it will focus on the
factors relevant to that part of the business. They may also want to differentiate
between factors which are very local, other which are national and those which
are global.
71
Notes
For example, a retailer undertaking PESTEL analysis may consider:
Local factors such as planning permission and local economic growth

rates
National factors such as UK laws on retailer opening hours and trade

descriptions legislation and UK interest rates
Global factors such as the opening up of new markets making trade easier.
The entry of Bulgaria and Romania into the European Union might make
it easier to enter that market in terms of meeting the various regulations
and provide new expansion opportunities. It might also change the labour
force within the UK and recruitment opportunities.
This version of PESTEL analysis is called LONGPESTEL. This is

illustrated below:
NATIONAL
LOCAL
POLITICAL Provision
of UK government
services by local policy on subsidies
council
ECONOMIC Local income
SOCIAL
TECHNOLOGICAL
ENVIRONMENTAL
LEGAL
UK interest rates
Local population Demographic

change (e.g., ageing
growth
population)
Improvements in UK wide technology
local technologies e.g., UK online
e.g., availability of Services
Digital TV
Local waste issues UK weather
Local licences/
planning .
permission
UK law
GLOBAL
World trade
agreements, e.g.,
further expansion of
the EU
Overseas economic
growth
Migration flows
International
technological
breakthroughs
e.g., Internet
Global climate change
International
agreements on human
rights or environmental
policy
In Foundations of Economics we focus on the economic environment. We

examine issues such as the effect of interest rate changes, changes in exchange
rates, changes in trade policy, government intervention in an economy via
spending and taxation and economic growth rates. These can be incredibly
important factors in a firm's macro-environment. The growth of China and
India, for example, has had massive effects on many organisations. Firms can
relocate production there to benefit from lower costs. These emerging markets
are also providing enormous markets for firms to aim their products at. With
a population of over 1 billion, for example, the Chinese market is not one you
would want to ignore, at the same time Chinese producers should not be ignored
either. However, the relative importance of economic factors compared to other
factors will depend on the particular position of a business. Exchange rate
72
fluctuations may be critically important to a multinational but less significant to

a local window cleaner. Rapid economic growth or economic decline may be
very significant to a construction business that depends heavily on the level of
income in the economy but may be slightly less sighificant to a milk producer
whose product is less sensitive to income. So whilst the economy is important
to all firms on both the supply side (e.g., unemployment levels affect the ease
of recruitment) and demand side (e.g., income tax affects spending power) the
relative importance of specific economic factors and the relative importance
of the economy compared to, say, regulation or social trends will vary. Whilst
we hope this book provides a good insight into the economy and the possible
effects of economic change on a business these must be considered in the light
of other macro and micro factors that influence a firms' decisions and success.
Notes

1.
Legal factors to be considered under PESTLE analysis include interest

rates, exchange rates, national income, inflation, unemployment and
stock market.
Technological factors to be considered under PESTLE analysis
include innovation, new product development, rate of technological
obsolescence.
Summary

projects based upon the projected cash flows of the project rather than
the balance sheets of the project sponsors. Usually, a project financing
structure involves a number of equity investors, known as sponsors, as
well as a syndicate of banks that provide loans to the operation.
The Cost Benefit Analysis (CBA) is an economic assessment tool/

technique for comparing the anticipated benefits of proposed investments/
projects with the corresponding costs to help users identify the alternative
with the maximum net benefit (benefits minus costs). The more the
benefits exceed the costs, the more the end-users (society) will benefit
from the project activity or policy decision.
The way of financing investments of the public infrastructure is a very

important issue. In the past, many project ideas ended up in a drawer
or in the bin for the simple reason of lack of public funds. For carrying
out infrastructure investments to meet public needs, there are basically
following options: the traditional, public-financed approach and the
alternative private-financed approach.
A Feasibility Study is the analysis of a business problem to determine if

it can be solved effectively. The operational (will it work?), economical
73
(costs and benefits) and technical (can it be built?) aspects are part of the
study. Results of the study determine whether the solution is feasible in
all the above aspects and thus should be implemented.
Notes
There are many factors in the macro environment that will affect the
decisions of the managers of any organisation. Tax changes, new laws,
trade barriers, demographic change and government policy changes are
all examples of macro change. To help analyse these factors managers
can categorise them using the PESTEL model. This classification
distinguishes between: Political factors, Economic factors, Social factors,
Technological factors, Environmental factors and Legal factors.
Keywords
Project finance: The long-term financing of infrastructure and industrial

projects based upon the projected cash flows of the project rather than the
balance sheets of the project sponsors.
Cost benefit analysis: An economic assessment tool/technique for

comparing the anticipated benefits of proposed investments/projects with
the corresponding costs to help users identify the alternative with the
maximum net benefit (benefits minus costs).
Feasibility study: The analysis of a business problem to determine if

it can be solved effectively. The operational, economical and technical
aspects are part of the study.
PESTEL Model: The classification that distinguishes between Political

factors, Economic factors, Social factors, Technological factors,
Environmental factors, Legal factors for project feasibility study.
1.
What is project financing? What is the importance of project financing?
2.
What are the different considerations for project financing? Explain with
suitable examples.
3.
What are the methods of infrastructure project funding? Give comparison

of different methods.
4.
What is traditional method of Project funding? How is it different from

Public Private Partnership method of project funding?
5.
What is feasibility study? Explain the importance of project feasibility

study.
6.
What is PEST analysis? Explain with suitable examples
7.
What is PESTEL analysis? What is the importance of this analysis?
Notes

Fill in the blanks.
1.
Risk identification and allocation is a key component of project finance.
2.

projects based upon the projected cash flows of the project.

Fill in the blanks.
1.
Legal & environmental factors extend the' PEST analysis to PESTLE

analysis.
2.
STEER analysis systematically considers Socio-cultural, Technological,

Economic, Ecological and Regulatory factors.

1.
False
2.
True
Cal Suggested Reacting

1.
Prasanna, Chandra. 2002. Project Management. New Delhi: Tata McGraw-Hill.

Project Managemnet Operations
75
Notes

Structure:
00 01
4.:1 Estimation of Time and Cost in Project

4.2 Economic Analysis of Projects
4.3 Return on Investment
4.4 Time Value of Money
4.5 Internal Rate of Return
4.6 Net Present Value
4.7 Economic Value Added
4.8 Payback Period
Summary
Key Words
Suggested Reading
UNIT
Objectives
Estimate the time and cost of project
Describe the concept of economic analysis of projects
Discuss the time value of money
Describe the concept of internal rate of return
Explain the concept return on investment
Evaluate the projects using net present value technique
Analyse the projects based on payback period technique
Appraise the economic value added concept
4A ESTIMATION OF TIME AND COST IN PROJECT'

The estimates are absolutely necessary inputs for successful
implementation of a project within the stipulated resource constraints.
It can be defined as the process of forecasting the requirement of time and
financial resources for the completion of project. This can be done by either
following top-down approach or the bottom-up approach.
1.
Top-down approach: Here the total time and costs mentioned for the
whole project is taken as reference and the same is not broken down to
the individual task level. This is also called macro estimation. Normally,
this approach is used during the project evaluation stage at the time of
selection and evaluation of the project by the top team. These estimates
are normally reasonably rough and are based on the experience of the
team who do it, and also the previous experience of the connected people
with similar activities. This process does not break down the project into
individual tasks or activities and therefore operates at gross top level. This
is normally substantiated by bottom up approach for the actual estimation.
2.
Bottom-up approach: Here the complete project is divided into individual

tasks. The estimates of these tasks for all variables are prepared. These
estimated costs or consumption parameters are added up (rolled up) to
arrive at the top level estimate. This is also called micro estimation.
This process does give the estimate which is reasonably close to the
reality. This process is necessary for actual implementation of the project. In
most cases, this approach cannot be successfully deployed for estimation at the
beginning due to absence of detailed break up of project and deliverable designs.
The individual estimates are prepared by the functions and the individuals who
would eventually execute the tasks and are specialists in the respective fields.
78
Methods of Estimation - Macro Type

1.
Ratio method: Based on past experience, this method does not break
down the project into tasks. It uses experience to create a ratio which
represents average costs per unit variable of the project which bundles
all variables into one. For example, the construction costs of residential
buildings are calculated using a ratio of cost in rupees per square metre
of construction or cost of transport in terms of rupees per ton kilometer
travel. Obviously the ratio figures are created based on many such past
experiences.
2.
Apportion method: This is similar to the ratio method. It is used for

executing projects which are very similar to earlier executed projects. It
uses the past experience of the similar projects to break down the same
into various deliverables or milestone activities. The costs are broken
down at the level of every deliverable. This helps to generate estimates
for each deliverable or milestone. Addition gives total estimate.
3.
Function point method: The project is identified by a typical activity

which is part of the project. Normally, this activity is repeated often in
the project and truly represents the project profile. For the said activity,
the historical data is also available in details which help managers arrive
at fairly accurate estimates. The ratio estimates are made based on this
activity costs. These ratios are used to estimate the total cost of the
project. For example for the cost of setting up a Telephone exchange,
the estimates are made based on cost ratio of the number of lines that the
new exchange will have. Cost of construction per unit area of constructed
building becomes the base for estimation of civil projects, etc.
4.
Learning curve method: It is an effective tool for estimation of projects

which contain lot of similar activities from the previous projects. It is a
proven fact that when the activities are carried out again, they consume
less time, every time it is repeated. This is used to make estimates in the
new projects. The logic is based on empirical formulae. For example,
time taken to develop a chip of higher capacity is much less than the one
that was taken for the prevalent capacity. Scientists were able to develop
a clear structure which stipulated the memory capacity of the chip of the
same size 10 years from now. Off course this logic does reach a saturation
level beyond which further improvements are much slower.
Notes
Methods of Estimation - Micro Type

1.
Template method: It is used for projects which are similar in nature to

the past projects. The detailed estimates are transferred from the previous
projects and adjustments are done for the known deviations.
2.
Parametric method: The total costs of the project in the historical data
are directly related to one of the typical variable parameter which is most
representative. For example, elapsed time.
3.
Detailed estimates method: It is possibly the most elaborate and therefore

accurate method of all. Detailed WBS activity chart is prepared. For each
79
activity the estimates are prepared from the likely members who actually
execute the said activity. Such data for all activities are generated to
arrive at a project estimate. This also helps in getting the support from the
same people when they actually execute the job because of the obviously
associated ownership.
Nbtes
4.
Hybrid phase estimation: This uses both the approaches. What is

prepared first is a macro estimate. As the project progresses through
the phases, detailed estimates are prepared for the immediate phase and
remaining are made staying at the macro estimate level. As the project
moves forward, this is repeated for successive phases. This process is
more suitable when the prevalence of uncertainty is of the much higher
magnitude and the refinement happens as we proceed with the work.
Development of new software or building of large airplanes is the classic
examples.
Level of detailing will defer in the organisational hierarchy. The senior

management would be more interested in the general plan and would not be
interested in the nuts and bolts of the project.
However, as we go to the lower levels in the hierarchy, the detailing
required goes reasonably high. This is because the actual execution of the
project is done at this level and will obviously need all the minute details.
Time phasing of the project
No project would be executable if the estimates are made only at macro
level. There is no point in telling finance people that the project would require
X amount of rupees. What is needed is the overall progress report card which
indicates the various time points at which resource needs will have to be
established.
4.2 ECONOMIC ANALYSIS OF PROJECTS

Economic feasibility of an option or a project is typically assessed through
a Cost Benefit Analysis, which can be performed either in the framework of a
Feasibility Study or as a separate study and then its results incorporated in the
overall Feasibility Study. There are various tools that can be used to measure
the economical feasibility of a project. Some of the tools used for economic
analysis are as follows:
1.
Adjusted Present Value (APV): Adjusted present value is the net present
value of a project if financed solely by ownership equity plus the present
value of all the benefits of financing.
2.
Payback Period: It measures the time required for the cash inflows to
equal the original outlay. It measures risk, not return.
3.
Cost Benefit Analysis: This includes issues other than cash, such as time
savings.
4.
Real Option Method: This attempts to value managerial flexibility that

is assumed away in NPV.
5.
Internal Rate of Return: This calculates the rate of return of a project

while disregarding the absolute amount of money to be gained.
6.
Modified Internal Rate of Return (MIRR): This is similar to IRR, but

it makes explicit assumptions about the reinvestment of the cash flows.
Sometimes it is called Growth Rate of Return.
7.
Accounting Rate of Return (ARR): This is a ratio similar to IRR arid

MIRR.
8.
Rate of Return (ROR): Also known as return on investment (ROI), rate

of profit or sometimes just return, is the ratio of money gained or lost
(whether realised or unrealised) on an investment relative to the amount
of money invested.
9.
Economic Value Added (EVA): An estimate of economic profit, which

can be determined, among other ways, by making corrective adjustments
to GAAP accounting, including deducting the opportunity cost of equity
capital. The concept of EVA is in a sense nothing more than the traditional,
commonsense idea of "profit,"; however, the utility of having a separate
and more precisely defined term such as EVA or Residual Cash Flow
is that it makes a clear separation from dubious accounting adjustments
that have enabled businesses such as Enron to report profits while in fact
being in the final approach to become insolvent.

Fill in the blanks.
1. Ratio, Apportion, Function point and Learning Curve methods are
methods of project estimation.
2
Template, Parametric, Detailed Estimates and Hybrid phases

methods of project estimation. .}
estimation methods are
ActIv" f
Activity 1
Visit a nearby project site and find the methodology used by them for
time and cost estimation.
Enlist the tools used for economic analysis.
Notes
4.3 RETURN ON INVESTMENT

Rate of Return (ROR), also known as Return on Investment (ROI), rate of profit
or sometimes just return, is the ratio of money gained or lost (whether realised
or unrealised) on an investment relative to the amount of money invested. The
amount of money gained or lost may be referred to as interest, profit/loss, gain/
loss, or net income/loss. The money invested may be referred to as the asset,
capital, principal or the cost basis of the investment. ROI is usually expressed
as a percentage rather than a fraction.
Return on investment or ROI is a figure of merit used to help make capital
investment decisions. It is calculated with the formula:
(Annual Profit)/(Investment Capital)
In this equation, the annual profit is the expected annual profit from operations
and normally does not include profit from financial operations unless they are
the main object of the business.
The term ROIC is an acronym for Return on Invested Capital.
The concept of return on investment is a very general business concept that is
used in all industry branches, from project management to real estate, and from
e-commerce to stock investment, home improvement, human resource training,
home remodeling or Internet marketing. Calculations are normally based on
capital invested, and profit, but they can also be made using gross margin and
cash flow. You do not need a sophisticated calculator to calculate a ROI (a
simple excel spreadsheet is sufficient in most cases), but advanced financial
calculations such as monthly average or annualized investment returns can be
quite tricky. In general, the investments with highest investment returns involve
more risks.
The initial value of an investment, V, does not always have a clearly defined
monetary value, but for purposes of measuring ROI, the expected value must
be clearly stated along with the rationale for this initial value. The multiple
value of an investment, V, also does not always have a clearly defined monetary
value, but for purposes of measuring ROI, the final value must be clearly stated
along with the rationale for this final value.
The rate of return can be calculated over a single period, or expressed as an
average over multiple periods.
1.
Single-period
a.
Arithmetic return - The arithmetic return is:

Vf
rarith = V.
rath is sometimes referred to as the yield. See also: effective interest rate,
effective annual rate (EAR) or annual percentage yield (APY).
b.
Logarithmic or continuously compounded return - The logarithmic

return or continuously compounded return, also known as force of
interest, is defined as:
r log = In
It is the reciprocal of the e-folding time.

2.
Multi period average returns

a.
Arithmetic average rate of return - The arithmetic average rate of

return over n periods is defined as:
raithmetic =
b.
1
n
vn rarith i = 1
(rarith 1, +
+ rarithn)
Geometric average rate of return - The geometric average rate

of return, also known as the time-weighted rate of return, over n
periods is defined as:
r geometric = I +
c.
II (1 + r arith.01/n
i=1
The geometric average rate of return calculated over n years is also

known as the annualised return.

Fill in the blanks.
1
is the ratio of money gained or lost (whether realised

or unrealised) on an investment relative to the amount of money
invested
,2. The term ROIC is an acronym for
4.4 TIME VALUE OF MONEY

Investments generate cash flow to the investor to compensate the investor
for the time value of money.
Except for rare periods of significant deflation where the opposite may
be true, a dollar in cash is worth less today than it was yesterday, and worth
more today than it will be worth tomorrow. The main factors that are used by
investors to determine the rate of return at which they are willing to invest
money include:
Estimates of future inflation rates
Estimates regarding the risk of the investment (e.g., how likely it is that
investors will receive regular interest/dividend payments and the return of
their full capital)
Notes
Notes
Whether or not the investors want the money available ("liquid") for other
uses.
The time value of money is reflected in the interest rates that banks offer
for deposits, and also in the interest rates that banks charge for loans such as
home mortgages. The "risk-free" rate is the rate on US Treasury Bills, because
this is the highest rate available without risking capital.
The rate of return which an investor expects from an investment is called
the Discount Rate. Each investment has a different discount rate, based on the
cash flow expected in future from the investment. The higher the risk, the higher
the discount rate (rate of return) the investor will demand from the investment.
Compounding or reinvesting
Compound interest or other reinvestment of cash returns (such as
interest and dividends) does not affect the discount rate of an investment, but
it does affect the Annual Percentage Yield, because compounding/reinvestment
increases the capital invested.
For example, if an investor put $1,000 in a 1 year certificate of deposit
(CD) that paid an annual interest rate of 4%, compounded quarterly, the CD
would earn 1% interest per quarter on the account balance. The account balance
includes interest previously credited to the account.
Compound Interest Example
1st
Quarter
$1,000
2nd
3rd
4th
Quarter
Quarter
Quarter
$1,010 $1,020.10 $1,030.30
Capital at the beginning of

the period
$10
$10.10
$10.20
$10.30
Dollar return for the period
$1,040.60
$1,010.00
$1,020.10
$1,030.30
Account Balance at end of the
period
1%
1%
1%
1%
Quarterly ROI
The concept of 'income stream' may express this more clearly. At the
beginning of the year, the investor took $1,000 out of his pocket (or checking
account) to invest in a CD at the bank. The money was still his, but it was no
longer available for buying groceries. The investment provided a cash flow of
$10.00, $10.10, $10.20 and $10.30. At the end of the year, the investor got
$1,040.60 back from the bank. $1,000 was return of capital.
Once interest is earned by an investor it becomes capital. Compound
interest involves reinvestment of capital; the interest earned during each quarter
is reinvested. At the end of the first quarter the investor had capital of $1,010.00,
which then earned $10.10 during the second quarter. The extra dime was interest
on his additional $10 investment. The Annual Percentage Yield or Future value
for compound interest is higher than for simple interest because the interest is
reinvested as capital and earns interest. The yield on the above investment was
4.06%.
84
Bank accounts offer contractually guaranteed returns, so investors cannot

lose their capital. Investors/depositors lend money to the bank, and the bank is
obligated to give investors back their capital plus all earned interest. Because
investors are not risking losing their capital on a bad investment, they earn a
quite low rate of return. But their capital steadily increases.
Notes
Returns when capital is at risk - Capital gains and losses

Many investments carry significant risk that the investor will lose some
or all of the invested capital. For example, investments in company stock shares
put capital at risk. The value of a stock share depends on what someone is
willing to pay for it at a certain point in time.
Unlike capital invested in a savings account, the capital value (price) of a
stock share constantly changes. If the price is relatively stable, the stock is said
to have "low volatility". If the price often changes a great deal, the stock has
"high volatility". All stock shares have some volatility, and the change in price
directly affects ROI for stock investments.
Stock returns are usually calculated for holding periods such as a month,
a quarter or a year.
Reinvestment when capital is at risk then rate of return and yield is
Yield is the compound rate of return that includes the effect of reinvesting
interest or dividends. Given below is an example of a stock investment of one
share purchased at the beginning of the year for $100.
Example: Stock with low volatility and a regular quarterly dividend,
reinvested
End of:
Dividend
Stock Price
Shares Purchased
Total Shares Held
Investment Value
Quarterly ROI
1st Quarter
$1
$98
0.010204
1.010204
$99
-l%
2nd Quarter
$1.01
$101
0.01
1.020204
$103.04
4.08%
3rd Quarter
$1.02
$102
0.01
1.030204
$105.08
1.98%
4th Quarter
$1.03
$99
0.010404
1.040608
$103.02
-1.96%
The quarterly dividend is reinvested at the quarter-end stock price.
The number of shares purchased each quarter = ($ Dividend)/($ Stock

Price).
The final investment value of $103.02 is a 3.02% yield on the initial

investment of
$100. This is the compound yield, and this return can be considered to be
the return on the investment of $100.
To calculate the rate of return, the investor includes the reinvested

dividends in the total investment. The investor received a total of $4.06 in
dividends over the year, all of which were reinvested, so the investment
amount increased by $4.06.
85
Ps
Arithmetic average and geometric average rates of return

Both arithmetic and geometric average rates of returns are averages of
periodic percentage returns. Neither will accurately translate to the actual dollar
amounts gained or lost if percent gains are averaged with percent losses.A10%
loss on a $100 investment is a $10 loss, and a 10% gain on a $100 investment
is a $10 gain. When percentage returns on investments are calculated, they are
calculated for a period of time not based on original investment dollars, but
based on the dollars in the investment at the beginning and end of the period.
So if an investment of $100 loses 10% in the first period, the investment amount
is then $90. If the investment then gains 10% in the next period, the investment
amount is $99.
A 10% gain followed by a 10% loss is a 1% loss. The order in which the
loss and gain occurs does not affect the result. A 50% gain and a 50% loss is a
25% loss. An 80% gain plus an 80% loss is a 64% loss. To recover from a 50%
loss, a 100% gain is required. The mathematics of this are beyond the scope
of this article, but since investment returns are often published as "average
returns", it is important to note that average returns do not always translate into
dollar returns.
Example 1 Level Rates of Return
Rate of Return
Geometric Average at End of Year
Capital at End of Year
Dollar Profit/(Loss)
Compound Yield
Year 1
5%
5%
$105.00
$5.00
5%
Year 2
5%
5%
$110.25
$10.25
Example 2 Volatile Rates of Return, including losses

Year 1
Year 2
-20%
'
50%
Rate of Return
9.5%
Geometric Average at End of Year 50%
$150.00 $120.00
Compound Yield
Year 3
5%
Year 4
5%
5%
5%
$115.76 $121.55
$15.76 $21.55
5.4%
Year 3
30%
16%
$156.00
Example 3 Highly Volatile Rates of Return, includinglusses

Year 1
Year 2
Year 3
0%
0%
-95%
Rate of Return
-77.6% -63.2%
Geometric Average at End of Year -95%
$5.00
$5.00
$5.00
Compound Yield
Year 4
-40%
-1.6%
$93.60
($6.40)
-1.6%
Year 4
115%
-42.7%
$10.75
($89.25)
-22.3%
Annual returns and annualised returns

Care must be taken not to confuse annual and annualised returns. An
annual rate of return is a single-period return, while an annualised rate of return
is a multi-period, geometric average return.
An annual rate of return is the return on an investment over a one-year

period, such as January 1 to December 31, or June 3 to June 2. Each ROI in the
cash flow example above is an annual rate of return.
Notes
An annualised rate of return is the return on an investment over a period

other than one year (such as a month, or two years) multiplied or divided to give
a comparable one-year return. For instance, a one-month ROI of 1% could be
stated as an annualised rate of return of 12%. Or a two-year ROI of 10% could
be stated as an annualised rate of return of 5%. **For GIPS compliance: you
do not annualise portfolios or composites for periods of less than one year. You
start on the 13th month.
In the cash flow example below, the dollar returns for the four years add
up to $265. The annualised rate of return for the four years is: $265 ($1,000 x
4 years) = 6.625%.
Uses
ROI is a measure of cash generated by or lost due to the investment. It
measures the cash flow or income stream from the investment to the investor,
relative to the amount invested. Cash flow to the investor can be in the form of
profit, interest, dividends, or capital gain/loss. Capital gain/loss occurs when the
market value or resale value of the investment increases or decreases. Cash flow
here does not include the return of invested capital.
Cash Flow Example on $1,000 Investment
Dollar Return
ROI
Year 1
$100
10%
Year 2
$55
5.5%
Year 3
$60
6%
Year 4
$50
5%
ROI values typically used for personal financial decisions include Annual
Rate of Return and Annualised Rate of Return. For nominal risk investments such
as savings accounts or certificates of deposit, the personal investor considers the
effects of reinvesting/compounding on increasing savings balances over time.
For investments in which capital is at risk, such as stock shares, mutual fund
shares and home purchases, the personal investor considers the effects of price
volatility and capital gain/loss on returns.
Profitability ratios typically used by financial analysts to compare a
company's profitability over time or compare profitability between companies
include Gross Profit Margin, Operating Profit Margin, ROI ratio, Dividend
yield, Net profit margin, Return on equity, and Return on assets.
During capital budgeting, companies compare the rates of return of
different projects to select which projects to pursue in order to generate
maximum return or wealth for the company's stockholders. Companies do so
by considering the average rate of return, payback period, net present value,
profitability index, and internal rate of return for various projects.
89
Note's
A return may be adjusted for taxes to give the after-tax rate of return. This
is done in geographical aim or historical times in which taxes consumed or
consume a significant portion of profits or income. The after-tax rate of return
is calculated by multiplying the rate of return by the tax rate, then subtracting
that percentage from the rate of return.
A return of 5% taxed at 15% gives an after-tax return of
4.25% 0.05 x 0.15 = 0.0075
0.05 - 0.0075 = 0.0425 = 4.25%
A return of 10% taxed at 25% gives an after-tax return of
7.5% 0.10 x 0.25 = 0.025
0.10 - 0.025 = 0.075 = 7.5%
Investors usually seek a higher rate of return on taxable investment returns
than on non- taxable investment returns.
A return may be adjusted for inflation to better indicate its true value in
purchasing power. Any investment with a nominal rate of return less than the
annual inflation rate represents a loss of value, even though the nominal rate of
return might well be greater than 0%. When ROI is adjusted for inflation, the
resulting return is considered as an increase or decrease in purchasing power. If
an ROI value is adjusted for inflation, it is stated explicitly, such as "The return,
adjusted for inflation, was 2%."
Many online poker tools include ROI in a player's tracked statistics,
assisting users in evaluating an opponent's profitability.
110
Fill in the blanks.

1.
------
--
IRR means
returns are often used by academics in their research
iketwits' Activity 3
Select a project of your choice and use IRR technique for the evaluation of
the project.
4.6 NET PRESENT VALUE

Net Present Value (NPV) or Net Present Worth (NPW) of a time series of
cash flows, both incoming and outgoing, is defined as the sum of the present
values (PVs) of the individual cash flows. In case when all future cash flows
are incoming (such as coupons and principal of a bond) and the only outflow of
cash is the purchase price, the NPV is simply the PV of future cash flows minus
the purchase price (which is its own PV). NPV is a central tool in discounted
cash flow (DCF) analysis, and is a standard method for using the time value of
money to appraise long-term projects. Used for capital budgeting, and widely
throughout economics, finance, and accounting, it measures the excess or
shortfall of cash flows, in present value terms, once financing charges are met.
Notes
The NPV of a sequence of cash flows takes as input the cash flows and a
discount rate or discount curve and outputting a price; the converse process in
DCF analysis, taking as input a sequence of cash flows and a price and inferring
as output a discount rate (the discount rate which would yield the given price as
NPV) is called the yield, and is more widely used in bond trading.
Formula
Each cash inflow/outflow is discounted back to its present value (PV).
Then they are summed. Therefore, NPV is the sum of all terms,
where
Rt
(1 + i)t
t - the time of the cash flow
i - the discount rate (the rate of return that could be earned on an investment in
the financial markets with similar risk.)
Rt- the net cash flow (the amount of cash, inflow minus outflow) at time t (for
educational purposes, Ro is commonly placed to the left of the sum to emphasize
its role as (minus the) investment.
The result of this formula if multiplied with the Annual Net cash in-flows
and reduced by Initial Cash outlay will be the present value but in case where
the cash flows are not equal in amount then the previbus formula will be used to
determine the present value of each cash flow separately. Any cash flow within
12 months will not be discounted for NPV purpose.
The discount rate
The rate used to discount future cash flows to their present values is a key
variable of this process.
A firm's weighted average cost of capital (after tax) is often used, but
many people believe that it is appropriate to use higher discount rates to adjust
for risk or other factors. A variable discount rate with higher rates applied to
cash flows occurring further along the time span might be used to reflect the
yield curve premium for long-term debt.
Another approach to choosing the discount rate factor is to decide the
rate which the capital needed for the project could return if invested in an
alternative venture. If, for example, the capital required for Project can earn
five per cent elsewhere, use this discount rate in the NPV calculation to allow
a direct comparison to be made between Project A and the alternative. Related
91
Notes
We compute the part or fraction of the next year's cash inflow need to
payback the initial cash outlay by taking the initial cash outlay less the
cumulative total in the last step then divide this amount by the next year's
cash inflow. E.g., ($10,000 - $ 9,000)/$3,000 = 0.334
To now obtain the payback period in years, we take the figure from the
last step and add it to the year from the step 2. Thus our payback period is
2 +.334 = 2.334 years
Instead of representing the years as decimal value we could represent the

payback period in years and months, this way we take the fraction 0.334
and multiply it by 12 to get the months, which is 4.01 months. Thus our
payback period is 2 years and 4 months.
Summary
98
The time and cost estimation is the most daunting and challenging task
for success of the project. The estimates are the absolutely necessary
inputs for successful implementation of the project within the stipulated
resource constraints.
It can be defined as the process of forecasting the requirement of time

and financial resources for the completion of project. This can be done by
either following the top-down approach or the bottom-up approach.
In the top-down approach, the total time and costs mentioned for the
whole project is taken as reference and the same is not broken down to
the individual task level. This is also called macro estimation.
In the bottom-up approach, the complete project is divided into individual

tasks. The estimates of these tasks for all variables are prepared. These
estimated costs or consumption parameters are added up (rolled up) to
arrive at the top level estimate. This is also called micro estimation.
Economic feasibility .of an option or a project is typically assessed

through a Cost Benefit Analysis, which can be performed either in the
framework of a Feasibility Study or as a separate study and then its results
incorporated in the overall Feasibility Study. There are various tools that
can be used to measure the economical feasibility of a project. Some of
the tools used for economic analysis are as follows:
Adjusted present value (APV): Adjusted present value is the net

present value of a project if financed solely by ownership equity
plus the present value of all the benefits of financing.
Payback period: It measures the time required for the cash inflows
to equal the original outlay. It measures risk, not return.
Cost-benefit analysis: It includes issues other than cash, such as

time savings.
Real option method: It attempts to value managerial flexibility

that is assumed away in NPV. Internal rate of return calculates the
rate of return of a project while disregarding the absolute amount of

money to be gained.
Modified internal rate of return (MIRR): It is similar to IRR, but

it makes explicit assumptions about the reinvestment of the cash
flows. Sometimes it is called Growth Rate of Return.
Accounting rate of return (ARR): A ratio similar to IRR and

MIRR.
Rate of Return (ROR): It is also known as return on investment

(ROI), rate of profit or sometimes just return. It is the ratio of money
gained or lost (whether realised or unrealised) on an investment
relative to the amount of money invested.
Economic Value Added (EVA): It is an estimate of economic

profit, which can be determined, among other ways, by making
corrective adjustments to GAAP accounting, including deducting
the opportunity cost of equity capital.
Notes
Keywords
Time and cost estimation: The process of forecasting the requirement of

time and financial resources for the completion of the project.
Adjusted present value: The net present value of a project if financed

solely by ownership equity plus the present value of all the benefits of
financing.
Payback period: An economical measure which measures the time

required for the cash inflows to equal the original outlay.
Cost benefit analysis: An economical measure where we compare cost

with the benefits which includes issues other than cash, such as time
savings.
Internal rate of return: An economical measure which calculates the

rate of return of a project while disregarding the absolute amount of
money to be gained.
Rate of return: The ratio of money gained or lost (whether realised or

unrealised) on an investment relative to the amount of money invested.
Economic value added: An estimate of economic profit, which can be

determined, among other ways, by making corrective adjustments to
GAAP accounting, including deducting the opportunity cost of equity
capital.
1.
What is time and cost estimation? What is the importance of time and cost
estimation for project management?
99
Notes
2.
What are the different approaches to time and cost estimation? Give their
comparison.
3.
What are the different tools available to measure economic feasibility of

the projects?
----------
Explain with examples.

4.
What are the different tools available to measure economic feasibility of

the projects?
Give comparison of these tools.
5.
What is IRR technique? Explain the process and use of IRR for project
evaluation.
6.
What is ROI technique? Explain the process and use of ROI for project
evaluation.
7.
What is NPV technique? Explain the process and use of NPV for project
evaluation.
8.
What is EVA technique? Explain the process and use of EVA for project
evaluation.
9.
What is Payback technique? Explain the process and use of Payback for
project evaluation.

Fill in the blanks.
1.
Ratio, Apportion, Function point and Learning Curve methods are macro
methods of project estimation.
2.
Template, Parametric, Detailed Estimates and Hybrid phases estimation

methods are micro methods of project estimat ion.

Fill in the blanks.
1.
Rate of Return is the ratio of money gained or lost (whether realised or

unrealised) on an investment relative to the amount of money invested.
2.
The term ROIL is an acronym for Return on Invested Capital.

100
1.
True
2.
True
Notes
Fill in the blanks.

1.
IRR means Internal Rate of Return.
2.
Logarithmic returns are often used by academicians in their research.

1.
False
2.
True

Fill in the blanks.
1.
Economic Value Added or EVA is an estimate of economic profit.
2.
The EVA is a registered trademark by its developer, Stern Stewart and Co.
(41) Suggested Reading

1.

McGraw-Hill.
101
Notes
102 j
Organising Projects
Structure:
eal se io
5.1 Introduction to Organisational Structures
UNIT
5.2 Types of Organisational Structures

5.3 Project Management Office
5.4 Responsibilities of Project Manager
5.5 Project Teams
5.6 Conflict Management
Summary
Key Words
Suggested Reading
Organising Projects
103
gla Notes
Objectives
.......7,7
Describe the concept of project organisation
Identify the different types of organisation structures
Explain the concept of project management office
State the responsibilities of project manager
Differentiate between project manager and project director
Create project teams
Implement conflict management in projects
5.1 INTRODUCTION TO ORGANISATIONAL STRUCTURES

Organisations are a variant of clustered entities. An organisation can be
structured in many different ways and styles, depending on their objectives and
ambience. The structure of an organisation will determine the modes in which
it operates and performs.
An organisational structure is mainly a hierarchical concept of
subordination of entities that collaborate and contribute to serve one common
aim.
Organisational structure allows the expressed allocation of responsibilities
for different functions and processes to different entities such as the branch,
department, workgroup and individual. Individuals in an organisational structure
are normally hired under time-limited work contracts or work orders, or under
permanent employment contracts or program orders.
5.2 TYPES OF ORGANISATIONAL STRUCTURES

Operational Organisations and Informal Organisations
The set organisational structure may not coincide with the facts evolving
in operational action. Such divergence decreases performance, when growing.
E.g., a wrong organisational structure may hamper cooperation and thus hinder
the completion of orders in due time and within limits of resources and budgets.
Organisational structures shall be adaptive to process requirements, aiming to
optimise the ratio of effort and input to output.
An effective organisational structure shall facilitate working relationships
between various entities in the organisation and may improve the working
efficiency within the organisational units. Organisation shall retain a set order
and control to enable monitoring the processes. Organisation shall support
command for coping with a mix of orders and a change of conditions while
104
performing work. Organisation shall allow for application of individual skills

to enable high flexibility and apply creativity. When a business expands, the
chain of command will lengthen and the spans of control will widen. When an
organisation comes to age, the flexibility will decrease and the creativity will
fatigue. Therefore organisational structures shall be altered from time to time to
enable recovery. If such alteration is prevented internally, the final escape is to
turn down the organisation to prepare for a for a re-launch in an entirely new set
up.
Notes
Common success criteria for organisational structures are:
Decentralised reporting
Flat hierarchy
High transient speed
High transparency
Low residual mass
Permanent monitoring
Rapid response
Shared reliability
Matrix hierarchy
Organisational structures developed from the ancient times of hunters

and collectors in tribal organisations through highly royal and clerical power
structures to industrial structures and today's postindustrial structures.
Pre-bureaucratic Structures
Pre-bureaucratic (entrepreneurial) structures lack standardisation of tasks.
This structure is most common in smaller organisations and is best used to solve
simple tasks. The structure is totally centralised. The strategic leader makes all
key decisions and most communication is done by one on one conversations. It
is particularly useful for new (entrepreneurial) business as it enables the founder
to control growth and development.
They are usually based on traditional domination or charismatic
domination in the sense of Max Weber's tripartite classification of authority.
Bureaucratic Structures
Bureaucratic structures have a certain degree of standardisation. They
are better suited for more complex or larger-scale organisations. They usually
adopt a tall structure. The. tension between bureaucratic structures and nonbureaucratic is echoed in Burns and Stalker distinction between mechanistic
and organic structures. It is not the entire thing about bureaucratic structure. It is
very much complex and useful for hierarchical structures organisation, mostly
in tall organisations.
Organising Projects
105
Notes
Post-bureaucratic
The term of post-bureaucratic is used in two senses in the organisational
literature: one generic and one much more specific. In the generic sense the
term post-bureaucratic is often used to describe a range of ideas developed
since the 1980s that specifically contrast themselves with Weber's ideal type
bureaucracy. This may include total quality management, culture management
and matrix management, amongst others. None of these however has left
behind the core tenets of bureaucracy. Hierarchies still exist, authority is still
Weber's rational, legal type, and the organisation is still rule bound. Heckscher,
arguing along these lines, describes them as cleaned up bureaucracies, rather
than a fundamental shift away from bureaucracy. Gideon Kunda, in his classic
study of culture management at 'Tech' argued that 'the essence of bureaucratic
control the formalization, codification and enforcement of rules and regulations
does not change in principle it shifts focus from organisational structure to the
organisation's culture'.
Another smaller group of theorists have developed the theory of the
Post-Bureaucratic Organisation provide a detailed discussion which attempts
to describe an organisation that is fundamentally not bureaucratic. Charles
Heckscher has developed an ideal type, the post-bureaucratic organisation, in
which decisions are based on dialogue and consensus rather than authority and
command, the organisation is a network rather than a hierarchy, open at the
boundaries (in direct contrast to culture management); there is an emphasis
on meta-decision-making rules rather than decision-making rules. This sort
of horizontal decision-making by consensus model is often used in housing
cooperatives, other cooperatives and when running a non-profit or community
organisation. It is used in order to encourage participation and help to empower
people who normally experience oppression in groups.
Still other theorists are developing a resurgence of interest in complexity
theory and organisations, and have focused on how simple structures can be
used to engender organisational adaptations. For instance, Miner et al. (2000)
studied how simple structures could be used to generate improvisational
outcomes in product development. Their study makes links to simple structures
and improvises learning. Other scholars such as Jan Rivkin and Sigglekow, and
Nelson Repenning revive an older interest in how structure and strategy relate
in dynamic environments.
Darwin's natural selection is a great thing. The shape of every species
is crafted over thousands of years, to get the functions it needs to survive in
the environment it operates. If it does not have the .necessary skills, it just dies
and is doomed with extinction. All the beautiful, blonde, long legged creatures
survive.
The Homo Projectus is an ugly thing. It survives in extreme situations,
where dirt has to be shoved. In this case it has the aspects of a hog. But to get
the right features to have a party of hogs operating in such a way the pack
will survive is something completely different. We cannot wait until nature has
106
killed all unsuccessful project organisations (the hog party), so the software
project manager has to help nature a little bit, tinkering with the organisation,
so it might have a chance to survive in the corporate jungle.
Notes
A project organisation is a temporary thing. It will only exist from the

projects start until its end. All the project team members are coming from
different part of the organisation. They will all have a temporary assignment
to the project. So, they have not only a project boss (the project manager, that
might be you), but also their 'normal' boss, who orders him around when the
employee is not in the project. These 'normal bosses' are an important group of
stakeholders.
The project organisation should be a result from the project strategy it
should be constructed in such a way that the strategy can be implemented within
the environment of the project ("look what the dog brought in, a presumptuous
sentence"). A very obvious example: if the strategy contains an aspect of having
independent reviews, the organisation should support its independence by
creating a separate working group with no ties to the other team members, e.g.,
But, I'm a little too far now mentioning working groups and the like.
5.3 PROJECT MANAGEMENT OFFICE

The project team that does the work should be as small as possible. Small
is beautiful, and effective. Don't start inviting everyone to the organisation.
Only people who have an added value and will spend a significant amount of
time to the project can be in the core organisation. Try to avoid going overboard
on working groups. Working groups can drown a project in communication
overhead. If there should be that much discussion anyway, postpone the project
and first make up the minds.
Next to the people who do the work are the people who have some
influence on it, but do nothing a large part of the stakeholders. The project
organisation can be used to satisfy some wishes of stakeholders to create the
much needed win-win situations. In its most simple form, you can create a
project trashcan ("The Project Tactical Non-Binding Advisory Committee")
where you put in the people who just want to be involved in the project (to save
their territory), but which you have no use for.
Functional structure
The functional organisation, shown in Figure 5.1 is a structure where
authority rests with the functional heads; the structure is sectioned by
departmental groups. Staff members are divided into groups (e.g., financial,
planning, public relations, engineering, legal, etc.) according to their specialised
knowledge. Some of these groups can be further subdivided into smaller
functional groups. For example, the Engineering Department may be further
subdivided into Mechanical Engineering and Electrical Engineering Units.
Organising Projects
107
Notes
Project
Head of the
Implementing Agency
Coordination
i
Head of the Department
(Functional manager)
JHead of the Department

(Functional Manager)
r
Head of the Department
(Functional Manager)
(blue boxes represent staff of the Departments engaged in the project activities)
Fig. 5.1: Functional Organisation

The main advantage of this organisational structure is that each functional
group has complete control over its segment of the project, enforcing in this
way the application of standards across projects.
The disadvantages of the functional organisation are that of speed,
flexibility and communication when attempting cross-functional projects. Since
in a functional organisation the work is divided between the departments, any
query or request must be passed among department heads for approval, causing
in this way delays. In addition, the responsibility of managing the project is
shared among the functional managers (head of the departments) and this may
cause lack of ultimate responsibility for project management.
Employees within the functional divisions of an organisation tend to
perform a specialised set of tasks, for instance the engineering department would
be staffed only with software engineers. This leads to operational efficiencies
within that group. However, it could also lead to a lack of communication
between the functional groups within an organisation, making the organisation
slow and inflexible.
This type of organisational structure is generally considered the least
effective for implementing and managing projects.
As a whole, a functional organisation is best suited as a producer of
standardised goods and services at large volume and low cost. Coordination
and specialisation of tasks are centralised in a functional structure, which makes
producing a limited amount of products or services efficient and predictable.
Moreover, efficiencies can further be realised as functional organisations
integrate their activities vertically so that products are sold and distributed
quickly and at low cost. For instance, a small business could start making the
components it requires for production of its products instead of procuring it
from an external organisation. It's not only beneficial for the organisation but
also for employees' faiths.
Divisional structure
Also called a "product structure", the divisional structure groups each
organisational function into divisions. Each division within a divisional structure
contains all the necessary resources and functions within it. Divisions can be
categorised from different points of view. A distinction can be made on the basis
of geographical basis (a US division and an EU division) or on product/service
basis (different products for different customers: households or companies).
Another example, an automobile company with a divisional structure might
have one division for SUVs, another division for subcompact cars, and another
division for sedans. Each division would have its own sales, engineering and
marketing departments.
The projectised organisation or divisional structure, shown in Figure 5.2
is a structure where the focus is on teams with cross-functional expertise. Most
of the organisation's resources are involved in project work team's mission to
complete the project. All team members working for a specific project have one
clear superior, the project manager and they all refer to him/her.
Project
Coordinadon
Project Manager ij
Head of the
Implementing Agency
Project Manager
staff
staff
Project Manager
4H
staff
stett
staff
staff
(blue boxes represent slat! engaged in the project activities)
Fig. 5.2: Projectised Organisation

The main advantages of the projectised organisation are speed and
flexibility. Since the experts are concentrated within the team and fully
committed to the project, it is easier to react to changing requirements and
complete the project on time. Responsibility for the success of the project is
clearly identified and lies on the Project Manager.
The main disadvantage of the projectised structure is the high resource
costs, since the organisation often has to hire extra staff with certain expertise
in order to implement different projects simultaneously. In addition, this type of
structure burdens the administrative overhead since there may be periods where
not all project teams are occupied.
The divisional structure is broken down into three areas: product, market,
and geographic.
Product Structure
Product structure groups employees together based upon specific
products produced by the company. An example of this would be a company
that produces three distinct products, "product a", "product b", and "product c".
This company would have a separate division for each product.
Organising Projects
Notes
Notes
Market Structure
Market structure groups employees together based upon specific markets
in which the company sells.
Geographic structure
Geographic structure groups employees together based upon specific
geographic location. This is often used by large companies that operate in many
areas throughout the United States or in both the US and overseas.
Matrix structure
This structure is a blend of functional and projectised organisations. In
the matrix structure (Figure 5.3), the personnel engaged in the project activities
belong to one or more functional units (departments). For project related
issues the project team members (staff) report to the Project Manager, who
is responsible for the timely completion of the project activities. For business
related issues the project team members report to the corresponding functional
managers. Once the implementation of the project or part of their work has
been completed, they are returned to the control of the functional manager for
reassignment. The person who is assigned to play the role of Project Manager
for a specific project is not necessarily one of the functional managers, but it can
be a single staff member possessing the appropriate skills and competencies.
The Project Manager in the matrix structure cooperates with the functional
manager to establish the resource requirements and plan their utilisation on
the project as well as to make the necessary revisions during the project's
implementation progress.
Heed of the
Implementing Agency
Heed of the Depertrnent

(Functional manage()
Heed of the Department

(Funclavi manager)
Prated
(blue boxes represent staff engaged in the project act Woes)
Cocandlcu
Fig. 5.3: Matrix Organisation

1110."
The main advantage of the matrix organisation is that it retains the benefits
of both functional and projectised structures. It also facilitates the effective
resource allocation to different projects.
Notes
For these reasons, the matrix structure is considered as the most effective
structure for implementing and managing projects and therefore is widely used.
The main disadvantage of the matrix structure is the potential for conflict
between the project manager and the functional manager regarding the resource
assignment, since the functional manager has to staff multiple projects with the
same experts.
The matrix organisation is an attempt to combine the advantages of the
pure functional structure and the product organisational structure. This form is
identically suited for companies, such as construction, that are "project-driven".
The figure below shows a typical matrix organisation.
In a matrix organisation, each project manager reports directly to the vice
president and the general manager. Since each project represents a potential
profit centre, the power and authority used by the project manager come directly
from the general manager.
Information sharing is mandatory in such an organisation, and several
people may be required for the same piece of work. However, in general, the
project manager has the total responsibility and accountability for the success
of the project. The functional departments, on the other hand, have functional
responsibility to maintain technical excellence on the project. Each functional
unit is headed by a department manager whose prime responsibility is to ensure
that a unified technical base is maintained and that all available information can
be exchanged for each project.
The basis for the matrix organisation is an endeavour to create synergy
through shared responsibility between project and functional management. Other
advantages of a pure matrix organisational form, to project management, include:
Key people can be shared hence the project cost is minimised.
Conflicts are minimal, and those requiring hierarchical referrals are more
easily resolved.
There is a better balance between time, cost and performance.
Authority and responsibility are shared.
Stress is distributed among the team.
Before we discuss the differences in organisational structure, we need

understand the meaning and purpose of organisational structure. Organisational
structure formally determines the hierarchy within an organisation
In other words, who reports to whom? Some companies refer to this as
the organisational chart. Types of organisational structure include: functional
structure, divisional structure, and matrix structure. Divisional structure is
further broken down into three sub-types: product structure, market structure,
and geographic structure.
Organising Projects
111
Notes
The matrix structure groups employees by both function and product. This
structure can combine the best of both separate structures. A matrix organisation
frequently uses teams of employees to accomplish work, in order to take
advantage of the strengths, as well as make up for the weaknesses, of functional
and decentralised forms. An example would be a company that produces two
products, "product a" and "product b". Using the matrix structure, this company
would organise functions within the company as follows: "product a" sales
department, "product a" customer service department, "product a" accounting,
"product b" sales department, "product b" customer service department,
"product b" accounting department. Matrix structure is amongst the purest
of organisational structures, a simple lattice emulating order and regularity
demonstrated in nature.
Weak/Functional Matrix: A project manager with only limited authority

is assigned to oversee the cross-functional aspects of the project. The
functional managers maintain control over their resources and project
areas.
Balanced/Functional Matrix: A project manager is assigned to oversee
the project. Power is shared equally between the project manager and
the functional managers. It brings the best aspects of functional and
projectised organisations. However, this is the most difficult system to
maintain as the sharing power is delicate proposition.
Strong/Project Matrix; A project manager is primarily responsible for
the project. Functional managers provide technical expertise and assign
resources as needed. Among these matrixes, there is no best format;
implementation success always depends on organisation's purpose and
function.
Organisational circle: Moving back to flat

The flat structure is common in entrepreneurial start-ups, university
spin-offs or small companies in general. As the company grows, however, it
becomes more complex and hierarchical, which leads to an expanded structure,
with more levels and departments.
Often, it would result in bureaucracy, the most prevalent structure in the
past. It is still, however, relevant in former Soviet Republics and China, as
well as in most governmental organisations all over the world. Shell Group
used to represent the typical bureaucracy top-heavy and hierarchical. It featured
multiple levels of command and duplicate service companies existing in
different regions. All this made Shell apprehensive to market changes, leading
to its incapacity to grow and develop further. The failure of this structure became
the main reason for the company restructuring into a matrix.
Starbucks is one of the numerous large organisations that successfully
developed the matrix structure supporting their focused strategy. Its design
combines functional and product based divisions, with employees reporting to
two heads. Creating a team spirit, the company empowers employees to make
their own decisions and train them to develop both hard and soft skills. That
makes Starbucks one of the best at customer service.
Notes
Some experts also mention the multinational design, common in global

companies, such as Procter & Gamble, Toyota and Unilever. This structure can
be seen as a complex form of the matrix, as it maintains coordination among
products, functions and geographic areas.
In general, over the last decade, it has become increasingly clear that
through the forces of globalisation, competition and more demanding customers,
the structure of many companies has become flatter, less hierarchical, more
fluid and even virtual.
A project management office is a separate office considered for overall
administration of project. There are three basic types of Project Management
Office (PMO) organisations, varying in the degree of control and influence they
have on projects within the organisation. You will need to determine which type
you need to establish in order to have an effective project office.
The three types of PMOs include:
Supportive PMO
The Supportive PMO generally provides support in the form of on-demand
expertise, templates, best practices, access to information and expertise on other
projects, and the like. This can work in an organisation where projects are done
successfully in a loosely controlled manner and where additional control is
deemed unnecessary. Also, if the objective is to have a sort of "clearing-house"
of project management information across the enterprise to be used freely by
project managers, then the Supportive PMO is the right type.
Controlling PMO
In organisations where there is a desire to "reign in" the activities,
processes, procedures, documentation, and more a controlling PMO can
accomplish that. Not only does the organisation provide support, but it also
requires that the support be used. Requirements might include adoption of
specific methodologies, templates, forms, conformance to governance, and
application of other PMO controlled sets of rules. In addition, project offices
might need to pass regular reviews by the controlling PMO, and this may
represent a risk factor on the project. This works if a) there is a clear case
that compliance with project management organisation offerings will bring
improvements in the organisation and how it executes on projects, and b) the
PMO has sufficient executive support to stand behind the controls the PMO
puts in place.
Directive PMO
This type goes beyond control and actually "takes over" the projects by
providing the project management experience and resources to manage the
project. As organisations undertake projects, professional project managers from
the PMO are assigned to the projects. This injects a great deal of professionalism
Organising Projects
113
Notes
into the projects, and, since each of the project managers originates and reports
back to the directive PMO, it guarantees a high level of consistency of practice
across all projects. This is effective in larger organisations that often matrix out
support in various areas, and where this setup would fit the culture.
The best type is very specific to the organisation, culture, and history of
what works and what does not. But the objectives are more or less to:
Implement a common methodology
Standardise terminology
Introduce effective repeatable project management processes
Provide common supporting tools
Ultimately, the objective is to improve levels of project success within the

organisation
Being aware of these types can help you and your organisation more
easily accomplish this.
In a well-run project there is a lot going on. The routine project management
processes require a combination of special skills and administrative resource.
Rarely is it enough just to appoint a project manager. To do the job properly
requires time and resources.
It is common to pint in place a small project office team to deal with
the administrative tasks of the project, freeing up the project leadership and
project resources to get on with their jobs. A project office team might comprise
roles such as project manager, project planner, progress tracker, financial
controller, process administrator (change control, risks, issues, configuration,
documentation management), quality controller, communications manager,
organisational change manager, and administrative support.
It may be beneficial to use an integrated set of support tools. Project
information can be shared among the team members from a single data source.
Modern tools enable effective communication of project information through
existing user interfaces such as web browsers and email. Typical uses would be
to:
Make the detailed calculations concerning scheduling, costs and progress,

etc.
Publish progress information
Publish individuals' task details
Manage the workflow for submitting and handling changes, risks, and
issues
Enforce controls, for example in the "checking in" and "checking out" of
documentation
Put in place the project management people, processes and technology. Few
organisations get the most out of their programmes and projects. Intelligently
adapting a company's current approach to adopt the features of best-practice
114
management approaches can lead to considerable benefits. It will ensure your

objectives are realistic and will produce optimum benefit. It will seek to deliver
the goals with no surprise. It will ensure everything is done to optimise the
overall benefit to the organisation, despite changes to the business, changes in
the economy and the inevitable snags along the way. In these uncertain times
you need to be able to answer the following questions with assurance.
Do I have confidence in the timescales, costs and net benefits?
Do I understand all the risks to achieve that?
Am I certain this is the best investment we can make with our limited
resources?
Notes
Each project should have a proper definition, for example, objectives,

budget, performance measures, accountabilities and timescale. It should follow
well-defined project management processes, designed to ensure it stays on track
to deliver optimum benefit. To have any degree of confidence in the outcome
of a project you need to put in place the right people with the right combination
of skills. They should work with the best practice processes and tools to make
sure the project is properly defined and run. This needs to be in place before the
work starts.
To have any degree of confidence in the outcome of a project you need to
put in place the right people with the right combination of skills. They should
work with the best practice processes and tools to make sure the project is
properly defined and run. This needs to be in place before the work starts.
Activity t Activity 1
1..
1.
Make a list of the common success criteria for organisational structures.

Name the three types of project management offices with examples. }
5.4 RESPONSIBILITIES OF PROJECT MANAGER

The role of the project manager is one of great responsibility. It is the
project manager's job to direct, supervise and control the project from beginning
to end. Project managers should not carryout project work, managing the project
is enough. Here are some of the activities that must be undertaken:
1.
The project manager must define the project, reduce it to a set of manageable
tasks, obtain appropriate resources and build a team to perform the work.
2.
The project manager must set the final goal for the project and motivate
his/her team to complete the project on time.
3.
The project manager must inform all stakeholders of progress on a regular

basis.
4.
The project manager must assess and monitor risks to the project and
mitigate them.
Organising Projects
I
.- MI II
Notes
5.
No project ever goes exactly as planned, so project managers must learn

to adapt to and manage change.
Project manager must have a range of skills including:

Leadership
People management (customers, suppliers, functional managers
and project team)
Effective Communication (verbal and written)
Influencing
Negotiation
Conflict Management
Planning
Contract management
Estimating
Problem solving
Creative thinking
Time Management
"Project managers bear ultimate responsibility for making things happen.

Traditionally, they have carried out this role as mere implementers. To do their
jobs they needed to have basic administrative and technical competencies.
Today they play a far broader role. In addition to the traditional skills, they
need to have business skills, customer relations skills, and political skills.
Psychologically, they must be results-oriented self-starters with a high tolerance
for ambiguity, because little is clear-cut in today's tumultuous business
environment. Shortcomings in any of these areas can lead to project failure." J.
Davidson Frame.
The Project Manager is responsible for everything that is required to
make the project a success whether directly or indirectly. It is not like a typical
hierarchical line management role. The Project Manager is at the centre of
everything related to the project. Controlling the contributions of seniors and
peers is just as important as managing the work of the team.
116
The Project Manager needs to manage upwards - ensuring that the

inverted hierarchy comprising the organisation's leadership and the
project sponsors are doing all that is required to guarantee the success of
the project.
The Project Manager is also the main focal point for liaison with other
departments, projects and initiatives within the organisation, taking into
account the needs and contributions of other internal groups.
The Project Manager is equally the main point of contact for aspects
requiring co-operation and co-ordination with external parties such as
the project's suppliers and contractors, customers, suppliers, regulatory
bodies, and other third parties making sure everything is in place to
guarantee success.
The Project Manager has direct responsibility for the activities of all
project participants, all project tasks and all deliverables.
Notes
Leadership Team
Steering Group
\ Project Dilutor
ti Sponsors
Internal Liaison Project' ExtemalLialon
Line De part/news Manager Trading Pariners
Othe z Projec is
Suppliers
IT /
Contractors
Project Team
Participant s
Deliverables
Tasks
Fig. 5.4: Project Management Activities

The project manager's skills are essential from the beginning. The defined
approach and its business case will rely on a good understanding of the project
process along with reliable estimating and carefully considered planning.
The project manager's prime objective to deliver the results, there are
many supporting disciplines and processes. These should ensure that the project
will deliver a valuable result without surprises. The foremost need is to monitor
the anticipated level of benefits and make adjustments to deliver optimum
results. The leadership team should also actively identify and manage risks,
issues, changed requirements, quality standards, plus a host of other side issues.
Not all these processes follow the traditional development lifecycle. In
particular, it is wrong to consider the project has finished when the new system
goes live. That way you will never know whether it delivered the planned
benefits and you will probably not achieve them! Management attention must
be retained to deliver the benefits through to the Post-Implementation Review
(PIR) and beyond.
Organising Projects
-117
Notes
Project Concept & Delude n
Pito or Stagg
Mar"runt
Plannirg
'prxdig Mak. %sacs"

sim Oning Rstork
Projec t'
End
.
& Mugs&
001
11131
Bildiurvere
Ali
Sole & arm Ceti
Onionda Mowed
Cecueggis Cattel
Tam hi* abeam el Merl Coma do
Orgriatimpal Chug Hewed
tying Comisiall
Prg wood & howitirg
Sionateeir HIMIONSI
Fig.5.5: Project Management Framework

Here is a summary of the processes:
118
The concept, objectives, approach and justification of the project are

properly defined, agreed and communicated.
Management-level planning maps out an overall management plan from

which resources, acquisitions and sub-contracts can be identified, cost and
put in place. The business case will be re-assessed to ensure the original
assumptions and justification hold true. At this stage, many of the detailed
management processes will be defined and instigated.
A project will pass through several stages or phases, each with a different
objective and deliverable. Typically the phases will require different
skills, structures and resource levels. It is normal to plan, estimate and
resource each phase separately (albeit overlapping the preliminary work
to avoid stoppages).
Planned benefits will be assessed and monitored throughout the project.

Optimising benefit should be the prime goal of the project manager.
Quality requirements and approaches will be defined and agreed during

the project start-up. Typically, there will be rules that apply to the routine
work of the team plus specified quality audits at the end of the phases.
Risks will be assessed at the start of the project. Contingency plans and
avoiding action will be defined as appropriate. The risk management
process will pro-actively monitor risks throughout the project. Risk
assessments and plans will be modified as appropriate.
All participants will be encouraged to communicate potential issues for

resolution.
The issues management process will ensure they are considered and
addressed.
The scope of the project and specific changes to the solution will be
controlled through a management process with appropriate balances and
controls focused on achieving optimum overall benefit.
Versions of all deliverables will be controlled (whether temporary working

papers or permanent outputs) through a configuration management
process.
A documentation management process will ensure all information is

available to all those who require it, and is subject to careful control over
authorship, reviews and updates.
An effective team will be nurtured through appropriate initiation, training,

communications, and social events.
Organisational change issues will be assessed early in the project, leading

to a course of communications, events and other activities to ensure all
parties affected by the change are ready and willing to change.
The needs to communicate outside the team with other parts of the
organisation, customers, suppliers, and other parties will be assessed. A
course of communications will be defined and actioned.
Large projects inevitably require a process to handle expenditure on

subcontractors, equipment, software and facilities. Project accounting
will monitor and control expenditure both as a routine management
activity and as part of the overall focus on delivering optimum benefits.
Where sub-contractors are involved, there will be a management process

to agree and monitor contracts.
At the end of the project, there will be several activities to transition work,
processes and deliverables to line operation. The team also need to ensure
filing and documentation is in good order, leaving behind sufficient detail
for the operation of the system, audits concerning the project, and as a
baseline for future maintenance and development. People, equipment and
facilities need to be demobilised.
After the live solution has settled down, it is normal to organise a PostImplementation Review to measure the success of the project, to see what
further improvements can be made, and to learn lessons for the future.
Notes
The PM's actual role depends on the structure of his/her organisation,

which can be function-oriented, project-oriented, or some type of matrix in
between. In a heavily project-oriented organisation, the PM may have relatively
unlimited authority, answering only to upper management. At the other end of
the spectrum is an organisation that manages by function. The PM must deal
with functional managers as equals, or possibly even superiors, and negotiate for
Organising Projects
119
resources. Most organisations fall somewhere in between these two extremes.

Figure 5.6 depicts the level of PM authority associated with different types of
organisations.
1
Function
Oriented
Organization Type
Matrix
Project
Oriente
-------PM Authority
Fig. 5.6: Organisation Type and Project Management Authority

It is essential that the PM understands the organisation's structure and
knows the level of authority that goes with the job. It is also essential that upper
management grants authority and establishes an environment that will enable
the PM to successfully accomplish the project objectives.
PMs need both management and technical skills. The key management
skills are those needed to perform or direct project management activities,
which are listed in Table 5.1.
Table 5.1: Management Skills for Project Managers
),,
1E--151d11:
Integration
Management
011101111011bn
Coordinate project plan development. execute the plan, and manage the
change control process to ensue that all aspects of the project are
_ woildno together.
Establish project scope at the start. Develop and impiement plans and
Scope
procedures to verify that scope Is achieved and maintained. Define and
Management
oversee the process for controlling chances to the scope.
identify potential risks Mitigate large risks and plan how to deal with
Risk Management
smaller risks Monitor the project to detect and resolve problems.
Time and Schedule Estimate the duration of project activities. trie proper sequence of these
activities, and develop and control the project schedule.
Management
Estimate project costs and develop and control the project budget.
Cost and Budget
Management
..
Establish and control processes to ensure project goals are met to the
Quality
stakeholders' satisfaction. This includes quality planning. quality
Management
1 assurance. and quality control.
Define methods and lines of reporting and inforrnauon distnbution: Who
Communications
gets reports and project information? How often? What is the content?
Oversee procurement and delivery of materials, equipment, and services
Procurement
needed for the project This includes planning, solicitation, source
Management
selection. and contract administration.
Develop good leadership qualities Plan learn organization. obtain the
Human Resources
right people to staff the positions, and develop thew skills as Individuals
Management
and as a team.
Develop a systematic approach to project control integrating cost and
Earned Value
schedule control with performance control.
Management
The PM's technical skills should include at least some technical

understanding of the project field. Remember, however, the PM will not
typically be doing the technical work but will be directing the work that others
do. The essential level of PM expertise is the ability to understand what others
are doing, but not necessarily how they do their jobs.
Bear in mind that the Project Manager needs to achieve this without direct
control over the participants. The Project Manager will not have power over the
leadership, nor the internal and external contributors. Even in the project team
there may be loaned staff, part-timers and sub-contractors who will have their
prime loyalties elsewhere.
Notes

Fill in the blanks.
1.
To do their job, project managers need to have administrative and

competencies.
2.
has direct responsibility for the activities of all project

participants, all project tasks and all deliverqbles.
P41"
Activity 2
With examples list the main eight responsibilities of a construction project

manager.
5.5 PROJECT TEAMS

One of the newest organisational structures developed in the 20th
century is team. In small businesses, the team structure can define the entire
organisation. Teams can be both horizontal and vertical. While an organisation is
constituted as a set of people who synergise individual competencies to achieve
newer dimensions, the quality of organisational structure revolves around the
competencies of teams in totality. For example, every one of the Whole Foods
Market stores, the largest natural-foods grocer in the US developing a focused
strategy, is an autonomous profit centre composed of an average of 10 selfmanaged teams, while team leaders in each store and each region are also a
team. Larger bureaucratic organisations can benefit from the flexibility of teams
as well. Xerox, Motorola, and Daimler Chrysler are all among the companies
that actively use teams to perform tasks.
Effective project team performance is a critical success factor in
project management. This is especially true of strategic projects that require
collaborative efforts in ambiguous environment and with a goal of achieving
competitive results in a competitive marketplace.
Managing teams requires at least three stages. In the first stage teams are
selected, in the second stage the culture of the team is established and in the
third stage the culture is managed over the life cycle of the project.
Organising Projects
121
Notes
Stage I
Team membership is an important determinant of team performance. In
many cases it is possible to predict the outcome of a project, its possible success
or failure, from the group of people assigned to the team. Unless the team is
selected carefully and unless the leader is convinced that that team members
can do the job, project success may be jeopardized.
It is not necessarily true that all team members must be stars in their
own right. Many high performance teams are comprised of competent but not
necessarily outstanding team members. What makes the difference? Leadership!
Given the right leadership, a group of competent individuals can be developed
into a high-performing team.
Stage II
Stage II requires that a team culture must be established or if an appropriate
culture already exists, the culture must be reinforced. What is important is
that effective team culture cannot be assumed nor can the active process of
developed a team culture be ignored. An excellent example of this is the Boeing
777 team approach, which was established before the design project began and
communicated clearly to project team members. It was an open team culture
that encouraged constructive criticism and to a large extent it was this culture
that contributed to a very successful project outcome.
There are many ways to create a team culture. Consider the process of
spring training in professional baseball. In the US, teams start training in midFebruary and continue for about six weeks. Every day they work on individual
and team skills in preparation for the Major League season beginning in early
April. Wouldn't it be unthinkable for the Major League season to start without
spring training? Unthinkable for the team to meet for the first time moments
before the first game of the season
Yet most of our projects begin this way there is no period during which
we work with individuals and teams to build the kind of team culture capable of
achieving high performance results.
Perhaps we need spring training sessions before each project begins.
Stage III
The Boeing case example underscores the importance of deliberate team
management throughout the project. This is especially true when a new culture,
as was true in the Boeing case, was established. What we have learned is that it
is unlikely for a team to perform at its full potential without constant monitoring
and feedback. If left on its own team behavior may not be in the best interest of
the project.
Team selection
There are two variants of the team selection process. In the first variant,
there is little leeway in choosing team members because there may be few if
any choices. There may be, for example, a software design team that is routinely
122
used for a specific software project. Consider also a large joint project where
team members come from several organisations. It may not be possible to use
the same criterion when screening members.
In the second there may be considerable leeway in selecting members.
The project leader may have the option of interviewing several people to fill
each spot on the team.
Fiat Group in Italy, for example, maintains a database of employees, their
skill levels, training, evaluations, and availability. They have found this to be a
very effective way to assign team members to projects.
When there is choice in choosing team members, the process should
involve those who are positively predisposed toward the project and those who
have achieved a successful track record. But isn't this usually how selection
proceeds? No, not always. In some situations team members are chosen because
they or their supervisors may insist they be included. Sometimes including these
individuals may have a hidden agenda.
These issues, like many other management issues that need to be resolved
at the beginning of a project, are deferred in the hope that the issue will resolve
itself or go away.
Sometimes it does and sometimes it doesn't. One reason that issues of
team composition are resolved expeditiously is because the negotiation process
to solve them in another way takes time, and most leaders are anxious to get
busy with the project.
Network
Another modern structure is network. While business giants risk becoming
too clumsy to be proactive (such as), act and react efficiently, the new network
organisations contract out any business function that can be done better or more
cheaply. In essence, managers in network structures spend most of their time
coordinating and controlling external relations, usually by electronic means.
Some organisations are outsourcing its clothing to a network of 700 suppliers,
more than two-thirds of which are based in low-cost Asian countries. Not owning
any factories, H&M can be more flexible than many other retailers in lowering
its costs, which aligns with its low-cost strategy. The potential management
opportunities offered by recent advances in complex networks theory have been
demonstrated including applications to product design and development, and
innovation problem in markets and industries.
Virtual
A special form of borderless organisation is virtual. It works in a
network of external alliances, using the Internet. This means while the core
of the organisation can be small but still the company can operate globally
and be a market leader in its niche. According to Anderson, because of the
unlimited shelf space of the Web, the cost of reaching niche goods is falling
dramatically. Although none sell in huge numbers, there are so many niche
Organising Projects
Notes
Notes
products that collectively they make a significant profit, and that is what made
highly innovative Amazon.com so successful.
5.6 CONFLICT MANAGEMENT

Conflict in projects is inevitable. There will be conflict in developing
strategy, managing scope, planning for the project, execution of those plans, and
completing the project on time and within budget. There will be conflicts with
top management, with project leaders, between team members, with vendors,
and with customers or end-users.
We all know that not all conflict is bad. Conflict that forces us to reframe
a problem and take another view may improve the outcome or lower the risk
of failure. But there is also conflict that is dysfunctional and serves only to
sidetrack the team, waste time, cost money, and threaten group process.
Sometimes it is difficult, especially at the beginning of a conflict, to
determine whether it is functiOnal or dysfunctional. And placing the conflict in
one or the other of these categories depends upon the organisation. In closed
organisations where conflict is discouraged and group think is encouraged,
almost any conflict will be considered dysfunctional. In those organisations,
people are expected to go along to get along. At least this is the prevailing
philosophy on the surface. Beneath the surface, closed organisations create
their own time bombs.
In open organisations constructive or function conflict is encouraged.
Disagreement, challenges and questions become important ingredients to help
project managers make the decisions that are necessary to meet the tests of the
competitive market.
Of course, dysfunctional conflict, especially of a personal or aggressive
nature, is never welcomed in either open or closed organisations.
Nonetheless, a decision as to how the conflict is to be managed must be
made. If it is dysfunctional conflict, then boundaries must be established and
enforced. If it is functional conflict, then boundaries need to be reduced and
room created to consider the possibility that the problem needs to be reframed.
On several occasions, foam that had broken loose from the Challenger's
fuel tanks did little damage to the space vehicle. When engineers at NASA
expressed concern that the foam did present a hazard, they were overruled and
warned to keep quiet. Nothing was done. Management was under pressure to
complete a successful mission and they were unwilling to listen to anything
that would prevent this outcome. Had his conflict between engineers and
management been considered differently and the safety issue with regard to the
insulation reframed, the Columbia disaster may never have happened.
Since conflict is inevitable, two steps need to be undertaken. First, project
managers must show an ability to deal constructively with conflict and second
there must be a control mechanism to ensure that they are capable of putting
these skills to work.
1 24
Notes

1.
In open organisations, constructive or function conflict is discouraged.
2.
Conflict that forces us to reframe a problem and take another view

may improve the outcome or lower the risk of failure.
SCIM,
141Py
Summary
An organisational structure is mainly a hierarchical concept of

subordination of entities that collaborate and contribute to serve one
common aim.
Organisational structure allows the expressed allocation of responsibilities

for different functions and processes to different entities such as the
branch, department, workgroup and individual.
Common success criteria for organisational structures are decentralised

reporting, flat hierarchy, high transient speed, high transparency, low
residual mass, permanent monitoring, rapid response, shared reliability,
matrix hierarchy.
The functional organisation is a structure wherein authority rests with the

functional heads; the structure is sectioned by departmental groups. Staff
members are divided to groups according to their specialised knowledge.
The main advantage of this organisational structure is that each functional

group has complete control over its segment of the project, enforcing in
this way the application of standards across projects.
The disadvantages of the functional organisation are that of speed,

flexibility and communication when attempting crossfunctional
projects. Since in a functional organisation the work is divided between
the departments, any query or request must be passed among department
heads for approval, causing delays. In addition, the responsibility of
managing the project is shared among the functional managers (head of
the departments) and this may cause lack of ultimate responsibility for
project management.
Divisional structure, also called a "product structure" or "project structure",

groups each organisational function into divisions. Each division within
a divisional structure contains all the necessary resources and functions
within it. Divisions can be categorised from different points of view. There
can be made a distinction on geographical basis (a US division and an
EU division) or on product/service basis (different products for different
customers' households or companies). Each division would have its own
sales, engineering and marketing departments.
Organising Projects
125
In the projectised organisation or divisional structure, the focus is on teams

with cross-functional expertise. Most of the organisation's resources are
involved in project work; team's mission is to complete the project. All
team members working for a specific project have one clear superior, the
Project Manager and they all refer to him/her.
Matrix structure is a blend of functional and projectised organisations. In

the matrix structure, the personnel engaged in the project activities belong
to one or more functional units (departments). For project related issues
the project team members (staff) report to the Project Manager, who is
responsible for the timely completion of the project activities. For business
related issues the project team members report to the corresponding
functional managers. Once the implementation of the project or part of
their work has been completed, they are returned to the control of the
functional manager for reassignment.
The main advantage of the matrix organisation is that it retains the

benefits of both functional and projectised structures. It also facilitates
the effective resource allocation to different projects.
The main disadvantage of the matrix structure is the potential for conflict
between the project manager and the functional manager regarding the
resource assignment, since the functional manager has to staff multiple
projects with the same experts.
A project management office is a separate office considered for overall

administration of project. There are three basic types of Project
Management Office (PMO) organisations, varying in the degree of control
and influence they have on projects within the organisation. These are
Supportive PMO, Controlling PMO, and Directive PMO.
The best type is very specific to the organisation, culture, and history of what
works and what does not. But the objectives are more or less to implement
a common methodology, standardise terminology, introduce effective
repeatable project management processes, provide common supporting
tools and to improve levels of project success within the organisation.
The role of the project manager is one of great responsibility. It is the

project manager's job to direct, supervise and control the project from
the beginning to end. Project managers should not carry out project work,
managing the project is enough.
Conflict in projects , is inevitable. There will be conflict in developing

strategy, managing scope, planning for the project, execution of those
plans, and completing the project on time and within budget. There will
be conflicts with top management, with project leaders, between team
members, with vendors, and with customers or end-users.
Conflict that forces us to reframe a problem and take another view may
improve the outcome or lower the risk of failure. But there is also conflict
that is dysfunctional and serves only to sidetrack the team, waste time,
cost money, and threaten group process.
4Keywords
Notes
Organisational structure: A hierarchical concept of subordination of

entities that collaborate and contribute to serve one common aim.
Functional structure: A structure wherein authority rests with the

functional heads and the structure is sectioned by departmental groups.
Divisional structure: Also called a "product structure" or "project

structure", groups each organisational function into a divisions.
Matrix structure: A blend of functional and projectised organisations.
t S 7i.- -
"''roti
estios
1.
What is an organisational structure? What is the importance of proper

organisational structure for the success of a project?
2.
Explain the evolution of organisational structure.
3.
What is a functional organisation? How it is different from divisional

organisation?
4.
What is a matrix organisation? Explain the advantages and disadvantages

of matrix organisation.
5.
What are the responsibilities of a project manager? Explain in detail.
6.
What is a PMO? Explain the types of PMO.
7.
.What is a project team? Explain the importance of team for project

management.
8.
What are the reasons of conflict in projects? How can it be managed?

Fill in the blanks.
1.
To do their job, project managers need to have administrative and technical

competencies.
2.
Project manager has direct responsibility for the activities of all project
participants, all project tasks and all deliverables.

1.
False
2.
True
Organising Projects
127
Notes
r' Suggested Reading

1.
128
Project Planning
Structure: ow
6.1 Project Life Cycle
UNIT
6.2 Project Definition Phase

6.3 Project Planning Phase
6.4 Project Execution Phase
6.5 Project Closeout Phase
6.6 Project Planning and Control System
6.7 Statement of Work
6.8 Work Breakdown Structure
6.9 Responsibility Matrix
Summary
Key Words
Suggested Reading
Project Planning
129
Notes
Objectives
Describe the concept of project life cycle
Define a project defining
Explain the concepts of project planning, project execution, project

controlling and project closing
Analyse the concept of work breakdown structure
K..
Prepare the scope of work
6.1 PROJECT LIFE CYCLE

Projects, like products, have life cycles and are usually performed in
phases. Each phase accomplishes specific work towards reaching the project
goal and produces one or more deliverables. These are tangible, real items
used in attaining the final goal of the project, and could include plans, studies,
designs or software or hardware prototypes. The end of a phase is defined by
completing its deliverable.
Project Processes
The Program Management Institute defines five major process groups used
in projects: initiation, planning, executing, controlling, and closing. Processes
are sequences of activities that accomplish specific functions necessary to
complete or enable some portion of the project. These are not phases themselves
but can be found both in projects and in each major phase of a programme or
large project. Because the activities in later phases may require changes in the
products of earlier phases, these processes become iterative and often overlap
phases as well as each other. An example would be an issue in the execution
phase requiring a change to plans made in the planning phase. This overlap is
shown in Figure 6.1.
A
PlAnnV19
Activity
Closing
Tiovd
Fin sh
Fig. 6.1: Project Management Processes Overlap Initiation Process

The initiation process consists of formally validating or authorising the
project. It often includes some form of analysis such as a feasibility study, a
preliminary requirements study, a concept of operations, or a preliminary plan.
130
Planning Processes
Notes
Planning processes establish the scope or boundaries of the project. They

lay the foundation and define an expectation baseline. Future proposed changes
are evaluated against this baseline.
Executing Processes
The executing processes are those that direct or enable the actual work of
the project. They consist of the following:
Executing the project plan
Performing quality assurance activities
Performing procurement activities
Developing team and individual competencies
Communicating to team members and stakeholders
Controlling Processes
Controlling processes are ongoing throughout most of the project. They
include verifying that the project is proceeding according to plan or determining
where and how much a deviation is occurring. They are absolutely essential to
the progress and success of the project. They include the following:
Monitoring, measuring, and reporting the performance of prof ect activities
Verifying the project is continuing within scope
Controlling changes to the project scope
These processes are, in turn, enabled by these supporting processes:
Schedule control
Cost control
Quality control
Functional scope control
Risk monitoring and control
Earned value management techniques, if properly employed, have been

shown to be a worthwhile approach to indicate project status, progress, and
trends toward successful completion.
Closing Processes
The closing processes are accomplished following the completion of the
project objectives. Their purpose is to resolve any open issues, complete any
paperwork required for formal completion of the project, and gather information
useful for evaluating project performance for future reference. The first process
is contract closeout, where any remaining contract issues are settled. The other
process is administrative closure, where formal documents terminating the
project are generated, and an appropriate history of project performance and
lessons learned is gathered.
Project Planning
131
Notes _
Figure 6.2 illustrates an example of a very generic project life cycle with its
phases and major deliverables.
De fi n tio n )0(Project Rules
Nanning .:-0( Project Plan

Example
Project
Life Cycle
Executioniq Project Goal Complete)

cat
Closure-741
Close i4ForrnalProject
Review j
Time
a
Fig. 6.2: Example of a Generic Project Life Cycle

While major aspects of project management are applicable across
all projects, life cycles may vary depending on the type of project and the
organisation performing the work. It is important to implement an appropriate
life cycle for the product.
The phases identified in Figure 6.1 are common across most projects.
However, they may be called by different names or split into additional phases.
They may even be iterative where, for example, a prototype is designed, built,
and tested, then the results are used to design, build and test a new prototype.
Project phases should, in most cases, be comparable to the generic project
phases discussed in the following sections.
6.2 PROJECT DEFINITION PHASE

This phase begins when upper management creates a project charter that
defines the project's purpose and identifies the PM. The charter should also
include a statement of support authorising the PM to perform his/her functions.
During this phase, the project rules are defined. Both the PM and stakeholders
determine the project's goals, scope, and constraints. Key individuals and groups
are identified as members of the project core team, and their roles are defined
by both the PM and upper management. Upper management along with the PM
also defines communications channels, authority, and the chain of command.
These project rules are written in three documents: the project statement
of work (PSOW), the project responsibility matrix, and the project
communication plan. The PSOW establishes the scope of the project and
documents what is to be accomplished. For an internal project, the PSOW
becomes the primary requirements document. However, the PSOW is not
the same as a contract statement of work (SOW). For a project where much
of the work is contracted, the SOW is a binding, contractual agreement.
Notes
WO* Ph41s,
Determine goals, scope.
and project constraints.
11 Announces Project
- States Purpose
- Identifies Project Manager
I Stateraent of Support
1/4c."
ri--
Identify core team

members (Individuals and
groups) and their roles.
Responstiltty Matrix
Define communications
channels. methods,
frequency. and content.
Communications Plan
Fig. 6.3: Project Definition Phase

The proper definition of project has to take care of following aspects:
The project has specific goals to accomplish, and you understand the
reasoning behind them.
All stakeholders (interested parties) understand and agree on the expected

project outcomes.
Upper management is solidly behind the project.
You understand the level of authority you have been granted in relation
to the project and the rest of the organisation, and the level of authority is
appropriate.
You understand how the organisation operates, including how to get

things done within the organisation.
You understand what you are responsible for delivering at both a macro
and a micro level.
You know the high-priority risks your project faces.
Check your Progress I

Fill in the blanks.
1.
The
phase begins when upper management creates a
project charter that defines the project's purpose and identifies the
PM.
PSOW stands for
6.3 PROJECT PLANNING PHASE

Planning is defined as determination of all the activities which are to be
completed for completion of the project, establishing logical interdependence
between various activities and establishing a set of priorities for the
accomplishment of the project activities.
The planning phase uses the project rules as a foundation and defines
the path to achieve the project goals. It is performed by the PM and the core
Project Planning
Notes
project team, which interfaces with appropriate elements of the organisation,

and identifies the actual work to be done. It includes estimating schedule, cost
and resources required to perform the work, and produces plans to serve as a
baseline and direct the work. A key part of schedule planning is identifying the
critical path. This is the chain of interdependent, sequential project activities that
takes the longest time to complete, and thus determines the minimum schedule
for the project. Planning also includes risk identification and risk reduction
efforts. The results of the planning phase become the project plan.
Figure 6.4 shows the inputs, activities and products of the planning phase.
Note the feedback loop from the phase activities to the project rules. This
indicates that the rules may need to be modified after more detailed analysis in
this phase reveals deficiencies or inefficiencies in the rules. This illustrates the
iterative nature of project management. Remember, the project plan is fluid and
the PM should expect changes.
rigs and data:*
a 0100 10 MOW green
Identity the tasks required
to achieve protect goals
Estimate snort required.
Ealenanit required stoning
levels and speciinias.
Ea11110/ L WOW end
timing of malaisals and
orpiment
imolai
11117:
eadbuch
DPW task sequence.
estimate minimal schedule
and develop a schedule.
Estimate coals: labor,
materiels. laden* eic.
Develop a budget
Fig. 6.4: Project Planning Phase

Project management requires a perfect balance to be met. What must be
balanced here and throughout the project are schedule, cost, quality and scope.
Changes to the scope of the project will almost certainly affect at least one
of these, requiring changes in the others to achieve balance again. Likewise,
changes in one or more of these three constraints will require changes in the
others and/or changes to the scope or expectations of the project. This balance is
shown in Figure 6.5. Note that these do not necessarily define the project scope
but they do constrain it.
Fig. 6.5: Balancing Constraints within Project Scope

Again, a manager can control any three of these four constraints. For
example, if one chooses to control schedule, cost, and quality, the functional
capability of the product may have to be reduced. Likewise, if one attempts to
expand functional capability (i.e., requirements bloat) while maintaining cost
and quality, the schedule may have to be relaxed to maintain the balance.
Other planning processes include the following:
Define activities needed to perform the project.
Estimate activity duration.
Estimate a minimum schedule and develop a project schedule.
Conduct risk management.
Develop communications planning.
Conduct staff planning.
Develop organisation definition.
Sequence activities.
Conduct resource planning.
Estimate costs.
Develop a spending plan or budget.
Conduct quality planning.
Conduct procurement planning.
Develop a project plan.
Applying the previous information to a real project will depend on

several things. A PM assigned to an ongoing project has little control over how
the project is set up. In this case, the new PM will need to quickly learn the
following:
Project purpose and objectives.
Project phases and deliverables.
Project budget and current spending status.
Project schedule and current status.
Current problems and issues.
Major risks.
Project team organisation and contacts.
Project management processes in place or planned.
Life cycle of the product the project is supporting.
Communications that detail who gets what information and when.
Project Management Checklist

This checklist is provided to guide you in essential actions to ensure your
project is on track in meeting cost, schedule, and performance requirements.
If you cannot check an item off as affirmative, you need to either rectify the
Project Planning
Notes
I-
. uglesi "
"-- i
Elements
Objectives
Activities
Schedule
Budget
Organisation
Work methods (Procedure, Standards)
Once the Objective is defined, the points to be considered are:
Major elements of work required to satisfy the objective
How are these elements interrelated?
What are the schedules for completion?
What are the organisational resources available? Which functional

division will be responsible for the work elements?
What are the information flow and communication requirements between

the involved parties?
Development of resource costing and accounting methods.
Establishment of the management information and reporting system.

1.
Planning is defined as determination of all the activities which are to

be completed for completion of the project.
Planning excludes risk identification and risk reduction efforts.
6.4 PROJECT EXECUTION PHASE

With a project plan for guidance, the actual project work can begin in
earnest. This is the phase where project goals are achieved. While Figure 6.6
may make it look far simpler than the planning phase, the execution phase entails
directing the various work groups in their activities, monitoring their progress,
solving problems and resolving issues that will certainly come up, making
changes to the plan, and coordinating these changes. (These activities are part
of the executing and controlling processes discussed in the project processes
section.) If your planning has been done well, you will have a smoother ride
through this phase. This phase is complete when the product is complete, the
project goals are reached, or the project is terminated.
138
Notes
Ectiattoitfiftaitik.
Product or Goal
Execute project plan and

accomplish project goals.
LProjoct Plan
Feedback
Fig. 6.6: Project Execution Phase

During Project Execution we must check for:
What your project's expenditures are to date and any difference between
those and the budget?
The status of project activity completion along the critical path and any
difference between that and the schedule.
Any issues or problems with quality or performance that may impact the
critical path.
Any contract performance issues.

Fill in the blanks.
1.
2.
is the phase where project goals are achieved.

Project execution is relatively easier, if
has been done well.
6.5 PROJECT CLOSEOUT PHASE

The closeout phase begins with the delivery of the product or completion
of the project goals or project termination. It consists primarily of tying up
loose ends. Any unresolved issues from the contract or SOW are resolved in
this phase. The contract is signed off as fulfilled and all other paperwork is
completed.
A very important activity of this phase is assembling the project history.
This is a summary of all that has been accomplished. It should include
information that will allow either you or a follow-on PM to understand what
was done and why. Of particular importance is a compilation of lessons learned
from the project so either you or others in your organisation can,do things better
on the next project. Figure 6.7 summarises the closeout phase.
Project Planning
139
Notes
Closeout Phase
Product Is
delivered or
goals are met. ;
Resolve open Issues.
....
Stakeholders Satisfied
Complete contractual
obligations (contract
closeout).
Contract Closed
Assemble project history

and lessons learned.
Project History
Fig. 6.7: Project Closeout Phase

All project managers desire to bring their projects to a successful
conclusion. The typical success factors are meeting cost, schedule, and quality
objectives within the allotted scope while also meeting the associated customer
expectations. The standard practices to accomplish this desire have been
outlined in this article. They include the following: obtaining and maintaining
the necessary support from the project sponsor, supporting organisation and
customer employing an appropriate life cycle and breaking the project into
success- oriented phases, setting aside an appropriate amount of time to
understand the expectation of key stakeholders adequate planning to accomplish
key objectives and finally, executing the project plan while balancing the
naturally occurring changes with a companion control and tracking system.

Fill in the blanks.
1.
phase begins with the delivery of the product or

The
completion of the project goals or project termination.
2.
Avery important activity of project closeout phase is
6.6 PROJECT PLANNING AND CONTROL SYSTEM

One of the major reasons for project failure is the failure to monitor it
when it is being executed.
We have already seen that project management is substantially different
than the normal work management. The primary differentiating factor is the
diverse nature of activities and the fact that the project has a strong time pressure
on it. Also, there is a tremendous management focus on projects for obvious
reasons.
When you study the projects that failed, poor monitoring emerges as one
of the major reasons for such failure.
We have already studied what PDCA is all about. The process gives a
very simple process to monitor the progress of any activity that's spread over
140
time and has multiple activities rolled in it. This process can easily be used for
project monitoring also with very good results.
Notes
What is additionally available for project activity is the "Network" and

"CPM" process. These two processes clearly define the following things to a
lowest activity level in the form of WBS or the Work Breakdown Structure.
Clear activity details, including the scope, measurement for completion,

etc.
Time required for doing the activity
Other resources required for the activity Men, Machines, Money,

Materials, etc.
The relationship of the said activity with other activities in the project
Whether it lies on the critical path or not
Responsible person or function for the said activity
This database itself creates a very handy footprint for monitoring the
activities of the project.
If we apply the concept of PERT to the project (which anyway is
necessary), what we additionally get is the range of time limits for each activity
within which the same is to be completed. The range is defined by using the
probability method from statistics and is therefore pretty reliable. These time
estimate ranges could be also used to estimate the value ranges for other
resources of the project.
When we combine this with the database mentioned above, what we have
in hand is a clear complete database for monitoring the project from "Start to
Finish".
The Monitoring Process
A. The management process
Define the responsibility for monitoring the progress for each

activity.
Define the reporting relationship of the monitoring person within

the project organisation.
Define the monitoring and review process. Also define the review
calendar for each activity.
Define the reporting process two-way reporting, one for the team
and the other for the top management team.
Define the reporting format also for both ways.
Define the mechanism which will enable the project team to raise
the red flag to draw the attention of the people before it's too late.
Project Planning
141
Notes
B. Working process
Prepare/refer to a format for each activity that defines the activity as
mentioned above. This formatted document is a pre-requisite for CPM
process. As mentioned above, it clearly gives all the information for each
activity.
Project manager has to first ensure the availability of adequate

resources in time.
For every variable of the activity, define the permissible limits.
Ideal way is to use the activity format from CPM process as also the
network diagram which makes the variables relevant to the project
activity flow.
It also brings in a clear visual impact for monitoring process.
Transfer the data from monitoring responsibility matrix to each

activity on the network.
Here the review process starts taking the PDCA route and could be
made three pronged (Trishul)
First pointer looks at the part of the work that should have happened
at the time of review. The process checks whether same has been completed
within the planned parameters. If there are deviations, it takes.note of them and
analyses the reasons for deviations and the CAPA strategy for the deviations. It
also evaluates the impact of the deviations on overall project parameters and the
subsequent activities.
Second pointer tries to look at the activities that are already underway
or are planned for initiation in the immediate future. For the activities already
underway, it monitors the progress with respect to the plan and identifies for
additional needs (if any) to ensure the plan compliance. It also factors the inputs
coming from the first pointer for their possible effects on the activities on hand
and the necessary CAPA strategy. With the second pointer, we are actually
trying to be proactive so as to build the first pointer leanings into the working of
subsequent project activities.
Third pointer actually tries to look at the immediately succeeding
activities from the perspective of the experience from the first pointer. This is a
completely proactive step to build the learning into all subsequent activities.
Every time the review is made as per the calendar, all three activities are
carried out. With this approach, we achieve the continuity in the monitoring
process. With the second and third pointers we have already created a process
for monitoring the activities which were underway or were about to begin.
In the subsequent review process this data becomes the data base for review
and thus reduces the review efforts as well as eliminates many of the possible
failures.
A typical integrated planning, monitoring and control system for a
major project starts with development of master control network which forms
14.2
the base of overall planning and monitoring of the projects. Based on this
network, engineering schedule, tender schedule and procurement schedule
are finalised and based on these schedules overall construction schedule of
the project is formulated. This overall construction schedule is further broken
up into contractor's schedule, monthly construction programme, and weekly
programmes. Based on frequency of reviews, weekly progress report, monthly
progress report and exception report are formulated. Exception report forms the
basis for various action plan of the project.
Detailing:
(SoW, WBS)
Notes
Scheduling:
I PERT, CPM etc.
udgets
Feedback
Management
Decision making
Reports
(Time, cost,
Performance)
Tracking:
Time/Cost/
Performance
Fig.6.8: Project Life Cycle Analysis

1.
WBS stands for Work Breakdown System.
2.
A typical integrated planning, monitoring and control system for a

major project starts with development of master control network.
6.7 STATEMENT OF WORK

A Statement of Work (SOW) is a formal document that captures and
defines the work activities, deliverables and timeline a vendor will execute
against in performance of specified work for a customer. Detailed requirements
and pricing are usually included in the statement of work, along with standard
regulatory and governance terms and conditions.
There are many formats and styles of statement of work document
templates that have been specialised for the hardware or software solutions
being described in the request for proposal. Many companies create their own
customised version of SOWs for use within their industry or vertical that has
been either specialised or generalised to accommodate the typical request and
proposals they receive.
It is important to note that in most cases the statement of work being agreed
upon is a binding contract. Master service agreements or consultant/training
Project Planning
443
Notes
Requirements, Deliverables and Non-Goals

The next section in the scope statement should list the requirements of the
project. The requirements are objectives that must be met during the project,
and often they include significant milestones or goals. The objectives need
to be quantifiable and identified clearly. Any milestones or goals need to be
also clearly identified, as well as any non-goals. Non-goals are items that are
specifically not going to be addressed by the project, which helps to eliminate the
scope creep. By clearly identifying these as non-goals, the scope cannot include
them later on without going through a change management process. Ultimately,
many project managers track their milestones, goals, and/or deliverables using
a work breakdown structure.
The deliverables for a project need to be clearly identified within a scope
statement. If necessary, deliverables need to be tied to specific milestones in
the project schedule. The deliverables also need to be agreed upon by the major
stakeholders as well as the project owner. Deliverables may include any training
necessary for personnel at the culmination of the project. Or deliverables may
be a final product to be provided to the stakeholders. No matter what makes up
a project's deliverables, specific details regarding them are the golden rule. The
more clearly the deliverables are identified and specified, the less chance there
will be for scope creep to occur later on.
Cost estimates for the project should also be included in the scope
statement. This is an essential process of project planning, so the cost estimates
should be as accurate as possible. If the cost estimates are too low, the project
will go over budget, sometimes significantly so. If the cost estimates are too high,
resources that are allocated to the project, whether they are money, equipment
or people are unavailable for other projects and could negatively affect them.
So the more on track the cost estimates are, the more efficient and successful
the project will be. This can be a difficult task for the project manager to do, but
effective cost management is a critical success factor for projects.
Finalisation and Acceptance
The last significant section of a scope statement is the formal acceptance
signatures. Once the project manager has compiled all of the documentation
into a concise and clear statement, all the major stakeholders as well as the
project owner need to sign off on it. This is a very significant step and can
be a very useful tool in mitigating scope creep as well. A meeting should be
held where everyone can be provided a copy of the scope statement. At that
time, any discrepancies can be cleared up or last minute changes can be made.
Once everyone signs off on the scope statement, there should be agreement
between all parties and the project can begin. By having everyone sign the
scope statement, there is very little chance of surprises down the road. And
in the event that something does pop up, there is documentation of what was
agreed upon initially so that changes can be made if necessary. If anything does
change down the road and the scope does need to be increased for some reason,
signatures should be obtained from everyone once more.
Exhaustively detailed specifics, clear and concise language throughout,

and avoiding ambiguity are the keys to make a scope statement effective and
useful. It is also very beneficial to have all of this information documented in
one place even if the process of creating it is enormous. The task of creating a
scope statement can encompass a great deal of time for any project manager,
but the rewards usually include more successful projects and minimised scope
creep throughout. And this can be a highly desirable benefit, as scope creep is
often a significant cause of project failure. So document as much as possible,
as clearly as possible, and make sure everyone involved is aware of what is
expected. Through clear and concise documentation, a scope statement's
usefulness shines all the way to project success.
Activity
Notes
Activity 1
List down the contents of Statement of Work.
6.8 WORK BREAKDOWN STRUCTURE I

Work Breakdown Structure (WBS) in project management and systems
engineering, is a tool used to define and group a project's discrete work elements
(or tasks) in a way that helps organise and define the total work scope of the
project.
A work breakdown structure element may be a product, data, a service or
any combination. A WBS also provides the necessary framework for detailed
cost estimating and control along with providing guidance for schedule
development and control. Additionally, WBS is a dynamic tool and can be
revised and updated as needed by the project manager.
Aircraft
System
Level 1
Air
Vehicle
Training
Peculiar
Support
Equipment
Level 2
1
Receiver
Fire
Control
Communication
Equipment
Services
Depot Level 3
Fig. 6.9: Aircraft Management

The workbreakdown structure is atree structure, which shows a subdivision
of effort required to achieve an objective; for example a programme, project, and
contract. In a project or contract, the WBS is developed by starting with the end
objective and successively subdividing it into manageable components in terms
of size, duration, and responsibility (e.g., systems, subsystems, components,
Project Planning
11147
Notes
tasks, subtasks, and work packages) which include all steps necessary to achieve
the objective.
The work breakdown structure provides a common framework for the
natural development of the overall planning and control of a contract and is the
basis for dividing work into definable increments from which the statement of
work can be developed and technical, schedule, cost, and labour hour reporting
can be established.
A work breakdown structure permits summing of subordinate costs
for tasks, materials, etc., into their successively higher level "parent" tasks,
materials, etc. For each element of the work breakdown structure, a description
of the task to be performed is generated. This technique (sometimes called a
System Breakdown Structure) is used to define and organize the total scope of
a project.
The WBS is organised around the primary products of the project (or
planned outcomes) instead of the work needed to produce the products (planned
actions). Since the planned outcomes are the desired ends of the project, they
form a relatively stable set of categories in which the costs of the planned actions
needed to achieve them can be collected. A well-designed WBS makes it easy
to assign each project activity to one and only one terminal element of the
WBS. In addition to its function in cost accounting, the WBS also helps to map
requirements from one level of system specification to another, for example, a
requirements cross-reference inatrix mapping functional requirements to high
level or low level design documents.
WBS Design Principles
One of the most important Work Breakdown Structure design principles
is called the 100% Rule. It has been defined as follows:
The 100% Rule states that the WBS includes 100% of the work defined
by the project scope and captures all deliverables internal, external and interim
in terms of the work to be completed, including project management. The
100% rule is one of the most important principles guiding the development,
decomposition and evaluation' of the WBS. The rule applies at all levels within
the hierarchy the sum of the work at the "child" level must equal 100% of the
work represented by the "parent" and the WBS should not include any work
that falls outside the actual scope of the project, that is, it cannot include more
than 100% of the work. It is important to remember that the 100% rule also
applies to the activity level. The work represented by the activities in each work
package must add up to 100% of the work necessary to complete the work
package.
Mutually Exclusive Elements
In addition to the 100% Rule, it is important that there is no overlap
in scope definition between two elements of a work breakdown structure.
This ambiguity could result in duplicated work or miscommunications about
responsibility and authority. Likewise, such overlap is likely to cause confusion
regarding project cost accounting. If the WBS element names are ambiguous,
a WBS dictionary can help clarify the distinctions between WBS elements.
The WBS Dictionary describes each component of the WBS with milestones,
deliverables, activities, scope, and sometimes dates, resources, costs, quality.
Notes
Planned outcomes, non-planned actions

If the work breakdown structure designer attempts to capture any actionoriented details in the WBS, he/she will likely include either too many actions
or too few actions. Too many actions will exceed 100% of the parent's scope
and too few will fall short of 100% of the parent's scope. The best way to adhere
to the 100% rule is to define WBS elements in terms of outcomes or results. This
also ensures that the WBS is not overly prescriptive of methods, allowing for
greater ingenuity and creative thinking on the part of the project participants.
For new product development projects, the most common technique to ensure
an outcome-oriented WBS is to use a product breakdown structure. Featuredriven software projects may use a similar technique which is to employ a
feature breakdown structure. When a project provides professional services, a
common technique is to capture all planned deliverables to create a deliverableoriented WBS. Work breakdown structures that subdivide work by project
phases (e.g., Preliminary Design Phase, Critical Design Phase) must ensure
that phases are clearly separated by a deliverable also used in defining entry
and exit criteria (e.g., an approved Preliminary Design Review document, or an
approved Critical Design Review document).
Level of detail
A question to be answered in determining the duration of activities
necessary to produce a deliverable defined by the WBS is when to stop dividing
work into smaller elements. There are several heuristics or "rules of thumb"
used when determining the appropriate duration of an activity or group of
activities necessary to produce a specific deliverable defined by the WBS.
The first is the "80-hour rule" which means that no single activity or group
of activities to produce a single deliverable should be more than 80 hours
of effort.
The second rule of thumb is that no activity or series of activities should be

longer than a single reporting period. Thus, if the project team is reporting
progress monthly, then no single activity or series of activities should be
longer than one month long.
The last heuristic is "if it makes sense" rule. Applying this rule of thumb,
one can apply "common sense" when creating the duration of a single
activity or group of activities necessary to produce a deliverable defined
by the WBS.
A work package at the activity level is a task that:
Can be realistically and confidently estimated
Makes no sense practically to break down any further
Project Planning
149 .-
Notes
Can be completed in accordance with one of the heuristics defined above
Produces a deliverable which is measurable and
Forms a unique package of work which can be outsourced or contracted

out
WBS Coding Scheme

It is common for work breakdown structure elements to be numbered
sequentially to reveal the hierarchical structure. For example, 1.3.2 rear wheel
identifies this item as a Level 3 WBS element, since there are three numbers
separated by a decimal point. A coding scheme also helps WBS elements to be
recognised in any written context.
A practical example of the WBS coding scheme is:
1267.1 Systems Integration
1267.1.1 Requirements Definition
1267.1.2 Regulations
1267.1.3 Scheduling
1267.1.4 Monitoring & Control
1267.1.5 Procurement Management
1267.1.6 Closeout
1267.2 Design
1267.2.1 Conceptual Design
1267.2.2 Preliminary Design
1267.2.3 Final Design
Terminal Element
A terminal element is the lowest element (activity or deliverable) in a work
breakdown structure; it is not further subdivided. Terminal elements are the
items that are estimated in terms of resource requirements, budget and duration
linked by dependencies and scheduled. A terminal element is sometimes called
a work package, although the two terms are not synonymous.
Example
WBS LEVEL 3:
1. 8kyck
1.1 From. Set
1
11.11
.1.1 Fek.
Ebrastor
ki414
WBS LEVEL 2:
I. Maid*
1.1 Fraia. $ol
WBS LEVEL 1:
I. Mold* 1s
ucruk 641_
*Ude_
1.4 Orals. %Vim_
LS nide' trim _
1i1r4w11144_
t7 FIciect Sys
(16'
.$
1.1.4 Soot
1.2 Crank
1.3 141$.4.
1.11 Fred Vtrumi
1.32 Rw Wheel
1$
1.4 &akin Systm
6,
1.4 Shitii Systaln
100 \ lertsvit144
111 Co-440_
1.0.2 Design_
1./13 Portably.
1.14 Teeing
1.7 Proiest Ito
27
3
3
13
17
6
3
5
10
I/
100
150
The WBS construction technique employs the 100% rule during WBS
construction. The figure on the right shows a work breakdown structure
construction technique that demonstrates the 100% rule and the "progressive
elaboration" technique. At WBS level 1 it shows 100 units of work as the total
scope of a project to design and build a custom bicycle. At WBS level 2, the
100 units are divided into seven elements. The number of units allocated to
each element of work can be based on effort or cost it is not an estimate of task
duration.
Notes
The three largest elements of WBS level 2 are further subdivided at level
3. The two largest elements at Level 3 each represent only 17% of the total
scope of the project. These larger elements could be further subdivided using
the progressive elaboration technique.
WBS design can be supported by software (e,g., a spreadsheet) to allow
automatic rolling up of point values. Estimates of eff9rt or cost can be developed
through discussions among project team members. This collaborative technique
builds greater insight into scope definitions, underlying assumptions, and
consensus regarding the level of granularity required to manage the project.
Pitfalls and Misconceptions
A work breakdown structure is not an exhaustive list of work. It is instead
a comprehensive classification of project scope.
A WBS is neither a project plan, a schedule, nor a chronological listing.
It is considered poor practice to construct a project schedule (e.g., using project
management software) before designing a proper WBS. This would be similar
to scheduling the activities of home construction before completing the house
design. Without concentrating on planned outcomes, it is very difficult to follow
the 100% rule at all levels of the WBS hierarchy.
AWBS is not an organisational hierarchy. Some practitioners make the
mistake of creating a WBS that shadows the organisational chart. While it is
common for responsibility to be assigned to organisational elements, a WBS
that shadows the organisational structure is not descriptive of the project scope
and is not outcome-oriented.
WBS updates, other than progressive elaboratiOn of details, require formal
change control. This is another reason why a WBS should be outcome-oriented
and not be prescriptive of methods. Methods can, and do, change frequently, but
changes in planned outcomes require a higher degree of formality. If outcomes
and actions are blended, change control may be to rigid for actions and too
informal for outcomes. A WBS is not a logic model. Nor is it a strategy map.
:;',ctvity
Activity 2
Prepare a work breakdown structure to minimum three levels for making tea
starting from collecting the resources.
Project Planning
151
Notes
6.9 RESPONSIBILITY MATRIX

The written SOW is an effective tool for managing stakeholders and
their expectations. Developing SOW and responsibility matrix balances the
project based on high-level estimates of the cost, schedule, quality and resource
requirements.
Responsibility matrix lays out the major activities in the project and
precisely details the responsibilities of each stakeholder involved in a project.
It is an important project communication tool because all stakeholders can see
clearly whom to contact for each activity tool.
Steps involved in setting up a Responsibility Matrix
The four steps involved in setting up a responsibility matrix are:
1.
List the major activities of the project: Only the major project activities
should be listed. Detailed task assignments should be made in the project
plan. Because the responsibility matrix shows interaction between
organisations, it needs to emphasize the different roles required for each
task. In highlighting the roles of various stakeholders involved in the
project's major activities, the responsibility matrix should usually use
the same level of detail as the scope statement. On very large projects it
can be useful to develop multiple responsibility matrixes, with differing
levels of detail. These matrixes will define subprojects within the larger
project.
2.
List the stakeholder groups: Stakeholder groups are listed on the

horizontal axis of the responsibility matrix. Groups such as project team
and user council should be named rather than individual team members.
These individual team assignments are documented in the project plan.
It is appropriate, however, to put individual names on the responsibility
matrix whenever a single person will be making decisions or has complete
responsibility for a significant part of the project.
3.
Code the responsibility matrix: The codes indicate the involvement

level, authority role, and responsibility of each stakeholder. While there
are no limits to the codes that can be used, here are the most common ones:
E execution responsibility (this group will get the work done), C must
be consulted (this group must be consulted as the activity is performed;
the group's opinion counts, but it doesn't rule), I must be informed (this
group just wants to know what decisions are being made), A approval
authority (usually an individual; this person has the final word on decisions
or on acceptance of the work performed for each activity). Specifying
clearly these different levels of authority is especially useful when there
are different stakeholders who all want to provide requirements to the
project.
4.
Incorporate the responsibility matrix in the project rules: The

responsibility matrix becomes part of the project rules, which means that
once it is accepted, all changes must be approved by those who approved
the original version. The advantage to this change management process is
that the project manager is always left with a written document to refer to
in the event of a dispute.
Notes
Constructing 'process maps' is a method currently favoured by Project

Managers, e.g., "4-fields mapping" on a development flow chart:
#1 Team Members
#2 Phases
With start/end
Criteria.
# 4 Standards
Listed for each
task
An important technique in making the "map" is the breakdown of

the project into phases.
This is the skilled role of the planner, viz., to determine the nature
and objectives of each phase.
The use of 'check-points' between phases is an additional insurance

for the management/manager towards monitoring progress;
importantly, management does not have to wait till the end to find
out that there is a fundamental problem!
This basic arrangement is called the "stage-gate" system:

I Concept
The "stage-gate" system:
It involves decisions being made actively at each milestone, denoted by

the "end" of each phase to move to the "start" of the next defined a
priori, which is not time dependant;
Calling a halt to activities can save future expenditure including rework

and must be enforced when:
The majority of benefits have already been achieved.
Initial plans and estimates have turned out to be wildly inaccurate.
New, more attractive alternatives emerge.
Organisational strategy shifts and the project outcome ceases to be

in line with the changed strategy.
Key persons (decision-makers) leave the organization.
Project requires higher capability than what is available.
Project Planning
153
Notes
154
Summary
Projects, like products, have life cycles and are usually performed in
phases. Each phase accomplishes specific work toward reaching the
project goal and produces one or more deliverables. These are tangible,
real items used in attaining the final goal of the project, and could include
plans, studies, designs, or software or hardware prototypes. The end of a
phase is defined by completing its deliverable.
The Program Management Institute defines five major process groups

used in projects: initiation, planning, executing, controlling, and closing.
Processes are sequences of activities that accomplish specific functions
necessary to complete or enable some portion of the project.
The project definition phase begins when upper management creates a

project charter that defines the project's purpose and identifies the PM.
The charter should also include a statement of support authorising the
PM to perform his/her functions. During this phase, the project rules are
defined. Both the PM and stakeholders determine the project's goals,
scope, and constraints.' Key individuals and groups are identified as
members of the project core team, and their roles are defined by both the
PM and upper management. Upper management along with the PM also
defines communications channels, authority, and the chain of command.
Planning is defined as, determination of all the activities which are

to be completed for completion of the project, establishing logical
interdependence between various activities and establishing a set of
priorities for the accomplishment of the project activities.
The planning phase uses the project rules as a foundation and defines
the path to achieve the project goals. It is performed by the PM and
the core project team, which interfaces with appropriate elements of
the organisation, and identifies the actual work to be done. It includes
estimating schedule, cost, and resources required to perform the work,
and produces plans to serve as a baseline and direct the work. A key part
of schedule planning is :identifying the critical path. This is the chain of
interdependent, sequential project activities that takes the longest time
to complete, and thus determines the minimum schedule for the project.
Planning also includes risk identification and risk reduction efforts. The
results of the planning phase become the project plan.
Project Execution Phase is the phase where project goals are achieved.
The execution phase entails directing the various work groups in their
activities, monitoring their progress, solving problems and resolving
issues that will certainly come up, making changes to the plan, and
coordinating these changes. This phase is complete when the product is
complete, the project goals are reached, or the project is terminated.
Project Closeout Phase begins with the delivery of the product or

completion of the project goals or project termination. It consists primarily
of tying up loose ends. Any unresolved issues from the contract or SOW
are resolved in this phase. The contract is signed off as fulfilled and all
other paperwork is completed. A very important activity of this phase
is assembling the project history. This is a summary of all that has been
accomplished.
One of the major reasons for project failure is the failure to monitor it
when it is being executed. We have already seen that project management
is substantially different than the normal work management. The primary
differentiating factor is the diverse nature of activities and the fact that
the project has a strong time pressure on it. Also, there is a tremendous
management focus on projects for obvious reasons.
A Statement of Work (SOW) is a formal document that captures and

defines the work activities, deliverables and timeline a vendor will
execute against in performance of specified work for a customer. Detailed
requirements and pricing are usually included in the statement of work,
along with standard regulatory and governance terms and conditions.
Work Breakdown Structure (WBS) in project management and systems

engineering, is a tool used to define and group a project's discrete work
elements (or tasks) in a way that helps organise and define the total work
scope of the project.
A work breakdown structure element may be a product, data, a service,

or any combination. A WBS also provides the necessary framework for
detailed cost estimating and control along with providing guidance for
schedule development and control. Additionally, WBS is a dynamic tool
and can be revised and updated as needed by the project manager.
Responsibility matrix lays out the major activities in the project and
precisely details the responsibilities of each stakeholder involved in
a project. It is an important project communication tool because all
stakeholders can see clearly who to contact for each activity.
Notes
Keywords
Initiation process: The initiation process consists of formally validating

or authorisng the project.
Planning processes: A process that establishes the scope or boundaries

of the project.
Executing processes: The executing processes are those that direct or

enable the actual work of the project.
Statement of work: A formal document that captures and defines the

work activities, deliverables and timeline a vendor will execute against in
performance of specified work for a customer.
Work breakdown structure: A tool used to define and group a project's

discrete work elements (or tasks) in a way that helps organise and define
the total work scope of the project.
Project Planning
.155
Ill Self-Assessment Questions

What is project life cycle? What are the important processes in project life
cycle?
2.
What is project definition? Explain the relevance and importance of

project definition,
3.
What is project planning? Explain the important features of project

planning.
4.
Explain the concept of overlap of project processes and its relevance in

project management.
5.
What is project execution? What are the contents of project execution?
6.
What is project controlling? How is project control applied for project

management?
7.
What is statement of work? What are its contents?
8.
What is work breakdown structure? How is it prepared?
9.
What is responsibility matrix? Explain its importance for proper project

controlling.
10. Explain the use of 4-fields mapping.

Fill in the blanks.
1.
The project definition phase begins when upper management creates a

project charter that defines the project's purpose and identifies the PM.
2.
PSOW stands for Project Statement of Work.

1.
True
2.
False

Fill in the blanks.
.156
1.
Project execution is the phase where project goals are achieved.
2.
Project execution is relatively easier, if planning has been done well,
Notes
Fill in the blanks.

1.
The project closeout phase begins with the delivery of the product or
completion of the project goals or project termination.
2.
A very important activity of project closeout phase is assembling the

project history.

I.
False
2.
True
() Suggested Reading
1.

McGraw-Hill.
Project Planning
157
Notes
--- , -------
158
UNIT
Structure:
7.1 Project Scheduling
7.2 Project Networks
7.3 Critical Path Method
7.4 Critical Path Calculations
7.5 Project Floats
7.6 Program Evaluation and Review Technique (PERT)
Summary
Key Words
Suggested Reading
159
Notes
Objectives
Create network diagram
Evaluate network diagrams
Find critical path using Critical Path Method
Find floats for network diagrams
Estimate time using PERT

J
7.1 PROJECT SCHEDULING I

The project contains many activities. Every activity consumes resources,
i.e., men, material, money and time. These activities also have a dependency
type of relationship with the other activities in the project. The completion
of the project is dependent on completion of all these defined activities. It is
therefore absolutely necessary that the PM prepares the time plan for each
of such activities. It helps to define the total work content in the project. It
also helps to define the requirement of total resources (of all kinds) for project
completion. This process is called as project scheduling process.
The scheduling activity starts by first listing all the activities in a structured
manner. Bar chart is one of the simplest methods to capture all the activities in
a graphical manner. It uses 2 axis method The X axis is used to indicate the
time required for each activity and the Y axis indicates the various activities.
Activity A
Activity B
Activity C
i
Activity D
Days
This way the PM can draw up all the activities in a structured manner so
as to capture everything. This chart is known as Gantt chart, named after the
person who first used it for project scheduling work.
A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt
charts illustrate the start and finish dates of the terminal elements and summary
PIM
elements of a project. Terminal elements and summary elements comprise the

work breakdown structure of the project. Some Gantt charts also show the
dependency (i.e. precedence network) relationships between activities. Gantt
charts can be used to show current schedule status using percent complete
shadings and a vertical "TODAY" line as shown here.
Notes
Although now regarded as a common charting technique, Gantt charts

were considered revolutionary when they were introduced. In recognition of
Henry Gantt's contributions, the Henry Laurence Gantt Medal is awarded for
distinguished achievement in management and in community service. This chart
is used also in information technology to represent data that have been collected.
In the simplest form what the Gantt chart captures is only the time required
for each activity. It does not capture the need of other resources. Also, it does not
necessarily define the dependency of the activities on each other. This process
is adequate for small and simple projects having less no. of activities and where
the span of the project is comparatively of small size.
As an improvement over this process, some dependency logic could be
built into the chart by positioning the activities on X axis to denote the preceding
or proceeding relation of the defined activities.
A
Activity A
Activity B
Activity C
Activity D
The above diagram shows the dependency of activity C on activity A

completion and activity D on activity C completion. This is achieved graphically by
displacing the bar for such activities suitably positioned to define the relationship.
Yet another variation adds another bar next to the activity bar to indicate
the actual data of the activity start and completion. This is called Program
Progress Chart.
161
Notes

All these processes help manage simple straight and other simple forms
of projects which are linear in nature, have few independent activities and also
have smaller time and cost outlays.
WEEKS: 1 2 3 4 5 6 7 8 9 10 11 12 13
WBS 1 Summary Element 1 IIMMIMIIIN 57% complete

WBS 1.1 Activity A
WBS 1.2 Activity B
75% complete
START-TO-START
WBS 1.3 Activity C
67% complete:
FINISH-TO-START
50% complete
FINI81-140FINISH4,
J0% complete
WBS 1.4 Activity D
WBS 2 Summary Element 2

WBS 2.1 Activity E
WBS 2.2 Activity F
111
1111 0% complete
0%
C clple
te
0% complete
0% complete
WBS 2.3 Activity G

TODAY
Features of Gantt Chart
Gantt chart helps to plan how long a project should take.
A Gantt chart lays out the order in which the tasks need to be carried out.
Early Gantt charts did not show dependencies between tasks but modern
Gantt chart software provides this capability.
A Gantt chart lets you see immediately what should have been achieved
at any point in time.
A Gantt chart lets you see how remedial action may bring the project back
on course.
Most Gantt charts include "milestones" which are technically not available
on Gantt charts. However, for representing deadlines and other significant
events, it is very useful to include this feature on a Gantt chart.
Gantt charts have become a common technique for representing the

phases and activities of a project Work Breakdown Structure (WBS), so they
can be understood by a wide audience.
A common error made by those who equate Gantt chart design with project
design is that they attempt to define the project work breakdown structure at
the same time that they define schedule activities. This practice makes it very
difficult to follow the 100% rule. Instead the WBS should be fully defined to
follow the 100% rule, and then the project schedule can be designed.
Although a Gantt chart is useful and valuable for small projects that fit
on a single sheet or screen, they can become quite unwieldy for projects with
162
more than about 30 activities. Larger Gantt charts may not be suitable for most
computer displays. A related criticism is that Gantt charts communicate relatively
little information per unit area of display. That is, projects are often considerably
more complex than can be communicated effectively with a Gantt chart.
Notes
Gantt charts only represent part of the triple constraints (cost, time and
scope) of projects, because they focus primarily on schedule management.
Moreover, Gantt charts do not represent the size of a project or the relative size
of work elements, therefore the magnitude of a behind-schedule condition is
easily miscommunicated. If two projects are the same number of days behind
schedule, the larger project has a larger impact on resource utilization, yet the
Gantt does not represent this difference.
Although project management software can show schedule dependencies
as lines between activities, displaying a large number of dependencies may
result in a cluttered or unreadable chart.
Because the horizontal bars of a Gantt chart have a fixed height, they can
misrepresent the time-phased workload (resource requirements) of a project,
which may cause confusion especially in large projects. In the example shown
here, Activities E and G appear to be the same size, but in reality they may be
orders of different magnitude different. A related criticism is that all the activities
of a Gantt chart show planned workload as constant. In practice, many activities
(especially summary elements) have front-loaded or back- loaded work plans,
so a Gantt chart with percent-complete shading may actually miscommunicate
the true schedule performance status.
7.2 NETWORK DIAGRAMS

Project planning is a part of project management, which relates to the
use of schedules such as Gantt charts to plan and subsequently report progress
within the project environment.
Initially, the project scope is defined and the appropriate methods for
completing the project are determined. Following this step, the durations for
the various tasks necessary to complete the work are listed and grouped into a
work breakdown structure. The logical dependencies between tasks are defined
using an activity network diagram that enables identification of the critical path.
Float or slack time in the schedule can be calculated using project management
software. Then the necessary resources can be estimated and costs for each
activity can be allocated to each resource, giving the total project cost. At this
stage, the project plan may be optimised to achieve the appropriate balance
between resource usage and project duration to comply with the project
objectives. Once established and agreed, the plan becomes what is known as
the baseline. Progress will be measured against the baseline throughout the life
of the project. Analysing progress compared to the baseline is known as earned
value management.
The inputs of the project planning phase inclnde Project Charter and the
Concept Proposal. The outputs of the Project Planning phase include the Project
163
Notes
Requirements, the Project Schedule, and the Project Management Plan.

Project network is a graph (flow chart) depicting the sequence in which a
project's terminal elements are to be completed by showing terminal elements
and their product breakdown structure show the "part-whole" relations. In
contrast, the project network shows the "before-after" relations.
The most popular form of project network is activity on node, the other
one is activity on arrow. The condition for a valid project network is that it
doesn't contain any circular references.
Project dependencies can also be depicted by a predecessor table. Although
such a form is very inconvenient for human analysis, project management
software often offers such a view for data entry.
An alternative way of showing and analysing the sequence of project
work is the design structure matrix.
For complex projects the most commonly used process is the "Networking
process." This was developed in 1957 by planners of DuPont and Remington
Rand companies. The process is known as Critical Path Method or simply CPM.
Another method was developed in 1958 by US Navy and is known as Program
Evaluation and Review Techniques or simply PERT.
For both the methods, it is necessary to define every activity of the project
in specific way and assign the resources needed for the same. It is also necessary
to define the dependency relationship of each activity before we embark on the
project plan. Dependency clearly specifies as to when the particular activity can
start With respect to other activities (before or after them).
Preparing Network
Every activity is denoted by 2 circles and an arrow. Every circle is called
as event or node.
Each event in itself just denotes either start or completion of some activity.
Event in itself does not contain anything and does not therefore need any
resources.
Actual activity is denoted by an arrow.
20
The first circle denotes the first event which is the start of activity A.
The second circle denotes the completion of activity A after 20 time units.
The arrows and so the flow of the activities' chart always goes from left to right.
1.
The activities which could be started simultaneously are called concurrent

activities.
2.
Any activity that occurs before the given activity is called as preceding
activity.
3.
Any activity that occurs after the given activity is called as succeeding
activity.
4.
Any imaginary activity is called as dummy activity. It is not a real one

and therefore does not need any resources. It is denoted by a dotted
line. Dummy activities are normally required to be created to ensure the
conformance to all the dependency rules.
5.
The crisscrossing of the lines is to be avoided while drawing the network.
6.
Closed loops within the network are normally avoided by following the
relationships and dependencies carefully and with the use of dummy activity.
7.
Dummy activities are used only when it's an absolute must for dependency
conformance.
Notes
There are different methods depending upon format of the network used.
There are two types of networks: Activity-On-Node (AON) and Activity-onArrow (AOA). Results are same in both the cases.
Arrow Diagram
The arrow diagram shows the required order of tasks in a project or
process, the best schedule for the entire project, and potential scheduling and
resource problems and their solutions.
Difference between AOA and AON
Method for constructing a unique AOA net with a node for each precedence
constraint of its corresponding AON network (yielding small number of dummy
arcs).
AON
A new format used by the project management software.
Better at showing different types of dependencies.
Easy to understand. Can be constructed through placing cards each with

name of an activity. Good for group discussion.
Following diagram indicates the example of activity on arrow:
165
AOA
Nodes or circles are the starting and ending points of activities.
Activities are represented by arrows showing relationships between

activities.
Sometimes, dummy activities (dotted lines) are used for linking two
activities.
Can only show finish-to-start dependencies.
Following diagram indicates the example of activity on node:
Air
WV
AIL
MIL
Situations in network diagram Given below are the situations which indicate
the construction possibilities of a network diagram.
a.
A must finish before either B or C can start
A
C
b. Both A and B must finish before C can start
B
c.
Both A and C must finish before either of B or D can start. A must

finish before B can start
A
N,Dummy
4
C
CSC
-11111-0
Notes
Lay foundation
Lay
foundation
*. Dummy
1
Order material
(a) Incorrect precedence

relationship
Order material
(b) Correct precedence
relationship
Concurrent Activities
Network example
Illustration of network analysis of a minor redesign of a product and its
associated packaging.
Activity
number
1
2
3
4
5
6
7
8
9
10
11
Completion
time (weeks)
6
Redesign product
2
Redesign packaging
.
3
Order and receive components for redesigned product
2
Order and receive material for redesigned packaging
4
Assemble products
1
Hake up packaging
1
Package redesigned product
6
Test market redesigned product
S
Revise redesigned product
1
Revise redesigned packaging
1
Present results to the Board
For clarity, this list is kept to a minimum by specifying only immediate

relationships,that is relationships involving activities that "occur near to each
other in time".
Activity
number
must be finished before
1
2
3
4
5,6
7
8
8
9,10
Activity
number
can start
3
4
6
7
a
9
10
11
167
Notes MI
The relevant network is given below.

1(6)
7(1)
0IWO 10'0
6(1)
4(2)
2(2)

Fill in the blanks.
A Gantt chart is a type of
schedule.
1.
that illustrates a project
is a useful feature for representing deadlines and other

significant events on a Gantt chart.
1.
Critical Path Method (CPM) was developed in 1958 by US Navy.
2.
The inputs of the project planning phase include Project Charter and
the Concept Proposal.
muvo Activity 1
Select any project and prepare a Gantt chart for the same.
7.3 CRITICAL PATH METHOD

As with Gantt Charts, Critical Path Analysis (CPA) or the Critical Path
Method (CPM) helps you to plan all the tasks that must be completed as part
of a project. They act as the basis both for preparation of a schedule, and of
resource planning. During management of a project, they allow you to monitor
achievement of project goals. They help you to see where remedial action needs
to be taken to get a project back on course.
Within a project it is likely that you will display your final project plan as
a Gantt Chart (using Microsoft Project or other software for projects of medium
complexity or an excel spreadsheet for projects of low complexity).The benefit
168
of using CPA within the planning process is to help you develop and test your
plan to ensure that it is robust. Critical Path Analysis formally identifies tasks
which must be completed on time for the whole projdct to be completed on time.
It also identifies which tasks can be delayed if resource needs to be reallocated
to catch up on missed or overrunning tasks. The disadvantage of CPA, if you use
it as the technique by which your project plans are communicated and managed
against, is that the relation of tasks to time is not as immediately obvious as with
Gantt charts. This can make them more difficult to understand.
Notes
A further benefit of Critical Path Analysis is that it helps you to identify

the minimum length of the time needed to complete a project. Where you need
to run an accelerated project, it helps you to identify which project steps you
should accelerate to complete the project within the available time.
As with Gantt charts, the essential concept beiind Critical Path Analysis
is that you cannot start some activities until others are finished. These activities
need to be completed in a sequence, with each stage being more-or-less
completed before the next stage can begin. These are 'sequential' activities.
Other activities are not dependent on completion of any other tasks. You
can do these at any time before or after a particular stage is reached. These are
non-dependent or 'parallel' tasks.
Drawing a Critical Path Analysis Chart
Use the following steps to draw a CPA Chart:
Stepl: List all activities in the plan. For each activity, show the earliest start
date, estimated length of time it will take, and whether it is parallel or sequential.
If tasks are sequential, show which stage they depend on.
For the project example used here, you will end up with the same task list as
explained in the section on Gantt charts (we will use the same example as with
Gantt charts to compare the two techniques).
Table 7.1: Task List: Planning a Custom-Written Computer Project
Task
High level analysis
A.
Selection of hardware
B.
platform
C.
Installation and
commissioning of
hardware
D.
Detailed analysis of core
modules
Detailed analysis of
E.
supporting modules
F.
Programming of core
modules
G. Programming of
supporting modules
Earliest start
Week 0
Length
1 week
Type
Sequential
Dependent
on
Week 1
1 day
Sequential
Week 1.2
2 weeks Parallel
,
Week 1
2 weeks Sequential
Week 3
2 weeks Sequential
Week 3
2 weeks Sequential
Week 5
3 weeks Sequential
169
Notes
..... . . ,::-
Task
H. Quality assurance of
core modules
I.
Quality assurance of
supporting modules
Core module training
J.
Development and QA of
K.
accounting reporting
Development and
L.
QA of management
reporting
M. Development
of Management
Information System
Detailed training
N.
Earliest start
Week 5
Length
1 week
Type
Sequential
Dependent
F
Week 8
1 week
Sequential
Week 6
Week 5
1 day
1 week
Parallel
Parallel
C,H
E
Week 5
1 week
Parallel
Week 6
1 week
Sequential
Week 9
1 week
Sequential
I, J, K, M
Step 2 Plot the activities as a circle and arrow diagram. Critical Path Analyses
are presented using circle and arrow diagrams.
In these, circles show events within the project, such as the start and finish
of tasks. The number shown in the left-hand half of the circle allows you to
identify each one easily. Circles are sometimes known as nodes.
An arrow running between two event circles shows the activity needed
to complete that task. A description of the task is written underneath the arrow.
The length of the task is shown above it. By convention, all arrows run left to
right. Arrows are also sometimes called arcs.
An example of a very simple diagram is shown below:
Figure 2: Simple Circle and Arrow Diagram
I Week
-4 2
High- Level Analysrs
This shows the start event (circle 1), and the completion of the 'High
Level Analysis' task (circle 2). The arrow between them shows the activity of
carrying out the High Level Analysis. This activity should take 1 week.
Where one activity cannot start until another has been completed, we
start the arrow for the dependent activity at the completion event circle of the
previous activity. An example of this is shown below.
Figure 3: Circle and Arrow Diagram showing two activities that cannot be
started until the first activity has been completed.
1 Week
High Level Analysis.
Ftr
2 Weeks
(3
Core Module Anolviu
Here the activities of 'Select Hardware' and 'Core Module Analysis'

cannot be started until 'High Level Analysis' has been completed. This diagram
also brings out a number of other important points:
Within Critical Path Analysis, we refer to activities by the numbers in the

circles at each end. For example, the task 'Core Module Analysis' would
be called activity 2 to 3. 'Select Hardware' would be activity 2 to 9.
Activities are not drawn to scale. In the diagram above, activities are
1-week long, 2-week long and 1-day long. Arrows in this case are all the
same length.
In the example above, you can see a second number in the top, right- hand
quadrant of each circle. This shows the earliest start time for the following
activity. It is conventional to start at 0. Here units are whole weeks.
A different case is shown below:
Notes
Figure 4: Circle and Arrow Diagram showing on activity (6 to 7) that cannot

start until other activities (11 to 6, 5 to 6, 4 to 6, and 8 to 6) have been completed.
figure 4: Circle and Arrow Diagram snowrng an activity 16 to ,f)
that cannot start unit other aclivities ll 1 to 6. 5 to 6, 4 to 6. and 8 to 6;
hove been completed,
1 Week
supporting
(DOA atmodules
1 Week
Detailed Training
yoo 0
,046 too
0,64:004
it/ 4-
8vP
Here activities 6 to 7 cannot start until the other four activities (11 to 6, 5
to 6, 4 to 6, and 8 to 6) have been completed.

Fill in the blanks.
1.
helps to identify the minimum length of the time:

needed to complete a project.
171
Notes
7.4 CRITICAL PATH CALCULATIONS

Critical path method is used to find the path which is most critical and
needs focus on priority. For finding this path the steps are given below but,
before the steps can be understood, the nomenclatures for this path must be
understood clearly which are given below:
Path: A connected sequence of activities leading from the starting event

to the ending event.
Critical Path: The longest path (time) determines the project duration.
Critical Activities: All of the activities that make up the critical path.
Earliest Start Time (ES): Earliest time an activity can start ES =

maximum Earliest Finish time of immediate predecessors.
Earliest finish time (Ey): Earliest time an activity can finish = earliest
start time plus activity time.
EF= ES + t
Latest Start Time (LS): Latest time an activity can start without delaying
critical path time
LS= LF - t
Latest finish time (LF):, Latest time an activity can be completed without
delaying critical path time.
LS = minimum LS of immediate predecessors
Example for finding critical path

Following table gives the details of activities of a certain project. Let us
draw a diagram for the same and find the critical path for the same.
a
c''de
Preceding
Activity
Duration (Days) 6
d, e h, i, j
13
15
17 19
12
Activity
Figure 1 represents the network diagram for the project activities as per above.
o917
h,0
0 Dpo
Figure 2 below shows calculation of duration for activities a, b and c. The square
indicates earliest start time and earliest finish time.
Notes
Notes
Figure 3 indicates time durations for all the activities in the project.
Project's EF = 33
The network has four paths which are:

a f h The total duration is 6 + 15 + 9 = 30 Days
a g i The total duration is 6 + 17 + 6 = 29 Days
b d j The total duration is 8 + 13 + 12 = 33 Days
c e j The total duration is 5 + 9 + 12 = 26 Days
Since the path, b, d, j is having maximum duration of 33 . days, it becomes the
critical path. Figure 4 indicates the critical path shown with thick dashed line.
:3
I
I b
b, 8
d, 13
IP
t
1)
j, 12 "If
Properties of critical path

1.
This is the longest path reaching the goal.
2.
It can still have dummy activities on it.
3.
It is not necessary that the critical path has maximum number of activities
on it.
4.
There can be more than one critical path for tbe same project.
5.
Any impact on any activity lying on critical path directly affects the
project completion immediately.
6.
The PM should focus on all activities on critical path as the first priority
to ensure compliance to schedules.
7.
Activities that lie on critical path are called critical activities. The total
project duration cannot be less than the total time required for completing
the critical path activities.
Notes
7.5 PROJECT FLOATS

A float shows time available for delaying an activity without delaying
Finish Date of the Project. In other words, delay in some activity would not
increase the project duration. Please note that Critical Activities cannot be
delayed. However, Non-Critical Activities can start late or finish late within the
given limitation. Other names for float are: slack, cushion, margin, excess time
or flexibility. Float is of three types:
INDEPENDENT FLOAT (IF)
Shows the time available even if an activity' has a late start and early
finish.
It is the most adverse type of float and often results in a negative figure.
FREE FLOAT (FF)
Also called Normal Float, it shows time for which an activity can be
delayed without delaying the early start of successor activity/activities.
If there are more than one succeeding activities, minimum of the floats
would be taken as free float.
FF will always be less than or equal to TF and never more.
In all critical activities, FF is always zero.
TOTAL FLOAT (TF)
It shows time for which an activity can be delayed from its ES without
delay in project completion. (In FF, when one activity was delayed, the
succeeding activity was started on time as per its ES and not delayed.)
As in FF, in case of more succeeding activities, minimum to be taken.
In TF, however, if one activity is delayed, the succeeding activity or

activities would be affected or re-scheduled.
175
Note _---
On Critical Activities, TF is always zero (as well as FF)
CALCULATIONS OF FLOATS UNDER AON

1.
INDEPENDENT FLOAT (IF): EF LS
2.
FREE FLOAT (FF): (ES of succeeding activity) (EF of the activity)
3.
TOTAL FLOAT (TF): (LF) (EF)
In case of free float, the formula is: Early Start of Successor Activities
minus Early Finish of Existing Activity. Naturally, if we can finish an activity
early but the next will start sometime later, we have a free float to delay our
activity.
Calculation of float under AOA - In case of AOA formulae are:
a)
IF(i,j)=EF(j) -ES(i) - D(i,j)
b)
FF(i,j) = EF(j) - ES(i) - D(i,j), (If there are more than one activities,
minimum thereof)
c)
TF(i,j) = LF(j) - ES(i) - D(i,j) (If there are more than one activities,
minimum thereof)
Display of calculated floats under both formats

AON shows calculated floats in their respective places. AON is versatile
format and can accommodate all type of floats. In case of AOA, the floats are to
be shown separately which makes it rather inconvenient to follow.
Example for calculation of floats
Consider the network as per earlier diagram. We have already calculated
EST and EFT. Now let us calculate LFT and LST as follows:
Step I:
......
176
a, 6
06
tb, 6
0,8
27 33
d, 93
8 21
c,5
9, 9
5 14
Step II: The diagram below shows the EST, EFT, LST and LFT for all the
activities.
Notes
f, 15
Step III: The diagram below shows the floats associated with each activity.
F, 15
A, 6
6
9
B, 8
0
4 23'29
27 33
J, 12
It is clear from the diagram that the float is nil for the critical path activities
177
Notes

Fill in the blanks.
shows time available for delaying an activity without delaying
Finish Date of the Project.
1.
Free float is also called

L
Activity 2
Prepare a network diagram for making tea starting from collecting resources
ending at making and serving the same and find critical path by assuming
\..t.ife estimates for each activity.
7.6 PROGRAM EVALUATION AND REVIEW TECHNIQUE

(PERT)
PERT is based on the assumption that an activity's duration follows a

probability distribution instead of being a single value.
Three time estimates are required to compute the parameters of an

activity's duration distribution:
Pessimistic time (to - the time the activity would take if things did
not go well
Most likely time (tm) - the consensus best estimate of the activity's
duration
Optimistic time (to) - the time the activity would take if things did go
well
So every activity has the above 3 time estimates based on past experiences
and judgment of the project team. The activity time is calculated by the
following formula
T=
t +p
t
e to + 4 m
6
The concept of 3 time estimates as mentioned above clearly underlines the factor
of uncertainty involved in the estimation of times for the project activities.
The concept Te is developed based on the statistical concept of probability of
occurrence of a particular event. This is also based on the statistical concept
of normal distribution of events when you conduct the analysis of actual
experimental data.
This formula clearly shows the fact that the probability of the activity getting
carried in realistic estimated time of tmis 4 times more than the probability of
the activity getting carried in either optimistic or pessimistic time.
Notes
If the difference between the values of t., tp on one side and tn, on the other
side is substantially small, then it can be said that the activities are more likely
to be carried out in the given estimated time as also the project completion.
On the contrary hand, if these differences are large it can be safely said
that the probability of the activities and the project getting completed in time is
much smaller.
These deviations are evaluated based on 2 parameters namely:
1.
Variance
2.
Standard deviation
Both of these parameters try to capture the difference between the mean
time t1 and the two other extreme times t., tp frequency of their occurrence. More
is the difference and more is the frequency more so is the probability of project
getting completed in actual time different from the CPM time estimate.
Variance 62 = ((tp to)/6)2
Standard deviation = v (G)2 = (tp to)/6
One can observe from the CPM process that the schedule along the critical
path has the highest probability and therefore lowest variance amongst all the
paths.
As you compare the other paths with CPM path they would have lower
probability and therefore higher variance signifying larger possibilities of
deviations and delays.
In any recurring type of events it is known that the event need not
necessarily complete itself in the same amount of time since it depends on so
many variables.
Every activity is an event of this type and can normally be completed in
a range of time values from minimum time to maximum time. Somewhere in
between lies the most likely time or the realistic time value also known as the
mean value.
The project consists of many such activities and therefore would follow a
similar behavioural pattern having range of completion time values and a mean
realistic time.
The activity and the project are dependent on many independent variables.
The completion of activity (and project) will follow a pattern which is called
normal distribution pattern.
The possibility of completing the activity in minimum or maximum time
is much smaller as compared to the realistic mean time value ().
We know what standard deviation is (")
Frequency of occurrence around realistic mean time value (p) is always
'179
Notes
maximum. As you move away from (u) in either direction, the frequency of
occurrence reduces substantially.
The standard deviation C) defines this concept numerically. More is the
value of ('), lower is the frequency of occurrence and vice versa.
As a manager, we can have the values of (-) and () for each activity and
also for the whole project. These values help identify the activities that have
high values of C).
These activities are the ones which will have higher probability of
deviating from the mean time value ().
As such they become the target activities for the manager to focus and
work upon to avoid issues of delays and cost overruns.
One C) of deviation on either side of the mean value covers a probability
spectrum of little over 68%, two 0 covers little over 95% and three 0 covers
little over 99% of the probability.
Steps in PERT
Draw the network.
Analyse the paths through the network and find the critical path.
The length of the critical path is the mean of the project duration probability
distribution which is assumed to be normal
The standard deviation of the project duration probability distribution

is computed by adding the variances of the critical activities (all of the
activities that make up the critical path) and taking the square root of that
sum
Probability computations can now be made using the normal distribution

table.
Determine probability that project is completed within specified time
X -
Where m = to = project mean time

s = project standard mean time
x = (proposed) specified time
Normal Distribution Curve
Notes
Probabi I ity
PERT Example
Let us consider an example for time estimation using PERT. For this consider
the data as per following table.
Immed. Optimistic Most Likely Pessimistic
Activity Predec. Time (Hr.) Time (Hr.)
A
B
C
D
E
F
G
H
I
J
K
A
A
A
B,C
B,C
E,F
E,F
D,H
G,I
4
1
3
4
0.5
3
1
5
2
2.5
3
6
4.5
3
5
1
4
1.5
6
5
2.75
5
Time (Hr.)
8
5
3
6
1.5
5
5
7
8
4.5
7
----- -
..11111
Notes
For this network, the expected time and variance is calculated and shown
as follows:
Activity Expected Time Variance
A
B
C
D
E
F
G
H
I
4/9
4/9
0
1/9
1/36
1/9
4/9
1/9
1
1/9
4/9
6
4
3
5
1
4
2
6
5
3
5
K
The paths in the n
Path No.
1
2
3
4
5
6
7
8
9
Path activities
ADJ
AEHJ
ACFHJ
AEIK
ACGK
ACFIK
BGK
BFHJ
BFI-K
Path Duration
6+5+3
6+1+6+3
6+3 + 4 +6+3
6+1+5+5
6+3+2+5
6+3 + 4 +5 +5
4+2+5
4+4+6+3
4+4+5+5
Total Time
14
16
22
17
16
23
11
17
18
Thus, the critical path is A C F I K with total duration of 23 days.

The variance for the critical path is as per following:
Vpath= VA + Vc+ VF VI + VK = 4/9 + 0 + 1/9+ 1 + 4/9 = 2
The standard deviation for the path is spath = 1.414
Now suppose we want to know about the probability of completing the
project in 24 days. We can use the concept of normal distribution to calculate
area under the curve, "Z" which is calculated as follows:
z = (24 - 23)/s = (24-23)/1.414 =. 71
By considering this value of Z and looking at normal distribution table,
we get value of probability for completing the project in 24 days as follows:
From the Standard Normal Distribution table:
P (z <. 71) =. 5 +. 2612 =. 7612
182
Advantages
PERT chart explicitly defines and makes visible dependencies (precedence

relationships) between the WBS elements.
PERT facilitates identification of the critical path and makes this visible.
PERT facilitates identification of early start, late start, and slack for each
activity.
PERT provides for potentially reduced project duration due to better

understanding of dependencies leading to improved overlapping of
activities and tasks where feasible.
The large amount of project data can be organised and presented in

diagram for use in decision making.
Disadvantages
There can be potentially hundreds or thousands of activities and individual

dependency relationships/
The network charts tend to be large and unwieldy require several pages to
print and special size paper.
The lack of a timeframe on most PERT/CPM charts makes it harder to

show status although colors can help (e.g., specific colour for completed
nodes).
When the PERT/CPM charts become unwieldy, they are no longer used to
manage the project.

Fill in the blanks.
1.
PERT stands for
Activity 3
Select any project and prepare a network diagram and estimate time using
PERT for the same.
The activities in project have a dependency type of relationship with the

other activities in the project. It is therefore absolutely necessary that the
PM prepares the time plan for each of such activities. This process is
called project scheduling process.
The scheduling activity starts by first listing all the activities in a structured
manner.
Notes
184
Bar chart is one of the simplest methods to capture all the activities in a
graphical manner. It uses 2-axis method, the X axis is used to indicate
the time required for each activity and the Y axis indicates the various
activities.
This way the PM can diaw up all the activities in a structured manner so
as to capture everything. This chart is known as Gantt chart named after
the person who first used it for project scheduling work.
A Gantt chart is a type of bar chart that illustrates a project schedule.

Gantt charts illustrate the start and finish dates of the terminal elements
and summary elements of a project. Terminal elements and summary
elements comprise the work breakdown structure of the project. Some
Gantt charts also show the dependency (i.e., precedence network)
relationships between activities. Gantt charts can be used to show current
schedule status using percent-complete shadings and a vertical "TODAY"
line.
The logical dependencies between tasks are defined using an activity

network diagram that enables identification of the critical path. Float or
slack time in the schedule can be calculated using project management
software. Then the necessary resources can be estimated and costs for each
activity can be allocated to each resource, giving the total project cost.
Project network is a graph (flow chart) depicting the sequence in which
a project's terminal elements are to be completed by showing terminal
elements and their breakdown structure show the "part-whole" relations.
In contrast, the project network shows the "before-after" relations.
The most popular form of the project network is activity on node, the
other one is activity on arrow. The condition for a valid project network
is that it doesn't contain any circular references. Project dependencies
can also be depicted by a predecessor table. Although such a form is very
inconvenient for human analysis, project management software often
offers such a view for data entry.
An alternative way of showing and analysing the sequence of project

work is the design structure matrix.
For complex projects the most commonly used process is the "Networking
process". This was developed in 1957 by planners of DuPont and
Remington Rand companies. The process is known as Critical Path
Method or simply CPM, Another method was developed in 1958 by US
Navy and is known as Program Evaluation and Review Techniques or
simply PERT.
For both the methods, it is necessary to define every activity of the project
in specific way and assign the resources needed for the same. It is also
necessary to define the dependency relationship of each activity before
we embark on the project plan. Dependency clearly specifies as to when
the particular activity can start with respect to other activities (before or
after them).
Critical path method is used to find the path which is most critical
and needs focus on priority. It is defined as the longest path (time). It
determines the project duration. Critical activities are all of the activities
that make up the critical path.
PERT is based on the assumption that an activity's duration, follows

a probability distribution instead of being a single value. Three time
estimates are required to compute the parameters of an activity's duration
distribution:
Notes
Pessimistic time is the time, the activity would take if things did not go
well. Most likely, time is the consensus best estimate of the activity's
duration. Optimistic time is the time the activity would take if things did
go well.
So every activity has the above three time estimates based on past
experiences and judgment of the project team. The activity time is
calculated by the following formula:
T= te + 40 tm + t p
The concept Te is developed based on the statistical concept of probability

of occurrence of a particular event. This is also based on the statistical
concept of normal distribution of events when you conduct the analysis
of actual experimental data.
Pe Keywords!
Gantt chart: A type of bar chart that illustrates a project schedule.
Project network: A graph (flow chart) depicting the sequence in which

a project's terminal elements are to be completed by showing terminal
elements.
Path: A connected sequence of activities leading from the starting event

to the ending event.
Critical path: The longest path (time), it determines the project duration.
Critical activities: All of activities that make up the critical path.
Earliest start time: Earliest time an activity can start and is equal to the
maximum earliest finish time of immediate predecessors.
Earliest finish time: Earliest time an activity can finish and is equal to
the earliest start time plus activity time.
Latest start time: Latest time an activity can start without delaying
critical path time.
Latest finish time: Latest time an activity can be completed without

delaying critical path time.
1185
Notes
Float: A float shows time available for delaying an activity without

delaying finish date of the project.
Independent float: A float which shows the time available even if an

activity has a late start and early finish.
Free float: It shows time for which an activity can be delayed without
delaying the early start of successor activity/activities.
Total float: It shows time for which an activity can be delayed from its
ES without delay in project completion.
PERT: A network technique used for estimating project duration.
11 1
1
1.
What is project scheduling? What are the tools used for project scheduling?
2.
What is the use of Gantt chart? How Gantt chart can be used for project
scheduling and tracking?
3.
What is the process of preparing network? What rules should be kept in

mind for preparing network diagram?
4.
What is activity-on-an-arrow diagram? How it is different compared to

the activity on node?
5.
What is CPM? How is critical path used for project scheduling?
6.
What are floats? Explain different types of floats.
7.
What is PERT? How PERT can be used for project time estimation?
8.
For the following data, prepare the network diagram and find critical path.
Activity
Preceding Activity
AB
A
C
B
D
E
C
D
F
G
E,F
H
G
I
G
J
H,I
186
Normal Duration (Days)

5
6
7
8
4
6
7
5
8
4
9.
Prepare network diagram and find minimum average duration of the

project and probability of completing project in 42 days. (Use normal
distribution table)
Activity Optimistic Duration
(Days)
1-2
10
1-3
6
1-4
8
2-5
8
2-6
12
3-7
6
7
5-8
6-8
5
7-9
4
8-9
4
6
4-9
f 9-10
8
Most likely
Duration (Days)
12
8
9
10
18
9
8
7
6
6
7
9
Pessimistic
Duration (Days)
16
10
10
12
21
12
9
9
10
8
8
12
10. Prepare network diagram and find floats and critical path.
Activity
A
B
C
D
E
F
G
H
I
J
Preceding Activity
A
A
B
C
D
E, F
G
G
H,I
Normal Duration (Days)

9
6
8
8
12
6
7
5
4
4

Fill in the blanks.
1.
A Gantt chart is a type of bar chart that illustrates a project schedule.
2.
Milestone is a useful feature for representing deadlines and other

significant events on a Gantt chart.

1.
False
2.
True
Notes
Notes

Fill in the blanks.
1.
Critical Path Analysis helps to identify the minimum length of the time
needed to complete a project.

Fill in the blanks.
1.
Float shows time available for delaying an activity without delaying

Finish Date of the Project.
2.
Free float is also called normal float.

Fill in the blanks.
1.
PERT stands for Program Evaluation and Review Technique.
ClSuggested Reading
1.

Structure:
444
8.1 Project Resources

8.2 Resource Constraints
8.3 Resource Aggregation
8.4 Resource Levelling and Smoothing
8.6 Project Crashing
8.7 Crashing Process
8.8 Time-Cost Relationship
8.9 Project Crashing Example
Summary
Key Words
Suggested Reading
UNIT
Notes
Objectives
Analyse allocation of resources for projects
Do the resource leveling for projects
Explain the time-cos> relationship in project
Describe the concept of project crashing
Calculate the cost and time for projects
Use the concept of crashing for reducing project duration
8.1 PROJECT RESOURCES

In any process we always have limited resources. Given the finite nature
of resource availability, a project plan may have to be modified so that it is
practical. This is the major thrust of resource planning and management. In
projects there are four stages of resource management. These stages are resource
definition, resource allocation, resource aggregation, and resource leveling.
Resource definition involves identifying the critical resources that need to be
planned and managed for the ,successful completion of the project in a multiproject environment as projects are competing for scarce resources.
Resource allocation addresses the problem of the optimum use and timing of
the assignment of these resources to the various project activities.
Resource aggregation involves determining the aggregate resources that will
be needed, period by period, to complete all project activities.
Resource leveling is the last stage in the process. In this stage, we attempt to
ensure that the demand for resources does not exceed availability. Specifically,
demand for resources is smoothed to ensure that the peaks and valleys are
reduced.
Project Constraints
Every project will face constraints. The primary impact of project constraints
is the likelihood of delay in the completion of the project. There are three types
of project constraints: technological, resource and physical. The technological
constraints relate to the sequence in which individual project activities must
be completed. For example, in constructing a house, pouring the foundation
must occur before building the frame. Resource constraints relate to the lack
of adequate resources which may force parallel activities to be performed in
sequence. The consequence of such a change in network relationships is delay
in the completion date of the project. We will examine the nature of resource
constraints in much greater detail in the next section. Physical constraints are
caused by contractual or environmental conditions. For example, due to space
190
limitations an activity such as painting a wall may have to be performed by only

one person (Gray and Larson, 2003).
Notes
In general, from a scheduling perspective, projects can be classified as

either time constrained or resource constrained. A project is classified as time
constrained in situations where the critical path is delayed and the addition
of resources can bring the project back on schedule and the project can be
completed by the required date. However, the additional resource usage should
be no more than what is absolutely necessary. The primary focus, for purposes
of scheduling, in time constrained projects is resource utilisation. On the other
hand, a project is resource constrained if the level of resource availability cannot
be exceeded. In those situations where resources are inadequate, project delay
is acceptable, but the delay should be minimal. The focus of scheduling in these
situations is to prioritise and allocate resources in such a manner that there is
minimal project delay. However, it is also important to ensure that the resource
limit is not exceeded and the technical relationships in the project network are
not altered.
8.2 RESOURCE CONSTRAINTS

The most important resources that project managers have to plan and
manage on day-to-day basis are people, machines, materials and working
capital. Obviously, if these resources are available in abundance then the project
could be accelerated to achieve shorter project duration. On the other hand, if
these resources are severely limited, then the result more likely will be a delay
in the project completion time. Depending on the type of resources, the costs
of providing an abundance of such resources to accelerate project completion
time can be very high. However, if resources are readily available and excess
premiums are not incurred to use them on the project, then project cost should
be low, as some project costs are resource related while others are likely to be
time dependent. In general, projects with a shorter duration are less expensive.
The longer the duration of the project, the higher will be overall project cost
due to the increase in fixed costs such as overheads. The reality is that as long
as the work on a project is ongoing it will continue to draw resources into its
orbit. Whatever the parameters of the project, it is unlikely that the relationship
between cost and duration is linear. For any particular project, the decision
to place the project on the curve between the point of least duration with its
associated higher resource requirements and a point of increased duration with
its associated lower resource requirements depends on the particular parameters
of the project.
When a project plan is first devised it is likely that the plan will identify
peaks of resource requirements. However, given the finite nature of resource
availability, it may be impractical to meet such peak resource needs. Ideally, there
should be an even demand for resources over the entire project duration, with a
smooth increase at the beginning of a project and a smooth decrease at the end.
Given the limited nature of resources, thoughtful consideration should be given
191
Notes
to the project resource requirements the project plan should be refined when
necessary so that it is practical. The process of refining the plan to effectively
manage and schedule resources (sometimes referred to as resource modeling)
comprises of four major stages: resource definition, resource allocation, resource
aggregation, and resource leveling (which includes resource smoothing). In the
subsequent sections we will discuss of these major stages.
Resource Definition
The first step in resource modeling is to decide exactly what resources
are considered important enough to be modeled. While most resource
modeling is concerned with people or workers (such as welders or computer
programmers), it may also include other resources such as machines (such as
a computer of a particular specification), or space on a project where space is
restricted and where this restriction limits the amount of other resources which
can be deployed at any one time. Often resources are specified in terms of the
number of units of resource required, e.g., four mechanics or two computer
programmers. Alternatively, resources may be specified in terms of the hours
or days that a specific resource is required, e.g., 32 mechanic hours or 16
computer programmer days. Resources may be considered as consumable, such
as materials that may be used once and once only, or non-consumable, such as
people, which may be used again and again. The way in which consumable
resources are used is not critical as long as they are used efficiently. However,
the way in which non-consumable resources are used can have a significant
impact on the project. For example, there is a significant difference between
requiring 16 units of a non-consumable resource for one week, thus requiring
16 units to be made available at that time, and requiring one non-consumable
unit for 16 weeks, thus only requiring one unit which can be reused 16 times.
Resource modeling is therefore mainly concerned with non-consumable
resources with an important caveat. It should never be assumed that the quantity
of resources deployed and the task duration are inversely related. Thus, one
should never automatically assume that the work that can be done by one man
in 16 weeks can actually be done by 16 men in one week. Furthermore, there
are many situations in which tasks may have to be carried out in a serial fashion,
while in other situations only one or two persons can be usefully employed due
to a limited number of workers. Understanding the nature of the job and the
size of the work team needed to do the job is an essential aspect of resource
modeling. Resource definition may also include the creation of resource
profiles which show how many units of each resource are available for use
in the project at any given time. In multi-project situations, this is not an easy
matter, as resources may be required to work on several projects simultaneously
and there, determination of the resources required for one project must also
consider the use of the same resources for other projects.
Resource Allocation
Resource allocation, also called resource loading, is concerned with
assigning the required number of those resources identified in the previous step
to each activity identified in the plan. More than one type of resource may be
attributed to a specific activity. For example, fixing the plates on a ship's hull
may require 10 fitters, 20 welders, 15 labourers and a certain type of welding
machine. From a practical standpoint, resource allocation does not have to
follow a constant pattern some activities may initially require fewer resources
but may require more of the same resources during the later stages of the project.
At this stage, the impact of any resource allocation decision is not known and
we cannot yet answer questions such as:
Is lack of resources on this particular activity having an adverse effect on

the duration of the whole project? Such an activity is more likely to be on
the critical path.
By excessive use of resources are we completing this activity more

quickly than necessary in terms of the overall project duration? Such an
activity is not likely to be on the critical path.
Notes
These questions will be answered later in the resource modeling process,

specifically during the resource leveling and smoothing stage.
to

1.
The four stages of resource management in projects are:

i.
Resource definition
Resource allocation
ii.
iii.
iv.
Resource aggregation
Resource leveling
v.
Resources cost cutting
vi. Resource controlling
1.
The first step to resource modeling is allocating resources.
2.
Resource allocation is concerned with assigning the required number

of identified resources to each activity identified in the plan.
8.3 RESOURCE AGGREGATION

Resource aggregation, or resource loading, is simply the summation, on
a period-by-period basis, of the resources required to complete all activities
based on the resource allocation carried out in the previous stage. The results
are usually shown graphically as a histogram. Such aggregation may be
done on an hourly, daily, or weekly basis, depending on the time unit used to
allocate resources. When a bar chart is used as the planning tool, the resource
aggregation is fairly simple and straightforward. For a given bar chart, there is
a unique resource unit aggregation chart which can .be drawn underneath the
bar chart. However, a separate graph will be required for each resource unit.
193
An example is shown in Figure 8.1 below, where, for a particular resource, the
required resource units for each time period are annotated on the bar chart. The
total number of resource units for each time period can then be summed and a
resource aggregation or load chart can be produced.
Notes

Week
10
10
10
10
Activity
REMINIail,
tip
D
E
Total resource
units requirement
.
......
10
18
10
12
10
10
14
El
....
15
Resource
unit
aggregation
chart
10
5
%-
Fig. 8.1: Resource Unit Aggregation Chart derived from a Bar Chart
However, when a network is used for planning, the resource aggregation
procedure is not so simple or straightforward. As the network is not drawn to
a time-scale, there is not a direct link between the network and the demand for
resources. Therefore, a schedule must be prepared which tabulates activities
in terms of time. However, this highlights another difficulty, namely that those
activities which are not on the critical path do not have fixed starting and
finishing times but are constrained by the earliest and latest starting and finishing
times. However, this seeming difficulty offers the planner considerable scope
for adjusting the demand for resources. This will be discussed in more detail
later, but the limits, within which resources can be adjusted, without extending
the overall project duration, are the resource requirements between the earliest
starting times and the latest starting times. This is illustrated in Figure 8.2, which
shows the differing resource requirements that arise when both earliest and
latest start times are considered and also highlights the resource requirements
for those activities which are on the critical path.
Notes
Resource units
ET
Resource requirement for earliest start

Resource requirement for latest start
Resource requirement for activities on the critical path.
rt
2'
n
112 1
- I-
41
14
12
10
Weeks
Fig. 8.2: Resource Unit Aggregation Chart
8.4 RESOURCE LEVELLING AND SMOOTHING

Having established the resource requirements through resource allocation
and aggregation, we will now examine the next phase of the planning and
resource management process, resource leveling. We will now compare those
requirements with resource availability by developing resource profiles.
Disregarding factors such as economic considerations, if sufficient resources
are available so that supply always exceeds demand then, we should have no
problem. However, the most likely scenario is that, at some point, demand will
exceed supply. Such a scenario is illustrated in Figure 8.3.
Resource
Quantity
11
,.....
Resource
Demand
- Over demand of
,z resources
10
9 Resource availability
..
.....____
7
6
5
...
r.
4
3
2
1
1
5
Week
10
Fig. 8.3: Resource Demand compared to Resource Availability
195
Notes
Resource leveling is the process that ensures resource demand does not
exceed resource availability. The ideal scenario would be a buildup of resource
usage at the beginning of the project and a reduction at the end of the project.
However, the approach to resource leveling will also depend on whether
resources are dedicated to a particular project or shared across several projects
and whether there is a need to ,keep all resources fully utilised.
We will begin by analysing the issues involved in resource leveling for a
situation where a bar chart has been used as the primary planning technique for
a simple project. The reason for this is that resource leveling must be considered
within a time framework and bar charts are drawn to a time scale while networks
are not. Examine Figure 8.1. In this figure, the time-scale for the activities
comprising the project are shown in a bar chart, which also shows resource
requirements for one particular resource unit. An examination of the bar chart
and its associated resource chart in Figure 8.1 shows that improvements can be
made to the level of resource requirements by:
Delaying or bringing forward the start of certain activities
Extending the duration of certain activities and so reducing the demand

for resources over the duration of the activity or by a combination of both
of these adjustments
However, there are problems with using the simple bar chart as a tool
for resource leveling. For example, we do not have any information about the
interdependency of tasks. Therefore, if we delay a task by starting later than
originally planned or by extending the duration of the task, we cannot evaluate
the exact impact this will have on the overall project. Referring to Figure 8.1
again, if we assume that the maximum amount of resource availability is 14
units, then we have a problem in week 2 because 18 units of resources are
required in that week. In order to reduce the resource demand in week 2, we
may have to extend Activity A into week 3 (if this is possible) and spread the
resource demand over three weeks, or delay the commencement of Activity
B. However, the exact impact of these changes on the overall project duration
cannot be easily determined.
Another issue is that the critical path(s) cannot be easily determined,
although we may be able to deduce which activities are critical by inspection.
Clearly, if we do not wish to extend the overall duration of the project we must
avoid extending or delaying activities which are on the critical path. Finally, the
availability of slack or float is not clear. Knowing this is important because it is
this attribute that can be utilised to adjust our resource requirements.
Resource leveling can be accomplished more easily if resource
requirements to complete an activity are expressed in terms of hours or days
required. The definition of resource requirements using such units of measure
can help us determine if an activity should be completed in a short time through
the use of many resources or over a longer period of time through the use of
fewer resources. In practice, however, there is a limit to the number of resources
that can be deployed and, therefore, a limit to the amount by which any activity
duration can be shortened.
We will now examine situations where networks are used as the primary
planning method. Generally, there are two approaches to leveling and smoothing
the resources required:
Notes
Time-limited resource considerations

In this case emphasis will be placed on completing the project within
a specified time. This time is usually determined by network analysis.
Adjustments in the timing of any activity, and the resources required
at a given time, must be undertaken within the float (slack) available.
Obviously there can be no adjustment of activities which are on the
critical path.
Resource-limited resource considerations
In this case the project must be completed with the resources available
even if this means extending the project duration. If the total resource demand
exceeds the resource availability at any time then some of the activities must be
delayed until there is sufficient resource availability.
For both of the above approaches, information concerning the earliest and
the latest start times and slack will be used to level resources.
Resource Smoothing
Resource smoothing is part of the resource leveling process. In itself,
resource smoothing is the process that, not withstanding any constraints imposed
during the leveling process, attempts to determine a resource requirement that
is "smooth" and where peaks and troughs are eliminated. For example, even
if 7 units of a given resource are available at any one time, utilising 5 of these
units each week is preferable to 4 one week, 7 the next, 2 the next and so on.
Even if there is no limit to the amount of any one resource available, it is still
desirable that resource usage is as smooth as possible. Given that the resource
requirements of those activities on the critical path are fixed, some order or
priority should be established for selecting which activity and which particular
resource associated with this activity should be given priority in the smoothing
process. In determining which activity should be given priority, a subjective
judgment should be made about the type of resource (or resources) associated
with each activity priority should be given to the activities whose resources
are considered to be the most important. Beyond this consideration, activities
should be ranked in order of total work content and total float or slack available
for that activity. A useful device for prioritising is to consider the ratio of total
work content/total float remaining and give priority to activities with the highest
value of this ratio.
Solving the resource scheduling problem for optimal solutions is extremely
complex, particularly for large project networks with many different resource
types. However, several heuristics are available to solve such problems. These
heuristics allocate resources to activities to minimise project delay based on
certain priority rules. The two most commonly used heuristics are the serial
197
and the parallel methods. In the serial method of resource allocation, activities
are sorted into a list and resources are allocated to each of these activities one
at a time until resources are allocated to all activities. In the parallel method,
however, resources are allocated on a period by period basis rather than each
activity. In this method, only those activities whose preceding activities have
been completed will be considered. If two or more activities compete for the
same resources, then allocation of resources is based on certain prescribed
priority rules. Compared to the serial method, the parallel method has been the
most widely used heuristic. The following priority rules, in the order presented,
have been found to be the most effective in minimising project delay.
Minimum slack
Smallest duration
Lowest activity identification number
Regardless of the scheduling heuristic used, the primary impact of the resource
constrained scheduling is the loss of flexibility due to the reduction in slack.
Furthermore, the reductiOn in slack also increases the number of critical or
near-critical activities.
1.
Fill in the blanks.

1.
2.
is the process that ensures resource demand does

not exceed resource availability.
is part of the resource leveling process.
8.5 RESOURCE SCHEDULING

We will now go through an example to demonstrate the resource scheduling
process for a resource constrained scenario using the parallel heuristic and
the priority rules given above. We will solve two problems. In solving these
problems, two critical assumptions are made.
No splitting activities are allowed, i.e., once an activity is placed on the

schedule it will be worked on continuously until it is finished.
The resource level used for an activity cannot change.

In actual practice, however, these limiting assumptions do not exist.
Time-Constrained Network - Example (Gray and Larson, 2003)
This next example has several parts. We will discuss each of them in some
detail.
Notes
LEGEND
ID
ES
0 2
61
SL Resource
EF
SL
LS Duration LF
5
Fig. 8.4: Time-Constrained Network Example

First, compute the early, late, and slack times for the activities in the network in
Figure 8.5, assuming a time-constrained network. Which activities are critical?
What is the time-constrained project duration?
LEGEND
4 1 4 ; 10
0
0 1 ! 0
4
1
1
416
10
ES
LS
5
2 1
6 4 10
ID
EF
SL Resource SL
Duration LF
Fig. 8.6: Time-Constrained Network Example showing Early, Late and

Slack Times
Now, assume you are using a computer using software that schedules
projects by the parallel method and the following heuristics. Schedule only one
period at a time!
Minimum slack
Smallest duration
Lowest activity identification number
(Hint: Remember to maintain the technical dependepcies of the network.)
199
Notes
ID RES DUR ES
2
'2
0,1,2,3
1,,
0
-1.-2
.1
4
10
5,6,7,8
10
-1 -2
10,11,12 13
9 10 11 12 13 14 15
6 7
LF SL 0 1 2 3 4 5
. ..
1 ". 1
,.,.
10,
,
0,1,
-2
Resources Scheduled
Resources Available
Fig. 8.7: Scheduled Resource Load Chart with ES and Slack Updates
Note: The parallel method schedules resources to various activities through
leveling and smoothing. This is accomplished in the above problem by delaying
and reducing the slack on activities 3, 5 and 6. Using the load profiles presented
above, graphical resource aggregation charts, similar to the ones presented
earlier in this lesson, can be developed.
Next, keep a log of each activity change and the update you make for
each period, e.g., period 0-1, 1-2, 2-3, etc. The log should include any changes
or updates in ES and slack times each period, activities scheduled and activities
delayed. (Hint: Remember to maintain the technical dependencies of the
network.) The log is shown in Table 8.1 below.
Table 8.1 Log of the Parallel Method of Scheduling
PERIOD ACTIVITY CHANGES
Schedule activity 2 first by the minimum slack rule
2
0-1
Schedule activity 1
1
3
Delay activity 3 ES to period 1. Reduce slack to 0.
Delay activity 5 ES to period 6. Reduce slack to 0.
5
Delay activity 3 ES to period 2. Reduce slack to -1.
1-2
3
5
6
3
2-3
5
6
Schedule activity 3
3
3-4
Schedule activity 4
4
4-5
No changes
5-6
No changes
6-7
No changes
7-8
Schedule activity 5
8-9
5
No
changes
9-10
No changes
10-11
No changes
11-12
Schedule activity 6
12-13
6
Proj ect Management Operations
Note: The parallel method schedules resources to various activities through

leveling and smoothing. The log presented above shows how this was
accomplished in the above problem by delaying and reducing the slack on
activities 3, 5, and 6.
Now, list the order in which you scheduled the activities of the project.
Which activities of the schedule are now critical?
The order is (2, 1, 3, 4, 5, 6) and the critical activities are 2, 3, 5, and 6 as
these are the activities with the least or negative slack.
Finally, re-compute the slack for each activity given in the new schedule.
What is the slack for activity 1? 4? 5?
For this, see the answer to the second question. The slack for 1 = (0), 4 =
(2), and 5 = (0).
Benefits of Resource Scheduling
The process of scheduling resources before the project begins provides
the following benefits:
1.
If project delay is unacceptable, it allows sufficient time for considering

alternatives such as cost-time trade-offs and changing of priorities.
2.
Provides information to prepare time-phased work package budgets with

dates.
3.
Enables project managers to determine the amount of flexibility they have

over certain resources.
ik
Activity 1
Visit any project site or any organisation and prepare the network for the
project carried out there. Find the resources required and see how the
\.._resource levelling can be done.
8.6 PROJECT CRASHING

Crashing refers to a particular variety of project schedule compression
which is performed for the purposes of decreasing total period of time (also
known as the total project schedule duration). The diminishing of the project
duration typically takes place after a careful and thorough analysis of all
possible project duration minimisation alternatives in which any and all
methods to attain the maximum schedule duration for the least additional cost.
There are a number of standard and typical approaches to attempting to crash
a project schedule. One of the most commonly utilised methods of crashing a
project schedule involves minimising the schedule activity durations while, at
the same time, increasing the assignment of resources on schedule activities.
Crashing is something which can be utilised to attempt to get the most value
out of a project assignment. Essentially, it boils down to an attempt to get the
Notes
Notes
8.7 CRASHING PROCESS

' The critical path is the place to look when you want to shorten a
schedule. By definition, the critical path is the sequence of tasks that is nothing
but back-to-back work, with no slack, which you can subtract to reduce the
duration. Figure 8.10 shows that shortening the "Build Ship Infrastructure"
task won't do anything to shorten the overall project duration. Because the
"Build Improbability Drive" task is longer, it determines when the "Assemble
Components" task starts, regardless of how little time it takes to build the ship.
Ted 1911.
iv..., :1,9.
imerntria
4-4
."IneI
1 Wro
Fig. 8.10: Only Critical Path can shorten the Project Duration
Crashing the project isn't as simple as finding all the tasks on the critical
path and wildly assigning resources to them. Some tasks cost more per week to
crash than others. Figure 8.11 shows a crash table that uses the cost of crashing
a task and the number of weeks it reduces the schedule to calculate the crash
cost per week.
From your Microsoft Office Project Professional 2003 schedule, you can
export the tasks on the critical path, their durations, and their original costs.
Then, by importing that information onto a Microsoft Office Excel 2003
worksheet, you can calculate the crash cost per week for each task. Sorting the
tasks by the crash cost per week quickly shows you the least costly tasks for
crashing.
This worksheet is sorted by using three columns. Column A identifies the
tasks on the critical path, so the sort begins by separating the critical path tasks
from the rest of the schedule. Then, the "Crash Cost per Week" column is sorted
in ascending order to find the least costly tasks. Finally, the "Crash Duration"
column is sorted in descending order to find the cheapest tasks that shorten the
schedule the most. By looking for the largest reduction at the lowest price, you
crash the fewest tasks.
Telt Name
NO Cruse
5 Assemble Coreponerts
1 Design Step
6 Test SNP
2 &mkt Imorob4t.ily Orme
4 6okt Shap ltdrastruclue
3 Teti VornrottabOtie nil Yll
ID
CP
Cl
CP
CP
Crash
Gash
COSI tx.e'
DINB000 DUr9[109
Cr aS#1
Original
Clash
Week
(Wks)
(ttrk0 Reduchon Cost ISW Cost 51,41 LSI.1)
20
26
25
50
40
16
16
18
19
45
36
14
4
8
6
5
4
2
12
20
74
56
26
6
16
32
33
100
42
16
100
150
1 50
10 00
3 50
4 09
Crew
IlesuN
121
117
109
103
96
96
99
Fig. 8.11: Crashing Table
Crashing works as per following:
Notes
The Build Improbability Drive task costs $10 million for every week
that we cut from the schedule. Therefore, it will cost $50 million to reduce the
schedule by five weeks. Build Improbability Drive engineers are, well, pretty
improbable to come by, so hiring a second one for the project comes at a steep
price. On the other hand, if you start by crashing the ,least costly task, Assemble
Components, you can shorten the schedule by four weeks for only $4 million.
Crashing a task can change the critical path on the project, even adding a
task to the critical path that wasn't there before. For example, if you reduced the
"Build Improbability Drive" task to less than 40 weeks, the status of the "Build
Ship Infrastructure" task would be elevated to the critical path. To accurately
evaluate your crash decisions, you should review the critical path after every
task crash.
If you look closely at the worksheet in Figure 8.11, you'll notice that the
"Build Ship Infrastructure" task and the "Test Improbability Drive" task cost
less per week to crash than the "Build Improbability Drive" task. Why aren't
they crashed earlier? The answer lies in the "Crash Result" column. These two
tasks aren't on the critical path. Although crashing those tasks costs money,
their shorter durations don't shorten the overall project schedule one bit.
Figure 8.12 illustrates the benefit of crashing the least costly tasks first.
As you can see, the initial reductions shorten the schedule significantly without
much of an increase in overall cost. But, as you dig deeper for more reductions,
each additional week comes at a higher and higher price.
Total Cost
$250 -
$200
$150
$100
$50
SO
98
103
109
117
121
Weeks
Fig. 8.12: Additional Reductions in Duration come at increasingly Higher

Prices
205
Notes .
Crash tables are simple to create. Here are the basic steps that are required
to be performed:
A.
Export the work package tasks (ID and Task Name fields), the original
duration (Duration field), and the original cost (Original Cost field) from
your Project Professional 2003 schedule, and open that file in Excel 2003.
B.
You must calculate the potential crash duration for each critical path task
and the cost to crash each task.
C.
On the Excel worksheet, add a column to calculate crash reduction, which

is how many weeks you can crash each task. Crash reduction is simply the
original duration minus the crash duration.
D.
Add another column to calculate the crash cost per week, which is the
crash cost divided by the crash reduction value.
' Check your Progress 4
Fill in the blanks.

1.
The
schedule.
is the place to look when you want to shorten a
8.8 TIME-COST RELATIONSHIP

The crashing results in reducing the duration but may result in increase in cost.
Thus, while crashing we must keep in mind following aspects:
There is flexibility in activity duration.
Normal duration entails least activity cost.
With expenditure of additional resources it is generally possible to

accomplish the activity in a shorter duration.
The minimum possible duration of the activity is its crash duration, when
its cost is the highest.
For technological reasons it is not possible to shorten duration below the

crash limit even by spending more money or resources.
Time-Cost Relationship of a Typical Job

Following figure shows typical time-cost relationship. The figure shows
that initially the cost reduces as the time is reduced to normal duration. But if
we try to reduce time beyond normal duration, the cost increases gradually. If
we try to reduce the duration beyond this limit, the cost increases exponentially.
206
Notes
Direct
cost of
job
Crash
Normal
Job duration
Fig.8.13: Time-Cost Relationship of a Typical Job

The project has direct and indirect costs. The direct costs are directly
proportional to the activities. As the duration reduces, these costs increase .as
we may have to put additional resources. Direct Costs are associated with the
performance of the specific activity, such as:
Cost of planning and design
Raw material procurement
Labour costs
Manufacturing or processing costs
Travel, communication, transportation
Consultant fees, etc.

Direct cost increases with the crashing of the project duration.
The indirect costs are the administrative costs and not related to the
activities directly.
These are fixed expenses incurred on daily basis during the project.
Project Indirect Costs include overhead costs such as:
Managerial services
Indirect supplies
Equipment rentals
Allocation of fixed expenses
Site office maintenance
Thus, this cost will be directly proportional to the project duration and
it will reduce with the reduction in the project duration and increase with the
duration of the project. This is shown in the figure below.
Indirect
cost of
project
Direct
cost of
job
Crash
Normal
Project duration
Fig. 8.14: Crash Cost vs. Project Duration

207
Notes
Point 3 to 4: Now we have 3 critical paths which are A D G, A F and B

G each with 13 days. The duration for path C E - G and C H becomes 11
days and 5 days respectively. Now we crash F & G by 1 day each. This results
in duration for the paths A D G, A F and B G 12 days. The project
duration becomes 12 days. And the cost increases for F & G by Rs. 60 & Rs.140
respectively. Thus, total increase is Rs. 200.
Direct
cost
increment
800
700
600
500
400
320
300
200
160
100
Crash A,G &

relax D by 1 day
Crash D by 2 Days
P2
11
12
113
14
15
P1
1
16
Project
Duration
Point 4 to 5: Now we have 3 critical paths which are A D G, A F and B

G each with 12 days. The duration for path C E - G and C H is 10 days
and 5 days respectively. The project duration is 12 days. Now we crash B, D
& F by 1 day each. This results in duration for the paths A D G, A F and
B G 11 days. The duration for path C E G and C H is 9 days and 5 days
respectively. The cost increases by Rs. 120 for B, Rs. 80 for D & Rs. 60 for G.
Thus, total cost increase in this case is 120 + 80 + 60 + 260 Rs.
Direct
cost
increment
800
700
600
500
400
300
200
100
Crash F,G by 1 day

Crash A,G &
relax D by 1 day
5201
Crash D by 2 Days
32Q
P2
160
P1
Proj ect
Duration
11
12
14
15
16
Project Cost: The figure below indicates the total cost of crashing and
combining all the stages.
210
Direct
cost
increment
_780
800
700
5 20
600
500
400
120
300
200
100
Notes
Crash B,D,F by 1 day
Crash F,G by 1 clay
_ _ _ 1)5
Crash A ,0
2d0
relax D by 1 day
Project
Duration
200
Crash D by 2 Days
160
11
Project Total Costs: In case project has indirect cdst of Rs. 100 per Day, The
total project cost will be as indicated in figure beloW.
Project Indirect costs = Rs 100 1 day'
Total
Jar
Cost
Indirect
cost
Direct cost
Duration
Activity 2
Select any project and prepare a network diagram and estimate time using
CPM for the same. Find the possibility of crashing, looking at the cost and
the duration of each activity.
""',.',,,, Summary
In projects there are four stages of resource management. These stages

are resource definition, resource allocation, resource aggregation, and
resource leveling.
The management of resources is must as every project will face constraints.

The primary impact of project constraints is the likelihood of delaying the
completion of the project. There are three types of project constraints:
technological, resource and physical.
The technological constraints relate to the sequence in which individual

project activities must be completed. Resource constraints relate to the lack
of adequate resources which may force parallel activities to be performed
in sequence. The consequence of such a change in network relationships
is delay in the completion date of the project. Physical constraints are
caused by contractual or environmental conditions.
In general, from a scheduling perspective, projects can be classified as

either time constrained or resource constrained. A project is classified
211
as time constrained in situations where the critical path is delayed and

the addition of resources can bring the project back on schedule and the
project completed by the required date. However, the additional resource
usage should be no more than what is absolutely necessary. On the other
hand, a project is resource constrained if the level of resource availability
cannot be exceeded. In those situations where resources are inadequate,
project delay is acceptable, but the delay should be minimal.
Notes
212
The most important resources that project managers have to plan and
manage on day-to-day basis are people, machines, materials and working
capital. Depending on the type of resources, the costs of providing an
abundance of such resources to accelerate project completion time can be
very high.
Resource leveling is the process that ensures resource demand does not
exceed resource availability. The ideal scenario would be a buildup of
resource usage at the beginning of the project and a reduction at the end
of the project. Resource leveling improvements can be made to the level
of resource requirements by:
Delaying or bringing forward the start of certain activities
Extending the duration of certain activities and so reducing the demand

for resources over the duration of the activity or by a combination of both
of these adjustments
Resource leveling can be accomplished more easily if resource

requirements are expressed in terms of hours or days required for
completing an activity. For this we can go for time-limited resource
considerations or resource-limited resource considerations.
Resource smoothing is the process that, not withstanding any constraints

imposed during the leveling process, attempts to determine a resource
requirement that is "smooth" and where peaks and troughs are eliminated.
Several heuristics are available to solve resource smoothing problems.
The two most commonly used heuristics are the serial and the parallel
methods.
Crashing refers to a particular variety of project schedule compression

which is performed for the purposes of decreasing total period of time
(also known as the total project schedule duration). Crashing results
in minimising the schedule activity durations while, at the same time,
increasing the assignment of resources on schedule activities. Crashing
can be done by increasing resources or by fast tracking.
The project has direct and indirect costs. The direct costs are directly
proportional to the activities. As the duration reduces, these costs increase
as we may have to put additional resources.
Notes
/OKeywords
Resource definition: Identifying the critical resources which are to be

planned and managed for the successful completion of the project in a
multi-project environment as projects are competing for scarce resources.
Resource allocation: Addresses the problem of the optimum use and

timing of the assignment of these resources to the various project activities.
Resource aggregation: Involves determining the aggregate resources

that will be needed, period by period, to complete all project activities.
Resource leveling: The last stage in the process. In this stage, we attempt
to ensure that the demand for resources does not exceed availability.
Resource smoothing: The process that attempts to determine a resource

requirement that is "smooth" and where peaks and troughs are eliminated
and does not withstand any constraints imposed during the leveling
process.
1.
What is project scheduling? What are tools used for project scheduling?
2.
What is resource levelling? How can this be achieved?
3.
What are project constraints? How can these be managed?
4.
What is resource smoothing? How can this be achieved?
5.
What is the relationship of cost with time in project management? How

can this be minimised?
6.
What is project crashing? How can project be crashed?
7.
What is the direct cost in project? How it is different from indirect cost?
8.
What is cost slope? What is the use of cost slope in project management?
9.
A Project has 7 activities. The relationship between the activities is as

under:
Activity
Preceding activity
Duration
Manpower Required
A
1
2
B
2
1
CD
A
1
2
1
1
E
B
3
1
F
G
CD
2
1
1
1
If only 3 persons are available, do the resource leveling, find the project
duration.
213
Notes .
10. Prepare network diagram and find minimum duration of the project and
minimum cost if the fixed cost is Rs. 2000 per day.
Activity Preceding
Activity
A
B
C
D
E
F
G
H
I
J
A
A
B
B
C
E,F
G
G
H,I
Normal
Duration
(Days )
10
6
8
8
12
6
7
5
4
4
Crash
days
8
5
6
6
9
5
5
4
6
3
Normal cost
12000
6000
6400
6400
8400
4800
4900
5500
5600
4000
Crash Cost
16000
7500
7800
7200
9900
6000
5500
6000
7200
4500
Answers to Check your, Progress

1.
The four stages of resource management in projects are:

i.
Resource definition
ii.
Resource allocation
iii.
Resource aggregation
iv.
Resource leveling

1.
False
2.
True

Fill in the blanks.
1.
Resource levelling is the process that ensures resource demand does not
exceed resource availability.
2.
Resource smoothing is part of the resource leveling process.

Fill in the blanks.
1.
Spending more money to get something done more quickly is called

crashing.
2.
Fast-tracking involves overlapping tasks which were initially scheduled

sequentially.
Notes
Fill in the blanks.

1.
The critical path is the place to look when you want to shorten a schedule.

1.
True
2.
True
n
i Suggested Reading
1.

McGraw-Hill.
215
Notes
216
Project Management. Operations

Structure:I
owe
9.1 Project Management Process
UNIT
9.2 Activity Scheduling

9.4 Cost Scheduling
9.5 Earned Value Analysis
9.6 Estimation of Cost per Activity/ Task
Summary
Key Words
Suggested Reading
Prgject Implementation and Monitoring
217
Notes
Objectives
Explain the project management process
Do activity scheduling
Identify and estimate resources and cost required for projects
9.1 PROJECT MANAGEMENT PROCESS

Any project plan unless executed well will fail. Thus, for a successful
project management, execution of plans is as important as its planning. It is
important to note that many of the processes within project management are
iterative in nature. This is mainly due to the existence of and the necessity for
progressive elaboration in a project throughout the project life cycle. This means
that the more you know about your project, the better you are able to manage
it. Apart from the tools, methods, techniques and processes, an effective project
management requires organisational support, as well as teams as building
blocks.
The project management process, as happens with any other process,
receives certain inputs (business need, problem or opportunity) and constraints
(time, cost, quality, technical aspects, social, political and environmental
conditions, legal restrictions, etc.) and by applying the appropriate mechanisms
(techniques, tools, equipment, organisation, human resources, etc.) it produces
specific output (project deliverables). The following diagram illustrates the
project management process.
Constraints
Input
Project Management
41111
Output
Mechanisms
Fig. 9.1: The Project Management Process
and surprises, but will provide standard processes and procedures to deal with
them and help prevent the following:
218
Projects finishing late, exceeding budget or not meeting customer

expectations
Inconsistency between the processes and procedures used by different

projects managers
Unorthodox way of delivering success to a project through high stress

levels, significant amounts of overtime and based solely on the goodwill
of some individuals
Project management seen as not adding value and as a waste of time and
money
Unforeseen internal or external events impacting the project
Notes
A good project management requires perfect planning, organised

implementation and analytical monitoring and control. For any project to have
good implementation, we need to understand following processes:
Activity scheduling which includes identification of the activities,

determination of activities' sequence and dependencies, estimation of
activities/tasks duration and scheduling of activities.
Resource scheduling which includes development of resource plan,

identification of types and quantities of, resources, development of
resource schedule and assignment of resources to project activities/ tasks
Cost schedules which includes development of cost plan, identification

and estimation of costs, development of cost schedule
9.2 ACTIVITY SCHEDULING

The activity scheduling comprises the following processes:
1.
Identification of the activities: The activities implied in the delivery of

each of the products/deliverables need to be identified to give a fuller
picture of the plan's workload. For this purpose a step-by-step approach
for the preparation of a detailed activity schedule can be followed.
The first step of this approach is to list the main activities. In order
to do this use as basis the WBS we have developed. Identify all the
activities required to create the products or develop the deliverables
that have been identified and presented in level 1 and then list them.
The list of activities should normally include management activities
as well.
The second step is to break activities down into manageable tasks.

The purpose of breaking activities down into tasks is to make them
sufficiently simple to be organized and managed easily. Normally the
tasks identified should lead to the products/deliverables presented
in the WBS in level 2.
We have to be careful in getting the level of detail right. The most

common mistake is to break the activities down into too much
detail. The subdivision should stop as soon as you have sufficient
detail to estimate the time and resources required to implement the
work.
.2 1-9
Notes
2.
The major difference between subdivision here and in the

development of the WBS is that the final outputs here are described
as activities and not as deliverables.
When using the WBS to identify which activities are needed, the
project manager may find out that has forgotten to incorporate one
deliverable in the WBS or that the deliverable descriptions have to
be corrected to indicate the exact outputs of the project. In this case
the WBS must be updated.
It is noted that as has already been described the WBS and the
activity list are being prepared sequentially first the WBS and then
the activity list. nowever, sometimes it is convenient to develop
them simultaneously.
Determination of activities' sequence and dependencies: Once the

activities' have been identified and broken down to smaller components,
they must be related to 'each other to determine the activity sequencing
(order in which the activities should be undertaken) and dependencies
(which activity must be completed before the start up of another activity).
This can best be described with an example as follows:
Implementing training in the "public procurement best practice guide"
to 100 main purchasers. The Cypriot contracting authorities who has
the following prerequisites: Completion of the compilation of the best
practice guide, formulation of the training strategy, development of
the training programme and preparation of the training material. The
sequence dictates that the preparation of training programme and training
material comes before the training delivery while dependencies include
the fact that training cannot start until the contracting authority approves
the training material. Dependencies may also occur between activities
that will be undertaken by the same person (i.e., a trainer who is assigned
to provide training both to future trainers and to the main purchasers may
not be able to complete both tasks at the same time).
Dependencies can be distinguished in the following types:
Mandatory dependencies: Mandatory are those dependencies that

are inherent in the nature of the work (e.g., on a construction project,
the walls cannot be built and plastered until after the foundation has
been laid)
Discretionary dependencies: Discretionary dependencies are those

defined by the Project Management Team. Normally the Project
Management Teath has a good knowledge of the thematic area in
which the project refers and besides is aware of any unusual aspect
of the project that oblige the application of a certain implementation
sequence
External dependencies: External dependencies are those derived

by non-project activities (e.g., software testing depends on the
delivery of the hardware by an external supplier).
Any schematic display of the logical relationships of project activities

is called Project Network Diagram. There is more than one technique to
construct a Project Network Diagram as already explained in earlier units.
To understand better, presented below is the Precedence Diagramming,
since is the one used by most of the project management software
packages (e.g., MS Project, Primavera Planner).
Notes
According to this method, the Activities are presented as boxes and their
dependencies as arrows. There are four types of dependencies but only
one is the most commonly used, the finish to start. More specifically, the
types of dependencies are:
Finish to Start (FS): In this case the work of the successor cannot start
until the work of the predecessor has finished.
Finish to Finish (FF): In this case the completion of the work of the
successor depends on the completion of the work of the predecessor.
Start to Start (SS): In this case the initiation of the work of the
successor depends on the initiation of the work of the predecessor.
Start to Finish (SF): In this case (it is rarely used) the completion
of the work of the successor depends on the initiation of the
predecessor.
A typical diagram drawn using the precedence diagramming method is

presented in the following scheme:
A
I Start
--+ Finish
Fig. 9.2: Precedence Project Network Diagram

All types of dependencies between the activities are being "declared"
when producing the time schedule and they are automatically presented
as connecting arrows on the Gantt chart. In this perspective, the Project
Network Diagram itself is not something compulsory, but the activities'
sequence and dependencies must be identified, since they are necessary
for the activities scheduling.
3.
Estimation of the activities '/tasks ' duration: Activity duration

estimating is the process of making a realistic quantitative assessment of
the likely number of work periods that will be required to complete an
activity.
The estimate is often progressively elaborated and more accurate. To ensure
that the estimates at this stage are realistic, those of the project team who
221
are more familiar with the nature of the specific activity and those who
have the necessary technical knowledge or experience (by participating or
managing similar activities/projects in the past) should be consulted. The
inputs that are necessary for the activity duration estimation are:
Notes
4.
Activity list: This is as per the process discussed above.
Constraints and assumptions: The constraints form resource

side, management side or any other processes and the assumptions
made for arriving at conclusions.
Resource requirements: The duration of most activities is

influenced by the number of the resources assigned to them and by
the skills and capabilities they possess. Normally, a senior consultant
working full time can be expected to complete a certain activity in
less time than a junior consultant, also working full time. Besides,
two people from an Implementing Agency working together in a
specific task are expected to complete it in half the time it takes
to each of them individually. It has to be noted that although the
number of the resources assigned to each task is a significant input
for the activity duration estimating, there are cases in which the
activity duration estimation is mainly based on historical data and
experience from the implementation of previous similar projects. In
these cases the activities' duration is predetermined and the number
of resources needed to carry out the activities is defined accordingly.
Historical information: This refers to data available at the project

files of similar projects concerning the actual duration of their
activities. It refers also to information available to databases like
how long it takes concrete to cure, how long it usually takes a
Ministry to respond to certain types of request, how long it takes
for a law to be voted, etc.
Identified risks: The project team may choose to incorporate an

additional time period (usually called as reserve time) to the activity
duration as recognition that one or more of the identified risks may
occur. This time can be a percentage of the estimated duration or a
fixed period.
Scheduling of activities: Scheduling follows estimates of the time for

each activity and is a very crucial step in the Planning Phase since a
plan can only show the feasibility of achieving its objectives when the
activities are put together in a schedule that defines when each activity
will be carried out. In order to proceed with scheduling we need the
following inputs:
The Activities' sequence and dependencies
Activity duration estimates
Resource requirements and resource availability: This includes

the number of people who will be available to do the work, should
be established. Any specific information like names, percentage
availability, and availability in certain periods starting from and

ending at should also be noted.
Notes
MEd
Assumptions made, if any, about the process.

Constraints: There are two major categories of time constraints
that we should consider during schedule development. First, impose
on which dates the activity starts or finishes which can be used to
restrict the start or finish to occur either no earlier than a certain date
or no later than a specified date for the present programming period
must be completed before the next programming period starts).
Second, the project owner or the project stakeholders may request
that a certain deliverable be completed by a specified date
Milestones: Milestones are the key events that provide the basis by
which the project implementation will be monitored and managed.
The simplest milestones are the dates estimated for completion of
each Activity, for submission of deliverables, or for getting approval
by the client (acceptance of the product produced).
Time leads and lags: There are cases that a dependency between
two activities may require specification of a lead or lag to accurately
define the relationship.
There are many different approaches to scheduling. The steps can either be
done manually or a computer tool (software) can be used. Project Management
Software (like Microsoft Project, Primavera, etc.) is widely used to assist with
schedule development.
The project schedule includes at least the start and finish dates of each
activity and their duration (in days, weeks, months, etc.). It can also include
information concerning the responsible for the implementation of each action. It
may be presented in summary form or in detail graphically or in a tabular form.

Fill in the blanks.
1.
in project management include development of cost
plan, identification and estimation of costs, development of cost
schedule.
1.
The different processes in activity scheduling are:
i.
Identification of the activities
ii.
iii.
Determination of the activities' sequence and dependencies

Estimation of the activities/tasks duration
iv.
v.
Scheduling of the activities

Summation of all the activities
vi.
Reducing some of the activities
223
Notes
it- 3
f: Activity 1
:'t1/400v"v
Select any project and prepare a list of activities for the same and prepare
the activity schedule.
9.3 RESOURCE SCHEDULING

The resource scheduling includes following processes:
1.
Development of Resource Plan: The Resource Plan identifies the

physical resources that are needed to complete the project successfully
and schedules their usage during the project implementation period.
Obviously, in order to develop a resource plan, every activity and task
should have been identified. Generally, the resource planning should be
performed in parallel with the development of the activities schedule,
since the determination of the resource requirements affects directly
the estimation of the activities/ tasks duration. In order to develop the
Resource Plan, the following steps should be followed:
Identification of what types of resources (labour, equipment,

material) and in what quantities are required in order to perform
project activities and tasks.
Development of Resource Schedule by estimating when and for

how long each resource is going to be utilised.
Assignment of resources to specific project activities and tasks.

DoeW
ient
IdAlication
of types and
quantities of
flIttalifC011 .
__e ,
Rosourco
Schodulo
resources
project
activities!
Fig. 9.3: Development of the Resource Plan

For simple projects the development of a Resource Plan may be limited
to entering only the resource name against the project activity on the
Activities Schedule. However, for larger and more complex projects, a
detailed resource plan should be completed to ensure that the resource
allocation is both accurate and appropriate.
It should be noted that the assignment of sufficient resources both in
terms of quantity and appropriateness is a critical factor for the successful
outcome of the project. The assignment of less human resources
than actually needed to perform certain activities/tasks, as well as the
assignment of resources who do not possess the appropriate skills and
expertise to perform their duties, are two of the most common reasons for
project failure.
There are various software packages in the market, such as MS Project and
Primavera Project Planner (P3), which can be used to develop, monitor
and control a detailed resource plan.
224
2.
Identification of types and quantities of resources: Once the Work

Breakdown Structure (WBS) has been applied and the project activities
have been identified, you are ready to identify the types (labour, equipment,
material) and quantities of the resources needed to implement the project.
In order to identify the resource requirements the following steps should
be followed:
a.
Review the project scope and activities/tasks list in order to identify

the project's requirements for people, equipment and material
resources.
b.
Gather historical information from old project files, databases and

from people who have worked on similar projects, regarding what
types and numbers of resources were required for performing similar
work on previous projects, as well as the duration of the relative tasks.
c.
Consider how resource quantities, capabilities and quality affect

the duration of the activities/tasks. The duration of most tasks is
influenced by the number of resources assigned to them. In most
cases, particularly for production tasks, two resources can complete
a task in half the time it would take for a single resource. Similarly, a
resource working half time on a task will typically take about twice
as much time as the same resource working full time. However,
in other instances, for example, for design tasks, adding resources
does not guarantee that the duration will decrease. The duration of
most tasks is also influenced by the capabilities and experience of
the resources assigned to them. For example, a team member with
five years experience can typically be expected to complete a task
in less time than one with two years experience.
d.
As we collect information about the project in hand and other similar

projects, we will have to continue to refine the duration estimates for
the project tasks. The accuracy of the duration estimates is closely
related to the accuracy of your resource requirements.
e.
Identify the resource types and quantities needed. Once we have

collected all the necessary information, we will have to identify the
types of resources and the quantities needed for each. Generally, the
resources are distinguished in three main categories:
Labour (or Human Resources): It is not necessary at this stage

of the project to be identified by name, but the professional
qualifications and the type of skills required for carrying out an
activity/task should be identified. For example, there is no need to
specify that Mr. X will be used to elaborate the detail design for the
construction of a bridge, but you could say that one civil engineer
with relative experience in bridge construction projects is required.
Do not forget to identify the necessary resources required to perform
the project management tasks, such as the Project Manager, Quality
Manager, etc.
Notes
.225
Usually the quantity of a labour resource is measured by using the

term Full Time Equivalent (FTE). One FTE indicates one person
that will work 8 hours per day for 5 days per week. Respectively 0,
5 FTE indicates one person who will spend half of his full time in
the project. Another frequent measure of labour usage is the manmonths (mm) or the man-days (md) or the man-hours (mh) that the
resource is going Ito be used. For example, if you determine that
for the implementation of a specific task 3 mm of an architect are
needed, it means that this person will spend 3 months x 20 (or 21 or
22) days = 60 md = 480 mh for the implementation of this task.
Equipment: We have to list the equipment that will be used for

the performance of works (e.g., excavators, cranes), the delivery of
services or supplies (e.g., classrooms for the conduction of training
seminars, lorries for carrying supplies and warehouses for storing
supplies), as well as for carrying out supportive actions like project
and procurement management (e.g., computers, software packages,
photocopiers).
The quantity of equipment resources is defined either by the number
of units (e.g., 3 computers, 1 projector, 2 classrooms). In case of
external equipment resources and especially when these will be
leased or rented, it is important to define their usage time (e.g., rent
an excavator for three days, rent a special machine tool for some
hours, book a classroom for one week, etc.).
Material: We have to list the material that will be used for the
production of the ideliverables. For example, in case of a building
construction project, materials like bricks, cement, steel, cables,
paints will be used. Or in case of a training delivery project,
materials like paper for printing the training material and blank CDs
for distributing the training material to participants will be used.
In addition, material that will be used for project management and
procurement management activities should also be listed (e.g., paper
for printing the tender documents, posters to be used for publicity
actions of the project, etc.)
The quantity of material resources is defined using the appropriate
measurement units for each material. For example, 50 m of cable, 5
to of cement, 50 kg of plastic paint, 5000 sheets of printing paper,
100 blank CD-Rs, etc.
f.
226
Get expert's judgement. Once you have identified the types and
quantities of resources you should present the resource requirements
to an individual expert or a group of experts in order to assess
them and advise you for their suitability and appropriateness. Such
expertise and specialised knowledge may be acquired either from
other units within the agency (e.g., technical unit, HR unit) or/
and by external consultants or/and by professional and technical
associations or/and by industry groups.
g.
3.
Examine the adequacy of resources. Regardless of whether the project

will be implemented with own resources (in-house production) or it
will be contracted out to an economic operator through a tendering
process, you have to examine the sufficiency of the internal resources,
because even in the second case (outsource production) you will need
to involve internal resources for performing the project management
tasks in order to monitor and control the contractor. The sufficiency
of internal resources (i.e., those resources owned by the Implementing
Agency) should be examined both in terms of quantity, as well as
in terms of skills, experience and expertise with relation to project
requirements. Taking into account the result of adequacy examination,
as well as the organisational policies regarding staffing and the rental or
purchase of supplies and equipment you should decide whether there
is a need to acquire external resources. If, for example, there is a need
to use a legal advisor in performing some activities and there is not
such an expert in the Agency's staff, you will need to hire an external
advisor, or if for example there is a need of classrooms for conducting
training seminars and the Agency doesn't own any classroom or the
classrooms it owns are used for another project that given period, it will
have to rent them either from another agency or from a private entity.
Notes
Development of Resource Schedule: After receiving an expert's

judgement assuring you that the type and quantities of the resources that
have been identified are appropriate for achieving the project goals and
objectives it is time to estimate when and for how long each resource will
be utilised in order to develop the Resource Schedule.
In order to achieve this you should look at the starting and finishing dates
of the activities and tasks in which each of the resources will be used,
since at the end of the day the most important thing is to achieve effective
and on time completion of all planned activities and tasks. For example,
in a building construction project where you will need the architect for
the elaboration of the architectural study, you have to advise the Activities
Schedule for finding out when and for how long this task will take place,
in order to estimate the corresponding period that the architect will need
to be engaged in the project. For the same project the building equipment
& material will mainly be used in the construction stage, so you have to
schedule them according to when that stage will take place. Undoubtedly,
there are resources that will be used in more than one phases of the project
or in more than one activities/tasks, like for example the Quality Manager,
who is responsible for managing and assuring quality in all the phases
of the project. In these cases we should estimate the whole duration for
which the resource will be engaged.
The Resource Schedule developed in the planning phase is usually called
"Baseline Resource Schedule", since it will be used during the project
execution phase for tracking progress by viewing the variances between
the baseline estimates and the actual data
227
Notes
4.
Assignment of resources to project activities/tasks: Once we have

estimated when and for how long each resource will be needed in the
project we will have to assign them to specific activities/tasks of the
project in order to complete the development of the Resource Plan. When
assigning resources to activities/tasks we should take into account the
following factors in order to build a more effective Resource Plan:
i.
Availability of resources. The most important factor for deciding

which resource will be assigned to what activity(ies)/task(s), is the
potential availability of the resources in the periods the corresponding
activity/task will take place. This is especially important for the
internal resources and mainly for the human resources, since it's rare
for the employees of an Implementing Agency to be assigned only
to one project from start to finish with no additional responsibilities
outside the scope of a single project. For this reason you should
ask the functional manager or the head of the unit, who is directly
responsible for the management of the certain employee you want
to assign to the project, about his/her planned engagements in other
projects or activities of the Implementing Agency. Having examined
his/her availability for the specific period and after receiving the
relative approval from his/her superior you are able to assign him/her
to one or more activities/ tasks. Do not forget that availability doesn't
refer solely to the resource start and end dates in the project, but it
refers also to the amount of time that the resource is able to devote to
the project, i.e., whether the resource is working part or full time on
the project and whether his/her availability changes at any point.
The availability of external resources is something that is examined and

managed by the respective Project Manager of the contractor. What you have
to do in this case, as a representative of the Implementing Agency, is to define
the quality characteristics, quantities and required effort from these resources,
as well as the time periods in which these resources will be engaged in the
project and include them in the Terms of Reference and in the terms of the
contract. As general guidelines we should consider the following:
a.
Be realistic about the availability of resources. Allowance should be

made for official non-working days, holidays and time that people
will spend on non-project activities.
b.
Assign busier resources on tasks that cannot be performed by other

resources.
c.
Consider assigning additional resources on tasks in order to prevent

or alleviate over allocation.
d.
Use under allocated resources to help relieve the over allocated ones.
e.
Plan for contingencies in order to be prepared for potential situations.

For example, "What if I don't have 3 Visual Basic programmers in
June?" or "What if my only environmental engineer quits or becomes
disabled before his critical assignment to Environmental Impact
Assessment Study task in mid-July?" These potential situations can

be identified by a vigorous risk analysis, based on past experience
and perceptive forecasting. We may not be able to forecast specific
events, but we can note that the possibility exists. For this reasoni
alternative resources or/and skills should be identified and evaluated
outsourcing candidates should be contacted and evaluated trigger
dates for action decisions should be determined and auto alarms set
up potential scope adjustment options should be evaluated.
f.
Cost of resources: Apart from being effective in terms of schedule,

the Resource Plan should also be effective in terms of cost, since the
cost of the resources has usually a great contribution to the overall
cost of the project. In this perspective we should try to:
Assign more expensive resources to tasks that cannot be performed

by less expensive resources, so that you obtain the maximum return
from the use of resource.
Assign less expensive resources to as 'many tasks as possible to

keep the project within budget limitations, but without putting in
danger the successful outcome of the task.
g.
Capability of resources: The more familiar we are with resource

capabilities, the more efficiently and effectively we can assign the
resources to the tasks. Concerning the human resources you need
to understand their background, experience, skills and capabilities.
Concerning the equipment we have to be familiar with their operation,
performance and maintenance. As far as materials are concerned we
need to know their quality characteristics, their suitability for purpose
and the rate of consumption. In this perspective we should try to:
Assign the most efficient resources to critical tasks, to ensure that

your schedule does not slip.
Use the resources with the higher quality or the more effective resources
on high-risk tasks or tasks that require the highest level of quality.

1.
The different processes in resource scheduling are:

i.
ii.
Development of the resource plan

Identification of types and quantities of resources
iii.
Development of resource schedule
iv.
Assignment of resources to project activities/tasks
v.
vi.
Funding the resource plan

Crashing the resource plan
Notes
Notes
Pdiw Activity 2
Select any project and prepare a list of resources required for the project
along with the quantity and type of resources.
9.4 COST SCHEDULING

The preparation of cost schedule includes following processes:
1.
Development of Cost Plan: The Cost Plan is usually prepared after the
development of the Activities Schedule and the Resource Plan, since it
requires input from both of them. Based on the information now known
about the project as a result of Project Planning activities (i.e., more detail
and greater accuracy regarding project activities, tasks and durations, a
more detailed understanding of the resources required to perform the
work and their associated costs), the Project Manager can refine the
budget required to complete the project. This is particularly important
when a project or some of its components are planned to be performed
under contract (i.e., through a tendering process), since in this case
the value of the contract should be accurately estimated in order to be
included in the relative tender documents. The cost planning is also very
important in case that the project is implemented with own resources (inhouse production), since the establishment of a realistic and accurate cost
plan will help you to effectively monitor costs during the execution and
monitoring phase in order to stay within budget.
In order to develop the Cost Plan, the following steps should be followed:
Identification and estimation of costs that are expected to be incurred

in the project
Development of Cost Schedule by estimating when each of the

costs will be incurred
Estimation of cost per activity/task

Identificatior
and estimation
of costs
Development of
Cost Schedule
Estimation of
cost per
activity/ task
Fig. 9.4: Steps to be followed for the Development of the Cost Plan
For simple projects the development of a Cost Plan may be limited to
entering only the overall cost against the project activity on the Activities
Schedule. However, for larger and more complex projects, a detailed Cost
Plan should be completed to ensure that the overall expenditure is both
accurate and appropriate.
There are various software packages in the market, such as MS Project and
Primavera Project Planner (P3), which can be used to develop, monitor
and control a detailed cost plan.
230
2.
Identification and Estimation of Costs: The identification of the various

costs is closely related to the resource requirements of the project, since
the greatest percentage of the project's overall cost consists of the costs of
the resources needed to complete the project activities. When developing
a Cost Plan, apart from the costs of all resources that will be charged to
the project, we should also take into account travel costs, administrative
costs and contingency costs. More specifically, the basic types of costs,
which are usually incurred in a project, are the following:
i.
Costs of resources: This type of costs include the following

subcategories:
Labour costs: They are costs associated with labour resources

(both internal and external ones). They include salaries, wages or
any other kind of remuneration provided to people who are assigned
to perform one or more activities of the project.
Equipment costs: They are costs associated with the purchasing,

renting or leasing of equipment, as well as with the operation/using
and maintenance of the equipment (operating costs). In case that the
equipment resources are internal, there are no purchasing, renting
or leasing costs, but only operating and maintenance cost.
Materials costs: They are costs associated with the purchasing or

usage of materials.
iv.
Travel costs: They are costs associated with any travelling that may be
required in the scope of the project. They include transportation costs
(e.g., flight tickets, taxi fees, car fuel, parking fees, etc.), accommodation
costs (e.g., hotel rooms, apartments, etc.) and any daily allowances (e.g.
lunch/ dinner, entertainment).
v.
Administrative costs or overheads: These are the costs associated with

the performance of administration and coordination activities. Examples
of such costs are: office supplies (e.g., printing paper, envelopes, labels,
etc.), postage or delivery costs, costs for utilities (e.g., electricity, water,
telecommunication), clerical and administrative salaries and wages,
legal and insurance fees, memberships in technical and professional
organisations.
vi.
Contingency costs: These are the costs which, based on past experiences,
are known to be regularly encountered but difficult or impossible to
estimate at the time the plan is prepared. These costs may result from
incomplete design, unforeseen and unpredictable conditions, risks
or uncertainties within the defined project scope. The reason that they
are included in the Cost Plan is to reduce the risk of budget overrun.
Contingency costs may be either built into the above costs or listed as a
separate category.
Notes
After identifying the various costs it is time to estimate the value of each
cost. Depending on the way that they are estimated/calculated the resource costs
can be distinguished into three categories:
231
Notes
Rate-based costs: They are costs of resources that depend on the

amount of work to be done (in case of labour or equipment) or
on the consumption quantities (in case of materials). In order to
estimate the rate-based resource costs you should first estimate the
cost per unit and then multiply it by the number of units to calculate
the total value of each cost. In case that unit rates (e.g., staff cost
per hour or per day, rent cost of facility per day or per month, bulk
material cost per kg or per m3) are not known or predetermined,
then they have to be estimated. The estimation of unit rates can be
made using historical information like records of previous projects,
commercial cost-estimating databases and project team knowledge,
but in order to be more realistic and accurate they should be based
on recent data.
Per-use costs: This category applies mainly for equipment costs

and circumstantially for material costs. The per-use costs are onetime costs that are assigned each time the resource is used and do
not depend on the amount of work to be done. For example, rental
equipment might have a delivery or setup charge every time it is
used, in addition to an hourly charge. Another example of per-use
cost is the amount that has to be paid to the licensor of a material
(e.g., specialised software with per-use license) each time the
material is used.
Fixed costs: They are costs that remain constant regardless of the
task duration, the work performed by a resource, or the number of
assigned resource. units. A rate-based resource cost may increase
when a task takes more time, but a fixed cost does not. For example,
if a consultant is paid hourly and is scheduled to complete a task in
five days, but the task takes seven days, the consultant will be paid
more than planned. If the consultant is paid a fixed amount for the
work, then the cost will be the same no matter how long the task
takes.
Fixed costs can be assigned to a task in addition to rate-based
resource costs. For example, if the performance of a task requires
a machine that has to be purchased, the cost of purchasing that
machine is a fixed, cost, while the operating cost of this machine is
a rate-based cost.
For the estimation of the'rest costs (except from the costs of resources) we
can apply the following general guidelines:
232
Travel costs consist of a fixed part (transportation costs) and a

variable part (per-diem costs, i.e., accommodation, lunches/dinners,
etc.). So, in order to estimate the total cost of a travel you need to
know the exact destination in order to estimate the transportation
costs and its duration in order to estimate the per-diem costs. The
estimation of the travel costs is not always an easy exercise and
requires experience from previous projects in order to be in a
position to predefine how many travels and of what duration will be
necessary in the scope of a particular project. For this reason, you

should always reserve an amount in the contingency costs in order
to cover unscheduled travels.
Administrative costs or overheads (facilities and administration,

rent, electricity, depreciation, telephone, etc.) are indirect costs
that cannot be identified to a specific project or function. However,
these are actual costs that are incurred by an entity. They are usually
determined as a percentage of salaries and wages or as a percentage
of total direct costs. A commonly used method to estimate the
overheads is by dividing the yearly sum of all administrative
costs with the yearly sum of the "productive time" of the entity's
employees. In this way you can calculate an administrative cost
rate (Rs/hr or Rs/day) specific for your entity, which can then be
multiplied by the scheduled labour time (hours or days) for the
particular project in order to calculate the total administrative cost
of the project. Another method that will lead to more accurate results
but is more difficult to apply, is to estimate the administrative costs
that are expected to be incurred during the project period and then
apportion them to the project by taking into account the number of
employees and the amount of facilities that will be engaged in the
project.
Contingency costs: The traditional method to estimate contingency

costs is to consider them as percentage (%) of the total cost based
on experience and past data. Another method which is more rational
and reliable is to determine the contingency costs as alternative/
different percentages (%) to each major element of cost (e.g.,
labour, equipment, material, travels), based on the concept that each
element has its own uncertainty. These deterministic methods work
effectively for simple projects under stable conditions. For more
complex projects that involve great uncertainties, more advanced
methods of calculation should be used, such as quantitative risk
analysis, method of moments, Monte Carlo Simulation, etc.
Notes
Once all the elements of costs have been estimated, we can easily
estimate the overall cost of the project by summing up all the individual
costs. It should be noted that the estimated overall cost of the project
should not exceed in any case the approved budget. Any refinements of
the budget as a result of the cost estimating process are allowed only if
they don't cause an overrun of the budget. For example, the review of cost
estimates may bring up the need to make adjustments to the cost totals or/
and reallocations of costs between activities. These adjustments of cost
estimates should be done with respect to the overall budget of the project.
3.
Development of Cost Schedule: After we have estimated all costs, we

have to estimate when these costs are expected to be incurred during the
project implementation period and develop the Cost Schedule. In order to
determine when the resource costs will be incurred we should look at the
233
Notes
Resource Schedule to find out when each resource is planned to be used. In

case we have commercial software like MS Project to develop the Project
Plan, the cost schedule will be prepared automatically based on the schedule
that would have previously been prepared for the usage of resources and the
assignment of resources to specific tasks/activities. The only thing that we
have to do in this case is to assign cost rates and cost per-use to each of the
resources and then define the cost accrual method. Usually, there are three
available options for determining when the costs will accrue. We can either
select a cost to accrue at the start of a task (it is preferred when we have a
lump-sum amount payable at the start) or at the end of a task (it is preferred
when we are holding payment until the work is finished) or we can select
the prorated method according to which the cost is distributed over the
task's duration and the cost accrual is based on the completion percentage
of a task. It should be noted that per-use costs always accrue at the start of
a task. In case we do' not have specialised software for developing the Cost
Schedule, all the above actions should be made manually.
The accrual of fixed costs depends on the schedule of the activities to
which they are assigned. For example, the costs associated with a travel will be
incurred within the timeframe of the activity or task in the framework of which
the travel will take place. Another example is the cost for catering services that
will accrue within the timeframe of a training seminar. As with resource costs,
we can select the fixed cogs to be incurred at the start or finish of a task or we
can select the prorated accrual method.
As far as the administrative costs are concerned, they are either evenly
distributed over the project's duration or they are incorporated in the labour
costs following in this way their distribution in time.
The exact time that contingency costs may accrue cannot easily be
determined, since they are unpredictable costs. Therefore, they are either
incorporated (as a percentage) in the other categories of costs or more
frequently they are kept updistributed and if/when they eventually accrue they
are subtracted from the estimated total amount in order to track variances.
Based on the developed Cost Schedule, we can prepare the Cost Baseline
Graph that will be used to measure and monitor cost performance during the
project execution phase. The Cost Baseline graph is usually displayed in the
form of an S-curve as illustrated in Figure 9.5.
A
Cost Baseline
Cumulative
costs
Time
Fig. 9.5: Cost Baseline Graph (S-Curve)

The above graph represents the cumulative project costs in the time. In
order to prepare this graph we need to create an intermediate table that will sum,
for each time period of our schedule (week or month), the planned costs, and
calculate the cumulative cost for each period (week or month). A simple Excel
graph will then enable us to generate our Cost Baseline Graph. For cost schedule
estimate and monitoring we can use the concept of Earned value analysis.
f'CtV"si
Notes
Activity 3
List the different processes in cost scheduling.
9.5 EARNED VALUE ANALYSIS

Earned Value Analysis (EVA) is a project management technique that is
used for measuring project performance. It indicates how much of the budget
should have been spent, in view of the amount of work done so far, and the
baseline cost for the task, assignment or resource.
EVA was developed by the US Department of Defence to determine the
performance of large military procurement contracts. However, its techniques
are still applying even to small and simple projects.
EVA for large and complex projects can be performed with the help of
specialised commercial software, such as Microsoft Project and Primavera
Project Planner. However, a simple EVA for small projects can be performed
manually with the help of spreadsheets to speed up the calculations.
The basic methodology for performing EVA is described, based on the
guidelines provided by Microsoft Office Online Assistance. At the root of
earned value analysis are three fundamental values calculated for each task:
1.
Budgeted cost of work scheduled (BCWS): The budgeted cost of work

scheduled, which is the portion of the cost that is planned to be spent on
a task between the task's start date and the status date. For example, the
total planned budget for a 4-day task is 100 and it starts on a Monday. If
the status date is set to the following Wednesday, the BCWS is 75.
2.
Actual Cost of work performed (ACWP): The actual cost of work

performed, which is the total actual cost incurred while performing work
on a task during a given period. For example, if the 4-day task actually
incurs a total cost of 35 during each of the first 2 days, the ACWP for this
period is 70 (but the BCWS is still 75).
3.
Budgeted cost of work performed (BCWP): The budgeted cost of work

performed (BCWP), which is the percentage of the budget that should
have been spent for a given percentage of work performed on a task. This
is literally the value earned for the work performed. For example, if after
2 days 60% of the work on a task has been completed, you might expect
to have spent 60% of the total task budget, or 60.
235
Notes
Earned value analysis is always specific to a status date we choose. We

may select the current date, a date in the past, or a date in the future. Most of the
time, we will set the status date to the date we last updated project progress. For
example, if the current day is Tuesday, 25th July, but the project was last updated
with progress on Friday, 22nd July, we would set the status date to Friday, 22nd
July.
The following simple example describes how to analyse project
performance with earned value analysis.
Let's say a task has a budgeted cost (BCWS) of 100, and by the status
date it is 40% complete. The earned value (BCWP) is 40, but the scheduled
value (BCWS) at the status date is 50. This tells you that the task is behind
schedule, less value has been earned than was planned. Let's also say that the
task's actual cost (ACWP) at the status date is 60, perhaps because a more
expensive resource was assigned to the task. This tells you that the task is
also over budget more cost has been incurred than was planned. You can see
how powerful such an analysis can be. The earlier in a project's life cycle you
identify such discrepancies between ACWP, BCWP and BCWS, the sooner you
can take steps to remedy the problem.
From the above three fundamental values, several other key values are
determined. The most common and useful ones are:
Cost Variance (CV), which is the difference between a task's estimated cost
and its actual cost and is calculated using the following formula:
CV = BCWPACWP
Take our earlier example where the total planned budget for a 4-day task
is 100 and it starts on a Monday. When the status date is set to the following
Wednesday, the BCWS is 75, the ACWP for this period is 70, and the BCWP
is 60. In that case, the task's CV is -10
Schedule Variance (SV), which is the difference between the current progress
and the scheduled progress of a task, in terms of cost. The scheduled variance
is calculated using the following formula:
SV = BCWP BCWS
In the example above, the task's SV is -15.
Cost Performance Index (CPI), which is the ratio of budgeted costs to actual
costs and is calculated using the following formula:
CPI = BCWP
ACWP
In the example above, the task's CPI is about 0,86 or 86%.
236
Schedule Performance Index (SPI), which is the ratio of work performed to

work scheduled and is calculated using the following formula:
Notes
SPI BCWP
BCWS
In the example above, the task's SPI is about 0,80 or 80%.
One common way of visualising the key values of earned value analysis
is to use a chart. The following figure presents a snapshot of a typical EVA
chart and explains in graphic format the various key values of the earned value
analysis.
Ciiimilalive Cosi
ACWP
Cosi)
(Aducil
1\
CV
BCWS
(Planned Value)
SV
Time Now
Tune
Fig. 9.6: Earned Value Analysis Chart

Earned value indicators that are variances or ratios can help you determine
if there is enough money left in the budget and if the project will finish on time.
Variances, such as a cost variance (CV) and schedule variance (SV), can be
either positive or negative:
A positive variance indicates that the project is ahead of schedule or

within budget. Positive variances might enable us to reallocate money
and resources from tasks or projects with positive variances to tasks or
projects with negative variances.
A negative variance indicates that the project is behind schedule or over

budget and we need to take action. If a task or project has a negative CV,
we might have to increase our budget or accept reduced profit margins.
Ratios, such as the Cost Performance Index (CPI) and the Schedule
Performance Index (SPI), can be greater than 1 or less than 1.
A value that's greater than 1 indicates that the project is ahead of schedule
or under budget
A value that's less than 1 indicates that you're behind schedule or over
budget.
For example, an SPI of 1.5 means that you've taken only 67 per cent of
the planned time to complete a portion of a task in a given time period, and a
CPI of 0.8 means that we are spending 1,25 for every 1,00 of budgeted work
accomplished.
237
Notes
Resolving cost problems

Each time we update our Cost Schedule, we should review it to identify
cost problems or potential problems. Identifying cost problems will allow you
to take corrective actions to ensure that you will complete the project within
the approved budget. Since Cost Schedule is changing constantly we have to
analyse it each time you correct and refine it. In order to identify cost problems
it is suggested that we take following steps:
Review the baseline, actual and remaining costs to identify whether the
project will or will not stay within budget.
Review cost variances per type of cost or per task to find out when and
where the actual costs exceed or are less than the budgeted ones.
Find which types of costs are already over budget. Perform the same
exercise with the tasks' cost to find out if you need to make any reallocation
of resources (or costs) to stay within budget.
Perform Earned Value Analysis (EVA) to get reliable answers to the

questions "Is there enough money left in the budget to complete the
project?" and "Is there enough time left in the schedule to finish the
project on time?". EVA is the most commonly used method for measuring
project performance. It indicates how much of the budget should have
been spent, in view of the amount of work done so far and the baseline
cost for the task, assignment or resources.
After we have identified cost variances that occur over time, we should
take corrective actions to keep costs within budget. Before we make any major
changes, it is recommended that we save a backup copy of the initial cost
schedule, so that we can refer to it as we are making changes that may affect
costs of other resources or tasks.
In order to get an overview of options that are available keep costs under
control, we have to consider how quality affects costs. The changes that we will
make in our schedules to stay within budget depend mainly on our priorities.
For instance, we could choose to sacrifice quality by using less expensive
resources (e.g., people with less experience and skills, equipment with less
operational power, materials of lower quality, etc.) or by removing some of
the tasks we meant to accomplish. Alternatively, we could choose to spend a
little more money on quality resources, under the thought that those resources
will complete the task or project in significantly less time and probably with
less total cost. Regardless of the actions we decide to take to reduce costs, we
have to examine their effects on tasks, resources and quality of the deliverables.
We may also need to discuss the effect of these actions on quality with the
appropriate stakeholders. In order to keep costs within budget we can take the
following actions:
Replace, remove or adjust the resources assignments to reduce the cost

of tasks. When you've made new assignments or changed existing
assignments, you need to communicate these changes to the resources
who are assigned.
Reduce rates of resources (if this is possible), who are assigned to tasks
that are in danger of exceeding their budget. This can be possible only if
you have included profit or overhead in the cost rate.
Assign per-use costs more efficiently. This can be achieved, for instance,
by combining tasks (i.e., let them run together), which involve the use of
a resource with a per-use cost.
Reduce or remove overtime work to eliminate overtime costs. Have in

mind that when you reduce or delete overtime work, the duration of the
task may be longer.
Reduce unnecessary fixed costs. For example, you can cancel a travel that
is not so important for the progress of the work or reduce the number of
project staff that was scheduled to travel.
Reduce the scope by shortening a task's duration or by deleting tasks that

can be omitted. You may also need to remove resources when reducing
scope, keeping the cost of resources down.
Notes
Once we have taken actions to optimise the costs, we have to examine

their effects on:
Critical path to verify that the adjustments you made didn't affect it
adversely.
Project dates and costs to verify that the adjustments you made do not
adversely affect important dates or other costs
Resource allocation to verify that the adjustments you made do not cause
any over allocations or under allocations.
Other projects to verify that the adjustments we made do not adversely

affect other projects.
t ,
L t Activity 4
Give examples of the following from the industry:

1.
Earned Value Analysis (EVA)
3.
Cost Performance Index (CPI)
9.6 ESTIMATION OF COST PER ACTIVITY/ TASK

Apart from identifying when the various costs are likely to occur, it is also
important to identify the cost of undertaking each activity/task laid down in the
Activities Schedule. As with the development of the Cost Schedule this can be
done very easily and without much effort if we are using commercial software
like MS Project. In this case the estimation of cost per activity/task is done
automatically by the software, provided that we have assigned:
Resources to project activities/tasks
239
Notes
Cost rates and cost per-use to each of the resources
Fixed costs to project activities/tasks.
Once we have estimated the cost of each activity/task we should review

the total cost in order to verify that it falls within our budget. If the total cost
does not meet our budget, we may need to examine each individual task's
costs and each resource's task assignments to see where costs can be reduced.
As a result of this process we may come up with revised resource and Cost
Schedules or even with a revised Activities Schedule, since time, costs and
resources are interrelated. This means that applying changes to one of them will
cause respective changes to the others.
Summary
240
The project management process receives certain inputs (business need,

problem or opportunity) and constraints (time, cost, quality, technical
aspects, social, political and environmental conditions, legal restrictions,
etc.) and by applying the appropriate mechanisms (techniques, tools,
equipment, organisation, human resources, etc.) it produces specific
output (project deliverables).
A good project management requires perfect planning, organised

implementation and,analytical monitoring and control. For any project to
have good implementation, we need to understand following processes:
Activity scheduling which includes Identification of the Activities,

Determination of activities' sequence and dependencies, Estimation of
Activities'/tasks' duration and Scheduling of Activities.
Resource scheduling which includes Development of Resource Plan,

Identification of types and quantities of resources, Development of
Resource Schedule and Assignment of resources to project activities/
tasks.
Cost Schedules which includes Development of Cost Plan, Identification

and estimation of costs, Development of Cost Schedule.
Earned Value Analysis (EVA) is a project management technique that is

used for measuring project performance. It indicates how much of the
budget should have been spent, in view of the amount of work done so
far, and the baseline cost for the task, assignment or resource.
The basic methodology for performing EVA is based on the guidelines

provided by Microsoft Office Online Assistance. At the root of earned
value analysis are three fundamental values calculated for each task:
Budgeted cost of work scheduled, Actual Cost of work performed,
Budgeted cost of work performed. Earned value analysis is always
specific to a status date we choose. From the above three fundamental
values, several other key values are determined. The most common and
useful ones are: Cost Variance (CV), which is the difference between a
task's estimated cost and its actual cost, Schedule Variance (SV), which is
the difference between the current progress and the scheduled progress of
a task, in terms of cost, Cost Performance Index (CPT), which is the ratio
of budgeted costs to actual costs, and Schedule Performance Index (SPI),
which is the ratio of work performed to work scheduled.
Notes
3/ Keywords
Budgeted cost of work scheduled: Portion of the cost that is planned to

be spent on a task between the task's start date and the status date.
Actual cost of work performed: The total 'actual cost incurred while
performing work on a task during a given period.
Budgeted cost of work performed: The percentage of the budget that

should have been spent for a given percentage of work performed on a
task.
Earned value analysis: A project management technique which indicates

how much of the budget should have been spent, in view of the amount
of work done so far, and the baseline cost for the task, assignment or
resource.
Cost variance: The difference between a task's estimated cost and its
actual cost.
Schedule variance: The difference between the current progress and the
scheduled progress of a task, in terms of cost.
Cost Performance Index: The ratio of budgeted costs to actual costs.
Schedule performance index: The ratio of work performed to work

scheduled.
1.
What is project management process? Explain' with the help of inputs and
outputs.
2.
What is activity scheduling? Explain the process of activity scheduling.
3.
What is resource scheduling? Explain the process of resource scheduling.
4.
What is cost scheduling? Explain the process of cost scheduling.
5.
What is BCWP? How it is different from ACWP?
6.
What is ACWP? Explain the importance of ACWP compared to BCWP

for project monitoring.
7.
What is CPI? Explain the difference between CPI and SPI.
8.
How is cost estimation done for projects? What are the different types of
costs required to be considered for cost estimation?
241
Notes

Fill in the blanks.
1.
Cost schedules in project management include development of cost plan,

identification and estimation of costs, development of cost schedule.

1.
The different processes in activity scheduling are:

i.
Identification of the activities
ii.
Determination of the activities' sequence and dependencies
iii.
Estimation of the activities/tasks duration
iv.
Scheduling of the activities

1.
The different processes in resource scheduling are:

i.
Development of the resource plan
ii.
Identification of types and quantities of resources
iii.
Development of resource schedule
iv.
Assignment of resources to project activities/tasks
Suggested Reading
1.

McGraw-Hill.
Structure:
up
WI
10.1 Project Control Process
UNIT
10
10.2 Schedule Management

10.3 Resource Management
10.4 Cost Management
10.5 Quality Management
10.6 Issue Management
10.7 Change Management
10.8 Risk Management
10.9 Communication Management
10.10 Execution of Communication Plan/Distribution of Information
10.11 Reporting Project's Performance
10.12 Reviewing the Project Execution and Contr91 Phase
10.13 Closing Processes
Summary
Key Words
Suggested Reading
243
Notes
Monitor project progress
Identify the costs associated with the project
Analyse project monitoring techniques
Evaluate project monitoring indices
Identify project variances
10.1 PROJECT CONTROL PROCESS

Executing and controlling processes are the management processes
undertaken in the third and longest phase of project management life cycle,
where most resources are applied. It is the phase during which the deliverables
are produced and presented to the Contracting Authority for acceptance. To
ensure that the project's requirements are met, the Project Manager monitors
and controls the activities, resources and costs that are required for the
production of the deliverables throughout the execution phase. In this phase all
the plans, schedules, procedures and templates that were prepared during the
Planning phase are utilized to ensure that the project proceeds as planned. In
this perspective, the following management processes are undertaken:
244
Schedule Management: It is the process during which the actual progress

of the activities and tasks is being tracked and if needed corrective actions
are taken to bring tasks, activities or the whole project back on schedule.
Resource Management: It is the process during which the actual progress

of resources' work is being tracked and if needed corrective actions are
taken to resolve resource allocation problems.
Cost Management: It is the process during which the actual costs are
tracked against estimates and if needed corrective actions are taken to
keep costs within budget.
Quality Management: It is the process by which the quality of the

deliverables is assured qnd controlled, using the relative techniques and
applying the Quality Plan developed in the previous phase.
Issue Management: It is the process by which issues related to the project

are formally defined, assessed and resolved.
Change Management: It is the process by which changes to the project's

scope, deliverables, timescales or resources are formally defined,
evaluated and approved prior to implementation.
Risk Management: It is the process of keeping track of the risks identified

during the Initiation and Planning Phases, monitoring residual risks and
identifying new risks, ensuring the execution of risk plans (preventive
and contingency actions) and evaluating their effectiveness in reducing

risk.
Acceptance Management: It is the process by which the produced

deliverables are reviewed and accepted by the Contracting Authority
according to the Acceptance Plan.
Communication Management: It is the process by which information is

distributed to project stakeholders according to the Communication Plan
and project's performance is reported.
Notes
Issue
Manigement // I
Fig. 10.1: The Executing and Controlling Processes

Closing processes are the management processes undertaken in the last
phase of the Project Life Cycle. Their purpose is to evaluate the project
implementation and results, gather and document lessons learned and best
practices to be applied in similar future projects, plan any post project
review required and finally arrange the archiving of project's records. In
this perspective, the following processes must be undertaken:
Administrative Closure: It is the process during which all project records

are collected and archived and all the resources provided to the project are
being released.
Project Evaluation Review: It is the process during which the project is

being evaluated (Did the project achieve what it was intended to? What
worked well and what didn't?, Was the project management's quality
good?, etc.).
Post-project Review: It is the process during which the benefits achieved

by the project's products are being assessed after a period of use.
Normally the post-project review occurs outside the project. However,

for the completeness of the presentation it is described as part of the Project
Closure phase, since it is closely related to the project's outcomes.
Performance
of
Administrative
Closure
Conduction of
ProOct
Evaluation
Review
_Po
sit
r NNW,
Fig. 10.2: The Closing Processes
245
Notes
10.2 SCHEDULE MANAGEMENT

Schedule Management (or Schedule Control) is the process during which
the actual progress of the activities and tasks is being tracked and if needed
corrective actions are taken to bring tasks, activities or the whole project back
on schedule.
During the Planning phase, a baseline is established for the Activities
Schedule. This baseline will be used as a starting point against which performance
on the project will be measured. It is one of many tools that the Project Manager
can use during Execution & Control to determine if the project is on track. The
steps that are undertaken to manage the Activities Schedule are the following:
Record progress of activities and tasks by exchanging status information

with your Project Team Members and the Management Team of the
contractor.
Update the Activities Schedule on a regular basis to ensure that the

project is on track.
Identify and resolve schedule problems that may affect the project's
finish date.
> Record
progress of
activities &
tasks
Update the
Activities
Schedule
Identify and
resolve
schedule
problems
Fig. 10 3: Steps to be followed for managing the Activities Schedule
Fill in the blanks.

1.
is the process during which the benefits achieved by

the project's products are being assessed after a period of use.
are the management processes undertaken in the last
phase of the Project Life Cycle.
10.3 RESOURCE MANAGEMENT

Resource Management is the process during which the actual progress of
resources' work is tracked and if needed corrective actions are taken to resolve
resource allocation problems.
During the Planning phase, a baseline is established for the Resource
Schedule. This baseline will be used as a starting point against which resource
progress will be measured. In this way the Project Manager will be able to
monitor resource allocation and its impact on schedules and budgets, as well as
to take the necessary actions to ensure that the project is on track. The steps that
are undertaken to manage the Resources are the following:
-246
Record resource progress by calculating the total time actually spent by

labour and equipment resources and the actual consumption of material
resources to undertake the project activities/ tasks.
Update the Resource Schedule on a regular basis to ensure that the

resource progress is on track.
Identify and resolve resource allocation problems to get the best

performance and results from resources and. to ensure that the overall
project schedule won't be affected.
Notes
Fig. 10.4: Steps to be followed for managing Resources

1.
Factors affecting schedule management are:
\..
i.
ii.
Availability of raw materials

Labour
iii.
iv.
Machines & Equipment

Technology
Financial decisions
v.
vi. Managerial/Management decisions
Actv"Y Activity I
With an example from Infrastructural Projects, write how would you manage
your main resources deployed in the Project.
10.4 COST MANAGEMENT

Cost Management (or Cost Control) is the prodess during which the actual
costs are tracked against estimates and if needed corrective actions are taken to
keep costs within budget. During the Planning phase, a baseline is established
for the Cost Schedule. This baseline will be used as a starting point against
which financial progress will be measured. In this way the Project Manager will
be able to monitor cost variances and their impact on schedules and resources,
as well as to take the necessary actions to ensure that the project stays within
budget.
247
11.5M-1
The steps that are undertaken to control costs are the following:
Record actual costs (or expenses) based on resource and schedule

progress as well as on current cost rates.
Update the Cost Schedule on a regular basis to ensure that the financial
progress is on track.
Identify and resolve cost problems to ensure that the project stays within
budget.
Record actual
costs (or
expenses)
Update the
Cost
Schedule
Identify and
resolve cost
problems
Fig. 10. 5: Steps to be followed for managing Costs

Fill in the blanks.
and
1. Cost management is governed by

2.
PBP stands for
3.
Cost Reduction without compromising quality is done by
10.5 QUALITY MANAGEMENT

Quality Management (or Quality Control) is the process by which
the quality of the deliverables is assured and controlled, using the relative
techniques and applying the Quality Plan developed in the previous phase.
During the Planning phase, the quality criteria and standards for the project
deliverables were set, the requirements for established (by the Contractor)
quality management and assurance systems were defined and included in the
Tender Documents and finally the quality control process to be followed by
the Contracting Authority were established. During the Execution and Control
Phase, the Contracting Authority monitors if the Contractor implements the
quality assurance activities that the later has described in his offer while in
parallel monitors the quality of the deliverables submitted by the Contractor.
The steps that are undertaken to control quality are the following:
Monitoring of the quality assurance activities implemented by the

Contractor
Organising and implementing deliverable quality reviews.
Monitoring of the \\..

Organising S.
quality assurance \" Implementing
r
activities
deliverable
by
I:ga
re (ow
or
Fig. 10.6: Steps to be followed during the Quality Management

Monitoring of the quality assurance activities implemented by the
Contractor
Depending on the quality assurance activities that the Contractor is
supposed to implement, the Project Manager should:
Examine the Peer Review Report that normally has to be attached to the
Deliverable concerned and check whether all the information needed are
included.
Study the Progress Reports prepared by the Contractor and examine

whether the Contractor updates regularly the Project Schedule. If the
project timeline is not on track, the Project Manager has to determine
why this happens and take immediate action to remedy the problem.
Use a checklist to ensure that all the quality assurance activities defined in
the Contractor's offer (and consequently in the Contract and in the Project
Kick off document (or Inception Report) are being implemented.
This process helps the Project Manager to monitor what is being done
well, to identify real or potential issues and to suggest ways of improvement. It
is recommended to perform this process regularly during Project Execution and
Control Phase and of course at the end of the project.
Checklist for Contractor's Quality Assurance activities
The questions listed below are indicative of what the Project Manager
may ask to check is the consistency between what the Contractor promised and
what actually performs
Project management process and deliverables
Does the Contractor produce progress reports on the agreed intervals that
contain all the recommended components from the Tender Documents?
Is the project scope clear in the Project Inception Report? (Is it clear as to
what is "in" and "out" of the scope?
Is the Project Schedule defined sufficiently to enable the Project Manager

to monitor the task execution?
Was a project baseline established?
Is the project schedule maintained on a regular basis by the Contractor?
Has the Contractor prepared a Resource Plan?
Has the Contractor described at the Inception Report the quality standards
for the project and the quality assurance and control activities he is going
to perform?
249
Notes
Does the Contractor perform the quality assurance activities he is

supposed to?
Has the Contractor identified and prioritized possible risks of the project?
Has a mitigation plan been developed for each?
If any risks events have occurred to date, was the risk mitigation plan
executed successfully?
Have all the Project Management deliverables been approved by the

Project Steering Committee?
Deliverables
Do the deliverables produced so far meet the Contracting Authority's

needs?
Do the deliverables produced so far meet the objectives set in the Project
Fiche and in the Tender Documents?
Do the deliverables produced so far achieve the quality standards defined

in the Quality Plan?
It should be mentioned that except from monitoring the implementation

of quality assurance activities by the Contractor, the Project Manager should
also examine whether all the management activities planned to be implemented
by the Contracting Authority's Project Management Team in order to ensure
qualitative project implementation, are actually performed. In this perspective,
the Project Manager should use a similar to the above presented Checklist,
consisting of questions like the one that follow.
Project Management Process Checklist
Have you identified and assigned the appropriate resources for the
performance of project management activities?
Is the schedule progres's being monitored regularly to ensure that the

project is on track?
Is the resource and finanbial progress being monitored regularly to ensure

that there are not any resource allocation problems and the project is
within budget?
Does the project organisation ensure that decisions are taken in the
appropriate 'management level?
Does the Project Management Team take actions to mitigate risks?
Are regular project team meetings conducted? Are minutes of meeting

kept and disseminated after the meeting?
Are there any quality review mechanisms in place?
Are there any quality reviews being performed according to the plan?
Have Change Control Process been established and applied?
Has an Acceptance Management Plan been established and applied?

Does it describe explicitly the process to be followed to accept or reject
deliverables?
Are all the stakeholders aware of their involvement in the project?
Does the Communication Plan describe the method to be used for

communicating with all the stakeholders? Does it also indicate the
frequency of the communication?
Is the Project Progress Report being reviewed by the Project Steering

Committee?
Notes
A Deliverable Quality Review is a structured process designed to assess

the conformity of the deliverable against the quality criteria that have been set
in the Quality Plan.
There are three basic steps in a quality review, the activities of which are
described below:
a) Preparation
Confirmation that the product is ready for the review.
Definition of the date the review will take place.
Confirmation of the availability of the reviewers.
Making the product/deliverable available for inspection by the

reviewers. In case that the deliverable is a printed document, e.g.,
a study, a draft law, a guide, etc., a copy of the deliverable and its
description should be distributed to the reviewers.
Assessment of the product/deliverable against predefined quality

criteria by each reviewer and detection of suspected errors or
deficiencies.
Preparation of a list with the suspected errors and deficiencies.
b) Review meeting or preparation of list

This incorporates the comments of all reviewers. Depending on the
volume of comments and concerns, a review meeting can take place or
the Project Manager can study the individual lists with the comments
prepared by the reviewers and prepare a new one which incorporates the
remarks of all reviewers. In case that a review meeting takes place, the
following activities should be implemented:
Discussion, clarification and agreement on each of the points raised

by the reviewers.
Agreement on which points will be incorporated at the final Quality

Review Report.
Agreement on the follow-up actions needed for each agreed

deficiency.
Agreement on the content of the final Quality Review Report.
c) Follow up
Notification to the Project Steering Committee and the Contractor

of the Quality Review Result.
251
__L
In case of construction projects, the most important decisions regarding

the quality of a completed facility are made during the design and planning
phase. The Contractor normally submits to the Contracting Authority a plan for
the project implementation through which the component configurations, work
and material specification's as well as functional performance are defined and
agreed. Quality control in construction typically involves insuring compliance
with minimum standards of material and workmanship (contained in the above
mentioned work and material specifications) in order to insure the performance
of the facility according to the design. In this framework, quality reviewers of
the Contracting
Authority have to check the reports prepared by the Contractor during
the execution of the project and they might also perform on-site inspections.
Besides, random samples of materials can be tested in specialised laboratories
to insure compliance.
ActN'ti
Activity 2
Write with an example, the factors in Quality management of a Project.
10.6 ISSUE MANAGEMENT

Issue Management involves capturing, reporting, resolving, escalating
and tracking issues that occur as a project progresses in accordance with the
Issue Management Plan.
Anyone involved in the project can and should inform the Project
Manager of identified issues. It is the responsibility of the Project Manager
to foster an environment where communicating issues is strongly encouraged.
If individuals are fearful of communicating issues the resulting effect on the
project can be extremely serious.
The Project Manager should capture and track issues as soon as they arise
using the Issue Log. Once a description of a new issue has been logged, the
Project Manager should estimate the potential impact that the issue could have
on the project. Based upon potential impact the Project Manager must prioritise
the issue in relation to all other open issues. The goal of issue management is to
resolve all problems completely and promptly, but in reality the issues with the
highest priority should be addressed first.
It should be noted that the urgency and the importance of a project issue
are not the same thing. The Project Manager must deal with urgent project
issues quickly, whereas with important issues comprehensively.
The Project Manager or the Project Steering Committee (depending on
the limits authority to handle issues) may decide either:
Q,52 I
To assign resolution actions, or
To raise a project risk if the issue is likely to impact the project in the
future, or
To raise a change request (or ask the Contractor to raise a change request)
if the issue results in the need for a change to the project/contract, or
To close the issue if this is not impacting the project anymore.
Notes
The Project Manager should monitor the implementation of the resolution

actions and update the Issue Log to reflect what has occurred. As issues are
closed their status should be changed to "closed" and the name of the person
who resolved the issue, as well as the closure date should be documented.
The Project Manager should review periodically the Issue Log to identify
the issues that have not been resolved till that moment. All open issues should
be reviewed and discussed at the next status meeting since unresolved issues
are one of the most important reasons for project failure.
10.7 CHANGE MANAGEMENT

Change Management is the process by which changes to the project's
scope, cost, time scales or resources are formally defined, evaluated, approved
prior to implementation and finally controlled.
The change management process that is recommended to be used by the
Contracting Authorities in case of projects being implemented with internal
resources is the following:
One of the individuals authorised to be a requestor identifies a requirement

for change to any aspect of the project and completes a Change Request
Form, which is then submitted to the Project Manager.
The Project Manager registers the change request in the Change Log and
assigns to it an ID.
He/she then analyses the request, examines its complexity and whether
the change is feasible or not. He/she also assesses the full impact of the
change to the project and defines in detail the change requirements, costs,
additional resources needed and risks.
The Project Manager based on the analysis performed, recommends to

the Project Steering Committee the acceptance or reject of the change and
documents this recommendation on the Change Request Form.
The Project Steering Committee, which is responsible for approval,

reviews the available information and taking into consideration the
project manager's recommendation decides whether to approve or reject
the change requested. The decision is recorded in the minutes of meeting
which are validated in the next meeting of the Project Steering Committee.
In case that the change request has been approved, the Project Manager
must incorporate the effect of the change into the appropriate Plan (e.g.,
in the Activities Schedule and the Resources Plan if the whole duration of
the project is prolonged, in the Cost Plan if the budget has been changed,
etc.) and update the Change Log.
253
Notes
The above-presented process can similarly be followed in case of projects

being implemented by contractors. However, in case of projects contracted out
by Ministries or Services or Departments of Ministries or Independent Offices,
there could be following competent bodies to handle the change requests
depending on the limits of authority granted to each one of them:
The Coordinator in Charge or the Competent Official (the Project

Manager)
The Departmental Committee for Variations and Claims and the central
committee for variations & claims.
10.8 RISK MANAGEMENT

Risk Management is the process of keeping track of the risks identified
during the Initiation and Planning Phases, monitoring residual risks and
identifying new risks, ensuring the execution of Risk Plans (preventive and
contingency actions) and evaluating their effectiveness in reducing risk.
The steps that should be undertaken to manage risks are the following:
. .. --------
Risk Monitoring
Risk Control
NN,
Risk
Monitoring
Risk Control
Fig. 10.7: Steps to be followed for managing Risks

As the project matures, the risks change. Anticipated risks may disappear
while new ones emerge. Therefore, the Project Manager must continually look
for new risks, reassess old ones and re-evaluate risk mitigation actions.
More specifically, the purpose of risk monitoring is to:
254
Determine if identified risks have occurred and risks responses have been
implemented as planned
Evaluate if the planned risk response actions were as effective as expected

and so estimate if new actions should be developed
Examine if some of the initial identified risks are no longer valid
Identify if the risk probabilities have changed the expected level of impact
is different or the date of impact may be sooner or later than the original
anticipated
Make sure that the preventive/contingency actions planned to be performed

still make sense in the context of the latest project developments and
that these actions are assigned to the appropriate in terms of skills and
position, project team members
Determine if risk exposure has changed from its prior state and then
analyse the new trends
Identify if new risks that were not previously identified have arisen or
even worse occurred
Notes
In order to perform successfully risk monitoring the Project Manager

should regularly perform formal project risk reviews and risk response audits
and then update the Risk Log.
In project risk reviews the whole Project Team should be involved
since every team member has his own expertise and knowledge raised via
his participation at the implementation or management of specific tasks and
activities. All the risk review findings (changes to risks prioritization, risk
disappear, new risks, actions taken etc) should be registered in the Risk Log
thus updating it.
The risk response audits examine the effectiiieness of the risk response in
avoiding or mitigating risk occurrence. Implementation of risk control actions
may not eliminate the identified risks but reduce their impact or probability. In
this case all the risks must be reassessed so that the new most important risks be
identified and prioritised to be controlled.
Risk Control
Risk control refers to the implementation of the preventive or contingency
actions defined in the Risk Plan, to the development of alternative strategies for
risk mitigation or even to the re-planning of the project.
When a predefined risk occurs the Project Manager must normally invoke
the Risk Management Plan and implement the actions described there. There
are generally three possibilities:
The risk occurs as expected and the risk control actions defined in the
Risk Management Plan are proven adequate for dealing with it.
The risk occurs in a different manner and consequently the risk control
actions must be modified appropriately
A new unexpected risk is revealed, so the Risk Management Plan must be

updated to define and describe the appropriate actions for mitigating it.
It should be noted that during the entire risk management process, the
Project Manager should be especially vigilant regarding the effect on the
project's scope, cost, schedule and quality. With the appropriate contingency
plans established, many risks may not affect the above-mentioned basic
parameters of the project. However, when a risk event occurs that threatens one
or more of these parameters, the Project Manager must determine the actions to
be implemented in order to protect the project's integrity. In this perspective, a
change request may be issued which has to be managed formally according to
the predefined Change Management process.
povity Activity 3
Enlist with example from Projects, factors affecting risk management.
255
Notes
10.9 COMMUNICATION MANAGEMENT

Communication Management is the process by which information is
distributed to project stakeholders according to the Communication Plan and
project's performance is reported. During the Planning phase, a Communication
Plan/Matrix should be developed to describe which type of information will
be distributed and how project communications will occur during the Project
Execution phase. However, as the project progresses, events may occur that will
alter the way information is accessed or change communication requirements.
Therefore, the Project Manager, with the help of project team members, should
regularly review the initial Cbmmunication Plan and update it whenever it's
necessary to retain it applicable to the project.
The main processes that are undertaken in the framework of communication
management are the following:
Execution of Communication Plan and distribution of information.
Reporting project's performance by collecting and disseminating

information to stakeholders regarding the current (and future) status and
progress of the project.
Execution of \
Communication
Plan/ Distribution
of information ;/
Reporting
Prolat's
Performance
Fig. 10.8: Processes undertaken in the Framework of Communication

Management
10.10 EXECUTION OF ' COMMUNICATION PLAN/

DISTRIBUTION OF INFORMATION
During project execution, the Communication Plan is implemented so that
required information is made; available to the appropriate stakeholders at the
appropriate times and new communication requests receive a prompt response.
Following the Communication Plan ensures that all stakeholders are aware of
their communication responsibilities. The more information stakeholders have
regarding a project or deliverable, the less likely last minute conflicts, changes
or complaints will affect the project.
Communication is a bi-girectional process used to exchange information.
On the one hand, the Project Manager has to provide required information to
the project team members and appropriate stakeholders on a timely basis and
on the other hand the project team members and the stakeholders must provide
required information to the Project Manager. In this perspective, it is very
important that both sides (sender and receiver) exercise good communication
skills. The sender of information is responsible for making the information
clear, unambiguous and complete, so that the receiver can receive it correctly
and understand it properly. The receiver, in turn, is responsible for making sure
that the information is received in its entirety and understood properly.
?,,k6
The overall project communication can be improved by adhering to the

following communication guidelines:
Base communication strategies on stakeholder needs and feedback.
Ensure that communication is shared in a timely manner.
Promote an open, honest and face-to-face communication.
Create an environment where project team members and other stakeholders

can constructively exchange information and ideas.
Remember that communication is a two-way process. Listen as well as

deliver the message.
Involve senior management when appropriate.
Coordinate communication with project milestone events, activities and

results.
Conduct regular reviews and assessments of the Communication Plan.
Take advantage of existing information retrieval systems, communication

mechanisms, and opportunities.
Notes
Project information can be retrieved from various types of systems, such as

manual filing systems, electronic databases and project management software.
Information can be shared using a variety of communication mechanisms that
were defined during the Planning phase and documented in the Communication
Plan. These mechanisms may include project meetings, status and progress
reports, hard-copy document distribution, electronic mail, etc.
While executing the Communication Plan, the Project Manager must be
aware of how information will be used by the stakeholders and whether the
plan is effective. The Project Manager must be flexible and ready to modify the
plan if it doesn't work as expected or if the communication needs change, as the
project progresses and information on its performance is updated.
10.11 REPORTING PROJECT'S PERFORMANCE

Performance reporting involves collecting, processing and communicating
information to key stakeholders, regarding the performance of the project.
Performance reporting can be conducted using various tools and techniques,
most of which have been already described in the previous paragraphs. The
most widely used techniques for performance reporting are:
Performance review meetings that take place to assess the project's

progress or/and status.
Variance analysis which is about comparing actual project results (in terms
of schedule, resources, cost, scope, quality and risk) against planned or
expected ones.
Earned Value Analysis (EVA) used to assess project performance in terms

of time (schedule) and cost (or resources).
Notes.
Financial and Output Performance Indicators used to measure financial

and physical progress of the project.
Information of project's performance is usually communicated via

Progress Reports and Project Status Reports which are described in the
paragraphs below.
The use of a Progress Report
The Progress Report is a document prepared by the project team members
(in case of in-house production) or by the Management Team of the Contractor
(in case that the implementation of the project is totally outsourced) to provide
regular feedback to the Project Manager regarding the progress of the project.
Progress reports should be submitted on a regular basis to enable the Project
Manager to update the Activities' Schedule, identify any schedule problems or
potential problems and act proactively for their resolution. Progress Reports
are usually asked to be submitted every two weeks or every month, when the
project is implemented with own resources. However, in case that the project
is implemented by a Contractor, the progress reports are usually asked every
three or six months. Generally, a Progress Report should include the following
information:
Typical contents of a progress report
i.
Reporting period to which it refers
ii.
Project Title
iii.
Project Manager's rime
iv.
Authors of the report (or name of the contractor if applicable)
v.
Date of submission
vi.
Project synopsis (i..e., project goals and objectives, expected results,

project activities, duration, etc.)
vii.
Project progress in the reporting period (i.e., activities/tasks executed,

actual work accomplished, deliverables submitted, deviations for baseline
schedule, estimation of the effort required to complete activities/tasks)
viii. Work programme for the following reporting period (i.e., activities/tasks
to be executed, deliverables to be submitted, schedule estimates for key
milestones, etc.)
ix.
Updated/revised Activities Schedule showing the percentage of work

completed so far and the estimated start or finish dates for activities/tasks.
Depending on the specific monitoring requirements of the project, the

Progress Report may include also additional information regarding resources
and costs. For example, if you have a fee-based service or work contract with an
economic operator (Contractor), you will need to gather information regarding
the actual time spent by labour resources. So, in that case you should ask the
Contractor to attach the relative timesheets. Another example could be when
you want to track actual costs incurred by the resources, where you have to
258
collect information on time spent labour resources; usage time of equipment

resources, used quantities of materials, travel or any other incidental expenses.
Notes
In case of small projects with only few team members, the Progress
Report can be substituted by personal judgment and observations of the Project
Manager or by day-to-day discussions with the team members on the progress
of the deliverables. On the contrary, in case of large and complex projects, where
progress reporting is an important aspect of communication management, the
Progress Reports should be formally submitted to the Project Manager by the
Team Manager(s) (or by the Contractor), who have to prepare them by collecting
the relative progress information from individual team members.
The use of a Project Status Report
The project status report is a document prepared by the Project Manager
using the information provided by the progress reports to present the status of
the project to key stakeholders, including the project steering committee, the
project owner and the funding agency. Depending on the duration and the size
of the project, as well as on specific communication requirements of the project
owner or/and the funding agency, the status report can be prepared monthly,
quarterly or biannually. Usually, status reports are prepared with the same or
less frequency than progress reports since they require input from them. The
aim of the project status report is to:
Provide an overview of project's progress up to date
Ensure that the key stakeholders are regularly informed on the progress of
the project
Inform the key stakeholders about issues that require immediate action or
resolution
Generally, a project status report should include the following information:
Overall status of the project

Status of Activities Schedule
Status of Resource Schedule
Status of Cost Schedule
Status of Quality and Acceptance of Deliverables
Status of Risks
Status of Issues
Recommendations to the recipients of the report about actions or decisions

that they should take in order to keep the project on schedule or bring it
back on schedule, to keep costs within budget, to mitigate or eliminate
risks or to close any pending issues
Work programme and objectives for the next reporting period
Other documents that can be attached to the Status Report are: Status Gantt
Chart, Notes of meetings, Quality Review Reports, Deliverable Acceptance
Forms, Risk Log, etc.
259
Note's I
The report should include only summarised information which is relative

to the recipients of the Project Status Report. In case of large projects several
other reports may be generated over the project execution period, which can
focus on specific management processes providing more detailed information
on a certain topic. For example, the Quality Manager may prepare and
submit to the Project Manager on a monthly basis a report with the results of
the performed quality reviews. Or the Project Manager may have to submit
an analytical Financial Report to the Funding Agency on a quarterly basis to
inform them about the financial progress of the project and the percentage of
funds' absorption.
Normally, the Status Report becomes the point of discussion for the Status
Meeting, which is a regularly scheduled event, where the Project Manager
presents the status of the project to the Steering Committee (and maybe to
the Project Owner or/and the Funding Agency). In these meetings the Project
Manager can invite members- of the Project Team who have expertise in a certain
area of the discussion. It is, however recommended that the Project Manager
invites periodically the Project Team to review the status of the project, discuss
their accomplishments and communicate any issues or concerns in an open,
honest and constructive forum. On large projects where gathering the entire
team is not always possible, the Project Team members can be represented in
the meeting by the respective Team Manager(s), who can communicate the
status of their team work since they have a better insight into the day-to-day
activities of their team members.
10.12 REVIEWING THE PROJECT EXECUTION AND

CONTROL PHASE
Given below is the summary checklist that can be used for reviewing
the activities of the Execution and Control Phase in order to ensure that all
requirements of the phase are met.
Checklist: Reviewing the Project Execution and Control Phase
Sr. Critical Questions
Yes No N/A
No.
Schedule Management
1. Is the progress of the activities/tasks being recorded?
2. Is the Activities Schedule being updated regularly?
3. Is the Activities Schedule being reviewed to identify
problems or potential problems with task schedules?
Resource Management
4. Is the resource progress being recorded?
5. Is the Resource Schedule being updated regularly?
6. Is the Resource Schedule being reviewed to identify
and resolve resource allocation problems?
260
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
Cost Management
Are the actual costs (expenses) being recorded?
Is the Cost Schedule being updated on a regular basis?
Is the Cost Schedule being reviewed to identify and
resolve cost problems?
Quality Management
Are the quality assurance activities implemented during
the execution of the project being monitored?
Are the deliverable quality reviews being organised and
conducted regularly?
Are the results of the deliverable quality reviews being
documented?
Issue Management
Are the project issues being formally identified and
raised?
Is issue management process being applied when
necessary?
Change Management
Are changes to project's scope, cost, deliverables,
timescales or resources being formally identified and
requested?
Is change control process being applied when necessary?
Risk Management
Are the risks being monitored according to the processes
defined in the Risk Plan?
Are the risk mitigation actions being evaluated in terms
of their effectiveness?
Are the preventive or contingency actions defined in
the Risk Plan being applied?
Acceptance Management
Are the produced deliverables being reviewed and
accepted according to the Acceptance Plan?
Communication Management
Is information being distributed according to the
Communication Plan?
Are Project Status Reports being prepared regularly by
the Project Manager?
Are Project Progress Reports being prepared and
submitted regularly to the Project Manager?
Is the project's progress and performance being
communicated?
`milm = Activity 4
Prepare a checklist for reviewing the performance of the contractor.
Notes
Notes
10.13 CLOSING PROCESSES

Closing processes are .the management processes undertaken in the
last phase of the Project Life Cycle. Their purpose is to evaluate the project
implementation and results, gather and document lessons learned and best
practices to be applied in similar future projects, plan any post project review
required and finally arrange the archiving of project's records. In this perspective
the following processes must be undertaken:
Administrative closure: It is the process during which all project records

are collected and archived and all the resources provided to the project are
being released.
Project evaluation review: It is the process during which the project is
being evaluated (Did the project achieve what it was intended to? What
worked well and what didn't? Was the project management's quality
good?, etc.)
Post-project review: It is the process during which the benefits achieved
by the project's products are being assessed after a period of use.
Performance \ Conduction ef
Project
of
Evaluation
/ Administrative
Closure, . Review
__..z..: .
rev! ow
Fig. 10.9: The Closing Processes

Normally the post-project review occurs outside the project. However,
for the completeness of the presentation it is described as part of the Project
Closure phase, since it is closely related to the project's outcomes.
Performance of Administrative Closure
During this process the Project Manager has to:
Check whether there are any unfinished businesses at the end of

the project and document them in a Report called Follow on Action
Recommendations.
Ensure that all the deliverables of the project have been produced, accepted
and approved by the appropriate organization structure (e.g., Acceptance
Committee, Project Ste&ing Committee, etc.)
Complete and archive all project information, notify all involved parties
that the project is to be closed and therefore the resources committed are
being disbanded
Update the CVs of the human resources involved in the project and
evaluate their performance.
Identifying
follow - on
actions
Ensuring that el
lho deliverables
have been
accepted
Completing 8.
archiving all
project
information
Disbanding the
-, resources
/ used In the
project
Updating the CVi

of the human
resource'
involved
Notes
Fig. 10.10: Steps to be followed during the Administrative Closure of the

Project
Identifying Follow-on Actions
The aim of this step is to identify actions required following the project.
At the close of the project there may be a number of actions left pending.
For example, there may have been a number of requests for change that the
project steering committee decided not to implement during the project but that
were not rejected not all expected products may have been handed over or a
product may have been delivered with problems.
All pending issues regardless if they may lead to new projects or
improvement to the products of the current project during its operational life,
as well as risks that may affect the product in its useful life should be recorded
in a document called "Follow-on Action Recommendations". In this document,
except for presenting any "unfinished business" the Project Manager should
include recommendations for actions to be undertaken by the operational
support group.
Completing and archiving all Project Information
Throughout the course of the project, the Project Manager should have
maintained a project archive. As the project progressed, the purpose of the
archive was to create a central point of reference for all project materials to be
used by anyone involved in the project. Once the project comes to an official
close, the archive provides an audit trail documenting the history and the
evolution of the project.
During Project Closure, the Project Manager should examine whether
the correspondence exchanged, the project management documentation (like
project plan, risk plan, quality plan, acceptance plan, risk log, acceptance
forms, project status reports, project evaluation report, etc.), the project related
material, the deliverables (e.g., in case of studies, training material, draft of
laws, procedures manual, etc.), change request forms, approvals and decisions
taken have been indexed. If any of the above-mentioned material is missing,
the Project Manager should try to find and file it. The archive must be in both
electronic and hard copy forms.
Project Archive, apart from permitting future audit of the project's actions
and performance, may be useful to future project managers and of course to
those who later may carry out post-project review in order to assess achievement
of the benefits claimed in the Business Case. The following list presents the
typical contents of the project archive:
' 263
Notes
Checklist: Project contents that must be included in the project's archive

i.
Project Material
ii.
Business Case
iii.
Cost Benefit Analysis (if applicable)
iv.
Feasibility Study (if applicable)
v.
Project Fiche
vi.
Project Fiche for EU funding (if applicable)
vii. Approval for EU funding (if applicable)

viii. Tender Announcement (if applicable)
ix.
Tender Documents (if applicable)
x.
Contract (if applicable)
xi.
Activities Schedules (baseline and updates)
xii. Resource Plan (baseline and updates)

xiii. Cost Plan (baseline and updates)
xiv. Quality Plan
xv.
Risk Plan
xvi. Risk Log

xvii. Acceptance Plan
xviii. Communication Plan
xix. Inception Report (if applicable)
xx.
Project Progress Reports
xxi. Project Status Report

xxii. Expense Forms (if applicable)
xxiii. Timesheets (if applicable)
xxiv. Invoices and payments
xxv. Quality Review Reports
xxvi. Acceptance Forms
xxvii.Change request forms
xxviii.Letter of approval or rejection of change
xxix. Minutes of meetings,
xxx. Correspondence, including decisions, memos, letters, etc.
xxxi. Deliverables (if applicable)
xxxii.Project Evaluation Report
264
Disbanding the Resources used in the Project
Notes
During this step the Project Manager recommends to the Project Steering
Committee that the resources that were working for ,the project can be released
and that the support infrastructure can also be withdrawn. He/she also prepares
notification to any parties identified in the Communication Plan as needing to
be told about the project closure. Before sending the project closure notification
the Project Manager needs confirmation by the Steering Committee.
Updating the CVs of the Human Resources involved in the Project
During the course of the project, Project Team members most likely
improved their skills and qualifications or obtained,new ones. The investment
made in improving an individual's skills should not be lost. The Project Manager
is responsible to ensure that the CVs of the project team members have been
updated to include the reference of the project they participated, description of
their exact role and finally any skills newly developed. As it is obvious, up-todate CVs may become invaluable to future Project Managers when attempting
to staff appropriately their projects.
Finally, the Project Manager in cooperation with Team Managers (if the
project organisation includes this role) must evaluate the performance of each of
the project team members and then document their judgement by completing a
relative form. This evaluation form can then be submitted to each Project Team
Member's supervisor in order to be used as input to performance appraisals.
Conduction of Project Evaluation Review
During this process, the Project Manager evaluates the product produced,
the project management processes and in addition he/she gathers accumulated
experience, best practices and performance trends in order to communicate
them via the Project Evaluation Report.
In order to conduct the Project Evaluation Review, the Project Manager
has to:
Conduct project evaluation
Prepare the Project Evaluation Report

Conduct
Project
Evaluation
Prepare the
Project
Evaluation
Report
Fig. 10.10: Steps to be followed for Project Evaluation

Conduction of Post-project Review
Many project products should be re-examined after a period of use to
check the achievement or not of the benefits expected. For example, when you
implement a business process reengineering project you will have to wait for a
few months after the completion of the project in order to identify, e.g., whether
265
Notes
the administrative costs have been reduced and the productivity has been
increased. Similarly, when we run a project for the expansion of the railway
network we have to wait a year or more in order to realise whether the number
of passengers served by it is increased and the traffic in the respective highways
and roads has been diminished.
If this is the case, a recommended date should be defined for conducting
the post project review. Besides a plan should be prepared which should define
the following:
What benefits will be measured? (These benefits should have been

previously defined in the Business Case.)
How will the achievement of these benefits be measured? (Usually the

achievement of the benefits is measured using Impact Indicators that have
been established during the Planning Phase.)
Who will carry out the' measurements? (It is not necessary to name certain
individuals but you could describe the required skills.)
Reviewing the Project Closure Phase

This includes a summary Checklist that can be used for reviewing the
activities of the Project Closure Phase in order to ensure that all requirements
of the phase are met.
Checklist: Reviewing the Project Closure Phase
A/A Critical Questions
1,
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
266
Yes No N/A
Administrative Closure
Have any follow-on actions been identified?
Have all the project deliverables been accepted?
Is all the project information collected and archived?
Have all parties that were involved in the project been
notified about the project closure?
Have the resources that were utilised during the
implementation of the project been released?
Have the CVs of the project team members been updated
with their role in the project and the skills they obtained?
Project Evaluation Review
Has a project evaluation review been performed?
Has a Project Evaluation Report been prepared?
Has the Project Evaluation Report been distributed to the
appropriate stakeholders?
Have lessons learned been identified and documented?
Post-roject Review
Is a post-project review necessary to identify if the
expected benefits have been achieved?
Have the benefits to be measured been defined?
Has the methodology/technique to be used for measuring
the achievement of the expected benefits been determined?
Note's
i:f\ctvm
Activity 5
4 L
Prepare a checklist for reviewing the performance of the project.
Summary
To ensure that the project's requirements are met, the project manager
monitors and controls the activities, resources and costs that are required
for the production of the deliverables throughout the execution phase.
In this phase all the plans, schedules, procedures and templates that
were prepared during the planning phase are utilised to ensure that
the project proceeds as planned. In this perspective, the following
management processes are undertaken: schedule management, resource
management, cost management, quality management, issue management,
change management, risk management, acceptance management and
communication management.
Closing processes are the management processes undertaken in the last

phase of the Project Life Cycle. Their purpose is to evaluate the project
implementation and results, gather and document lessons learned and
best practices to be applied in similar future projects, plan any postproject review required and finally arrange the archiving of project's
records. In this perspective, the following processes must be undertaken:
administrative closure, project evaluation review and post-project review.
During Project Closure, the Project Manager should examine whether the
correspondence exchanged, the project management documentation, the
project related material, the deliverables, change request forms, approvals
and decisions taken have been indexed. If any of the above-mentioned
material is missing, the Project Manager should try to find and file it. The
archive must be in both: electronic and hard copy forms.
Keywords
Schedule management: The process during which the actual progress of

the activities and tasks is being tracked and if needed corrective actions
are taken to bring tasks, activities or the whole project back on schedule.
Resource management: The process during which the actual progress

of resources' work is being tracked and if needed corrective actions are
taken to resolve resource allocation problems.
Cost management: The process during which the actual costs are tracked
against estimates and if needed corrective actions are taken to keep costs
within budget.
267
Notes
Quality management: The process by which the quality of the deliverables

is assured and controlled, using the relative techniques and applying the
Quality Plan developed in the previous phase.
Issue management: The process by which issues related to the project

are formally defined, assessed and resolved.
Change management: The process by which changes to the project's

scope, deliverables, timescales or resources are formally defined,
evaluated and approved prior to implementation.
Risk management: The process of keeping track of the risks identified

during the initiation and planning phases, monitoring residual risks and
identifying new risks, ensuring the execution of risk plans (preventive
and contingency actions) and evaluating their effectiveness in reducing
risk.
Acceptance management: The process by which the produced deliverable

are reviewed and accepted by the Contracting Authority according to the
Acceptance Plan.
Communication management: The process by which information is

distributed to project stakeholders according to the Communication Plan
and project's performance is reported.
Administrative closure: The process during which all project records are
collected and archived and all the resources provided to the project are
being released.
Postproject review: The process during which the benefits achieved by

411
6
268
Self-Assessment Questions 1
1.
What is project scheduling? What are tools used for project scheduling?
2.
What is resource leveling? How can this be achieved?
3.
What are project constraints? How can these be managed?
4.
What is resource smoothing? How can this be achieved?
5.
What is the relationship between cost and time in project management?

How can this be minimised?
6.
What is project crashing? How can project be crashed?
7.
What is the direct cost in project? How it is different compared to indirect

cost?
8.
What is cost slope? What is the use of cost slope in project management?
9.
A Project has 7 activities. The relationship between the activities is as

under
rActivity
A
Preceding activity
Duration
1
Manpower Required 2
B
2
1
D
A
1
1
2
1
B
3
1
F
C
2
1
G
D
1
1
If only 3 persons are available, do the resource leveling and find the
project duration.
10. Prepare network diagram and find minimum duration of the project and
minimum cost if the fixed cost is Rs. 2000 per day.
Activity Preceding Normal Duration
Activity
(Days)
A10
B
A
6
C
8
A
D
B
8
E
B
12
F
C
6
G
E,F
7
5
H
G
I
4
G
J
H,I
4
Crash
days
8
5
6
6
9
5
5
4
6
3
Normal Crash Cost

Cost
12000
16000
6000
7500
6400
7800
7200
6400
9900
8400
4800
6000
4900
5500
6000
5500
7200
5600
4000
4500

Fill in the blanks.
1.
Post-project review is the process during which the benefits achieved by

2.
The closing processes are the management processes undertaken in the

last phase of the Project Life Cycle.

1.
Factors affecting schedule management are:

i.
Availability of raw materials
ii.
Labour

Fill in the blanks.
1.
Cost management is governed by Material Cost and Labour Cost.
2.
PBP stands for Pay Back Period.
Notes
3.
Cost Reduction without compromising quality is done by optimisation of

resources.
rl Suggested Reading
1.

Structure: gio lip
11.1 Understanding Contracts
11.2 Project Contract Process
11.3 Project Contract Terms
11.4 Contract Administration
11:5 Types of Contracts
Summary
Key Words
Suggested Reading
UNIT
11
Notes
Objectives
Explain contracts
Draft project contracts
Prepare request for proposals
Prepare bids
Evaluate bids
Differentiate between the different types of contracts
11.1 UNDERSTANDING CONTRACTS

Projects can be implemented by organisations (depending on the circumstances)
Totally in-house where all the activities are performed by the employees
within the organisation.
Partly in-house and partly outsourced where some activities are done in
house and some activities are outsourced.
Totally outsourced wherein all the activities are performed by an outside

agency.
Whenever an external agency is involved, Project contract comes into play.

In law, a contract is an agreement between two or more parties which, if
it contains the elements of a valid legal agreement, is enforceable by law or by
binding arbitration. That is to say, a contract is an exchange of promises with
specific legal remedies for breach. These can include Compensatory remedy,
whereby the defaulting party is required to pay monies that would otherwise
have been exchanged were the contract honored, or an Equitable remedy such
as Specific Performance, in 'which the person who entered into the contract is
required to carry out the specific action they have reneged upon.
Agreement is said to be reached when an offer capable of immediate
acceptance is met with a "mirror image" acceptance (i.e., an unqualified
acceptance). The parties must have the necessary capacity to contract and the
contract must not be trifling, indeterminate, impossible, or illegal. Contract law
is based on the principle expressed in the Latin phrase pacta sunt servanda
(usually translated "agreements are to be kept", but more literally "pacts must
be kept"). Breach of contract is recognised by the law and remedies can be
provided.
As long as the good or service provided is legal, any oral agreement
between two parties can constitute a binding legal contract. The practical
limitation to this, however, is that generally only parties to a written agreement
have material evidence (the written contract itself) to prove the actual terms
uttered at the time the agreement was struck. In daily life, most contracts can
be and are made orally, such as purchasing a book or a sandwich. Sometimes

written contracts are required by either the parties, or by statutory law within
various jurisdiction for certain types of agreement, for example when buying a
house or land.
Contract law can be classified, as is habitual in civil law systems, as part
of a general law of obligations.
According to legal scholar Sir John William Salmond, a contract is "an
agreement creating and defining the obligations between two or more parties".
As a means of economic ordering, contract relies on the notion of
consensual exchange and has been extensively discussed in broader economic,
sociological and anthropological terms (see "Contractual theory", below). In
American English, the term extends beyond the legal meaning to encompass a
broader category of agreements.
The eight key requirements for the creation of a contract are:
Agreement (Offer and Acceptance)
Capacity to contract
Consideration
Legal purpose
Legality of form
Intention to create legal relations
Consent to contract
Vitiating factors: Misstates, undue influence, misrepresentation, duress In

civil law systems, the concept of consideration is not central.
In most systems of law, parties have freedom to choose whether or not

they wish to enter into a contract, absent superseding duties. In addition, for
some contracts formalities must be complied with under legislation sometimes
called a statute of frauds (especially transactions in real property or for relatively
large cash amounts).
Offer and Acceptance
The most important feature of a contract is that one party makes an offer
for an arrangement that another accepts. This can be called a concurrence of
wills or ad idem (meeting of the minds) of two or more parties. The concept is
somewhat contested. The obvious objection is that a court cannot read minds
and the existence or otherwise of agreement is judged objectively, with only
limited room for questioning subjective intention. There must be evidence
that the parties had each from an objective perspective engaged in conduct
manifesting their assent, and a contract will be formed when the parties have
met such a requirement. An objective perspective means that it is only necessary
that somebody gives the impression of offering or accepting contractual terms
in the eyes of a reasonable person, not that they actually did want to form a
contract.
Notes
Notes
Offer and acceptance does not always need to be expressed orally or in

writing. An implied contract is one in which some of the terms are not expressed
in words. This can take two forms. A contract which is implied in fact is one
in which the circumstances imply that parties have reached an agreement even
though they have not done so expressly. For example, by going to a doctor for
a checkup, a patient agrees that he will pay a fair price for the service. If one
refuses to pay after being examined, the patient has breached a contract implied
in fact. A contract which is implied in law is also called a quasi-contract, because
it is not in fact a contract rather, it is a means for the courts to remedy situations
in which one party would be finjustly enriched were he or she not required to
compensate the other. For example, a plumber accidentally installs a sprinkler
system in the lawn of the wrong house. The owner of the house had learned the
previous day that his neighbour was getting new sprinklers. That morning, he
sees the plumber installing them in his lawn. Pleased at the mistake, he says
nothing, and then refuses to pay when the plumber delivers the bill. Will the
man be held liable for payment? Yes, if it could be proven that the man knew
that the sprinklers were being installed mistakenly, the court would make him
pay because of a quasi-contract. If that knowledge could not be proven, he
would not be liable. Such a claim is also referred to as "quantum meruit"
Invitation to treat
Where a product in large quantities is advertised in a newspaper or on
a poster, it generally is not considered an offer but instead will be regarded as
an invitation to treat; since there is no guarantee that the store can provide the
item for everyone who might want one. A display of goods on the shelves of a
self-service shop is also an invitation to treat, with the offer being made by the
purchaser at the checkout and being accepted by the shop assistant operating the
checkout. If the person who is to buy the advertised product is of importance,
for instance because of his personality, etc., when buying land, it is regarded
merely as an invitation to treat.
Consideration and estoppels
Consideration is known, as 'the price of a promise' and is a requirement
for contracts under common law. The idea behind consideration is that both
parties to a contract must bring something to the bargain. A party seeking to
enforce a contract must show that it conferred some benefit or suffered some
detriment (though it might be trivial, see below) that is recognized by law. For
example, money is often recognised as consideration, but in some cases money
will not suffice as consideration (for example, when one party agrees to make
partial payment of a debt in exchange for being released from the full amount).
Some common law and civil law systems do not require consideration,
and some commentators consider it unnecessary. The requirement of intent by
both parties to create legal relations by both parties performs the same function
under contract. Although several rules govern consideration, the following are
the principal rules:
" 274 '
Consideration must be "sufficient" (i.e., recognisable by the law), but need

not be "adequate" (i.e., the consideration need not be a fair and reasonable
exchange for the benefit of the promise). For instance, agreeing to sell a
car for a penny may constitute a binding contract.
Consideration must not be from the past. For instance, in Eastwood v.

Kenyon, the guardian of a young girl obtained a loan to educate the girl
and to improve her marriage prospects. After her marriage, her husband
promised to pay off the loan. It was held that the guardian could not
enforce the promise because taking out the loan to raise and educate
the girl was past considerationit was completed before the husband
promised to repay it.
Consideration must move from the promisee. For instance, it is good

consideration for person A to pay person C in return for services rendered
by person B. If there are joint promisees, then consideration need only to
move from one of the promisees.
The promise to do something one is already contractually obliged to do

is not, traditionally, regarded as good consideration. The classic instance
is Stilk v. Myrick, in which a captain's promise to divide the wages of
two deserters among the remaining crew if they would sail home from
the Baltic short-handed, was found unenforceable on the grounds that the
crew were already contracted to sail the ship through all perils of the sea.
The promise must not be to do something one is already obliged by the

general law to do, e.g., to give refrain from crime or to give evidence in
court.
However, a promise from A to do something for B if B will perform a

contractual obligation B owes to C, will be enforceable - B is suffering
a legal detriment by making his performance of his contract with A
effectively enforceable by C as well as by A.
Civil law systems take the approach that an exchange of promises, or a

concurrence of wills alone, rather than an exchange in valuable rights is the
correct basis. So if you promised to give me a book, and I accepted your offer
without giving anything in return, I would have a legal right to the book and you
could not change your mind about giving me it as a gift. However, in common
law systems the concept of culpa in contrahendo, a form of 'estoppels', is
increasingly used to create obligations during pre-contractual negotiations.
Estoppel is an equitable doctrine that provides for the creation of legal
obligations if a party has given another an assurance and the other has relied
on the assurance to his detriment. A number of commentators have suggested
that consideration be abandoned, and estoppel be used to replace it as a basis
for contracts. However, legislation, rather than judicial development, has been
touted as the only way to remove this entrenched common law doctrine.
275 ill
Notes
Intention to be legally bound

There is a presumption for commercial agreements that parties intend to
be legally bound (unless the parties expressly state that they do not want to be
bound, like in heads of agreement). On the other hand, many kinds of domestic
and social agreements are unenforceable on the basis of public policy, for
instance between children and parents. One early example is found in Balfour
v. Balfour. Using contract-like terms, Mr. Balfour had agreed to give his wife
30 a month as maintenance while he was living in Sri Lanka. Once he left, they
separated and Mr. Balfour stopped payments. Mrs. Balfour brought an action to
enforce the payments. At the Court of Appeal, the Court held that there was no
enforceable agreement as there was not enough evidence to suggest that they
were intending to be legally bound by the promise.
Third parties
The doctrine of privity of contract means that only those involved in
striking a bargain would have standing to enforce it. In general, this is still the
case, only parties to a contract may sue for the breach of a contract, although in
recent years the rule of privity has eroded somewhat and third-party beneficiaries
have been allowed to recover damages for breaches of contracts they were not
party to. In cases where facts involve third-party beneficiaries or debtors to
the original contracting party have been allowed to be considered parties for
purposes of enforcement of the contract. A recent advance has been seen in the
case law as well as statutory recognition to the dilution of the doctrine of privity
of contract.
Formalities and writing
A verbal exchange of promises may be binding and be as legally valid as a

written contract. An unwritten, unspoken contract, also known as "a contract
implied by the acts of the parties", which can be either implied in fact or implied
in law, may also be legally binding. Most jurisdictions have rules of law or
statutes which may render otherwise valid oral contracts unenforceable. This is
especially true regarding oral contracts involving large amounts of money or real
estate. For example, in the US, generally speaking, a contract is unenforceable if
it violates the Common Law Statute of frauds or equivalent state statutes which
require certain contracts to be in writing. The point of the Statute of Frauds is
to prevent false allegations of the existence of contracts that were never made,
by requiring formal (i.e., written) evidence of the contract. However, a common
remark is that more frauds have been committed through the application of the
Statute of frauds than have ever been prevented. Contracts that do not meet the
requirements of common law or statutory Statutes of frauds are unenforceable,
but are not necessarily thereby void. However, a party unjustly enriched by
an unenforceable contract may be required to provide restitution for unjust
enrichment. Statutes of frauds are typically codified in state statutes covering
specific types of contracts, such as contracts for the sale of real estate.
Notes
Ali
If a contract is in a written form, and somebody signs the contract, then

the person is bound by its terms regardless of whether they have read it or not,
provided the document is contractual in nature. Furthermore, if a party wishes
to use a document as the basis of a contract, reasonable notice of its terms must
be given to the other party prior to their entry into the contract. This includes
such things as tickets issued at parking stations.
11.2 PROJECT CONTRACT PROCESS

Project contract process is an important ingredient for the success of
the project. Once the Management has approved the Cost Budget and Time
Schedule, Project Contract process begins. This involves following steps as
shown in the diagram below:
4 Negotioflo
1 Request For Proposal

2 Submission of Tech and Price bids
3. Bid evaluation & short listing
Potential
Contractor
B
5 Contract award
Fig. 11.1: Projects Contracts Process

Step 1 First we define Scope of work to include the total activities to be
performed by us and by the outside agency and then we prepare detailed
technical specifications for each of the processes. Once this is done, we create
a responsibility matrix defining responsibility of individuals for all the project
activities. Finally we prepare and draft commercial terms and conditions to be
finalised with the outside agency.
277
Notes
Step 2 Selecting and working with outside vendors and contractors
Gather information about vendors and identify potential vendors.
Contact potential vendors and request information about their company

and capabilities.
Contact potential vendors and request examples of their work and request
references.
Qualify potential vendors.
Using the above information, determine those vendors who have the
capability to produce the materials you want to get developed. Include in
your decision such variables as geographical location, industry experience,
reputation, size of staff, and quality/level of work.
Step 3 In step 3, Request for Proposal (RFP) is floated to the prospective
Project Contractors (Bidders) for submission of Technical and Price bids which
contains:
Scope of work
Date of completion of work
Technical information/specifications
Request for information to verify financial and technical capability of the

Bidder
Draft contract terms
A Request for Proposal (referred to as RFP) is an early stage in a project

contract process, issuing an invitation for suppliers, often through a bidding
process, to submit a proposal on a specific commodity or service. The RFP
process brings structure to the procurement decision and allows the risks and
benefits to be identified clearly upfront.
The RFP may dictate to varying degrees the exact structure and format of
the supplier's response. The creativity and innovation that suppliers choose to
build into their proposals may be used to judge supplier proposals against each
other, at the risk of failing to capture consistent information between bidders
and thus hampering the decision making process. Effective RFPs typically
reflect the strategy and short/long-term business objectives, providing detailed
insight upon which suppliers will be able to offer a matching perspective.
Similar requests include a request for quotation and a request for information.
Key objectives of RFP
1.
Obtain correct information to enable sound business decisions.
2.
Decide correctly on strategic procurement.
3.
Leverage the company's purchasing power to obtain a favourable deal.
4.
Enable a broader and creative range of solutions to be considered.
Key Benefits of RFP
Informs suppliers that your company is looking to procure and encourages

them to make their best effort.
Requires the company to specify what it proposes to purchase. If the

requirements analysis has been prepared properly, it can be incorporated
quite easily into the Request document.
Alerts suppliers that the selection process is competitive.
Allows for wide distribution and response.
Ensures that suppliers respond factually to the identified requirements.
By following a structured evaluation and selection procedure an

organisation can demonstrate impartiality a crucial factor in public sector
procurements.
Notes
RFP Specifications
An RFP typically involves more than a request for the price. Other
requested information may include basic corporate information and history,
financial information (can the company deliver without risk of bankruptcy),
technical capability (used on major procurements of services, where the item
has not previously been made or where the requirement could be met by varying
technical means), product information such as stock availability and estimated
completion period, and customer references that can be checked to determine a
company's suitability.
In the military, an RFP is often raised to fulfill an Operational Requirement
(OR), after which the military procurement authority will normally issue a
detailed Technical Specification against which tenders will be made by potential
contractors. In the civilian use, an RFP is usually part of a complex sales process,
also known as enterprise sales.
RFPs often include specifications of the item, project or service for which
a proposal is requested. The more detailed the specifications, the better the
chances that the proposal provided will be accurate. Generally RFPs are sent to
an approved supplier or vendor list.
The bidders return a proposal by a set date and time. Late proposals may or
may not be considered, depending on the terms of the initial RFP. The proposals
are used to evaluate the suitability as a supplier, vendor or institutional partner.
Discussions may be held on the proposals (often to clarify technical capabilities
or to note errors in a proposal). In some instances, all or only selected bidders
may be invited to participate in subsequent bids, or may be asked to submit their
best technical and financial proposal, commonly referred to as a Best and Final
Offer (BAFO).
RFP Variations
Other variations in RFP include request for quotation, request for pricing,
request for qualification, request for tender and request for information.
'279 .
Notes
A Request for Quotation (RFQ) is used when discussions with bidders are
not required (mainly when the specifications of a product or service are already
known) and when price is the main or only factor in selecting the successful
bidder. An RFQ may also be used as a step prior to going to a full-blown RFP to
determine general price range. In this scenario, products, services or suppliers
may be selected from the RFQ results to bring in to further research in order to
write a more fully fleshed out RFP.
An RFQ is a standard business process whose purpose is to invite suppliers
into a bidding process to bid on specific products or services. RFQ generally
means the same thing as Invitation for Bid (IFB).
An RFQ typically involves more than the price per item. Information
like payment terms, quality level per item or contract length are possible to be
requested during the bidding process.
To receive correct quotes, RFQs often include the specifications of the
items/services to make sure all the suppliers are bidding on the same item/
service. Logically, the more detailed the specifications, the more accurate the
quote will be and comparable. to the other suppliers. Another reason for being
detailed in sending out an RFO is that the specifications could be used as legal
binding documentation for the suppliers.
The suppliers have to return the bidding by a set date and time to be
considered for an award. Discussions may be held on the bids (often to clarify
technical capabilities or to note errors in a proposal). The bid does not have
to mean the end of the bidding. Multiple rounds can follow or even a Reverse
auction can follow to generate the best market price.
RFQs are best suited to products and services that are as standardised and
as commoditised as possible, as this makes each suppliers' quotes comparable.
In practice, many businesses use a RFQ where an RFT or RFP would be more
appropriate.
An RFQ allows different contractors to provide a quotation, among which
the best will be selected. It also makes the potential for competitive bidding a
lot higher, since the suppliers could be quite certain that they are not the only
ones bidding for the products..
Requests for quotations are most commonly used in the business
environment but can also be found being applied to domestic markets.
A Request for Information (RFI) is a proposal requested from a potential
seller or a service provider to determine what products and services are
potentially available in the marketplace to meet a buyer's needs and to know the
capability of a seller in terms of offerings and strengths of the seller. RFIs are
commonly used on major procurements, where a requirement could potentially
be met through several alternate means. An RFI, however, is not an invitation
to bid, is not binding on either the buyer or sellers, and may or may not lead to
an RFP or RFQ.
280
A Request for Qualifications (RFQ) is a document often distributed

before initiation of the RFP process. It is used to gather vendor information
from multiple companies to generate a pool of prospects. This eases the RFP
review process by preemptively short-listing candidates which meet the desired
qualifications.
RFP is sometimes used for a request for pricing.
A Request for Tender (RFT) is a term more commonly used by government.
Step 4 The Bidders prepare Bid documents which would include:
Executive summary of the proposal.
Technical section giving technical details of the products that would be

supplied or activities that will be performed. In the Technical section,
the vendor should include timelines, projected required personnel, and
schedules for completing the project.
Price section in which the vendor must detail the time and costs that
will be required to complete the project. Price section includes all the
pricing terms which include basic prices, taxes and duties, costs related
to transportation, packaging, loading unloading, installation, erection,
testing commissioning, etc.
Management/Qualification section which includes background of the

bidder, their prior experience in similar type of projects.
Financial capability, CV of Project Manager and key Project personnel.
Legal section containing contract terms and how to handle contingencies.
Additional documentation and certificates as required.
Vendors must include a short demo or direct us to an Internet site which

demonstrates their production capabilities.
References of similar projects executed.
The bidding process is of different types as follows:

A. Single Stage: One-Envelope Bidding Procedure
In the Single Stage: One-envelope bidding procedure, bidders submit
bids in one envelope containing both the Price Proposal and the Technical
Proposal.
The envelopes are opened in public at the date and time advised in the
Bidding Document. The bids are evaluated, and following approval
by the ADB, the Contract is awarded to the bidder whose bid has been
determined to be the lowest evaluated substantially responsive bid.
Sometimes as per the request of the Customer organisation, Price Section
and all other sections are sealed in separate envelopes and submitted. This
is called Two-envelope Bidding. (Most Government contracts are of this
type.)
Notes
Notes
B.
Single Stage: Two-Envelope Bidding Procedure

In the Single Stage: Two-Envelope bidding procedure, bidders submit two
sealed envelopes simultaneously, one containing the Technical Proposal
and the other the Price Proposal, enclosed together in an outer single
envelope.
Initially, only the Technical Proposals are opened at the date and time
advised in the Bidding Document. The Price Proposals remain sealed
and are held in custody by the Purchaser. The Technical Proposals are
evaluated by the Purchaser. No amendments or changes to the Technical
Proposals are permitted.
The objective of the exercise is to allow the Purchaser to evaluate the
Technical Proposals without reference to price. Bids of bidders who do
not conform to the specified requirements may be rejected as deficient
bids.
Following approval of the technical evaluation and at a date and time
advised by the Purchaser, the Price Proposals are opened in. The Price
Proposals are evaluated, and following approval of the price evaluation,
the Contract is awarded to the bidder whose bid has been determined to
be the lowest evaluated substantially responsive bid.
C.
Two Stage: Two-Envelope Bidding Procedure

In the Two-Stage: Two-envelope bidding procedure, at the first stage,
bidders submit two sealed envelopes simultaneously, one containing the
Technical Proposal and the other the Price Proposal, enclosed together in
an outer single envelope.
Only the Technical Proposals are opened at the date and time advised in
the Bidding Document, and the Price Proposals remain sealed and are
held in custody by the Purchaser. The Technical Proposals are evaluated
and if the purchaser requires amendments or changes to the Technical
Proposals, such amendments and changes are discussed with the bidders.
The bidders are allowed to revise or adjust their Technical Proposals to
meet the requirements of the purchaser.
The objective of the exercise is to ensure that all Technical Proposals
conform to the same acceptable technical standard and meet the technical
solution required by the purchaser. Bids of bidders who are unable or
unwilling to bring their Technical Proposals to conform to the acceptable
technical standard will be rejected as deficient bids approval.
Following approval of the evaluation of Technical Proposals, bidders are
invited, at the second stage, to submit Modified Bid Proposals consisting
of Revised Technical Proposals and Supplementary Price Proposals based
on the technical standard agreed.
The original Price Proposals and the Modified Bid Proposals are opened at
a date and time advised by the Purchaser. In setting the date the Purchaser
will allow sufficient time for the Bidders to incorporate the changes in the
282
Revised Technical Proposals that are needed to meet the agreed technical
standard and to prepare the Supplementary Price Proposals that reflect
these changes.
The Price Proposals, Supplementary Prices Proposals, and Revised
Technical Proposals are evaluated, and following approval, the Contract is
awarded to the Bidder whose Bid is determined to be the lowest evaluated
substantially responsive Bid.
D.
Two-stage Bidding Procedure

In the two-stage bidding procedure, bidders first submit their Technical
Proposals, in accordance with the specifications, but without prices. The
Technical Proposals are opened at the date and time advised in the Bidding
Document. The Technical Proposals are evaluated and discussed with the
bidders.
Any deficiencies, extraneous provisions and unsatisfactory technical
features are pointed out to the bidders whose comments are carefully
evaluated. The Bidders are allowed to revise or adjust their Technical
Proposals to meet the requirements of the purchaser.
The objective of the exercise is to ensure that all Technical Proposals
conform to the same acceptable technical standard and meet the technical
solution required by the purchaser. Bids of bidders who are unable or
unwilling to bring their bids to conform to the acceptable technical
standard may be rejected as deficient bids.
After the evaluation of Technical Proposals, the second stage is to invite
Bidders to submit Price Proposals and Revised Technical Proposals in
compliance with the acceptable technical standard. The Revised Technical
Proposals and Price Proposals are opened in public at a date and time
advised by the purchaser.
In setting the date, the purchaser should allow sufficient time for bidders to
incorporate the changes involved in the Technical Proposals and prepare
Price Proposals.
The Price Proposals and Revised Technical Proposals are evaluated, and
following approval, the Contract is awarded to the bidder whose bid has
been determined to be the lowest evaluated substantially responsive bid.
Only after a bidder qualifies technically, his Price bid is opened to reveal
the price. If technically not qualified, the bidder does not progress further.
To avoid frivolous, non-serious bids, Bid (Tender) Security in the form of a
Demand Draft/Bank Guarantee is requested by the Customer Organisation
(mostly Government organisation). Non-Government organisations do
not insist on bid security.
Notes _All
Notes
E. STEP 5 Bid evaluation by Customer Organisation

Once the bids are received from the contractors, the bids are evaluated
based on Bidder's
Technical Solution approach
Project Organisation and Management
Previous experience in handling similar projects
Date of completion of project
Price
Reputation/Financial capability of the potential Contractor, etc.
Trying to fit all the parameters (in the previous slide) together can lead
to 'subjectivity' and low transparency in decision-making for selection.
A method commonly adopted for "objectivity in decision-making" is the
"Keppner-Treggo" matrix which uses weighted rating of the different
parameters. Constructing the decision matrix has the following phases:
Design phase: Design phase includes following steps:
Step 1: Define all the parameters that are relevant to the decision
Step 2: Rank the parameters in the order of importance and assign

weights (assigning "weights" brings in relative importance of each
parameter, i.e., all parameters are not treated on an equal basis)
Step 3: Define the metrics and measurement devices
Decision phase: The decision phase includes following steps:
Step 4: Shortlist the bidders on the basis of previous experience ,

reputation, inspections and documentary evidence
Step 5: Give the marks for each parameter on the pre-decided

metrics
Step 6: Compute the weighted average marks for each bidder per
parameter and compute the totals
Step 7: The contractor with the highest score is the "best choice"
Step 8: Check the 'best choice' against "other factors"
Bid Evaluation - Example

The following example illustrates the above process. ABC Ltd., XYZ
Co. and New Co. are the 3 bidders who have submitted their bids. The
company has decided to evaluate the bid on 6 parameters as per following
table. They have decided the weightages as per following table. Now
based on the bid submitted by the three contractors, the points are given
to the contractors which are shown in the following table.
2841 .-'
Evaluation Parameter
Ability to deliver on time

Ability to handle complexity
Ability to meet cost
Financial capability
Ability to meet quality
Confidence generation/ Reputation
Weightage
7
5
4
3
3
2
Score out of 10
ABC XYZ NEW
LTD. CO. CO.
6
8
7
6
7
8
8
6
7
8
5
6
8
7
7
7
5
9
Notes
Based on the weightages and points we calculated weighted scores as

follows: Weighted score = Weights x score out of 10
We find that the company New Co. has got maximum total weighted
score. So we can select New co. for awarding the project contract.
F.
STEP 6 Negotiations
Negotiations are conducted with shortlisted bidders after evaluation

of bids.
To clarify technical or other terms in the bid.
To reach agreement on time for completion and price.
A Letter of Intent (LOI) or Memorandum of Understanding (MOU) is

issued by the Customer Organisation to the successful Contractor, after
negotiations are concluded to the satisfaction of both Parties, indicating
the intention to enter into a contract.
A letter of intent or LOI is a document outlining an agreement between
two or more parties before the agreement is finalised. The concept is
similar to the so-called heads of agreement. Such agreements may be
Asset Purchase Agreements, Share Purchase Agreements, Joint Venture
Agreements and overall all Agreements which aim at closing a financially
large deal.
LOIs resembles written contracts, but is usually not binding on the parties
in their entirety. Many LOIs, however, contain provisions that are binding,
such as non-disclosure agreements, a covenant to negotiate in good faith,
or a "stand still" or "no-shop" provision promising exclusive rights to
negotiate. A LOI may also be interpreted as binding the parties if it too
closely resembles a formal contract.
The purposes of an LOI may be:
To clarify the key points of a complex transaction for the convenience

of the parties
To declare officially that the parties are currently negotiating, as in

a merger or joint venture proposal
To provide safeguards in case a deal collapses during negotiation
285
An LOI may also be, referred to as an MOU, term sheet or discussion

sheet. The different terms reflect different styles, but do not indicate any
difference under law. A contract, in contrast, is a legal document governed
by contract law.
Notes
There is, however, a specific difference between an LOI and MOU,

whereby an LOI is the intent from one party to another and does not
in this case have to be signed by both parties, whereas an MOU is an
agreement between two or more parties, which should be signed by all
parties to be valid.
A memorandum of understanding is a document describing a bilateral or
multilateral agreement between parties. It expresses a convergence of will
between the parties, indicating an intended common line of action. It is
often used in cases whete parties either do not imply a legal commitment
or in situations where the parties cannot create a legally enforceable
agreement. It is a more formal alternative to a gentlemen's agreement.
In some cases, depending on the exact wording, MoUs can have the binding
power of a contract, as a matter of law contracts do not need to be labeled
as such to be legally binding. Whether or not a document constitutes a
binding contract depends only on the presence or absence of well-defined
legal elements in the text proper of the document (the so-called "four
corners"). For example, a binding contract typically must contain mutual
consideration on legally enforceable obligation of the parties, and its
formation must take place free of the so-called real defenses to contract
formation (fraud, duress, lack of age or mental capacity, etc.).
One advantage of MoUs over more formal instruments is that, because
obligations under international law may be avoided, they can be put into
effect in most countries without requiring parliamentary approval. Hence,
MoUs are often used to modify and adapt existing treaties, in which case
these MoUs have factual treaty status. The decision concerning ratification,
however, is determined by the parties' internal law and depends to a large
degree on the subject agreed upon. MOUs that are kept confidential (i.e.,
not registered with the United Nations) cannot be enforced before any UN
organ, and it may be concluded that no obligations under international
law have been created.
Although MOUs in the multilateral field are seldom seen, the transnational
aviation agreements are actually MoUs.
G.
STEP 7 Contract award

Once the contractor is finalised, the contract is awarded formally to the
selected contractor. Prior to contract signing, the Customer Organisation
might ask for Performance Bank Guarantee (Security) from the successful
bidder. It is a Guarantee issued by a Bank on behalf of the Contractor at
his request stating that the Contractor will perform his obligations as per
the terms of the contract. The monetary value of the Guarantee is 10-15%
286
of the contract value. If the contractor fails to perform as per the terms
agreed, Customer can invoke the Bank Guarantee and encash it. Banks
charge a commission from Contractors to issue Guarantee
A performance BG (also called performance bond) states that in the event
of failure to perform an agreed task the beneficiary can raise a claim on the
bank. Example: Party A wins a tender to supply party B with equipment
for US$ 1 billion. Party A submits a performance bond. Thereafter, party
A backs out because it feels it cannot deliver on the agreed price and will
incur a loss. The beneficiary (party B) will claim against the performance
bond for failure to perform the contract.
A financial guarantee is a very broad and general guarantee that can be
issued by a bank to ensure that party A fulfils its financial obligations to
party B. Typical example is party B is a manufacturer and seller of goods
and party A is a newly established buyer & distributor of those goods and
requests a credit limit of USD 1 million. Party B will request party A to
arrange a Financial Guarantee stating that Party B will receive payment
of up to USD 1 million upon submission of proof of delivery of goods by
party B to party A (typically Invoice and signed Goods Receipt Note).
A performance bond is a surety bond issued by an insurance company or
a bank to guarantee satisfactory completion of a project by a contractor.
For example, a contractor may cause a performance bond to be issued in
favor of a client for whom the contractor is constructing a building. If the
contractor fails to construct the building according to the specifications
laid (most often due to the bankruptcy of the contractor), the client is
guaranteed compensation for any monetary loss up to the amount of the
performance bond.
Performance bonds are commonly used in the construction and
development of real property, where an owner or investor may require
the developer to assure that contractors or project managers procure such
bonds in order to guarantee that the value of the work will not be lost in
the case of an unfortunate event (such as insolvency of the contractor). In
other cases, a performance bond may be requested to be issued in other
large contracts besides civil construction projects.
The term is also used to denote a collateral deposit of "good faith money",
intended to secure a futures contract, commonly known as margin.
Performance bonds are generally issued as part of a 'Performance and
Payment Bond', where a Payment Bond guarantees that the contractor
will pay the labour and material costs they are obliged to.
H. STEP 8 Payments to Contractors
Last step is finalising the payment formalities for the contractor which
may include any of the following processes:
Advance payment: 10-15% of contract price is paid in advance to

the Contractors before commencement of the project.
Notes
.. .......
Notes
Running bills: Payments are made as per the progress of the project,
measured in terms of percentage completion or on achieving certain
milestones agreed upon.
Retention money: A small percentage say 10% of the contract

value is retained with the customer till the project is completed in
all respects to the satisfaction of the customer.

Fill in the blanks.
1.
is an agreement between two or more parties which, if

it contains the elements of a valid legal agreement, is enforceable by
law or by binding arbitration.

acceptance.
acceptance is met with a
is an early stage in a project contract process.
4.
A `LOF may als6 be referred to as a

discussion sheet
Achy" : Activity
term sheet or
List the parameters that you would use for evaluating a potential contractor
\...for a project.
11.3 PROJECT CONTRACT TERMS

Some of the important project contract terms are:
Liquidated Damages
One of the important clauses in the Contract is the schedule of completion
of the work. Delay in project completion leads to cost overrun and missed market
opportunities. Liquidated damages stipulates deduction of certain percentage of
the Contract Price payable for delays measured in weeks or days.
Liquidated damages (also referred to as liquidated and ascertained
damages) are damages whose amount the parties designate during the formation
of a contract for the injured party to collect as compensation upon a specific
breach (e.g., late performance).
When damages are not predetermined/assessed in advance, then the
amount recoverable is said to be 'at large' (to be agreed or determined by a
court or tribunal in the event of breach).
288
At common law, a liquidated damages clause) will not be enforced if its

purpose is to punish the wrongdoer/party in breach: rather than to compensate
the injured party (in which case it is referred to as a penal or penalty clause).
One reason for this is that the enforcement of the term would, in effect, require
an equitable order of specific performance. However, courts sitting in equity
will seek to achieve a fair result and will not enforce a term that will lead to the
unjust enrichment of the enforcing party.
Notes
In order for a liquidated damages clause to be upheld, two conditions must

be met. First, the amount of the damages identified must roughly approximate
the damages likely to fall upon the party seeking the benefit of the term. Second,
the damages must be sufficiently uncertain at the time the contract is made
that such a clause will likely save both the parties from the future difficulty of
estimating damages. Damages those are sufficiently uncertain may be referred
to as unliquidated damages, and may be so categorised because they are not
mathematically calculable or are subject to a contingency which makes the
amount of damages uncertain.
For example, suppose Joey agrees to lease a storefront to Monica, from
which Monica intends to sell jewellery. If Joey breaches the contract by refusing
to lease the storefront at the appointed time, it will be difficult to determine
what profits Monica will have lost because the success of newly created
small businesses is highly uncertain. This, therefore, would be an appropriate
circumstance for Monica to insist upon a liquidated damages clause in case
Joey fails to perform.
In the case of construction contracts, courts have occasionally refused
to enforce liquidated damages provisions, choosing to follow the Doctrine of
Concurrent Delay when both parties have contributed to the overall delay of the
project.
Force Majeure
Inability to perform contract work by either the Customer or Contractor
due to 'Acts of God' like floods, epidemics, earthquakes, war, etc. Both Parties
are excused from their obligations during the period of Force Majeure and no
penalties are levied during this period.
Force majeure (French for "superior force"), also known as cas fortuit
(French) or casus fortuitous (Latin), is a common clause in contracts that
essentially frees both parties from liability or obligation when an extraordinary
event or circumstance beyond the control of the parties, such as a war, strike,
riot, crime, or an event described by the legal term "act of God" (e.g., flooding,
earthquake, volcanic eruption), prevents one or both parties from fulfilling their
obligations under the contract. However, force majeure is not intended to excuse
negligence or other malfeasance of a party, as where non-performance is caused
by the usual and natural consequences of external forces (e.g., predicted rain
stops an outdoor event), or where the intervening circumstances are specifically
contemplated.
289
Note
Time-critical and other sensitive contracts may be drafted to limit the

shield of this clause where a party does not take reasonable steps (or specific
precautions) to prevent or limit the effects of the outside interference, either
when they become likely or when they actually occur. A force majeure may
work to excuse all or part of the obligations of one or both parties. For example,
a strike might prevent timely delivery of goods, but not timely payment for the
portion delivered. Similarly, a widespread power outage would not be a force
majeure excuse if the contract requires the provision of backup power or other
contingency plans for continuity.
A force majeure may also be the overpowering force itself, which prevents
the fulfilment of a contract. In that instance, it is actually the impossibility or
impracticability defences.
In the military, force majeure has a slightly different meaning. It refers
to an event, either external or internal, that happens to a vessel or aircraft that
allows it to enter normally restricted areas without penalty. An example would
be the US Navy aircraft that landed at a Chinese military airbase after a collision
with a Chinese fighter in April 2001. Under the principle of force majeure, the
aircraft must be allowed to land without interference.
The importance of the force majeure clause in a contract, particularly
one of any length in time, cannot be overstated as it relieves a party from an
obligation under the contract (or suspends that obligation). What is permitted to
be a force majeure event or circumstance can be the source of much controversy
in the negotiation of a contract and a party should generally resist any attempt
by the other party to include something that should, fundamentally, be at the
risk of that other party.
Under international law it refers to an irresistible force or unforeseen
event beyond the control of a State making it materially impossible to fulfil
an international obligation. Force majeure precludes an international act from
being wrongful where it otherwise would have been.
Subcontracts
Subcontract is a process where parts of the work under contract are
entrusted by the Main Contractor to other Contractors. The customer does
not pay subcontractors. Sub- contracting is between Main Contractors and
Subcontractors. If significant portion of the project work is carried out by
Subcontractors, Customer may stipulate that Contractor must get prior approval
before engaging subcontractor. The concept of subcontracting is as shown in
the figure below:

I
r Prime
Contractor
Fig.11.2: Subcontract Management

1.
At Common Law, a liquidated damages clause will be enforced to

punish the party in breach.
2.
Subcontracting is between subcontractors and customers.
11.4 CONTRACT ADMINISTRATION

The Contract Administration process helps to assure the project's goals
and needs are on track and on schedule and the seller is behaving appropriately.
The ContractAdministration process is a part of the Monitoring and Controlling
Process Group. The inputs for this process are:
Contract: A contract is an agreement between the buyer and the seller

which details their legal requirements and obligations.
Contract Management Plan: The Contract Management Plan utilises

the existing contract requirements to provide the buyer and the seller
with guidelines for administering and monitoring contracts for significant
purchases or acquisitions.
Selected Sellers: The selected sellers are sellers that the buyer deems the
best candidates for the project and that have negotiated a draft contract.
Performance Reports: Performance reports are more detailed than

work performance information, they use methods such as bar charts and
S-curves to organise and summarize information such as earned value
management and project work progress.
Approved Change Requests: Approved change requests verify which

changes to contracts or procurement procedures have been processed and
approved.
Notes
Notes
Work Performance Information: Work performance information, which

comes from the Direct and Manage Project Execution process, provides
statuses of the project schedule activities being done to accomplish the
project work. The team uses it to monitor the sellers' progress on schedule,
deliverables, and costs.
Once we have been able to get through the selection/acquisition phase,
the project manager needs to track administrative issues, contract
changes, and the seller's progress and quality of work to assure that the
project is running smoothly. The tools and techniques for the Contract
Administration process are:
292
Contract Change Control System: A contract change control system

defines the procedures fOr changing a contract. It encompasses all forms,
documented communications, tracking systems, and dispute resolution
procedures. Additional approval levels are necessary to authorise changes
and the procedures for getting the changes approved within the performing
organisation. The contract change control system should be integrated
into the Integrated Change Control System.
Buyer-conducted Performance Review: A buyer-conducted

performance review tracks the vendor's progress in execution and product
delivery within contractual parameters. Hopefully, your organisation is
including the cost and project schedule in the contract. The purpose is to
manage contract performance by recognising performance success and
failures, anticipated completion on the contract statement of work, and
finally identify areas of Contract non-compliance.
Inspections and Audits: Inspections and audits identify any defects in

the delivered work or product. Project managers assure inspections are
conducted and audits occur with the live event of a new process or inspect
new procedures.
Performance Reporting: Performance reporting involves gathering the

vendor's performance data and distributing it to stakeholders. Performance
Reporting can help to alert management on whether the vendor is meeting
contractual objectives.
Payment System: Payment systems are tools and claims administration

processes used for Contract Administration. The buyer uses a payment
system to compensate the vendor according to contract terms. Payment
systems include project management teams' reviews and approvals.
Larger projects may have individual payment systems.
Claims Administration: Claims administration resolves claims according

to the contract's dispute resolution procedures when the buyer and seller
cannot resolve a claim on their own. Claims administration documents,
processes, monitors, and manages claims during the life of the contract,
usually according to the contract terms.
Records Management System: A records management system is a set

of processes, related control functions, and automation tools which are
used to manage contract documentation and records. Project managers

use records management systems to manage contract documentation and
records to keep an index of contract documents and correspondence and
for help with retrieving, accessing, and archiving that documentation.
Information Technology: Information technology makes contract

administration more effective by providing electronic data exchange
between the buyer and seller, and automating portions of certain systems
and processes. Using information technology automates parts of the
records management system, payment system, claims administration, or
performance reporting.
The Contract Administration process outputs are:
Contract Documentation: Contract documentation includes the

contract, schedules, requested unapproved contract changes, approved
change requests, any seller-developed technical documentation, and work
performance information.
Requested Changes: Requested changes to the Project Management

Plan, its subordinate plans, and other elements such as the project schedule
and Procurement Management Plan may occur due to the Contract
Administration process. They are submitted for approval to the Integrated
Change Control process. Normally requested changes are addendums to
contracts.
Recommended Corrective Actions: Recommended corrective actions

are measures to make the seller compliant with the terms of the contract,
such as sending a warning letter requesting resolution of the problem or
withholding payment until the problem is corrected.
Organisational Process Assets (Updates): Updates to organisational

process assets consist of the buyers' and vendors' written records of all
contract administration, including actions taken and decisions made,
results of buyer audits and inspections, paymerit schedule updates, and
seller performance evaluation documentation.
Project Management Plan (Updates): Updates to the Project

Management Plan will consist of approved change requests affecting the
Procurement Management Plan.
0
_I
Nctisi"
Activity 2
...Enlist the contract administration process outputs.
11.5 TYPES OF CONTRACTS

Understanding the type of contract you are working under or to use on
your project is one of the more important elements of Project Management.
After all, the contract sets the scope and compensation and what could be more
Notes
I Notes
essential than that? However, different circumstances require different types

of contracts. The different types of contracts allow more or less flexibility, and
allocate different amounts of risk to the contractor and owner.
There is usually a cost associated with assuming risk, so contracts where
the contractor bears most of the risk typically cost more. However, in some
cases the contractor may be better able to mitigate the risk than the owner so
having the contractor assume that risk may be more economical. It all depends
on what the goals of both parties are. There are many different types of contracts
and they vary between industry and according to the type of goods supplied
or services performed. Contracts are usually categorised according to the type
of payment but can be tailored to incorporate common elements from several
different contract types. Some of the common forms of contract are examined
below.
A.
Fixed Price (FP or FFP - firm fixed price)/Lump Sum: The simplest
type of contract. The owner specifies the work and the contractor gives
a price. In this case the contractor assumes almost all of the risk and as a
result reaps whatever profit there is. A fixed price or lump sum contract
is an agreed price for the performance of work, supply of labor, or supply
or goods at a designated time. The scope of the contract defines the
expectations of both parties. This type of contract provides a degree of
certainty for both parties because the contract scope clearly spells out
what is involved. They can be short term or ongoing in duration.
Fixed price contracts are often used in governmental contracting as they
give an easy way to compare competitive bids and to budget for the work
as all the uncertainty in actual price becomes the responsibility of the
contractor. On the other hand, this may not be the cheapest way to get
the work done. Aside effect of the fixed price contract is the Change
Order which modifies the initial contract for unforeseen conditions and
changes. Some contractors are highly skilled at generating change orders
which can boost profits on the job. In some cases change orders can equal
the size of the original contract. Litigation is often more expensive than
construction, so arbitration and settlement are typical in these cases.
294
B.
Time and Materials (T&M): Simple billing at pre-negotiated rates for

labour and materials on a project. Some Fixed Price contracts specify this
as a method for determining costs of change orders. Labour rates include
a certain percentage markup for overhead. In this arrangement all risk
goes to the owner.
C.
Cost Plus Fixed Fee (CPFF or sometimes just Cost Plus): This type of
contract shifts most of the risk to the owner, but also allows the owner a
high degree of flexibility. The contractor under this form of contract has
profit at risk and will seek to minimize cost/duration to return a higher
proportional profit margin. This type of contract is more common on
projects which have high amounts of risk and uncertainty which would
scare contractors into giving impossibly high bids, or where the owner
just needs resources to work on a project.
The "fixed fee" is typically a percentage of estimated costs and the

contractor is reimbursed for other allowable costs. The difference between
CPFF and CPPC is that for fixed fee, the total amount of the fee is decided
in advance based on estimates.
D.
Cost Plus Percentage of Costs (CPPC): This is very similar to the cost
plus fixed fee contract except that the contractor bears even less risk.
Their fee is calculated based on a percentage of actual costs. It is generally
believed that having a fee at risk is a motivating factor for contractors, so
this approach is not allowed for federal government contracts (though
there may be loopholes) It is very similar to T&M.
E.
Cost Plus Incentive Fee (CPIF): This type of contract uses an incentive
fee for motivating better performance than you would get with percentage
or fixed fee. In addition to a fee, an incentive is paid for beating a schedule
or cost target. Like having the fee at risk, is intended to motivate the
contractor to minimise costs and duration. Determining the appropriate
incentive is one difficulty, another is that once the target has been missed,
the incentive is no longer a motivating factor, Often the incentive fee is
calculated as a percentage of savings and is shared by the owner and the
contractor. The flip-side of incentive fees are liquidated damages.
F.
Liquidated Damages: While not really a ,contract type, Liquidated

Damages are often part of Fixed Price contracts. They are the opposite
of an incentive payment and are payments made by the contractor to the
owner for failing to perform to a target date. The name liquidated damages
comes from the practice of determining a pre-agreed monetary (thus
liquidated) cost for damages to the owner's operations. For example, late
completion of a new production facility may cost the owner additional
costs to keep an aging and inefficient facility running or the presence
of the contractor may impair the owner's profitable use of a facility.
Rather than determining these costs at the end of the contract, the costs
are negotiated at the beginning and are usually quite large. This serves
to motivate the contractor and gives the contractor the cost information
needed to accurately determine the best course of action. It is intended
to reduce the costs of litigation. Liquidated damages may apply to the
contract as a whole or to smaller elements of it. For example, on a contract
where a road is being resurfaced during nighttime hours, failing to have it
back in operation by a certain time each day may be cause for liquidated
damages.
G.
Fixed Price Incentive Fee (FPIF): Similar to Fixed Price but with an
incentive fee. Motivation to perform is the reason.
H.
Unit Rate: Unit rate contract types are an agreed to rate for the
performance of specified work. Monetary exchange takes place when
work is performed and is directly proportional to the volume and range of
295
work. These types of contract are most prevalent in the building industry.
An example of a unit rate contract would be the supply of timber where
the monetary amount would be defined by the volume of units supplied.
The terms of this type of contract often accommodates flexibility for
price adjustment. The agreed to value may be subject to amendment if the
volume is reduced or exceeds the original negotiated terms and price.
Notes
Reimbursable Contract: A reimbursable contract type (cost plus) is

an upfront payment by the client party to the contractor. These types
of contracts are used when the scope of the work is difficult to define.
An example of this type of contract is the procurement of specialised
services to solve a problem that may take an indefinite period of time.
The upfront payment covers the contractor's commitments to the project.
Renegotiation for increased tenure or reimbursement may take place if
the contract comes to an abrupt end. These types of contract sometimes
contain a fixed cost component.
I.
So those are the most common contract types. Of course, a contract can
take any form that two parties can agree to (and which is not prohibited by law)
so hybrids of these forms are possible. Another way of classifying the contracts
is as per following:
Hard Contract: A hard contract is the type of contract most widely used
by project management consultants. This concept identifies a clear set of
deliverables that the Project Manager is expected to complete and submit
to the client. These deliverables typically have a set timetable for when
they must be completed. The other key aspect of the hard contract is that
there is a set fee associated with the contract. In essence, it says "here is
what we need", "this is when we need it" and "this is how much you get
paid".
A.
Using hard contracts requires the ability to accurately forecast the costs of
the project, as well as the ability to make sure the project comes in under
budget. Because the fee paid to the Project Manager is fixed, anything
that runs over budget ultimately translates into money out of the Project
Manager's pocket.
Soft Contract: A soft contract offers a significant degree of flexibility
on the part of the client and the Project Manager alike. In case of a soft
contract, the fee is flexible according to the needs of the project, which
are reassessed frequently as the project is executed.
B.
AcotY Activity 3
Prepare a checklist for including the terms in contract for construction
project.
Prepare a checklist for including the terms in contract for a software
development and installation project.
296
Summary
Projects can be implemented by organisations (depending on the

circumstances) totally in-house, partly in-house and partly outsourced
or totally outsourced. Whenever an external agency is involved Project
contract comes into play.
In law, a contract is an agreement between two or more parties which, if

it contains the elements of a valid legal agreement, is enforceable by law
or by binding arbitration. The eight key requirements for the creation of
a contract are: Agreement (Offer and Acceptance), Capacity to contract,
Consideration, Legal purpose, Legality of form, Intention to create legal
relations, Consent to contract, Vitiating factors like misstates, undue
influence, misrepresentation, duress.
Project contract process is an important ingredient for the success of the

project. Once the Management has approved the Cost Budget and Time
Schedule, Project contract process begins. This involves following steps:
o
Defining scope of work, preparing detailed technical specifications,

responsibility matrix and drafting commercial terms and conditions
Selecting and working with outside vendors and contractors
Preparing Request for Proposal (RFP)
Getting the bid from bidders
Bid evaluation by Customer Organisation
Negotiations
Contract award
Payments to contractors
One of the important clauses in the Contract is the schedule of the

completion of the work. Delay in project completion leads to cost overrun
and missed market opportunities.
Liquidated damages stipulate deduction of certain percentage of the

Contract Price payable for delays measured in weeks or days. Liquidated
damages (also referred to as liquidated and ascertained damages) are
damages whose amount the parties designate during the formation of a
contract for the injured party to collect as compensation upon a specific
breach (e.g., late performance).
Force majeure (French for "superior force"), also known as cas fortuit
(French) or casus fortuitous (Latin), is a common clause in contracts
that essentially frees both parties from liability or obligation when an
extraordinary event or circumstance beyond the control of the parties,
such as a war, strike, riot, crime, or an event described by the legal term
"act of God" (e.g., flood, earthquake, volcanic eruption), prevents one or
both parties from fulfilling their obligations under the contract.
Notes
Notes
Subcontract is a process where parts of the work under Contract are

entrusted by the Main Contractor to other Contractors. The customer does
not pay subcontractors. Subcontracting is between Main Contractors and
Sub contractors.
The Contract Administration process helps to assure the project's goals

and needs are on track and on schedule and the seller is behaving
appropriately. The Contract Administration process is a part of the
Monitoring and Controlling Process Group. The inputs for this process
are: Contract, Contract Management Plan, Selected Sellers, Performance
Reports, Approved Change Requests and Work Performance Information.
The tools and techniques for the Contract Administration process are:
Contract Change Control. System, Buyer-conducted Performance Review,
Inspections and Audits, Performance Reporting, Payment System,
Claims Administration, Records Management System and Information
Technology.
The ContractAdministration process outputs are: Contract Documentation,

Requested Changes, Recommended Corrective Actions, Organisational
Process Assets, and Project Management Plan.
Contracts are usually categorised according to the type of payment but

can be tailored to incorporate common elements from several different
contract types. Some of the common forms of contract are: Fixed Price,
Time and Materials, Cost Plus Fixed Fee, Cost Plus Percentage of Costs,
Cost Plus Incentive Fee, Liquidated Damages, Fixed Price Incentive Fee,
Unit rate, Reimbursable contract.
QdKeywords
298
Contract: An agreement between two or more parties which, if it

contains the elements of a valid legal agreement, is enforceable by law or
by binding arbitration.
Request for proposal: An invitation for suppliers, often through a

bidding process, to submit a proposal on a specific commodity or service.
Request for information: A proposal requested from a potential seller or

a service provider to determine what products and services are potentially
available in the marketplace to meet a buyer's needs and to know the
capability of a seller in terms of offerings and strengths of the seller.
Request for qualification: A document often distributed before initiation

of the RFP process.
Letter of intent: A document outlining an agreement between two or

more parties before the agreement is finalised.
Memorandum of understanding: A document describing a bilateral or

multilateral agreement between parties.
Performance bank guarantee: A guarantee issued by a bank on behalf

of the contractor at his request stating that the contractor will perform his
obligations as per the terms of the contract.
Liquidated damages: Damages whose amount the parties designate

during the formation of a contract for the injured party to collect as
compensation upon a specific breach (e.g., late performance).
Force majeure: A common clause in contracts that essentially frees

both parties from liability or obligation when an extraordinary event or
circumstance beyond the control of the parties, such as a war, strike, riot,
crime, or an event described by the legal term "act of God" (e.g., flooding,
earthquake, volcanic eruption), prevents one or both parties from fulfilling
their obligations under the contract.
Subcontract: A process where parts of the work under contract are

entrusted by the main contractor to other contractors.
Notes
1.
What is a contract? What is the importance of contracts for projects?
2.
Explain the process of preparing contract for projects.
3.
Explain the different types of documents used in the contract process.
4.
What are the different terms required to be looked at for project contracts?
5.
What are the ingredients of successful project contracts?
6.
What is bidding? Explain the different types of bids.
7.
What is request for proposal? How it is different from request for

information?
8.
What is letter of intent? Explain the importance of letter of intent.
9.
What is memorandum of understanding? How it is different from letter of

intent?
10.
What are liquidated damages? Explain the use of liquidated damages for
projects.
11.
What is performance guarantee? Explain the use of performance guarantee

for projects.
12.
What are the different types of contracts? Give comparison.
13.
PQR Ltd., STP Co. and RTS Co. are the three bidders who have submitted
their bids.
The company has decided to evaluate the bid on six parameters as per
following table. They have decided the weightages as per following table. Now
based on the bid submitted by the three contractors, the points are given to the
contractors which are shown in the following table. Find which bidder should
be selected.
299
Weightage Score out of 10

PQR
STP
LTD.
CO.
7
7
8
Ability to deliver on time
5
8
3
Ability to handle complexity
6
8
8
Ability to meet cost
3
7
8
Financial capability
7
8
6
Ability to meet quality
9
7
3
Confidence generation/ Reputation_
Evaluation Parameter
Notes
---
RTS
CO.
6
7
7
6
6
9

Fill in the blanks.
1.
Contract is an agreement between two or more parties which, if it contains

the elements of a valid legal agreement, is enforceable by law or by
binding arbitration.
2.

acceptance is met with a mirror image acceptance.
3.
RFQ is an early stage in a project contract process.
4.
An LOI may also be referredto as a MOU, term sheet or discussion sheet.

1.
False
2.
False
rTh Suggested Reading

1.
300

McGraw-Hill.

Structure:
40
12.1 Understanding Project Risks

12.2 Risk Management Process
12.3 Risk Identification
12.4 Risk Assessment
12.5 Risk Mitigation
12.6 Risk Management Planning
12.7 Risk Communication
12.8 Tools for Risk Management
Summary
Key Words
Suggested Reading
UNIT
12
Notes
Objectives
Identify risks associated with project
Evaluate the risk consequences
Assess risk
Do risk mitigation
Use communication for risk management
Prepare risk management plan
Use tools for risk management
12.1 UNDERSTANDING PROJECT RISKS 1

Since all projects involve some degree of risk, a project risk management
plan is necessary to define and document those procedures that will be used to
manage risk throughout the life of the project. Risk can be understood as any
factor that may potentially interfere with successful completion of the project.
Therefore, it follows that by recognising potential problems the project manager
and core team members can avoid most, if not all, of these problems through
proper actions. The potential problems arise from the constraints in projects
which are:
1.
Scope Risk: The scope risk arises for improper understanding of scope
or insufficient definition of scope. This risk includes Scope gap (illdefined scope), Dependency change (unexpected legal, regulatory, etc.)
and Integration defect (change due to unexpected behaviour). There are
variety of methods for arriving at and defining deliverables and hence,
defining the scope. He suggests using the "is/is not" method of bounding
the scope. The scope risk includes Risk Framework, Risk Complexity
Index and Risk Assessment Grid. Risk Framework looks at the project's
technology, the market and the manufacturing effects and uses the relative
change to each of these to determine the risk level of the project. Risk
Complexity Index looks at the technical aspects of the project (technology,
architecture and system) and generates a number from 0-99 to quantify
risk. Risk Assessment creates a grid of technology, structure and size to
estimate the risk.
Scope risk is introduced into a project when the Work Breakdown Structure
WBS is not fully defined and understood. A WBS at too high a level can
leave scope ill-defined not allowing for proper estimates or definition of
work to be performed. Often WBS elements that are defined at too high
a level indicate work that is not understood and indicates significant risk
due to uncertainty on the project. The scope risk can be avoided by
302
2.
Clearly defining deliverables
Ensuring the value of the deliverables exceeds the scope of work
Defining a work breakdown structure small enough to ensure work

is understood
Assigning ownership and determine reasons any items are not

accepted
Noting all risks, including non-quantifiable risks due to size or

complexity of project
Notes
Schedule Risk: Schedule risk is the second level of risks affecting project
duration which is due to
Project dependencies where the activities and resources are

interdependent.
Parts delays, which are due to delay in the activities which are part
of the project.
Estimation errors which occur due to error in estimation of activity

durations on the lower side as compared to actual time required for
the activities.
Decision delay wherein the delay in the activities occurs due to time
lost in waiting for the decisions to carry out the activities.
Hardware delay which is due to non-availability of hardware or

resources required for the project.
To assist in reducing these risks, the process should start with the WBS
and apply estimates for effort and resources. This is an iterative process.
A number of things should be kept in mind:
Historical data should be used where applicable.
Resources planning will affect these estimates so these processes

will need to be iterative.
We must be careful with the people hesitating to give estimates, as

it may imply additional uncertainty.
If the durations are greater than two weeks they should be broken
down further.
We must incorporate holidays, vacations and other non-project

time.
Following techniques can be used for estimating schedules:
Project-level Think-Do-Check based on project size
Historical data
Prior experience
Delphi Group Estimating (a form of Consensus estimates)
Program Evaluation and Review Technique (PERT)
_ ' .130'
Notes
3.
Resource Risk: The final category of risks is the resource risks which
include:
Outsourcing delays
Lack of funds
Attrition of resources
People joining the team late
Scarcity of skills
'
When planning one must determine the skill set required and to identify
and reserve the people with those skills. To ensure proper resource
utilisation, computerised tools can be used to properly look at staff
loading. The loading will need to be compared to other project's needs
and resource availability. Conflicts need to be resolved and documented
since this also indicates inherent risk in the project.
Outsourcing is mitigated best by thorough planning, proper Request for
Proposal (RFP) generation, a clear and succinct contract and monitoring
the subcontractor for progress. Funding issues can be addressed by
defining and planning financial outlays early in the project planning cycle.
To ensure avoidance of resource risk we must take following actions:
All skills required to finish the project must have a named resource.
Do not over commit staff.
Identify tasks with unreliable resource estimates.
Identify all understaffed tasks.
Document all outsourcing risks.
Build in funding for training, equipment and travel.
Determine the complete project cost.
When managing project risk it must be understood that only two of the
three constraints can be defined, the third will be determined by the other two.
It should be determined which of the three (resource, scope or schedule) is the
controlling constraint and which is the most acceptable to change. Determining
this and insuring the stakeholders understand and consequence of this is of
utmost importance.
If scope is the least important, determine methods to achieve the most
for the customer while using fewer resources, trim low priority scope, suggest
alternative solutions to the problem being addressed, and look for reusable
components from other projects.
For resource constraints look at cross-training staff or training new people.
Outsourcing is an option but it introduces significant risk.
If schedule constraints are an issue, it is possible to use schedule float.
Also carefully analyse the schedule for tasks that can overlap. If they exist, look
at defining the tasks with more granularities. Lastly, if the funds are available,
add more resources to try to compress the schedule. All of these introduce their
own risk. Moreover to avoid risks in general, we must take following actions:
Continually analyse the project for other risks.
Align project plan and objective.
Document project priorities.
Identify project alternatives.
Explore project opportunities.
Remove unnecessary project scope.
Document risk and impact of proposed changes.
Use all means to identify unknown project risk.
12.2 RISK MANAGEMENT PROCESS

According to the standard ISO 31000 "Risk Management - Principles and
Guidelines on Implementation," the process of risk management consists of
several steps as follows:
A. Establishing the context - Establishing the context involves:
i.
Identification of risk in a selected domain of interest.
ii.
Planning the remainder of the process.
iii.
Mapping out the following:
The social scope of risk management
The identity and objectives of stakeholders
The basis upon which risks will be evaluated, constraints
iv.
Defining a framework for the activity and an agenda for identification
v.
Developing an analysis of risks involved in the process
vi.
Mitigation or Solution of risks using available technological, human and

organisational resources
r
:,, ActwAy
Activity 1
1.
Enlist the potential risks in project management, with a specific focus

on infrastructure projects in India.
2.
Enlist the steps in the process of risk management in construction

projects.
305
Notes
12.3 RISK IDENTIFICATION

After establishing the context, the next step in the process of managing
risk is to identify potential risks. Risks are about events that, when triggered,
cause problems. Hence, risk identification can start with the source of problems,
or with the problem itself.
Source analysis: Risk sources may be internal or external to the system

that is the target of risk management.
Examples of risk sources are: stakeholders of a project, employees of a
company or the weather.
Problem analysis: Risks are related to the identified threats. For example,
the threat of losing money, the threat of abuse of privacy information or
the threat of accidents and casualties. The threats may exist with various
entities, most important with shareholders, customers and legislative
bodies such as the government.
When either source or problem is known, the events that a source may
trigger or the events that can lead to a problem can be investigated.
For example: stakeholders withdrawing during a project may endanger
funding of the project; privacy information may be stolen by employees
even within a closed network; lightning striking a Boeing 747 during
takeoff may make all people onboard immediate casualties.
The chosen method of identifying risks may depend on culture, industry
practice and compliance. The identification methods are formed by
templates or the development of templates for identifying source, problem
or event. Common risk identification methods are:
Objectives-based risk identification: Organisations and project teams

have objectives. Any event that may endanger achieving an objective
partly or completely is identified as risk.
Scenario-based risk identification: In scenario analysis, different

scenarios are created. The scenarios may be the alternative ways to
achieve an objective, or an analysis of the interaction of forces in, for
example, a market or battle. Any event that triggers an undesired scenario
alternative is identified as risk.
Taxonomy-based risk identification: The taxonomy in taxonomy-based

risk identification is a breakdown of possible risk sources. Based on the
taxonomy and knowledge of best practices, a questionnaire is compiled.
The answers to the questions reveal risks.
Common-risk checking: In several industries lists with known risks are

available.
Each risk in the list can be checked for application to a particular situation.
Risk charting: This method combines the above approaches by listing

resources at risk, threats to those resources modifying factors which may
increase or decrease the risk and consequences it is wished to avoid.
Creating a matrix under these headings enables a variety of approaches.

One can begin with resources and consider the threats they are exposed to
and the consequences of each. Alternatively one can start with the threats
and examine which resources they would affect, or one can begin with the
consequences and determine which combination of threats and resources
would be involved to bring them about.
Notes

Fill in the blanks.
1.
Stakeholders of a project, employees of a company or the weather

over an airport are the examples of
combines the common risk identification methods by listing

resources at risk.
12.4 RISK ASSESSMENT

Once risks have been identified, they must then be assessed as to their
potential severity of loss and to the probability of occurrence. These quantities
can be either simple to measure, in the case of the value of a lost building, or
impossible to know for sure in the case of the probability of an unlikely event
occurring. Therefore, in the assessment process it is critical to make the best
educated guesses possible in order to properly prioritise the implementation of
the risk management plan.
The fundamental difficulty in risk assessment is determining the rate of
occurrence since statistical information is not available on all kinds of past
incidents. Furthermore, evaluating the severity of the consequences (impact) is
often quite difficult for immaterial assets. Asset valuation is another question
that needs to be addressed. Thus, best educated opinions and available statistics
are the primary sources of information. Nevertheless, risk assessment should
produce such information for the management of the organisation that the
primary risks are easy to understand and that the risk management decisions
may be prioritised. Thus, there have been several theories and attempts to
quantify risks. Numerous different risk formulae exist, but perhaps the most
widely accepted formula for risk quantification is:
Rate of occurrence multiplied by the impact of the event equals risk
Composite Risk Index
The above formula can also be re-written in terms of a Composite Risk
Index, as follows:
Composite Risk Index = Impact of Risk event x Probability of Occurrence
The impact of the risk event is assessed on a scale of 0 to 5, where 0 and
5 represent the minimum and maximum possible impact of an occurrence of a
risk (usually in terms of financial losses).
307
Notes
The probability of occurrence is likewise assessed on a scale from 0 to 5,

where 0 represents a zero probability of the risk event actually occurring while
5 represents a 100% probability of occurrence.
The Composite Index thus can take values ranging from 0 through 25, and
this range is usually arbitrarily divided into three sub-ranges. The overall risk
assessment is then low, medium or high, depending on the sub-range containing
the calculated value of the Composite Index. For instance, the three sub-ranges
could be defined as 0 to 8, 9 to 16 and 17 to 25.
Note that the probability of risk occurrence is difficult to estimate since
the past data on frequencies are not readily available, as mentioned above.
Likewise, the impact of the risk is not easy to estimate since it is often
difficult to estimate the potential financial loss in the event of risk occurrence.
Further, both the above factors can change in magnitude depending on
the adequacy of risk avoidance and prevention measures taken and due to
changes in the external business environment. Hence it is absolutely necessary
to periodically re-assess risks and intensify/ relax mitigation measures as
necessary.
The other way of calculating the risk is by using risk consequence concept.
The risk consequence is given as:
Risk Consequence = Risk Likelihood x Risk Impact
Where risk likelihood is the probability of any risk occurring and risk
impact is the impact on project cost or project duration. Let us take up an
example to manage this.
Example: ABC Ltd. has forecasted total cost of USD 20,000 for the project and
expects to complete the project in 20 days. They have identified risks and made
an assessment as per following table. Find the revised estimate.
Risk
A
B
C
D
E
Risk Impact Days Risk Impact USD

1000
0
0
4
2000
3
1000
0
0
500
1000
Risk Likelihood %
20
10
40
30
30
10
60
20
Solution: We first calculate risk consequence which is given as:

Risk Consequence = Risk Likelihood x Risk Impact
We calculate risk consequence in days and money terms separately as per

following table.
Risk
A
B
C
D
E
F
G
H
Risk
Impact
Days
Risk
Impact
USD
0
4
3
0
2
1
0
4
1000
0
2000
1000
0
500
1000
0
Risk
Likelihood
%
20
10
40
30
30
10
60
20
TOTAL
Risk
Consequence
Days
Risk
Consequence
USD
0 X 0.2 = 0
4 X 0.1=0.4
3 X 0.4 = 1.2
0 X 0.3 = 0
2 X 0.3 =0.6
1 X 0.1 = 0.1
0 X 0,1 = 0
4 X 0.2 =0.8
3.1
1000 X 0.2 = 200

OX 0.1=0
2000 X 0.4 = 800
1000 X 0.3 = 300
OX 0.3 =0
500 X 0.1 =50
1000 X 0.6 = 600
OX 0.2=0
1950
Notes
Thus, the revised estimate is 23.1 days and USD 21,950.
12.5 RISK MITIGATION

Once risks have been identified and assessed, all techniques to manage
the risk fall into one or more of these four major categories:
Avoidance
Reduction
Sharing
Retention
Ideal use of these strategies may not be possible. Some of them may
involve trade-offs that are not acceptable to the organisation or person making
the risk management decisions. Some sources call these categories ACAT, for
Avoid, Control, Accept or Transfer.
Risk mitigation measures are usually formulated according to one or
more of the following major risk options, which are:
Risk avoidance (eliminate, withdraw from or not become involved)
This includes not performing an activity that could carry risk. An example
would be not buying a property or business in order to not take on the Legal
liability that comes with it. Another would be not being flying in order to not
take the risk that the airplane was to be hijacked. Avoidance may seem the
answer to all risks, but avoiding risks also means losing out on the potential gain
that accepting (retaining) the risk may have allowed. Not entering a business to
avoid the risk of loss also avoids the possibility of earning profits.
Type of risk avoidance is hazard prevention. Hazard prevention refers
to the prevention of risks in an emergency. The first and most effective stage
of hazard prevention is the elimination of hazards. If this takes too long, is too
costly, or is otherwise impractical, the second stage is mitigation.
r ViT971
Notes
Risk reduction
Risk reduction or "optimisation" involves reducing the severity of the
loss or the likelihood of the loss from occurring. 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. Fire
suppression systems may mitigate that risk, but the cost may be prohibitive as a
strategy.
Acknowledging that risks can be positive or negative, optimising risks
means finding a balance between negative risk and the benefit of the operation
or activity; and between risk reduction and effort applied. By an offshore
drilling contractor effectively applying HSE Management in its organisation, it
can optimise risk to achieve levels of residual risk that are tolerable.
Modern software development methodologies reduce risk by developing
and delivering software incrementally. Early methodologies suffered from
the fact that they only delivered software in the final phase of development;
any problems encountered in earlier phases meant costly rework and often
jeopardized the whole project. By developing in iterations, software projects
can limit effort wasted to a single iteration.
Outsourcing could be an example of risk reduction if the outsourcer can
demonstrate higher capability at managing or reducing risks. For example, a
company may outsource only its software development, the manufacturing
of hard goods, or customer support needs to be done by another company,
while handling the business management itself. This way, the company can
concentrate more on business development without having to worry as much
about the manufacturing process, managing the development team, or finding a
physical location for a call center.
Risk sharing
Briefly defined as "sharing with another party the burden of loss or the
benefit of gain from a risk, and the measures to reduce the risk."
The term of 'risk transfer' is often used in place of risk sharing in the
mistaken belief that you can transfer a risk to a third party through insurance
or outsourcing. In practice, if the insurance company or contractor go bankrupt
or end up in court, the original risk is likely to still revert to the first party. As
such in the terminology of practitioners and scholars alike, the purchase of an
insurance contract is often described as a "transfer of risk." However, technically
speaking, the buyer of the contract generally retains legal responsibility for the
losses "transferred", meaning that insurance may be described more accurately
as a post-event compensatory mechanism. For example, a personal injuries
insurance policy does not transfer the risk of a car accident to the insurance
company. The risk is still with the policy holder namely the person who has
been in the accident. The insurance policy simply provides that if an accident
(the event) occurs involving the policy holder then some compensation may be
payable to the policy holder that is commensurate to the suffering/damage.
,319
Some ways of managing risk fall into multiple categories. Risk retention
pools are technically retaining the risk for the group, but spreading it over the
whole group involves transfer among individual members of the group. This is
different from traditional insurance, in that no premium is exchanged between
members of the group up front, but instead losses are assessed to all members
of the group.
Notes
Risk retention
Involves accepting the loss, or benefit of gain, from a risk when it occurs.
True self-insurance falls in this category. 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. This includes risks that are so large or catastrophic that
they either cannot be insured against or the premiums would be infeasible. War
is an example since most property and risks are not insured against war, so the
loss attributed by war is retained by the insured. Also any amount of potential
loss (risk) over the amount insured is retained risk. This may also be acceptable
if the chance of a very large loss is small or if the cost to insure for greater
coverage amounts is so great it would hinder the goals of the organisation too
much.
1P..t.tw t. Activity 2
..Enlist the different techniques of risk management in construction projectsi)
12.6 RISK MANAGEMENT PLANNING
The procedure used to manage risks is defined in the planning stage,
documented in the project risk management plan, and then executed through the
life of the project. Risk Management is the process of thinking systematically
about all potential undesirable outcomes before they happen and determining
procedures that will avoid them, minimise their impact, or cope with their
impact.
Risk management planning is the identification, assessment, and
prioritisation of risks followed by coordinated and economical application of
resources to minimise, monitor, and control the probability and/or impact of
unfortunate events or to maximise the realisation of opportunities. Risks can
come from uncertainty in financial markets, project failures, legal liabilities,
credit risk, accidents, natural causes and disasters as well as deliberate attacks
from an adversary. Several risk management standards have been developed
including the Project Management Institute, the National Institute of Science
and Technology, actuarial societies, and ISO standards. Methods, definitions
and goals vary widely according to whether the risk management method is in
the context of project management, security, engineering, industrial processes,
financial portfolios, actuarial assessments, or public health and safety.
311
Notes
Any risk management process has to follow certain principles. The

International Oranization for Standardisation identifies the following principles
of risk mnagement:
Risk management should:
Create value.
Be an integral part of organisational processes.
Be part of decision-making.
Explicitly address uncertainty.
Be systematic and structured.
Be based on the best available information.
Be tailored.
Take into account human factors.
Be transparent and inclusive.
Be dynamic, iterative and responsive to change.
Be capable of continual improvement and enhancement.
A project risk management plan should also specify who is responsible

for managing the different areas of risk, how risks will be tracked through the
project life cycle, how contingency plans will be implemented, and how project
reserves will be allocated in order to handle risks.
Project size has an effect on the project risk management plan. Large
projects normally require more detailed risk planning than smaller projects
due to the bigger number, and complexity of potential risks. Quite often, this
requires developing and analysing alternative strategies and strategy evaluation
criteria.
The strategies to Manage risk include transferring the risk to another
party, avoiding the risk, reducing the negative effect of the risk, and accepting
some or all of the consequences of a particular risk.
Certain aspects of many of the risk management standards have come
under criticism for having no measurable improvement on risk even though the
confidence in estimates and decisions increase.
In ideal risk management, a prioritisation process is followed whereby the
risks with the greatest loss and the greatest probability of occurring are handled
first, and risks with lower probability of occurrence and lower loss are handled
in descending order. In practice the process can be very difficult, and balancing
between risks with a high probability of occurrence but lower loss versus a risk
with high loss but lower probability of occurrence can often be mishandled.
Intangible risk management identifies a new type of a risk that has a
100% probability of occurring but is ignored by the organisation due to a lack
of identification ability. For example, when deficient knowledge is applied
to a situation, a knowledge risk materialises. Relationship risk appears when
ineffective collaboration occurs. Process-engagement risk may be an issue when
312
ineffective operational procedures are applied. These risks directly reduce the
productivity of knowledge workers, decrease cost effectiveness, profitability,
service, quality, reputation, brand value, and earnings quality. Intangible risk
management allows risk management to create immediate value from the
identification and reduction of risks that reduce productivity.
Notes
Risk management also faces difficulties in allocating resources. This is the

idea of opportunity cost. Resources spent on risk management could have been
spent on more profitable activities. Again, ideal risk management minimises
spending and minimizes the negative effects of risks.
For creating risk management plan, select appropriate controls or
countermeasures to measure each risk. Risk mitigation needs to be approved by
the appropriate level of management. For instance, 4 risk concerning the image
of the organisation should have top management decision behind it whereas IT
management would have the authority to decide on computer virus risks.
The risk management plan should propose applicable and effective
security controls for managing the risks. For example, an observed high risk of
computer viruses could be mitigated by acquiring and implementing antivirus
software. A good risk management plan should contain a schedule for control
implementation and responsible persons for those actions.
According to ISO/IEC 27001, the stage immediately after completion of the
risk assessment phase consists of preparing a Risk Treatment Plan, which should
document the decisions about how each of the identifjed risks should be handled.
Mitigation of risks often means selection of security controls, which should be
documented in a Statement of Applicability, whichi identifies which particular
control objectives and controls from the standard have been selected, and why.
Implementation
Implementation follows all of the planned methods for mitigating the
effect of the risks. Purchase insurance policies fo'r the risks that have been
decided to be transferred to an insurer, avoid all risks that can be avoided
without sacrificing the entity's goals, reduce others, and retain the rest.
Review and evaluation of the plan
Initial risk management plans will never be perfect. Practice, experience,
and actual loss results will necessitate changes in the plan and contribute
information to allow possible different decisions to be made in dealing with the
risks being faced.
Risk analysis results and management plans should be updated periodi cally.
There are two primary reasons for this:
1.
To evaluate whether the previously selected security controls are still

applicable and effective, and
2.
To evaluate the possible risk level changes in the business environment.

For example, information risks are a good example of rapidly changing
business environment.
313
Notes
If risks are improperly assessed and prioritised, time can be wasted in

dealing with risk of losses that are not likely to occur. Spending too much time
assessing and managing unlikely risks can divert resources that could be used
more profitably. Unlikely events do occur but if the risk is unlikely enough
to occur it may be better to simply retain the risk and deal with the result if
the loss does in fact occur. Qualitative risk assessment is subjective and lacks
consistency. The primary justification for a formal risk assessment process is
legal and bureaucratic.
Prioritising the risk management processes too highly could keep an
organisation from ever completing a project or even getting started. This is
especially true if other work is suspended until the risk management process is
considered complete.
It is also important to keep in mind the distinction between risk and
uncertainty. Risk can be measured by impacts x probability.
Risk management activities
In project management, risk management includes the following activities:
Planning how risk will be managed in the particular project. Plan should
include risk management tasks, responsibilities, activities and budget.
Assigning a risk officer a team member other than a project manager

who is responsible for foreseeing potential project problems. Typical
characteristic of risk officer is a healthy skepticism.
Maintaining live project risk database. Each risk should have the
following attributes: opening date, title, short description, probability and
importance. Optionally a risk may have an assigned person responsible
for its resolution and a date by which the risk must be resolved.
Creating anonymous risk reporting channel. Each team member should

have possibility to report risk that he/she foresees in the project.
Preparing mitigation plans for risks that are chosen to be mitigated. The
purpose of the mitigation plan is to describe how this particular risk will
be handled what, when, by who and how will it be done to avoid it or
minimise consequences if it becomes a liability.
Summarising planned and faced risks, effectiveness of mitigation

activities, and effort spent for the risk management.

314
1.
Knowledge risk materialising out of deficient knowledge being

applied to a situation is a tangible risk.
Risk analysis results and management plans should be updated

periodically.
12.7 RISK COMMUNICATION
Notes
Risk communication is a complex cross-disciplinary academic field.

Problems for risk communicators involve how to reach the intended audience, to
make the risk comprehensible and relatable to other risks, how to pay appropriate
respect to the audience's values related to the risk, how to predict the audience's
response to the communication, etc. A main goal of risk communication is to
improve collective and individual decision-making. Risk communication is
somewhat related to crisis communication.
Bow-tie diagrams
A popular solution to the quest to communicate risks and their treatments
effectively is to use bow-tie diagrams. A Bow-Tie is a diagram that visualises
the risks you are dealing with. The diagram is shaped like a bow-tie, creating a
clear differentiation between proactive and reactive risk management. The power
of a Bow-Tie diagram is that it shows us how well we are controlling plausible
risk scenarios, in one easy to understand picture. In short, it provides a simple,
visual explanation of risk control in a way that no other method can achieve.
These have been effective, for example, in a public forum to model perceived
risks and communicate precautions, during the planning stage of offshore oil
and gas facilities in Scotland. Equally, the technique is used for HAZID (Hazard
Identification) workshops of all types, and results in a high level of engagement.
For this reason (amongst others) an increasing number of government regulators
for major hazard facilities (MHFs), offshore oil and gas, aviation, etc. welcome
safety case submissions which use diagrammatic representation of risks at their
core. Following figure is an example of bow-tie diagram.
Preventative Controls
Mitigative Controls
41
ro 1141.
I I I '
Hazards
Controls
.i--rijs
Controls
Fig. 12.1: Bow-tie Diagram

The bow-tie diagram represents visual illustration of the hazard, its causes,
consequences, controls, and how controls fail. The advantage of bow-tie diagram
is that the bow-tie diagram can be readily understood at all personnel levels.
Rules for the practice of risk communication
Accept and involve the public/other consumers as legitimate partners.

Plan carefully and evaluate your efforts with a focus on your strengths,
weaknesses, opportunities, and threats.
315
Notes
Listen to the public's specific concerns.

Be honest, frank, and open.
Coordinate and collaborate with other credible sources.
Meet the needs of the media.

Speak clearly and with compassion.

Fill in the blanks.
is to improve collective and individual
1.
A main goal of
decision-making.
diagram creates a clear differentiation between proactive and

reactive risk management.
12.8 TOOLS FOR RISK MANAGEMENT

There are various tools which help in proper risk management in project.
The two tools which are very helpful in this are as follows:
A. Porter's Five Forces Model
The Porter's 5 Forces tool is a simple but powerful tool for understanding
where power lies in a business situation. This is useful, because it helps
you understand both the strength of your current competitive position,
and the strength of a position you're considering moving into.
With a clear understanding of where power lies, you can take fair
advantage of a situation of strength, improve a situation of weakness,
and avoid taking wrong steps. This makes it an important part of your
planning toolkit.
Conventionally, the tool is used to identify whether new products,
services or businesses have the potential to be profitable. However it can
be very illuminating when used to understand the balance of power in
other situations too.
Five Forces Analysis assumes that there are five important forces that
determine competitive power in a business situation. These are:
1.
Supplier power: Here you assess how easy it is for the suppliers to
drive up prices. This is driven by the number of suppliers of each
key input, the uniqueness of their product or service, their strength
and control over you, the cost of switching from one to another, and
so on. The fewer the supplier choices you have, and the more you
need suppliers' help, the more powerful your suppliers are.
2.
Buyer power: Here you ask yourself how easy it is for buyers to
drive prices down. Again, this is driven by the number of buyers,
the importance of each individual buyer to your business, the cost
to them of switching from your products and services to those of

someone else, and so on. If you deal with few, powerful buyers,
then they are often able to dictate terms to you.
3.
Competitive rivalry: What is important ,here is the number and

capability of your competitors. If you have many competitors,
and they offer equally attractive products and services, then you'll
most likely have little power in the situation, because suppliers and
buyers will go elsewhere if they don't get a good deal from you.
On the other hand, if no one else can do what you do, then you can
often have tremendous strength.
4.
Threat of substitution: This is affected by the ability of your

customers to find a different way of doing what you do for
example, if you supply a unique software product that automates
an important process, people may substitute by doing the process
manually or by outsourcing it. If substitution is easy and substitution
is viable, then this weakens your power.
5.
Threat of new entry: Power is also affected by the ability of people

to enter your market. If it costs little in time or money to enter your
market and compete effectively, if there are few economies of scale
in place, or if you have little protection for your key technologies,
then new competitors can quickly enter your market and weaken
your position. If you have strong and durable barriers to entry, then
you can preserve a favorable position and take fair advantage of it.
Notes
These forces can be neatly brought together in a diagram like the one below:
Porter's Five Forces
threat of New Enity:
tens and cosi of naive
SiValallst know4odge
- Iconornicas of seek,
Cot, ochiontogos
Inchriolegy orotrAcren
Bailors ks onify
oic
N
N
Supplier
Power
Threat of
New
Entry
CornoetilMiRh,olry:
Nemo, of c:OrTipOriforr.
;Duddy offoroncos
Olhor dlifortricos
Swift:frog costs
Customer lOyilly
Costs or 110t-hil'iq mote;
/
/Competitive r
Rivalry
Buyer
Power
_
Supplier Power:
Nernixit of stiprecils
Sizo of 51.101-*01$
- UricitoOnesS of service
Ycra obely to 9ubstitula
- Cosi of crionryng
-etc
Threat of Substitution:
- Sr Lzlindo ixof art I 'arc-9
CoS1 Of crango
\
Threat of
Substitution
layer Power
Numboi of customers
Silo of colon:Sol
Wolof/COS ootwoon
ccmoofifors
Puce sertseivity
- ALAN to sUbstifulo
Cost of charging
otc-
Fig.12.2: Porter's Five Forces

317
To use the tool to understand the situation, we will have to look at each of
these forces one-by-one and write our observations.
Notes
We will have to brainstorm the relevant factors for our market or situation,
and then check against the factors listed for the force in the diagram above.
Then, we will have to mark the key factors on the diagram and summarise
the size and scale of the force on the diagram. An easy way of doing this
is to use, for example, a single "+" sign for a force moderately in your
favour, or "" for a force strongly against us.
Then we need to look at the situation we find using this analysis and think
through how it affects us. Bear in mind that few situations are perfect;
however, looking at things in this way helps you think through what you
could change to increase your power with respect to each force. What's
more, if you find yourself in a structurally weak position, this tool helps
you think about what you can do to move into a stronger one.
B.
Decision Tree Analysis

Decision trees are useful tools for helping you to choose between several
courses of action. They provide a highly effective structure within which
we can explore options, and investigate the possible outcomes of choosing
those options. They also help us to form a balanced picture of the risks and
rewards associated with each possible course of action. This makes them
particularly useful for choosing between different strategies, projects or
investment opportunities, particularly when our resources are limited.
Decision tree starts with a decision that we need to make. We need to
draw a small square to represent this on the left hand side of a large piece
of paper, half way down the page.
From this box, we need to draw out lines towards the right for each
possible solution, and write a short description of the solution along the
line. We have to keep the lines apart as far as possible so that we can
expand our thoughts.
At the end of each line, consider the results. If the result of taking that
decision is uncertain, we have to draw a small circle. If the result is
another decision, thdn we need to make, another square. Squares represent
decisions, and circle represent uncertain outcomes. Write the decision or
factor above the square or circle. If we have completed the solution at the
end of the line, just leave it blank.
Starting from the new decision squares on our diagram, we have to draw
out lines representing the options that we could select. From the circles
we have to draw lines representing possible outcomes. Again we need to
make a brief note on the line saying what it means. We have to keep on
doing this until we have drawn out as many of the possible outcomes and
decisions as we can see leading on from the original decisions.
An example is shown in Figure 1:

Figure I:
Example Decision Tree:
Should we develop a now
product or consolidate?
Notes
mascot reaction
InOdtittrIO
of
Dap,
Once we have done this, review your tree diagram. We have to challenge
each square and circle to see if there are any solutions or outcomes we have
not considered. If there are, we need to draw them in. If necessary, we have to
redraft our tree if parts of it are too congested or untidy.
Evaluating Decision Tree
Now we need to see which option has the greatest worth to us. For this we
need to start by assigning a cash value or score to each possible outcome. We
need to make our best assessment of how much we think it would be worth to
us if that outcome came about.
Next look at each circle (representing an uncertainty point) and estimate
the probability of each outcome. If you use percentages, the total must come
to 100% at each circle. If you use fractions, these must add up to 1. If you
have data on past events you may be able to make rigorous estimates of the
probabilities. Otherwise write down your best guess.
319
Notes
This will give you a tree like the one shown in Figure 2:
rigure
Example Ciecison Tree:
Should we develop a new
market reaction
$1,000.000
$-50.000
$2,000
$ I ,000,00C
$50,000
$2,000
$400 000
$20.000
$6,000
.11700
-7
_
'
$2,000
Calculating Tree Values

Once you have worked out the value of the outcomes, and have assessed
the probability of the outcomes of uncertainty, it is time to start calculating the
values that will help you make your decision.
Start on the right-hand side of the decision tree, and work back towards
the left. As you complete a set of calculations on a node (decision square or
uncertainty circle), all you need to do is to record the result. You can ignore all
the calculations that lead to that result from then on.
Calculating the value of uncertain outcome nodes
Where you are calculating the value of uncertain outcomes (circles on the
diagram), do this by multiplying the value of the outcomes by their probability.
The total for that node of the tree is the total of these values.
In the example in Figure 2, the value for 'new product, thorough
development' is:
320
0.4 (probability good outcome) x $1,000,000 (value) = $400,000
Notes
0.4 (probability moderate outcome) x 50,000 (value) = $20,000

0.2 (probability poor outcome) x 2,000 (value) $400
$420,400
Figure 3 shows the calculation of uncertain outcome nodes:
Hgurs
Example Deaston TresShould we develop a new
market reaction
$1,0001)O1)
1-4--]
.A 100
WO 0
0,4 x 1.000,000 = 400,0170

114 x
50.000 = 20,000
0.2 x
2.000 =
400
$50000
$2.000
420.400
$1,000,000
11,4001
$50,000
i>00,
0 1 x 1.000 COO= 100.000
0 2 x 50 CCO = 10.0c0
07x
Mee = 1,4C0
111,400
$2,000
$400,000
LLIEXA
fi
c.L.
C 1-131eze,--0
modemgo
$20.000
Q
>40".
Poo,.
0.3 x 400.000 = 120,000
0,4 x 20.000 = 8,000
0.3 x 4.000 =
1,800
129,800
4600,,j.
$6,000
$20 OCO
112,8001
04
04
Door
$2,000
0 d x 20.000 = 12,000
0,4 x 2.000 =
80(1
12 800
Note that the values calculated for each node are shown in the boxes.
Calculating the Value of Decision Nodes
When you are evaluating a decision node, write down the cost of each
option along each decision line. Then subtract the cost from the outcome value
that you have already calculated. This will give you a value that represents the
benefit of that decision.
Note that amounts already spent do not count for this analysis. These are
`sunk costs' and (despite the emotional cost) should not be factored into the
decision.
When you have calculated these decision benefits, choose the option that
has the largest benefit, and take that as the decision made. This is the value of
that decision node.
321
Notes
Figure 4 shows this calculation of decision nodes in our example:

'1)1, 4.
tnrroloIt.1141$ Weer
:00tio we Ovvolork aeow
n itelOtconsovcs7kv
'P KC tr.
In this example, the benefit we previously calculated for 'new product,

thorough development' was $420,400. We estimate the future cost of this
approach as $150,000. This gives a net benefit of $270,400.
The net benefit of 'new product, rapid development' was $31,400. On this
branch we therefore choose the most valuable option, 'new product, thorough
development', and allocate this value to the decision node.
By applying this technique we can see that the best option is to develop a
new product. It is worth much more to us to take our time and get the product
right, than to rush the product to market. And it's better just to improve our
existing products than to botch a new product, even though it costs us less.
Decision trees provide an effective method of decision-making because
they:
Clearly lay out the problem so that all options can be challenged.
Allow us to analyse the possible consequences of a decision fully.
Provide a framework to quantify the values of outcomes and the

probabilities of achieving them.
Help us to make the best decisions on the basis of existing information

and best guesses.
As with all decision-making methods, decision tree analysis should be

used in conjunction with common sense decision trees are just one important
part of our decision-making tool kit.
Almost everything we do in today's business world involves a risk of
some kind. Customer habits change, new competitors appear, and factors
311
outside your control could delay your project. But formal risk analysis and risk
management can help you to assess these risks and decide what actions to take
to minimise disruptions to your plans. They will also help you to decide whether
the strategies you could use to control risk are cost-effective.
IM Notes
Here we define risk as 'the perceived extent of possible loss'. Different

people will have different views of the impact of a particular risk what may be
a small risk for one person may destroy the livelihood of someone else.
One way of putting figures to risk is to calculate a value for it as: Risk =
Probability of event x Cost of event
Doing this allows us to compare risks objectively. We use this approach
formally in decision-making with Decision Trees.
To carry out a risk analysis, we can follow these steps:
1.
Identify threats: The first stage of a risk analysis is to identify threats

facing you. Threats may be:
Human - from individuals or organisations, illness, death, etc.
Operational - from disruption to supplies and operations, loss of

access to essential assets, failures in distribution, etc.
Reputation - from loss of business partner or employee confidence,

or damage to reputation in the market.
Procedural - from failures of accountability, internal systems and

controls, organisation, fraud, etc.
Project - risks of cost over-runs, jobs taking too long, of insufficient

product or service quality, etc.
Financial - from business failure, stock market, interest rates,

unemployment, etc.
Technical - from advances in technology, technical failure, etc.
Natural - threats from weather, natural disaster, accident, disease,

etc.
Political - from changes in tax regimes, public opinion, government

policy, foreign influence, etc.
Others - Porter's Five Forces analysis as discussed above may help

identify other risks.
--- .: ---- - . ------------- -
This analysis of threat is important because it is so easy to overlook

important threats. One way of trying to capture them all is to use a number
of different approaches:
Firstly, run through a list such as the one above, to see if any apply.
Secondly, think through the systems, organisations or structures

you operate, and analyse risks to any part of those.
See if you can see any vulnerabilities within these systems or

structures.
323 11
Notes
Ask other people, who might have different perspectives.
2.
Estimate risk: Once you have identified the threats you face, the next
step is to work out the likelihood of the threat being realised and to assess
its impact. One approach to this is to make your best estimate of the
probability of the event occurring, and to multiply this by the amount it
will cost you to set things right if it happens. This gives you a value for
the risk.
3.
Managing risk: Once you have worked out the value of risks you face,
you can start to look at ways of managing them. When you are doing this,
it is important to choose cost-effective approaches. In most cases, there is
no point in spending more to eliminate a risk than the cost of the event if
it occurs. Often, it may be better to accept the risk than to use excessive
resources to eliminate it. Risk may be managed in a number of ways:
By using existing assets: Here existing resources can be used

to counter risk. This may involve improvements to existing
methods and systems, changes in responsibilities, improvements to
accountability, and internal controls, etc.
By contingency planning: We may decide to accept a risk, but

choose to develop a plan to minimise its effects if it happens. A
good contingency plan will allow you to take action immediately,
with the minimum of project control if you find yourself in a crisis
management situation. Contingency plans also form a key part
of Business Continuity Planning (BCP) or Business Continuity
management (3CM).
By investing in new resources: Our risk analysis should give you

the basis for deciding whether to bring in additional resources to
counter the risk. This can also include insuring the risk: here you pay
someone else to carry part of the risk. This is particularly important
where the risk is so great as to threaten your or your organisation's
solvency.
Once you have carried out a risk analysis and management exercise, it
may be worth carrying out regular reviews. These might involve formal reviews
of the risk analysis, or may involve testing systems and plans appropriately.
Risk analysis allows you to examine the risks that you face or your
organisation faces. It is based on a structured approach to thinking through
threats, followed by an evaluation of the probability and cost of events occurring.
As such, it forms the basis for risk management and crisis prevention. Here
the emphasis is on cost-effectiveness. Risk management involves adapting the
use of existing resources, contingency planning and good use of new resources.
Contingency Planning
Fires, floods, tornadoes these are the things we often connect with
contingency planning. But what if your main supplier suddenly goes bankrupt?
Or, what if your entire sales force gets sick with food poisoning at your annual
sales conference? Or, your payroll clerk simply calls in sick on payroll day?
These things can all cause confusion and disorder if you haven't prepared for
them properly. Contingency planning is a key part of this preparation.
Notes
As you see, contingency planning is not just about major disasters.

On a smaller scale, it's about preparing for events such as the loss of data,
people, customers, and suppliers, and other disruptive unknowns. That's why
it's important to make contingency planning a normal part of your everyday
business operations.
The need for contingency planning emerges from a thorough analysis of
the risks that your organisation faces. It's also useful in thinking about new
and ongoing projects: what happens when 'Plan A' doesn't go as expected?
Sometimes Plan A simply means 'business as usual'. Other times, with more
sophisticated risk management plans, Plan A is your first response to deal with
an identified risk and when Plan A doesn't work, you use your contingency
plan.
Contingency planning isn't the only action that emerges as a result of
risk analysis. You can manage risk by using existing assets more effectively
or by investing in new resources or services that help you manage it (such as
insurance). Also, if a risk is particularly unlikely to materialise, you may decide
to do nothing about it, and manage around it if the situation arises.
Actisim Activity 3
1.
Prepare a checklist for at least 10 possible risks in construction project.

List the ways to manage these risks
2.
Prepare a checklist for 10 possible risks in software development

project. Write the steps to manage these risks.
Summary
Since all projects involve some degree of risk, a project risk management
plan is necessary to define and document those procedures that will be used
to manage risk throughout the life of the project. Risk can be understood
as any factor that may potentially interfere with successful completion of
the project. Therefore, it follows that by recognising potential problems
the project manager and core team members can avoid most, if not all, of
these problems through proper actions. The potential problems arise from
the constraints in projects which are: Scope risk, Schedule risk, Resource
Risk.
When managing project risk it must be understood that only two of the
three constraints can be defined, the third will be determined by the
other two. It should be determined which of the three (resource, scope or
schedule) is the controlling constraint and which is the most acceptable
,325
to change. Determining this and insuring the stakeholders understand and

consequence of this is of utmost importance.
Notes
The process of risk management consists of establishing the context,

identification, planning, mapping, defining a framework, developing an
analysis and mitigation.
Once risks have been identified and assessed, all techniques to manage
the risk fall into one or more of these four major categories: Avoidance,
Reduction, Sharing and Retention. Some of them may involve tradeoffs that are not acceptable to the organisation or person making the risk
management decisions.
The procedure used to manage risks is defined in the planning stage,

documented in the project risk management plan, and then executed
through the life of the project. Risk management is the process of thinking
systematically about all potential undesirable outcomes before they
happen and determining procedures that will avoid them, minimise their
impact, or cope with their impact. A project risk management plan should
also .specify who is responsible for managing the different areas of risk,
how risks will be tracked through the project life cycle, how contingency
plans will be implemented, and how project reserves will be allocated in
order to handle risks.
Risk communication is a complex cross-disciplinary academic field.

Problems for risk communicators involve how to reach the intended
audience, to make the risk comprehensible and relatable to other risks,
how to pay appropriate respect to the audience's values related to the
risk, how to predict the audience's response to the communication, etc. A
main goal of risk communication is to improve collective and individual
decision-making. A popular solution to the quest to communicate risks
and their treatments effectively is to use bow tie diagrams.
There are various tools which help in proper risk management in project.
The two tools which are very helpful in this are Porter's Five Forces
Model and Decision Tree Analysis.
Keywords
326
Risk: Any factor that may potentially interfere with successful completion
of the project.
Scope risk: The scope risk arises for improper understanding of scope or
insufficient definition of scope.
Schedule risk: The second level of risks effecting project duration which
is due to project dependencies, parts delay, estimation errors, decision
delay, hardware delay.
Resource risk: The risk which arises due to outsourcing delays, lack of
funds, attrition of resources, people joining the team late, scarcity of skills
and material shortage.
Risk sharing: Sharing with another party the burden of loss or the benefit
of gain, from a risk, and the measures to reduce a risk.
Risk retention: Involves accepting the loss, or benefit of gain, from a risk
when it occurs.
Notes
iii Self-Assessment Questions

1.
What is risk? What are the various types of risks that can occur in projects?
2.
What are the sources of risk in projects? Explain with suitable examples.
3.
What is mitigation? How risks can be mitigated?
4.
What is risk sharing? How it is different from risk retention?
5.
What is risk avoidance? How it is different from risk reduction?
6.
What is the importance of risk management? Explain the process of risk

management.
7.
What are the principles of risk management? Explain with suitable

examples.
8.
What are risk impact, risk likelihood and risk consequence? Explain with
suitable examples.
9.
What are the tools that can be used for risk management? Explain with
examples.
10.
What is the importance of decision tree for project risk management?
11.
What is the importance of Porter's Five Forces model for project risk
management?
12.
Explain the importance of proper communication for project risk

management.
13. ABC Ltd. has forecasted total cost of USD 10,000 for the project and
expects to complete the project in 10 days. They have identified risks and
made an assessment as per following table. Find the revised estimate.
Risk
A
B
C
D
E
F
G
H
Risk Impact Days Risk Impact USD Risk Likelihood %

20
0
1000
10
4
0
40
3
2000
30
0
1000
2
30
0
10
1
500
60
0
1000
4
20
0
327
Notes

Fill in the blanks.
1.
Stakeholders of a project, employees of a company or the weather are the

examples of risk sources.
2.
Risk charting combines the common risk identification methods by listing

resources at risk.

1.
False
2.
True

Fill in the blanks.
1.
Amain goal of risk communication is to improve collective and individual

decision-making.
2.
Bow-tie diagram creates a clear differentiation between proactive and

reactive risk management.
Suggested Reading
1.
328
Prasanna, Chandra. 2002. Project Management. New Delhi: Tata McGrawHill.

Structure: lo
13.1 Understanding Project Quality Management
UNIT
13
13.2 Quality Definition

13.3 Quality Control
13.4 Quality Assurance
13.5 Quality Improvement
13.6 Achievement of Quality in Projects
13.7 Quality Standards
Summary
Key Words
Suggested Reading
329
Notes
Objectives
Explain quality for project
Assess quality requirements for projects
Use quality tools for quality control
Implement quality assurance process
Implement process for quality improvement
Set quality standards
Establish parameters for quality of design and quality of conformance
13.1 UNDERSTANDING PROJECT QUALITY

MANAGEMENT
Quality management is the process for ensuring that all the project
activities necessary to design, plan and implement a project are effective and
efficient with respect to the purpose of the objective and its performance.
Project quality management (QM) is not a separate, independent process
that occurs at the end of an activity to measure the level of quality of the
output. It is not purchasing the most expensive material or services available
on the market. Quality and grade are not the same, grade are characteristics
of a material or service such as additional features. A product may be of good
quality (no defects) and be of low grade (few or no extra features).
Quality management is a continuous process that starts and ends with the
project. It is more about preventing and avoiding than measuring and fixing
poor quality outputs. It is part of every project management processes from the
moment the project initiates to the final steps in the project closure phase.
QM focuses on improving stakeholder's satisfaction through continuous
and incremental improvements to processes, including removing unnecessary
activities it achieves that by the continuous improvement of the quality of
material and services provided to the beneficiaries. It is not about finding and
fixing errors after the fact, quality management is the continuous monitoring
and application of quality processes in all aspects of the project.
Definition of Quality
Quality has been defined as:
1.
"The totality of characteristics of an entity that bear on its ability to

satisfy stated or implied needs." The stated and implied quality needs are
the inputs used in defining project requirements from the donor and the
beneficiaries.
2.
"Conformance to requirements or fitness for 'use": This means that the

product or services must meet the intended objectives of the project and
have a value to the donor and beneficiaries and that the beneficiaries can
use the material or service as it was originally intended. The central focus
of quality management is meeting or exceeding stakeholder's expectations
and conforming to the project design and specifications.
Notes
The ultimate judge for quality is the beneficiary, and represents how
close the project outputs and deliverables come to meeting the beneficiaries'
requirements and expectations. How a beneficiary defines quality may be
completely subjective, but there are many ways to make quality objective by
defining the individual characteristics and determine one or more metrics that
can be collected to mirror the characteristic. For instance, one of the features
of a quality product may be that it has a minimum amount of errors. This
characteristic can be measured by counting errors and defects after the product
is used.
Quality management is not an event it is a process, a consistently high
quality product or service cannot be produced by a defective process. Quality
management is a repetitive cycle of measuring quality, updating processes,
measuring, updating processes until the desired quality is achieved.
The Purpose of Management of Quality
The main principle of project quality management is to ensure the project
will meet or exceed stakeholder's needs and expectations. The project team
must develop a good relationship with key stakeholders, specially the donor and
the beneficiaries of the project, to understand what quality means to them. One
of the causes for poor project evaluations is the project focuses only in meeting
the written requirements for the main outputs and ignores other stakeholder
needs and expectations for the project.
Quality must be viewed on an equal level with scope, schedule and budget.
If a project donor is not satisfied with the quality of how the project is delivering
the outcomes, the project team will need to make adjustments to scope, schedule
and budget to satisfy the donor's needs and expectations. To deliver the project
scope on time and on budget is not enough, to achieve stakeholder satisfaction
the project must develop a good working relationship with all stakeholders and
understand their stated or implied needs. Project management consists of four
main processes:
Quality Definition
Quality Control
Quality Assurance
Quality Improvements
331
Notes
13.2 QUALITY DEFINITION

The first step on the quality management is to define quality, the project
manager and the team must identify what quality standards will be used in the
project, it will look at what the donor, beneficiaries, the organisation and other
key stakeholders to come up with a good definition of quality. In some instances
the organisation or the area of specialization of the project (health, water or
education) may have some standard definitions of quality that can be used by
the project.
Identifying quality standards is a key component of quality definition that
will help identify the key characteristics that will govern project activities and
ensure the beneficiaries and donor will accept the project outcomes.
Quality management implies the ability to anticipate situations and prepare
actions that will help bring the desired outcomes. The goal is the prevention of
defects through the creation of actions that will ensure that the project team
understands what is defined as quality.
Sources of Quality Definition
One source for definition of quality comes from the donor the project
team must establish conversations with the donor to be familiar with and come
to a common understanding of what the donor defines as quality. The donor
may have certain standards of what is expected from the project, and how the
project delivers the expected benefits to the beneficiaries. This is in line with the
project's ultimate objective that the project outcomes have the ability to satisfy
the stated or implied needs.
Another source for quality definition comes from the beneficiaries the
project team must be able to understand how the beneficiaries define quality
from their perspective, a perspective that is more focused on fitness for use, the
project outcomes must be relevant to the current needs of the beneficiaries and
must result in improvements to their lives. The team can create, as part of the
baseline data collection, questions that seek to understand how the beneficiaries
define the project will meet their needs, and a question that also helps define
what project success looks like from the perspective of a beneficiary.
The development organisation may have its own quality standards that
can reflect technical and managerial nature of the project. The organisation may
require from the project timely and accurate delivery of project information
needed for decision making, or compliance to international or locally recognized
quality standards that define specific technical areas of the project, this is quite
often in health, water and nutrition projects.
A worldwide recognized standard for project is the Sphere Standard,
used for emergency projects whose aim is to improve the quality of assistance
provided to people affected by disasters. This guideline defines the minimum
standards for water, sanitation, health, shelter, food security, nutrition, shelter
and settlement.
332
Quality Characteristics
Notes
All material or services have characteristics that facilitate the identification

of its quality. The characteristics are part of the conditions of how the material,
equipment and services are able to meet the requirements of the project and are
fit for use by the beneficiaries. Quality characteristics relate to the attributes,
measures and methods attached to that particular product or service.
Functionality is the degree, by which equipment performs its intended

function, this is important especially for clinical equipment, that the
operation should behave as expected.
Performance is how well a product or service performs the beneficiaries

intended use. A water system should be designed to support extreme
conditions and require little maintenance to reduce the cost to the
community and increase its sustainability.
Reliability is the ability of the service or product to perform as intended

under normal conditions without unacceptable failures. Material used for
blood testing should be able to provide the information in a consistent and
dependable manner that will help identify critical diseases. The trust of
the beneficiaries depends on the quality of the tests.
Relevance, it's the characteristic of how a product or service meets the

actual needs of the beneficiaries, it should be pertinent, applicable, and
appropriate to its intended use or application.
Timeliness, how the product or service is delivered in time to solve the

problems when its needed and not after, this' is a crucial characteristic for
health and emergency relief work
Suitability, defines the fitness of its use, it appropriateness and

correctness, the agriculture equipment must be designed to operate on the
soul conditions the beneficiaries will use it on.
Completeness, the quality that the service is complete and includes all
the entire scope of services. Training sessions should be complete and
include all the material needed to build a desired skill or knowledge
Consistency, services are delivered in the same way for every beneficiary.
Clinical tests need to be done using the same procedure for every patient.
Quality characteristics are not limited to the material, equipment or service

delivered to the beneficiaries, but also applies to the material, equipment and
services the project staff uses to deliver the project outputs. These include the
vehicles, computers, various equipment and tools and consulting services the
project purchases and uses to carry out its activities.
Quality characteristics must be included in all material, equipment
and services the project will purchase, the procurement officers must have a
complete description of what is required by the project, otherwise a procurement
office may purchase the goods or services based on her or his information of the
product.
333
Notes
Quality plan
Part of defining quality involves developing a quality plan and a quality
checklist that will be used during the project implementation phase. This check
list will ensure the project team and other actors are delivering the project
outputs according to the quality requirements. Once the project has defined the
quality standards and quality characteristics, it will create a project quality plan
that describes all the quality definitions and standards relevant to the project,
it will highlight the standards that must be followed to comply to regulatory
requirements setup by the donor, the organisation and external agencies such as
the local government and professional organisations (health, nutrition, etc.)
The quality plan also describes the conditions that the services and
materials must possess in order to satisfy the needs and expectations of the
project stakeholders, it describes the situations or conditions that make an
output fall below quality standards, this information is used to gain a common
understanding among the project team to help them identify what is above and
what is below a quality standard.
The quality plan also includes the procedure to ensure that the quality
standards are being followed by all project staff. The plan also includes the
steps required to monitor and control quality and the approval process to make
changes to the quality standards and the quality plan.

Fill in the blanks.
1.
is to ensure the project will meet or

The main principle of
exceed stakeholder's needs and expectations.
is conformance to requirements or fitness for use.
2
3.
Some of the different quality characteristics are functionality,

and timeliness.
, reliability,
- ActIvtY ^:
Activity 1
Prepare a checklist for quality characteristics of a project.
13.3 QUALITY CONTROL

Quality control is the use of techniques and activities that compare actual
quality performance with goals and define appropriate action in response to a
shortfall. It is the process that monitors specific project results to determine
if they comply with relevant standards and identifies different approaches to
eliminate the causes for the unsatisfactory performance.
The goal of quality control is to improve quality and it involves monitoring

the project outputs to determine if they meet the quality standards or definitions
based on the project stakeholder's expectations. Quality control also includes
how the project performs in its efforts to manage scope, budget and schedule.
a.
Acceptance: The beneficiaries, the donor or other key project stakeholders

accept or reject the product or service delivered. Acceptance occurs after
the beneficiaries or donor has had a change to evaluate the product or
service.
b.
Rework: It is the action taken to bring the rejected product or service into
compliance with the requirements, quality specifications or stakeholder
expectations. Rework is expensive, that is why the project must make
every effort to do a good job in quality planning and quality assurance to
avoid the need for rework. Rework and all the costs associated with it may
not refundable by the donor and the organisation may end up covering
those costs.
c.
Adjustments: Correct or take the necessary steps to prevent further

quality problems or defects based on quality control measurements.
Adjustments are identified to the processes that produce the outputs and
the decisions that were taken that lead to the defects and errors. Changes
are taken to the Change Control processes of the project.
Notes
Quality Control Tools

There are some good tools that can be used to control quality on a project.
These are cause and effect diagrams, Scatter diagram, Pareto charts, histograms,
check sheets and control charts.
1.
Scatter diagram: A scatter plot is a type of mathematical diagram using

Cartesian coordinates to display values for two variables for a set of data.
The data is displayed as a collection of points, each having the value
of one variable determining the position on the horizontal axis and the
value of the other variable determining the position on the vertical axis.
A scatter plot is also called a scatter chart, scatter diagram and scatter
graph. A scatter plot is when a variable exists that is under the control of
the experimenter. If a parameter exists that is systematically incremented
and/or decremented by the other, it is called the control parameter or
independent variable and is customarily plotted along the horizontal axis.
The measured or dependent variable is customarily plotted along the
vertical axis. If no dependent variable exists, either type of variable can
be plotted on either axis and a scatter plot will illustrate only the degree
of correlation (not causation) between two variables.
A scatter plot can suggest various kinds of correlations between variables
with a certain confidence interval. Correlations may be positive (rising),
negative (falling), or null (uncorrelated). If the pattern of dots slopes from
lower left to upper right, it suggests a positive correlation between the
variables being studied. If the pattern of dots slopes from upper left to lower
335
right, it suggests a negative correlation. A line of best fit (alternatively

called `trendline') can be drawn in order to study the correlation between
the variables. An equation for the correlation between the variables can
be determined by established best-fit procedures. For a linear correlation,
the best-fit procedure is known as linear regression and is guaranteed to
generate a correct solution in a finite time. Unfortunately, no universal
best-fit procedure is guaranteed to generate a correct solution for arbitrary
relationships.
Notes
One of the most powerful aspects of a scatter plot, however, is its ability
to show non-linear relationships between variables. Furthermore, if the
data is represented by a mixture model of simple relationships, these
relationships will be visually evident as superimposed patterns.
A_
B.
c.
1
D.
E.
Fig.13.1: Scatter Diagram

2.
336 .
Cause and effect diagram: Also known as fishbone diagrams or Ishikawa

diagrams (named after Kaoru Ishikawa, a Japanese quality control
statistician, who developed the concept in the 1960s, and is considered
one of the seven basic tools of quality management). It is named fishbone
diagram because of their fish-like appearance. It is an analysis tool that
provides a systematic way of looking at effects and the causes that create
or contribute to those effects. The Ishikawa Diagram is employed by a
problem-solving team as a tool for assembling all inputs (as to what are the
causes of the problem they're addressing) systematically and graphically,
with the inputs usually coming from a brainstorming session. It enables
the team to focus on why the problem occurs, and not on the history or
symptoms of the problem, or other topics that digress from the intent of
the session. It also displays a real-time 'snap-shot' of the collective inputs
of the team as it is updated. The possible causes are presented at various
levels of detail in connected branches, with the level of detail increasing
as the branch goes outward, i.e., an outer branch is a cause of the inner
branch it is attached to. Thus, the outermost branches usually indicate the
root causes of the problem. This is indicated in the diagram as below:
Insullkionl
hardness
Noornnforonwo
dellWry
Unlink
motion,
Wrong.. .cif on a-
Latent
Wrong
5lock keeping
Fa.uro 'offing
.4 tiCIAlaluf
H.C.,41
II 1.1krtvirig
Ercorn or
loohnology
Influence
Tolson drIbing
UncopobrIfIly
of machine
probteral
Ignorance
Doloollvo lowly
Faun of
%on ng WOloof
Notes
Inahr011m
Wrong rocord
Fig.13.2: Cause-and-Effect Diagram (Fishbone Diagram)

Causes
Causes can be derived from brainstorming sessions, then successively
sorted through affinity-grouping to collect similar ideas together. These
groups can then be labeled as categories of the fishbone. They will
typically be one of the traditional categories mentioned above but may
be something unique to the application in a specific case. Causes can be
traced back to root causes with the 5 Whys technique.
The 5 Whys is a question-asking method used to explore the cause/effect
relationships underlying a particular problem. Ultimately, the goal of
applying the 5 Whys method is to determine a root cause of a defect or
problem.
Example
The following example demonstrates the basic process:
My car will not start. (the problem)
Why? - The battery is dead. (first why)
337
Notes
Why? - The alternator is not functioning. (second why)
Why? - The alternator belt has broken. (third why)
Why? - The alternator belt was well beyond its useful service life
and has never been replaced. (fourth why)
Why? - I have not been maintaining my car according to the

recommended service schedule. (fifth why, a root cause)
The questioning for this example could be taken further to a sixth, seventh,
or even greater level. This would be legitimate, as the "five" in 5 Whys
is not gospel, rather, it is postulated that five iterations of asking why is
generally sufficient to get to a root cause. The real key is to encourage the
troubleshooter to avoid assumptions and logic traps and instead to trace
the chain of causality in direct increments from the effect through any
layers of abstraction to a root cause that still has some connection to the
original problem.
Typical categories of causes are: The original 4 Ms
Machine (Equipment)
Method (Process/Inspection)
Material (Raw, Consumables etc.)
Manpower
More categories
Mother Nature (Environment)
Manpower (physical work)
Mind Power (Brain Work): Kaizens, Suggestions
Measurement (Inspection)
Maintenance
Money Power
Management
The 8 Ps (Used in Service Industry)
338
People
Process
Policies
Procedures
Price
Promotion
Place/Plant
Product
The 4 Ss (Used in Service Industry)
Surroundings
Suppliers
Systems
Skills
Notes
Thus, the aim of Ishikawa diagram is to arrive at the root cause of the
problems.
3.
.Check sheet: A structured, prepared form for collecting and analysing

data, a generic tool that can be adapted for a wide variety of purposes.
The check sheet is a simple document that is used for collecting data in
real time and at the location where the data is generated. The document
is typically a blank form that is designed for the quick, easy, and efficient
recording of the desired information, which can be either quantitative
or qualitative. When the information is quantitative, the check sheet is
sometimes called a tally sheet. A defining characteristic of a check sheet
is that data is recorded by making marks ("checks") on it. A typical check
sheet is divided into regions, and marks made in different regions have
different significance. Data is read by observing the location and number
of marks on the sheet.
Five basic types of check sheets are:
1.
Classification: A trait such as a defect or failure mode must be

classified into a category.
2.
Location: The physical location of a trait is indicated on a picture

of a part or item being evaluated.
3.
Frequency: The presence or absence of a trait or combination of

traits is indicated.
Also number of occurrences of a trait on a part can be indicated.
4.
Measurement scale: A measurement scale is divided into intervals,

and measurements are indicated by checking an appropriate interval.
5.
Check list: The items to be performed for a task are listed so that, as
each is accomplished, it can be indicated as having been completed.
339
Notes
Pin diameter Check Sheet
Sheet No:
1532
Operator: Mw4,
Date:
2 at, (.9
Lathe number: 3 2 1 4 15
Remarks:
Cutter type:
332
Lowere...c LiraM
upper spec. LUTA
mm.
1 0 1 1 1 21,31.4151 6(1.71.8 1.9 2.0 21 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.0 3.1 3 2 3.3 3 4
25
20
,
15
----
10
--- -,
. -_
-_ --
-- -- --. __
-__ --- __ -- _
5
0
Total:
-- -,._...._ -_ --- -- __-- -_, -- -_ ---.

"
0 0 0 1 0 1 2 4 7 10 14 18 19 15 13 9 5 4 2 2 1 0 0 1 0
Fig.13.3: Checklist for Measured Parameters

4.
Pareto charts: These charts are based on Pareto's rule, which states that
80 per cent of the problems are often due to 20 per cent of the causes. The
assumption is that most of the results in any situation are determined by a
small number of causes and helps identify the vital few contributors that
account for most of the quality problems. The chart is a form of histogram
that orders the data by frequency of occurrence.
It shows how many defects were generated by a type of category of
identified cause. For example, to determine the errors in the collection of
beneficiary data the project team identified five causes and for each cause,
the measured frequency of errors. The data is plotted as shown in the
chart below. The bars represent each category and the line represents the
cumulative percentage of the errors, the chart allows to identify that 80
per cent of the errors coUld be reduced just by improving the collection of
data in two categories instead of focusing efforts to correct all categories.
5.
Control chart: It is a graphical display of data that illustrates the results

of a process over time. The purpose of a control chart is to prevent defects,
rather than detect them or reject them, and the chart allows determining
whether a process is in control or out of control over specified length of
time. Control charts are often used to monitor the production of large
quantities of products, but can also be used to monitor the volume and
frequency of errors in documents, cost and schedule variances and other
items related to project quality management. The customer has a limit
tolerance for defects; these are the upper and lower control limits in the
chart. Random examination of the products reveals data that once charted
on the graph identifies the times when the production process created
items that were outside the control limits. This helps the project determine
actions to help the beneficiaries improve the quality of their work.
NQtes
Control charts can also be used to the project management areas, such as
schedule and budget control, to determine whether the costs variances or
schedule variances are outside the acceptable limits set by the donor.
6. Histogram: The most commonly used graph for showing frequency
distributions, or how often each different value in a set of data occurs is
the histogram. In statistics, a histogram is a graphical display of tabulated
frequencies, shown as bars. It shows what proportion of cases fall into
each of several categories: it is a form of data binning The categories
are usually specified as non-overlapping intervals of some variable.
The categories (bars) must be adjacent. The intervals (or bands, or bins)
are generally of the same size. Histograms are used to plot density of
data, and often for density estimation: estimating the probability density
function of the underlying variable. The total area of a histogram used for
probability density is always normalised to 1. If the length of the intervals
on the x-axis is all 1, then a histogram is identical to a relative frequency
plot. An alternative to the histogram is kernel density estimation, which
uses a kernel to smooth samples. This will construct a smooth probability
density function, which will in general more accurately reflect the
underlying variable.
600 500
O
6.
400
300
200
100
0
0-10 11-21 22-32 33-43 44-54 55-65 60-76 77-87 88+

Salary (1 Thousands)
Fig.13.4: Histogram
13.4 QUALITYASSURANCE
Assurance is the activity of providing evidence to create confidence
among all stakeholders that the quality-related activities are being performed
effectively and that all planned actions are being done to provide adequate
confidence that a product or service will satisfy the stated requirements for
quality.
Quality assurance is a process to provide confirmation based on evidence
to ensure to the donor, beneficiaries, organisation management and other
stakeholders that product meet needs, expectations, and other requirements. It
341
assures the existence and effectiveness of process and procedures tools, and
safeguards are in place to make sure that the expected levels of quality will be
reached to produce quality outputs.
Quality assurance occurs during the implementation phase of the project
and includes the evaluation of the overall performance of the project on a regular
basis to provide confidence that the project will satisfy the quality standards
defined by the project.
One of the purposes of quality management is to find errors and defects as
early in the project as possible. Therefore, a good quality management process
will end up taking more effort hours and cost upfront.
The goal is to reduce the chances that products or services will be of poor
quality after the project has been completed. Quality assurance is done not only
to the products and services delivered by the project but also to the process and
procedures used to manage the project, that includes the way the project uses
the tools, techniques and methodologies to manage scope, schedule, budget and
quality. Quality assurance also includes whether the project meets any legal or
regulatory standards.
Quality Audits
Quality audits are structured reviews of the quality management activities
that help identify lessons learned that can improve the performance on current
or future project activities. Audits are performed by project staff or consultants
with expertise in specific areas. The purpose of quality audit is to review how
the project is using its internal processes to produce the products and services
it will deliver to the beneficiaries. Its goal is to find ways to improve the tools,
techniques and processes that create the products and services.
If problems are detected during the quality audits, corrective action will
be necessary to the tools, processes and procedures used to ensure quality
is reestablished. Part of the audit may include a review of the project staff
understanding of the quality parameters or metrics, and skills, expertise and
knowledge of the people, lin charge of producing or delivering the products or
services. If corrective actions are needed, these must be approved through the
change control processes.
The PDCA Cycle
The most popular tool used to determine quality assurance is the PDCA
Cycle. This cycle for quality assurance consists of four steps - Plan, Do, Check,
and Act. These steps are commonly abbreviated as PDCA. The four quality
assurance steps within the PDCA model stand for:
Plan: Establish objectives and processes required to deliver the desired

results.
Do: Implement the process developed.
Check: Monitor and evaluate the implemented process by testing the

results against the predetermined objectives
Act: Apply actions necessary for improvement if the results require

changes.
Notes
PDCA CYCLE
PDCA is an effective method for monitoring quality assurance because
it analyses existing conditions and methods used to provide the product or
service to beneficiaries. The goal is to ensure that excellence is inherent in every
component of the process. Quality assurance also helps determine whether the
steps used to provide the product or service is appropriate for the time and
conditions. In addition, if the PDCA cycle is repeated throughout the lifetime of
the project helping improve internal efficiency.
The PDCA cycle is shown below as a never-ending cycle of improvement.
This cycle is sometimes referred to as the Shewart/Deming cycle since it
originated with Shewart and was subsequently applied to management practices
by Deming.
Fig. 13.5: The PDCA Cycle

Quality assurance demands a degree of detail in order to be fully
implemented at every step. Planning, for example, could include investigation
into the quality of the raw materials used in manufacturing, the actual assembly,
or the inspection processes used.
The checking step could include beneficiary feedback or surveys to
determine if beneficiary needs are being met or exceeded and why they are
or are not. Acting could mean a total revision in the delivery process in order
to correct a technical flaw. The goal to exceed stakeholder expectations in a
measurable and accountable process is provided by quality assurance.
Assurance vs. Control
Quality assurance is often confused with quality control. Quality control
is done at the end of a process or activity to verify that quality standards have
been met. Quality control by itself does not provide quality, although it may
identify problems and suggest ways to improve it. In contrast, quality assurance
is a systematic approach to obtain quality standards.
7343
Notes
Quality assurance is something that must be planned for from the earliest
stages of a project, with appropriate measures taken at every stage. Unfortunately,
far too many development projects are implemented with no quality assurance
plan, and these projects often fail to meet quality expectations of the donor and
beneficiaries. To avoid problem the project must be able to demonstrate the
consistent compliance with the quality requirements for the project.
1110 Check your Progress 2

Fill in the blanks.
1.
PDC A cycle for quality assurance consists of four steps and

Quality assurance occurs during the
project.
phase of the
13.5 QUALITY IMPROVEMENT

It is the systematic approach to the processes of work that looks to
remove waste, loss, rework, frustration, etc. in order to make the processes
of work more effective, efficient and appropriate. Quality improvement refers
to the application of methods and tools to close the gap between current and
expected levels of quality by understanding and addressing system deficiencies
and strengths to improve, or in some cases, re-design project processes.
A variety of quality improvement approaches exists, ranging from
individual performance improvement to redesign of entire project processes.
These approaches differ in terms of time, resources, and complexity, but share
the same four steps in quality improvement:
344
Identify what you want to improve in the project using the data found in
the quality control process. Identify the areas that need improvement.
Analyze the problem or system. The team then investigates the causes for
the problem and its implications to the project, the causes may be internal
or external to the project.
Develop potential solutions or changes that appear likely to improve the

problem or system. The team brainstorms ideas and potential solutions
to the problem, taking in consideration its impact to the project schedule
and budget. After careful considerations the team decides and chooses the
best alternative.
Test and implement the solutions. The team may decide to test the solution
on a small scale to verify that it is capable of fixing the problem. It testes
for the initial assumptions made about the problem and once it confirms
that the solution is a viable alternative, it then proceeds to implement it in
a full scale solution.
Cost of Quality
Notes
The cost of quality is the sum of costs a project will spend to prevent poor
quality and any other costs incurred as a result of outputs of poor quality. Poor
quality is the waste, errors, or failure to meet stakeholder needs and project
requirements. The costs of poor quality can be broken down into the three
categories of prevention, appraisal, and failure costs.
Prevention costs: These are planned costs an organisation incurs to ensure

that errors are not made at any stage during the delivery process of that
product or service to a beneficiary. Examples of prevention costs include
quality planning costs, education and training costs, quality administration
staff costs, process control costs, market research costs, field testing costs,
and preventive maintenance costs. The cost of preventing mistakes are
always much less than the costs of inspection and correction.
Appraisal costs: These include the costs of verifying, checking or

evaluating a product or service during the delivery process. Examples of
appraisal costs include receiving or incoming inspection costs, internal
production audit costs, test and inspection costs, instrument maintenance
costs, process measurement and control costs, supplier evaluation costs,
and audit report costs.
Failure costs: A project incurs these costs because the product or service
did not meet the requirements and had to be fixed or replaced, or the
service had to be repeated.
Leadership
Joseph M. Juran, one of the leading experts in Quality management said
that "it is most important that management be quality-minded. In the absence
of sincere manifestation of interest at the top, little will happen below." What
this means is the main cause of quality problems is a lack of leadership. In
order to establish and implement effective quality projects, senior management
must lead the way. A large percentage of quality problems are associated with
management, not technical issues, it is the responsibility of the development
organisations senior management to take responsibility for creating, supporting,
and promoting quality programs.
Quality problems should be taken as an opportunity for improvement.
Problems can help identify more fundamental or systemic root causes and help
develop ways to improve the process. Unfortunately, projects do not have a
culture that promotes the identification of problems for the fear that making
improvements is an admission that the current way of doing things is flawed or
that those responsible are poor performers. Improved performance cannot occur
unless the project team feels comfortable that they can speak truthfully and are
confident that their suggestions will be taken seriously.
Maturity Models
Another approach to improve quality is the use of maturity models, which
are frameworks for helping organisations and projects improve their processes.
-345
Notes
The model includes a method for assessing the projects maturity levels as a
first step to determine the improvements needed to increase the capacity of the
project to deliver the project outputs as promised.
The use of the word "maturity" implies that capabilities must be grown
over time in order to produce repeatable success in project management. The
Random House College Dictionary defines "maturity" as full development or
perfected condition. "Maturity" also indicates understanding or visibility into
why success occurs and ways to correct or prevent common problems. "Model"
implies change, a progression, or steps in a process.
Project management maturity is the progressive development of an
organisations project management approach, methodology, strategy and
decision-making process. The appropriate level of maturity can vary for each
organisation based on specific goals, strategies, resource capabilities, scope and
needs.
The proper level of maturity to which an organisation should strive is
determined during a detailed assessment conducted by a professional project
management consulting team. The organisation has achieved full project
management maturity when it has met the requirements and standards for project
management effectiveness and it is capable of demonstrating improvements
such as on-time project delivery, cost reductions, organisational efficiency and
quality outcomes.
A project quality maturity usually consists of five levels:
Level 1: Informal level, there is no defined processes for quality practices

or standards. The organisation may be in the initial stages of considering
how projects should define quality, but most efforts are informal and ad
hoc.
Level 2: Defined level, the organisation has defined some basic quality
standards and project quality policies that are being adopted. But not all
projects are using it in a consistent manner.
Level 3: Repeatable level, the quality process is well documented and

is an organisational standard. All projects are using it and producing
consistent and repeatable results.
Level 4: Controlled level, all projects are required to use quality planning
standard processes. The organisation has a unit or roles that coordinate
quality standards and assurance and quality audits are done on a regular
basis.
Level 5: Optimised level, the quality process includes guidelines for

feeding improvements back into the process. Metrics are used as key
criteria for quality decisions and quality results are predictable.
The model helps an organisation identify where they stand and where
they should strive to reach. It is a simple way to determine the level of maturity
346
required for a project or organization. Some organisations may be comfortable

with achieving a level 3 while others may be encouraged to reach a level 4 due
to the need to comply with legal or regulatory standards.
Notes
Continuous Improvement
Quality is not something that is done at the end of a phase or at the end
of the project. It is a continuous process to ensure quality is performed in all
aspects of the project. The goal is to continuously improve based on the lessons
learned and new insights provided by the project. To be effective it should
happen during all the activities of the project. Continuous improvement, in
regard to project quality always focuses on improving stakeholder satisfaction
through continuous and incremental improvements to processes, including the
removal of any unnecessary activities. By applying a process that continuously
improves every element of the project can achieve better results than trying
to wait until the end of a phase or a mid-term evaluation to start making
adjustments and improvements to the work. It requires little effort and by doing
small incremental improvements the project can reach significant levels of
quality.
To implement continuous improvements, it is necessary to have a culture
of reflection that allows the project team to learn from mistakes and apply the
lesson at the next phase or cycle and not spend time and effort trying to put
blame; otherwise, the team will fear reporting any problems with quality and it
will be too late to do anything once the donor or the beneficiaries find out.
Fill in the blanks.
1.
The four steps of quality improvement are

develop and test.
2.
Cost of poor quality can be broken into three categories

appraisal cost and
13.6 ACHIEVEMENT OF QUALITY IN PROJECTS

First milestone to the achievement of the quality is the understanding of
the purpose of product derived from the company's quality policy. The next
important thing is to understand and interpret the two distinct but interrelated
aspects of quality:
Quality of design: Quality of design is the quality specified by the

designer on behalf of the customer.
Quality of conformance: Quality of conformance measures the extent

the products manufactured conforms to laid-down design (i.e., design
specifications).
347
Notes
1.
Quality of Design: Quality of design covers identification of the

right product, selection of the appropriate features (i.e., end-use,
ease of operation, ease of maintenance, durability, life, reliability,
strength, appearance, etc.) for the selected product and preparation
of detailed specifications (metallurgical, performance, dimensional,
etc.) to ensure that product renders satisfactory service to the
customer at the optimal cost.
Quality of design is primarily the function of the design department.

Those charged with the responsibility of design must:
Put continual effort in the development of the product.
Have in-depth knowledge of alternative materials, manufacturing

processes, etc.
Have access to the latest technology and production process being

adopted by the industries in the developed world.
The starting point in the product design is an assessment of customer's

expectations from the product. In fact, customer satisfaction has to be the
central theme of the product design. The design must consider all those
aspects that a consumer is concerned about.
The design should ensure that the product shall
(i)
Satisfy the functional requirements of its usage (use or functional

requirements).
(ii)
Provide adequate protection against harmful effect on body and

dangers to human life (safety requirements).
(iii) Give trouble-free service over its life span (reliability requirements).
(iv) Be repaired, in case of malfunction, with ease and without aid of
too many special tools (maintainability requirements).
(v)
Render ego satisfaction which comes from the possession of the

product of good quality (esteem requirements).
Customer's acceptance of the product and its price

A quality product which satisfies all the above aspects may not find a single
customer if its price is not within the reach of the potential customers.
Price, therefore, is a crucial consideration in the customer's acceptance of
the product and must be borne in mind throughout while working on the
design.
Price brings into focus the cost of production. Good quality design must
be capable of being produced within the cost frame that puts its price
within the reach of the target clientele.
Since design determines cost, every element of design, shape and size of
various parts, tolerances and finishes of their surfaces, specifications and
originating processes oftheir material, heat treatment and surface treatment
details, etc. must be specified strictly according to the requirements and
: 112115M
11 ;
nothing more or less.
Notes
Quality of design and manufacturing lead time

Even if the design is exactly what the customer wants, its quality is
doubtful if the shops cannot make it. The product quality will also be in
trouble if its manufacturing cannot be completed within the contracted
time because then there will always be temptation to skip the quality to
meet the delivery. Good quality design must be economically a viable
design. The design must enable:
Manufacturing of components within the facilities at the command

of the firm.
Producing a design on the basis of additional equipment may not

be desirable unless the sale of product is sure to increase to justify
additional expenditure.
Manufacturing of components at a cost low enough to enable the

firm to sell the product within their competitor's price range, leaving
enough profit margins.
Manufacturing of the product within the reasonable time.
Procurement of materials and parts at the right time and at the right
price.
The designer can take care of these aspects provided he knows:
The manufacturing capability of the machines available in the

plant (quality control can help to measure process capability of any
machine or process and provide this information to the designer).
Availability or otherwise of the materials in the market including

development of new materials which are more reliable and yet
cheaper (purchase can provide the information).
2.
Quality of Conformance: Quality of design must ensure that all

relevant features (i.e., performance, looks, ease of maintenance,
ease of operation, durability, reliability, cost of operation, etc.)
which determine the quality of a product are included in the design
parameters. These design features, however, are of little or no use
unless they are meticulously reflected in the final product, that is,
though the end-result of the good quality of design is the good quality
product provided the design parameters! given in the drawings and
specifications are strictly adhered to. This is where second aspect of
quality, i.e., "quality of conformance" comes into picture.
"Quality of conformance" refers to the extent the product manufactured

conforms to the laid-down design (i.e., design specifications and tolerances).
The more closely the product meets the requirements of the design, the higher
is said to be its quality of conformance.
Quality of design though is closely related to quality of conformance
yet the achievement of one does not guarantee the compliance of the other.
349
Notes
Good quality of design does not automatically guarantee high quality of the
product. It is the good design coupled with a good execution (conformance)
which results in good quality of product. Poor conformance, on the contrary,
can easily debase a good design.
Quality of conformance demands a system approach and control of every
item that goes into the product and control of every activity that is required
for the production of the product: the material, the tools, the equipment, the
processes, the preservatives, the packaging and packing, etc. Quality control
is the watch-dog which ensures that every element of production and activities
linked to it which could affect the quality of the end-product are regulated to the
extent desirable.
42I Check your Progress 4

Fill in the blanks.
1.
refers to the extent the product manufactured

Quality of
conforms to the laid-down design.
Quality of
is primarily the function of the design department.
13.7 QUALITY STANDARDS

Good design features, as mentioned earlier, are of little use unless they
are reflected in the final product. This is possible only if the pre-determined
quality is built into the product during process of production itself. This calls
for system approach. Since quality depends on all elements of production: raw
materials, equipment and workmen, hence all these must be tied up, and the first
and foremost step in enunciating quality is to lay down quality specifications.
Specifications are the definitions of the measurable as well as nonmeasurable characteristics of the product. Specifications lay down required
qualitative standards based on the design for every element of production
including material. For example, in defining qualitative requirements, the
specifications of materials should cover features like material composition,
dimensions, heat treatment and other parameters like physical condition, etc.
Specifications are mainly of four types: material specifications, dimensional
specifications, performance specifications and environmental specifications.
Material specifications pertain to the metallurgical aspects of the product

and they form a vital part of engineering function. Materials specifications
are based on experience, tests, experiments and applied research, etc.
Dimensional specifications refer to the size aspects of the product and

they are the ones that are incorporated into the component drawings.
Exact sizes are not specified since assembly will function satisfactorily
even if there are some variations in the part sizes. Also exact sizes are
too expensive to produce. Tolerances on the dimensions are therefore
specified to indicate the maximum permissible variability in their sizes.
Performance specifications refer to the actual performance of the

product.
Environmental specifications pertain to the climatic conditions which

the component/product/material should withstand (e.g., temperature,
moisture, etc.)
Notes
Two basic requirements of quality standards are:
Quality standards must be definite and ,understandable. They must

not leave even a slight doubt for any department, be it manufacturing,
inspection or any other. The reliance on judgement and the problem of
interpretation during inspection must be remote.
Quality standards should also be reasonable and achievable, i.e., they must
be economically viable. Absolute uniformity (i.e., to produce each item to
exact dimension) is not only impossible to obtain in production but also
costly to approach. The quality standards, therefore, must take into account
permissible amount of variation from the ideal. In an engineering drawing,
specification gives the basic dimension called nominal size which is
theoretically the perfect dimension and the permissible variations around
it called design tolerance which depends on the functional requirements
of the part.
Activm r Activity 2
Select project activities and use QC tools for measuring quality performance
of project activities.
LuMM
Summary
.6
Quality management is the process for ensuring that all project activities
necessary to design, plan and implement a project are effective and
Project quality management (QM) is not a separate, independent process
that occurs at the end of an activity to measure the level of quality of
the output. It is not purchasing the most expensive material or services
available in the market. A product may be of good quality (no defects) and
be of low grade (few or no extra features).
Quality management is a continuous process that starts and ends with

the project. It is more about preventing and avoiding than measuring
and fixing poor quality outputs. It is part of every project management
processes from the moment the project initiates to the final steps in the
project closure phase.
The main principle of project quality management is to ensure the project

will meet or exceed stakeholder's needs and expectations. Project quality
W5.1
management consists of four main processes: Quality Definition, Quality

Control, Quality Assurance and Quality Improvement.
The first step on the quality management is to define quality. The project
manager and the team must identify what quality standards will be used in
the project, it will look at what the donor, beneficiaries, the organisation
and other key stakeholders want to come up with a good definition of
quality. Identifying quality standards is a key component of quality
definition that will help identify the key characteristics that will govern
project activities and ensure the beneficiaries and donor will accept the
project outcomes.
Quality characteristics relate to the attributes, measures and methods

attached to that particular product or service. These include Functionality,
Performance, Reliability, Relevance, Timeliness, Suitability, Completeness
and Consistency.
Quality control is the use of techniques and activities that compare actual
quality performance with goals and define appropriate action in response
to a shortfall. It is the process that monitors specific project results to
determine if they comply with relevant standards and identifies different
approaches to eliminate the causes for the unsatisfactory performance.
The goal of quality control is to improve quality and involves monitoring

the project outputs to determine if they meet the quality standards or
definitions based on the project stakeholder's expectations. There are
some good tools that can be used to control quality on a project. These
are cause and effect diagrams, scatter diagram, Pareto charts, histograms,
check sheets and control charts.
Quality assurance is a process to provide confirmation based on evidence

to ensure the donor, beneficiaries, organisation management and other
stakeholders that product meet needs, expectations and other requirements.
It assures the existence and effectiveness of process and procedures
tools, and safeguards are in place to make sure that the expected levels
of quality will be reached to produce quality outputs. Quality assurance
occurs during the implementation phase of the project and includes the
evaluation of the overall performance of the project on a regular basis
to provide confidence that the project will satisfy the quality standards
defined by the project.
Quality improvement is the systematic approach to the processes of work

that looks to remove waste, loss, rework, frustration, etc. in order to make
the processes of work more effective, efficient and appropriate. Quality
improvement refers to the application of methods and tools to close the
gap between current and expected levels of quality by understanding
and addressing system deficiencies and strengths to improve, or in some
cases, re-design project processes.
Achievement of the quality in project involves the understanding of the

purpose of product derived from the company's quality policy. The next
important thing is to understand and interpret the two distinct but interProject Management Operations
related aspects of quality - Quality of design and Quality of conformance.
Notes
Quality success depends on proper definition of specifications which are

the definitions of the measurable as well as non-measurable characteristics
of the product. Specifications lay down required qualitative standards
based on the design for every element of production including material.
0Keywords
Quality: The totality of characteristics of an entity that bear on its ability

to satisfy stated or implied needs.
Quality management: The process for ensuring that all project activities
necessary to design, plan and implement a project are effective and
Functionality: The degree by which equipment performs its intended

function.
Reliability: The ability of the service or product to perform as intended

under normal conditions without unacceptable failures.
Relevance: The characteristic of how a product or service meets the

actual needs of the beneficiaries.
Quality control: The process that monitors specific project results to

determine if they comply with relevant standards and identify different
approaches to eliminate the causes for the unsatisfactory performance.
Scatter diagram: A type of mathematical diagram using Cartesian

coordinates to display values for two variables, for a set of data.
Check sheet: A structured, prepared form for collecting and analysing

data; a generic tool that can be adapted for a wide variety of purposes.
Pareto charts: These charts are based on Pareto's rule, which states that
80 per cent of the problems are often due to 20 per cent of the causes.
The chart is a form of histogram that orders the data by frequency of
occurrence.
Control charts: A graphical display of data that illustrates the results of

a process over time.
Quality assurance: A process to provide confirmation based on evidence

to ensure to the donor, beneficiaries, organisation management and
other stakeholders that product meet needs, expectations, and other
requirements..
Quality audits: Structured reviews of the quality management activities

that help identify lessons learned that can improve the performance on
current or future project activities.
PDCA cycle: A tool used to determine quality assurance.
353
Notes
Cost of quality: The sum of costs a project will spend to prevent poor
quality and any other costs incurred as a result of outputs of poor quality.
Quality of design: It covers identification of the right product, selection

of the appropriate features for the selected product and preparation of
detailed specifications to ensure that product renders satisfactory service
to the customer at the optimal cost.
Quality of conformance: The extent the product manufactured conforms

to the laid-down design.
g
1.
What is quality management? How does quality management differ for

projects as compared to other processes?
2.
What is quality definition? What is the importance of quality definition

for proper project management?
3.
What is quality control? How quality control is different from quality

assurance?
4.
What are the quality, control tools? Explain the different types of quality
control tools.
5.
What is quality improvement? Explain the process of quality improvement.
6.
What is quality of design? Explain with suitable examples.
7.
What is quality of conformance? Explain with suitable examples.
8.
What are the characteristics of quality? Explain with suitable examples.
9.
What is PDCA cycle? Explain the application of PDCA cycle for quality.
1 0 . What is quality specification? Explain different quality specifications for

projects.
Answers to Check your Progilli

Fill in the blanks.
354 S
1.
The main principle of Project Quality Management is to ensure the project

will meet or exceed 'stakeholder's needs and expectations.
2.
Quality is conformance to requirements or fitness for use.
3.
Some of the different quality characteristics are functionality, performance,

reliability, relevance and timeliness.
Notes
Fill in the banks.

1.
PDCA cycle for quality assurance consists of four steps - Plan, Do, Check
and Act.
2.
Quality assurance occurs during the implementation phase of the project.

Fill in the blanks.
1.
The four steps of quality improvement are identify, analyse, develop and
test.
2.
Cost of poor quality can be broken into three categories prevention cost,
appraisal cost and failure cost.

Fill in the blanks.
1.
Quality of Conformance refers to the extent the product manufactured

conforms to the laid-down design.
2.
Quality of Design is primarily the function of the design department.
rt$ Suggested Reading

1.

McGraw-Hill.
355
Notes

Structure:
14.1 Software Project Management Process
UNIT
14
14.2 Software Development Process

14.3 Software Development Models
14.4 Software Project Planning, Monitoring and Control
14.5 Software Development Cycle
14.6 Software Project Implementation
14.7 Software Testing
14.8 Software Deployment
14.9 Software Maintenance
Summary
Key Words
Suggested Reading
357
Notes
Explain the software development process
Analyse software development models
Plan and control software projects
Discuss project development cycle
Do software testing and software deployment
Do software maintenance
14.1 SOFTWARE PROJECT MANAGEMENT PROCESS

The international standard for describing the method of selecting,
implementing and monitoringithe life cycle for software is ISO 12207.
A decades-long goal has been to find repeatable, predictable processes
that improve productivity and quality. Some try to systematise or formalise the
seemingly unruly task of writing software. Others apply project management
techniques to writing software. Without project management, software projects
can easily be delivered late or over budget. With large numbers of software
projects not meeting their expectations in terms of functionality, cost, or delivery
schedule, effective project management appears to be lacking.
Organisations may create a Software Engineering Process Group (SEPG),
which is the focal point for process improvement. Composed of line practitioners
who have varied skills, the group is at the centre of the collaborative effort of
everyone in the organisation who is involved with software engineering process
improvement.
Fig.14.1: Software Development Activities

The activities of the software development process are represented in the

waterfall model. There are several other models to represent this process.
Notes
Planning
The important task in creating a software product is extracting the
requirements or requirements analysis. Customers typically have an abstract idea
of what they want as an end-result, but not what software should do. Incomplete,
ambiguous, or even contradictory requirements are recognised by skilled and
experienced software engineers at this point. Frequently demonstrating live
code may help reduce the risk that the requirements are incorrect.
Once the general requirements are gathered from the client, an analysis of
the scope of the development should be determined and clearly stated. This is
often called a scope document.
Certain functionality may be out of scope of the project as a function
of cost or as a result of unclear requirements at the start of development. If
the development is done externally, this document can be considered a legal
document so that if there are ever disputes, any ambiguity of what was promised
to the client can be clarified.
Implementation, testing and documenting
Implementation is the part of the process where software engineers
actually program the code for the project.
Software testing is an integral and important part of the software
development process. This part of the process ensures that defects are recognised
as early as possible.
Documenting the internal design of software for the purpose of future
maintenance and enhancement is done throughout development. This may also
include the writing of an API, be it external or internal. It is very important to
document everything in the project.
Deployment and maintenance
Deployment starts after the code is appropriately tested, is approved for
release and sold or otherwise distributed into a production environment.
Software Training and Support is important and a lot of developers fail
to realise that it would not matter how much time and planning a development
team puts into creating software if nobody in an organisation ends up using it.
People are often resistant to change and avoid venturing into an unfamiliar area,
so as a part of the deployment phase, it is very important to have training classes
for new clients of your software.
Maintaining and enhancing software to cope with newly discovered
problems or new requirements can take far more time than the initial
development of the software. It may be necessary to add code that does not fit
359
Notes
the original design to correct an unforeseen problem or it may be that a customer

is requesting more functionality and code can be added to accommodate their
requests. If the labour cost of the maintenance phase exceeds 25 per cent of
the prior-phases' labour cost, then it is likely that the overall quality of at least
one prior phase is poor. In that case, management should consider the option of
rebuilding the system (or portions) before maintenance cost is out of control.
Bug Tracking System tools are often deployed at this stage of the process
to allow development teams to interface with customer/field teams testing the
software to identify any real or perceived issues. These software tools, both
open source and commercially licensed, provide a customisable process to
acquire, review, acknowledge and respond to reported issues.
14.2 SOFTWARE DEVELOPMENT PROCESS

A software development process is concerned primarily with the production
aspect of software development, as opposed to the technical aspect, such as
software tools. These processes exist primarily for supporting the management
of software development, and are generally skewed toward addressing business
concerns. Many software development processes can be run in a similar way to
general project management processes. Examples are:
,360 . .
Risk management is the process of measuring or assessing risk and

then developing strategies to manage the risk. In general, the strategies
employed include transferring the risk to another party, avoiding the risk,
reducing the negative effect of the risk, and accepting some or all of the
consequences of a particular risk. Risk management in software project
management begins with the business case for starting the project, which
includes a cost benefit analysis as well as a list of fallback options for
project failure, called a contingency plan.
A subset of risk management that is gaining more and more attention

is "Opportunity Management", which means the same thing, except that
the potential risk outcome will have a positive, rather than a negative
impact. Though theoretically handled in the same way, using the term
"opportunity" rather than the somewhat negative term "risk" helps to
keep a team focused on possible positive outcomes of any given risk
register in their projects, such as spin-off projects, windfalls, and free
extra resources.
Requirements management is the process of identifying, eliciting,

documenting, analysing, tracing, prioritising and agreeing on requirements
and then controlling change and communicating to relevant stakeholders.
New or altered computer system requirements management, which
includes requirements analysis, is an important part of the software
engineering process whereby business analysts or software developers
identify the needs or requirements of a client having identified these
requirements they are then in a position to design a solution.
Change management is the process of identifyittg, documenting, analysing,

prioritising and agreeing on changes to scope (project management) and
then controlling changes and communicating to relevant stakeholders.
Change impact analysis of new or altered scope, which includes
requirements analysis at the change level, is an important part of the
software engineering process whereby business analysts or software
developers identify the altered needs or requirements of a client having
identified these requirements they are then in a position to re-design or
modify a solution. Theoretically, each change can impact the timeline
and budget of a software project, and therefore by definition must include
risk-benefit analysis before approval.
Software configuration management is the process of identifying, and

documenting the scope itself, which is the software product underway,
including all sub-products and changes and enabling communication of
these to relevant stakeholders. In general, the processes employed include
version control, naming convention (programming), and software archival
agreements.
Release management is the process of identifying, documenting,

prioritising and agreeing on releases of software and then controlling
the release schedule and communicating to relevant stakeholders. Most
software projects have access to three software environments to which
software can be released - Development, Test, and Production. In very
large projects, where distributed teams need to integrate their work before
release to users, there will often be more environments for testing, called
unit testing, system testing or integration testing, before release to User
Acceptance Testing (UAT).
A subset of release management that is gaining more and more attention is

Data Management, as obviously the users can only test, based on data that they
know, and "real" data is only in the software environment called "production". In
order to test their work, programmers must therefore also often create "dummy
data" or "data stubs". Traditionally, older versions of a production system were
once used for this purpose, but as companies rely more and more on outside
contributors for software development, company data may not be released to
development teams. In complex environments, datasets may be created that are
then migrated across test environments according to a test release schedule,
much like the overall software release schedule.
Software development can be looked from the following perspectives:
Iterative and Incremental Development
Iterative development prescribes the construction of initially small but
ever larger portions of a software project to help all those involved to uncover
important issues early before problems or faulty assumptions can lead to
disaster. Iterative processes are preferred by commercial developers because
it allows a potential of reaching the design goals of a customer who does not
know how to define what they want.
Notes
NoteS
Agile Development
Agile software development uses iterative development as a basis
but advocates a lighter and more people-centric viewpoint than traditional
approaches. Agile processes use feedback, rather than planning, as their primary
control mechanism. The feedback is driven by regular tests and releases of the
evolving software.
There are many variations of agile processes.
XP (Extreme Programming)
In XP, the phases are carried out in extremely small (or "continuous")
steps compared to the older, "batch" processes. The (intentionally incomplete)
first pass through the steps might take a day or a week, rather than the months or
years of each complete step in the Waterfall model. First, one writes automated
tests to provide concrete goals for development. Next is coding (by a pair of
programmers), which is complete when all the tests pass, and the programmers
can't think of any more tests that are needed. Design and architecture emerge
out of refactoring, and come after coding. Design is done by the same people
who do the coding. (Only the last feature merging design and code is common to
all the other agile processes.) The incomplete but functional system is deployed
or demonstrated for (some subset of) the users (at least one of which is on the
development team). At this point, the practitioners start again on writing tests
for the next most important part of the system.
r
11#
Fill in the blanks.
1.

implementing and monitoring the life cycle for software is
tools are often deployed to allow development teams to
interface with customer/field teams testing the software to identify
any real or perceived issues.
3.
is the process of measuring or assessing risk and then

developing strategies to manage the risk.
processes use feedback, rather than planning, as their primary
control mechanism.
14.3 SOFTWARE DEVELOPMENT MODELS

Several models exist to streamline the development process. Each one
has its pros and cons, and it's up to the development team to adopt the most
appropriate one for the project. Sometimes a combination of the models may be
more suitable.
362
Waterfall Model
Notes
The waterfall model shows a process, where developers are to follow

these phases in order:
1.
Requirements specification (Requirements Analysis)
2.
Software Design
3.
Implementation (or Coding)
4.
Integration
5.
Testing (or Validation)
6.
Deployment (or Installation)
7.
Maintenance
In a strict Waterfall model, after each phase is finished, it proceeds to the

next one. Reviews may occur before moving to the next phase which allows for
the possibility of changes (which may involve a formal change control process).
Reviews may also be employed to ensure that the phase is indeed complete.
The phase completion criteria are often referred to as a "gate" that the project
must pass through to move to the next phase. Waterfall discourages revisiting
and revising any prior phase once it's complete. This "inflexibility" in a pure
Waterfall model has been a source of criticism by other more "flexible" models.
Spiral Model
The key characteristic of a Spiral model is risk management at regular
stages in the development cycle. In 1988, Barry Boehm published a formal
software system development "spiral model", which combined some key aspect
of waterfall and rapid prototyping methodologies, but provided emphasis in a
key area which many felt had been neglected by other methodologies: deliberate
iterative risk analysis, particularly suited to large-scale complex systems.
The Spiral is visualised as a process passing through some number of
iterations, with the four quadrant diagram representative of the following
activities:
1.
Formulate plans to identify software targets, selected to implement the

program, clarify the project development restrictions
2.
Risk analysis is an analytical assessment of the selected programs, to

consider how to identify and eliminate risk
3.
The implementation of the project, the implementation of software

development and verification
4.
Customer evaluation is evaluation of the development work, the proposal

of amendments, plans to formulate the next step.
Risk-driven spiral model, emphasising the conditions of options and

constraints in order to support software reuse, software quality can help as a
special goal of integration into the product development. However, the spiral
- 3E3
...Notes
model has some restrictive conditions, as follows:

1.
Spiral model emphasises risk analysis, but requires customers to accept

and believe that much of this analysis is not easy, the relevant response
is not easy as well, therefore, this model is often adapted to large-scale
internal software development.
2.
If the implementation of risk analysis will greatly affect the profits of the
project, then risk analysis is meaningless. Therefore, spiral model is only
suitable for large-scale software projects.
3.
Good software developers should look for possible risks, an accurate

analysis of risk, otherwise it will lead to greater risk.
First stage is to determine the stage of the goal of accomplishing these

objectives, options and constraints, and then from the perspective of risk
analysis program, development strategy, and strive to remove all potential risks,
and sometimes necessary to achieve through the construction of the prototype.
If some risk cannot be ruled out, the program should end immediately, or else
start the development of the next steps.
14.4 SOFTWARE PROJECT PLANNING, MONITORING

AND CONTROL
The purpose of project planning is to identify the scope of the project,
estimate the work involved, and create a project schedule. Project planning
begins with requirements that define the software to be developed. The project
plan is then developed to describe the tasks that will lead to completion.
The purpose of project monitoring and control is to keep the team and
management up to date on the project's progress. If the project deviates from
the plan, then the project manager can take action to correct the problem. Project
monitoring and control involves status meetings to gather status from the team.
When changes need to be made, change control is used to keep the products up
to date.
Issue - In computing, the term issue is a unit of work to accomplish an
improvement in a system. An issue could be a bug, a requested feature, task,
missing documentation, and so forth. The word "issue" is popularly misused in
lieu of "problem". This usage is probably related. For example, OpenOffice.org
used to call their modified version of BugZilla IssueZilla. As of August 2006,
they call their system Issue Tracker.
Problems occur from time to time and fixing them in a timely fashion
is essential to achieve correctness of a system and avoid delayed deliveries of
products.
Severity levels - Issues are often categorised in terms of severity levels.
Different companies have different definitions of severities, but some of the
most common ones are:
364
Critical
High: The bug or issue affects a crucial part of a system, and must be
fixed in order for it to resume normal operation.
Medium: The bug or issue affects a minor part of a system, but has some
impact on its operation. This severity level is assigned when a non-central
requirement of a system is affected.
Low: The bug or issue affects a minor part of a system, and has very little
impact on its operation. This severity level is assigned when a non-central
requirement of a system (and with lower importance) is affected.
Cosmetic: The system works correctly, but the appearance does not
match the expected one. For example, wrong colours, too much or too
little spacing between contents, incorrect font sizes, typos, etc. This is the
lowest priority issue.
Notes
In many software companies, issues are often investigated by Quality

Assurance Analysts when they verify a system for correctness, and then assigned
to the developer(s) that are responsible for resolving them. They can also be
assigned by system users during the User Acceptance Testing (UAT) phase.
Issues are commonly communicated using Issue or Defect Tracking
Systems. In some other cases, emails or instant messengers are used.
f le, Check your Progress 2
Fill in the blanks.

1.
The purpose of
is to keep the team and management up to
date on the project's progress.
2.
In computing, the term

improvement in a system
is a unit of work to accomplish an
1 143 SOFTWARE DEVELOPMENT CYCLE

A software development process is a structure imposed on the development
of a software product. Similar terms include software life cycle and software
process. There are several models for such processes, each describing approaches
to a variety of tasks or activities that take place during the process. Some people
consider a life cycle model a more general term and a software development
process a more specific term. For example, there are many specific software
development processes that 'fit' the spiral life cycle model.
There is a large and growing body of software development organisations
that implement process methodologies. Many of them are in the defense
industry, which in the US requires a rating based on 'process models' to obtain
contracts.
365
Notes
Requirements analysis in systems engineering and software engineering

encompasses those tasks that go into determining the needs or conditions to
meet for a new or altered product, taking account of the possibly conflicting
requirements of the various stakeholders, such as beneficiaries or users.
Requirements analysis is critical to the success of a development project.
Requirements must be dqcumented, actionable, measurable, testable, related
to identified business needs or opportunities, and defined to a level of detail
sufficient for system design. Requirements can be functional and non-functional.
P
R
0
C
E
S
S
N
P
U
T
System Analysis
and Control
(Balance
Requirements
Analysis
Requirements
Loop
Il
Verification
Functional Analysis
and Allocation
A
Design
i
Loop
Design Synthesis
it_
V
PROCESS OUTPUT
Fig.14.2: Software Development Cycle

Conceptually, requirements analysis includes three types of activity:
Eliciting requireMents: Eliciting requirements is the task of

communicating with customers and users to determine what their
requirements are. This is sometimes also called requirements gathering.
Analysing requirements: Analysing requirements is the process of

determining whether the stated requirements are unclear, incomplete,
ambiguous or contradictory, and then resolving these issues.
Recording requirements: Requirements might be documented in various

forms, such as natural-language documents, use cases, user stories or
process specifications.
Requirements analysis can be a long and arduous process during which

many delicate psychological skills are involved. New systems change the
environment and relationships between people, so it is important to identify all
the stakeholders, take into account all their needs and ensure that they understand
the implications of the new systems. Analysts can employ several techniques to
elicit the requirements from the customer. Historically, this has included such
things as holding interviews, or holding focus groups (more aptly named in
this context as requirements workshops) and creating requirements lists. More
modern techniques include prototyping, and use cases. Where necessary, the
analyst will employ a combination of these methods to establish the exact
requirements of the stakeholders, so that a system that meets the business needs
is produced.
Notes
Requirements engineering
Systematic requirements analysis is also known as requirements
engineering. It is sometimes referred to loosely by times such as requirements
gathering, requirements capture or requirements specification. The term
requirements analysis can also be applied specifically to the analysis proper, as
opposed to elicitation or documentation of the requiiements, for instance.
Requirement engineering according to Laplante (2007) is "a subdiscipline of systems engineering and software engineering that is concerned
with determining the goals, functions, and constraints of hardware and software
systems." In some life cycle models, the requirement engineering process
begins with a feasibility study activity, which leads to a feasibility report.
If the feasibility study suggests that the product should be developed, then
requirement analysis can begin. If requirement analysis precedes feasibility
studies, which may foster outside the box thinking, then feasibility should be
determined before requirements are finalised.
Functional specification
A functional specification (also, functional spec, specs, functional
specifications document (FSD), or Program specification) in systems
engineering and software development is the documentation that describes the
requested behaviour of an engineering system. The documentation typically
describes what is needed by the system user as well as requested properties of
inputs and outputs.
System
Concept
P
Requirements
Integrated and
Qualified System
System Definition (Functional Baseline)
System Specification
uu
c t
Preliminary Design (Allocated Baseline)
Product
output
System
Spec
P
r
o
d
10,
Item Performance Specifications
ct
Detail Design (Product BL)

P
Product
Output
Performance Item Spec
dor p
r Ho.
.g,jit4
t:
i
to u
t I
511)tpeeetmo:i.
l
=
Drawings
Product
Output Process
and
Material
Specs
Drawings
51ST = System Integration and Text
Product
Output
Fig.14.3: Requirements Engineering

367
Notes
In systems engineering a specification is a document that clearly and

accurately describes the essential technical requirements for items, materials
or services including the procedures by which it can be determined that the
requirements have been met. Specifications help avoid duplication and
inconsistencies, allow for accurate estimates of necessary work and resources,
act as a negotiation and reference document for engineering changes, provide
documentation of configuration, and allow for consistent communication among
those responsible for the eight primary functions of Systems Engineering. They
provide a precise idea of the problem to be solved so that they can efficiently
design the system and estimate the cost of design alternatives. They provide
guidance to testers for verification (qualification) of each technical requirement.
A functional specification does not define the inner workings of the
proposed system. It does not include the specification how the system function
will be implemented. Instead, it focuses on what various outside agents (people
using the program, computer peripherals, or other computers, for example) might
"observe" when interacting with the system. A typical functional specification
might state the following:
When the user clicks the OK button, the dialog is closed and the focus
is returned to the main window in the state it was in before this dialog was
displayed.
Such a requirement describes an interaction between an external agent
(the user) and the software system. When the user provides input to the system
by clicking the OK button, the program responds (or should respond) by closing
the dialog window containing the OK button.
It can be informal, in which case it can be considered as a blueprint or user
manual from a developer point of view, or formal, in which case it has a definite
meaning defined in mathematical or programmatic terms. In practice, most
successful specifications are written to understand and fine-tune applications
that were already well-developed, although safety-critical software systems are
often carefully specified prior to application development. Specifications are
most important for external interfaces that must remain stable.
Purpose of functional specifications
There are many purposes for functional specifications. One of the primary
purposes in team projects is to achieve some form of team consensus on what
the program is to achieve before making the more time-consuming effort of
writing source code and test cases, followed by a period of debugging. Typically,
such consensus is reached after one or more reviews by the stakeholders on
the project at hand after having negotiated a cost-effective way to achieve the
requirements the software needs to fulfill.
Functional specification Process
In the ordered industrial software engineering life cycle (waterfall
model), functional specification describes what has to be implemented. The
next system specification document describes how the functions will be realised
using a chosen software environment. In non-industrial, prototypical systems

development, functional specifications are typically written after or as part of
requirements analysis.
Notes
When the team agrees that functional specification consensus is reached,

the functional spec is typically declared "complete" or "signed off'. After
this, typically the software development and testing team write source code
and test cases using the functional specification as the reference. While testing
is performed the behavior of the program is compared against the expected
behavior as defined in the functional specification.
Software Architecture
The software architecture of a program or computing system is the
structure or structures of the system, which comprise software components,
the externally visible properties of those components, and the relationships
between them. The term also refers to documentation of a system's software
architecture. Documenting software architecture facilitates communication
between stakeholders, documents early decisions about high-level design, and
allows reuse of design components and patterns between projects.
The field of computer science has come across problems associated with
complexity since its formation. Earlier problems of complexity were solved by
developers by choosing the right data structures, developing algorithms, and by
applying the concept of separation of concerns. Although the term "software
architecture" is relatively new to the industry, the fundamental principles of
the field have been applied sporadically by software engineering pioneers since
the mid-1980s. Early attempts to capture and explain software architecture of
a system were imprecise and disorganized, often characterised by a set of boxand-line diagrams. During the 1990s there was a concentrated effort to define
and codify fundamental aspects of the discipline. Initial sets of design patterns,
styles, best practices, description languages, and formal logic were developed
during that time. The software architecture discipline is centered on the idea
of reducing complexity through abstraction and separation of concerns. To
date there is still no agreement on the precise definition of the term "software
architecture".
As a maturing discipline with no clear rules on the right way to build a
system, designing software architecture is still a mix of art and science. The
"art" aspect of software architecture is because a commercial software system
supports some aspect of a business or a mission.
How a system supports key business drivers is described via scenarios
as non-functional requirements of a system, also known as quality attributes,
determine how a system will behave. Every system is unique due to the nature of
the business drivers it supports, as such the degree of quality attributes exhibited
by a system such as fault-tolerance, backward compatibility, extensibility,
reliability, maintainability, availability, security, usability, etc. To bring a
software architecture user's perspective into the software architecture, it can be
said that software architecture gives the direction to take steps and do the tasks
" 369
involved in each such user's specialty area and interest, e.g., the stakeholders
of software systems, the software developer, the software system operational
support group, the software maintenance specialists, the deployer, the tester
and also the business end-user. In this sense, software architecture is really
the amalgamation of the multiple perspectives a system always embodies. The
fact that those several different perspectives can be put together into software
architecture stands as the vindication of the need and justification of creation
of software architecture before the software development in a project attains
maturity.
Software design
Software design is a process ofproblem-solving and planning for a software
solution. After the purpose and specifications of software are determined,
software developers will design or employ designers to develop a plan for a
solution. It includes low-level component and algorithm implementation issues
as well as the architectural view.
The software requirements analysis (SRA) step of a software development
process yields specifications that are used in software engineering. If the
software is "semi-automated" or user-centred, software design may involve user
experience design yielding a storyboard to help determine those specifications.
If the software is completely automated (meaning no user or user interface), a
software design may be as simple as a flow chart or text describing a planned
sequence of events. There Are also semi-standard methods like Unified
Modeling Language and fundamental modeling concepts. In either case some
documentation of the plan is usually the product of the design.
A software design may be platform-independent or platform-specific,
depending on the availability of the technology called for by the design.

Fill in the blanks.
1.
The three types of activity included in requirements analysis are

and
eliciting requirements,
14.6 SOFTWARE PROJECT IMPLEMENTATION

Computer programming (often shortened to programming or coding)
is the process of designing, writing, testing, debugging/troubleshooting, and
maintaining the source code of computer programs. This source code is written
in a programming language. The code may be a modification of an existing
source or something completely new. The purpose of programming is to create
a program that exhibits a certain desired behaviour (customisation). The process
of writing source code often requires expertise in many different subjects,
including knowledge of the application domain, specialised algorithms and
formal logic.
370
Within software engineering, programming (the implementation) is

regarded as one phase in a software development process.
There is an ongoing debate on the extent to which the writing of programs
is an art, a craft or an engineering discipline. In general, good programming is
considered to be the measured application of all three, with the goal of producing
an efficient and evolvable software solution (the criteria for "efficient" and
"evolvable" vary considerably). The discipline differs from many other technical
professions in that programmers, in general, do not need to be licensed or pass
any standardized (or governmentally regulated) certification tests in order
to call themselves "programmers" or even "software engineers." However,
representing oneself as a "Professional Software Engineer" without a license
from an accredited institution is illegal in many parts of the world. However,
because the discipline covers many areas, which may or may not include critical
applications, it is debatable whether licensing is required for the profession as
a whole. In most cases, the discipline is self-governed by the entities which
require the programming, and sometimes very strict environments are defined.
Another ongoing debate is the extent to which the programming language
used in writing computer programs affects the form that the final program
takes. This debate is analogous to that surrounding the Sapir-Whorf hypothesis
in linguistics that postulates that a particular language's nature influences the
habitual thought of its speakers. Different language patterns yield different
patterns of thought. This idea challenges the possibility of representing the
world perfectly with language, because it acknowledges that the mechanisms
of any language condition the thoughts of its speaker community.
Said another way, programming is the craft of transforming requirements
into something that a computer can execute.
Quality requirements
Whatever the approach to software development may be, the final program
must satisfy some fundamental properties. The following properties are among
the most relevant:
Efficiency/performance: The amount of system resources a program

consumes (processor time, memory space, slow devices such as disks,
network bandwidth and to some extent even user interaction) - the less,
the better. This also includes correct disposal of some resources, such as
cleaning up temporary files and lack of memory leaks.
Reliability: How often the results of a program are correct. This

depends on conceptual correctness of algorithms and minimisation of
programming mistakes, such as mistakes in resource management (e.g.,
buffer overflows and race conditions) and logic errors (such as division
by zero or off-by-one errors).
Robustness: How well a program anticipates problems not due to

programmer error? This includes situations such as incorrect, inappropriate
or corrupt data, unavailability of needed resources such as memory,
operating system services and network connections, and user error.
Notes
Notes
Usability: The ergonomics of a program is the ease with which a person

can use the program for its intended purpose or in some cases even
unanticipated purpoSes. Such issues can make or break its success even
regardless of other issues. This involves a wide range of textual, graphical
and sometimes hardware elements that improve the clarity, intuitiveness,
cohesiveness and completeness of a program's user interface.
Portability: The range of computer hardware and operating system

platforms on which the source code of a program can be compiled/
interpreted and run. This depends on differences in the programming
facilities provided by the different platforms, including hardware and
operating system resources, expected behaviour of the hardware and
operating system, and availability of platform specific compilers (and
sometimes libraries) for the language of the source code.
Maintainability: The ease with which a program can be modified

by its present or future developers in order to make improvements or
customisations; fix bugs and security holes, or adapt it to new environments.
Good practices during initial development make the difference in this
regard. This quality may not be directly apparent to the end user but it can
significantly affect the fate of a program over the long term.
Algorithmic complexity
The academic field and the engineering practice of computer programming
are both largely concerned with discovering and implementing the most
efficient algorithms for a given class of problem. For this purpose, algorithms
are classified into orders using so-called Big 0 notation, 0 (n), which expresses
resource use, such as execution time or memory consumption, in terms of the size
of an input. Expert programmers are familiar with a variety of well-established
algorithms and their respective complexities and use this knowledge to choose
algorithms that are best suited to the circumstances.
Methodologies
The first step in most formal software development projects is requirements
analysis, followed by testing to determine value modeling, implementation, and
failure elimination (debugging). There exist a lot of differing approaches for
each of those tasks. One approach popular for requirements analysis is Use
Case Analysis.
Popular modeling techniques include Object-Oriented Analysis and
Design (GOAD) and Model-Driven Architecture (MDA). The Unified Modeling
Language (UML) is a notation used for both the GOAD and MDA.
A similar technique used for database design is Entity-Relationship
Modeling (ER Modeling). Implementation techniques include imperative
languages (object-oriented or procedural), functional languages and logic
languages.
Measuring language usage
Notes
It is very difficult to determine what are the most popular of modern

programming languages. Some languages are very popular for particular kinds
of applications (e.g., COBOL is still strong in the corporate data center, often on
large mainframes, FORTRAN in engineering applications, scripting languages
in web development, and C in embedded applications), while some languages
are regularly used to write many different kinds of applications.
Methods of measuring programming language popularity include:
counting the number of job advertisements that mention the language, the
number of books teaching the language that are sold (this overestimates the
importance of newer languages), and estimates of the number of existing lines
of code written in the language (this underestimates the number of users of
business languages such as COBOL).
Debugging
Debugging is a very important task in the software development process,
because an incorrect program can have significant consequences for its
users. Some languages are more prone to some kinds of faults because their
specification does not require compilers to perform 'as much checking as other
languages. Use of a static analysis tool can help detect some possible problems.
Debugging is often done with IDEs like Visual Studio, Net Beans, and
Eclipse. Stand-alone debuggers like GDB are also used, and these often provide
less of a visual environment, usually using a command line.
Programming languages
Different programming languages support different styles of programming
(called programming paradigms). The choice of language used is subject to
many considerations, such as company policy, suitability to task, availability
of third-party packages or individual preference. Ideally, the programming
language best suited for the task at hand will be selected. Trade-offs from this
ideal involve finding enough programmers who know the language to build a
team, the availability of compilers for that language, and the efficiency with
which programs written in a given language execute.
The details look different in different languages, but a few basic
instructions appear in just about every language:
Input: Get data from the keyboard, a file, or some other device.
Output: Display data on the screen or send data to a file or other device.
Arithmetic: Perform basic arithmetical operations like addition and
multiplication.
Conditional execution: Check for certain conditions and execute the appropriate
sequence of statements.
Repetition: Perform some action repeatedly, usually with some variation.
Notes
Many computer languages provide a mechanism to call functions provided

by libraries. Provided the functions in a library follow the appropriate run time
conventions (e.g., method of passing arguments), then these functions may be
written in any other language.
Fill in the blanks.

1. The two popular modeling techniques are
and
Ndmtv Activity 1
List at least six quality requirements of any software project development.
14.7 SOFTWARE TESTING
a&
------
Software testing is an investigation conducted to provide stakeholders

with information about the quality of the product or service under test. Software
testing also provides an objective, independent view of the software to allow
the business to appreciate and understand the risks at implementation of the
software. Test techniques include, but are not limited to, the process of executing
a program or application with the intent of finding software bugs.
Software testing can also be stated as the process of validating and
verifying that a software program/application/product:
Meets the business and technical requirements that guided its design and
development
Works as expected
Can be implemented with the same characteristics
Software testing, depending on the testing method employed, can be

implemented at any time in the development process. However, most of the test
effort occurs after the requirements have been defined and the coding process
has been completed. As such, the methodology of the test is governed by the
software development methodology adopted.
Different software development models will focus the test effort at
different points in the development process. Newer development models, such
as Agile, often employ test-driven development and place an increased portion
of the testing in the hands of the developer, before it reaches a formal team of
testers. In a more traditional model, most of the test execution occurs after the
requirements have been defined and the coding process has been completed.
A primary purpose for testing is to detect software failures so that defects

may be uncovered and corrected. This is a non-trivial pursuit. Testing cannot
establish that a product functions properly under all conditions but can only
establish that it does not function properly under specific conditions. The scope
of software testing often includes examination of code as well as execution
of that code in various environments and conditions as well as examining the
aspects of code: does it do what it is supposed to do and do what it needs to do?
In the current culture of software development, a testing organisation may be
separate from the development team. There are various roles for testing team
members. Information derived from software testing may be used to correct the
process by which software is developed.
Notes
Defects and failures

Not all software defects are caused by coding errors. One common
source of expensive defects is caused by requirement gaps, e.g., unrecognised
requirements that result in errors of omission by the program designer. A
common source of requirements gaps is non-functional requirements such as
testability, scalability, maintainability, usability, performance and security.
Software faults occur through the following processes. A programmer
makes an error (mistake), which results in a defect (fault, bug) in the software
source code. If this defect is executed, in certain situations, the system will
produce wrong results, causing a failure. Not all defects will necessarily result
in failures. For example, defects in dead code will never result in failures: A
defect can turn into a failure when the environment is changed. Examples of
these changes in environment include the software being run on a new hardware
platform, alterations in source data or interacting with different software. A
single defect may result in a wide range of failure symptoms.
Following are the common types of defects:
Compatibility
A common cause of software failure (real or perceived) is a lack of
compatibility with other application software, operating systems (or operating
system versions, old or new), or target environments that differ greatly from
the original (such as a terminal or GUI application intended to be run on the
desktop now being required to become a web application, which must render in
a web browser). For example, in the case of a lack of backward compatibility,
this can occur because the programmers develop and test software only on the
latest version of the target environment, which not all users may be running.
This results in the unintended consequence that the latest work may not function
on earlier versions of the target environment, or on older hardware that earlier
versions of the target environment was capable of using. Sometimes such issues
can be fixed by proactively abstracting operating system functionality into a
separate program module or library.
13'
Notes
Input combinations and preconditions

A very fundamental problem with software testing is that testing under
all combinations of inputs and preconditions (initial state) is not feasible, even
with a simple product. This means that the number of defects in a software
product can be very large and defects that occur infrequently are difficult to
find in testing. More significantly, non-functional dimensions of quality (how
it is supposed to be versus what it is supposed to do) usability, scalability,
performance, compatibility, reliability can be highly subjective something that
constitutes sufficient value to one person may be intolerable to another.
There are many approaches to software testing as per following:
1.
Functional vs. non-functional testing: Functional testing refers to tests

that verify a specific action or function of the code. These are usually found
in the code requirements documentation, although some development
methodologies work from use cases or user stories. Functional tests tend
to answer the question of "Can the user do this?" or "Does this particular
feature work?" Non-functional testing refers to aspects of the software that
may not be related to a specific function or user action, such as scalability
or security. Non-functional testing tends to answer such questions as
"How many people can log in at once?"
2.
Static vs. dynamic testing: Reviews, walkthroughs or inspections are

considered as static testing, whereas actually executing programmed code
with a given set of test cases is referred to as dynamic testing. Static
testing can be (and unfortunately in practice often is) omitted. Dynamic
testing takes place when;the program itself is used for the first time (which
is generally considered the beginning of the testing stage). Dynamic
testing may begin before the program is 100 per cent complete in order
to test particular sections of code (modules or discrete functions). Typical
techniques for this are either using stubs/drivers or execution from a
debugger environment. For example, spreadsheet programs are, by their
very nature, tested to a large extent interactively ("on the fly"), with
results displayed immediately after each calculation or text manipulation.
Software verification and validation

Software testing is used in association with verification and validation:
Verification: Have we built the software right? (i.e., Does it match the
specification?)
Validation: Have we built the right software? (i.e., Is this what the
customer wants?)
The terms verification and validation are commonly used interchangeably.
In the industry it is also common to see these two terms incorrectly

defined. According to the IEEE Standard Glossary of Software Engineering
Terminology:
"Verification is the process of evaluating a system or component to

determine whether the products of a given development phase satisfy the
conditions imposed at the start of that phase."
Notes
"Validation is the process of evaluating a system or component during or

at the end of the development process to determine whether it satisfies specified
requirements."
14.8 SOFTWARE DEPLOYMENT

Software deployment is all of the activities that make a software system
available for use. The general deployment process consists of several interrelated
activities with possible transitions between them. These activities can occur at
the producer site or at the consumer site or both. Because every software system
is unique, the precise processes or procedures within each activity can hardly
be defined. Therefore, "deployment" should be interpreted as a general process
that has to be customised according to specific requirements or characteristics.
Deployment activities
1.
Release: The release activity follows from the completed development

process. It includes all the operations to prepare a system for assembly
and transfer to the customer site. Therefore, it must determine the
resources required to operate at the customer site and collect information
for carrying out subsequent activities of deployment process.
2.
Install and activate: Activation is the activity of starting up the executable

component of software. For simple system, it involves establishing some
form of command for execution. For complex systems, it should make all
the supporting systems ready to use. In larger software deployments, the
working copy of the software might be installed on a production server in
a production environment. Other versions of the deployed software may
be installed in a test environment, development environment and disaster
recovery environment.
3.
Deactivate: Deactivation is the inverse of activation, and refers to

shutting down any executing components of a system. Deactivation is
often required to perform other deployment activities, e.g., a software
system may need to be deactivated before an update can be performed.
The practice of removing infrequently used or obsolete systems from
service is often referred to as application retirement or application
decommissioning.
4.
Adapt: The adaptation activity is also a process to modify a software

system that has been previously installed. It differs from updating in that
adaptations are initiated by local events such as changing the environment
of customer site, while updating is mostly started from remote software
producer.
377
Notes
5.
Update: The update process replaces an earlier version of all or part of a

software system with a newer release.
6.
Built-in: Mechanisms for installing updates are built into some software
systems.
Automation of these update processes ranges from fully automatic to
user- initiated and controlled. Norton Internet Security is an example of a
system with a semi-automatic method for retrieving and installing updates
to both the antivirus definitions and other components of the system.
Other software products provide query mechanisms for determining
when updates are available.
7.
Version tracking: Version tracking systems help the user find and install
updates to software systems installed on PCs and local networks. Webbased version tracking systems notify the user when updates are available
for software systems installed on a local system. For example, Version
Tracker Pro checks software versions on a user's computer and then
queries its database to see if any updates are available.
Local version tracking system notifies the user when updates are available
for software systems installed on a local system. For example, Software
Catalog stores version and other information for each software package
installed on a local system. One click of a button launches a browser
window to the upgrade web page for the application, including autofilling of the user name and password for sites that require a login.
Browser-based version tracking systems notify the user when updates are
available for software packages installed on a local system. For example,
wfx-Versions is a Firefox extension which helps the user find the current
version number of any program listed on the web.
8.
Uninstall: Uninstallation is the inverse of installation. It is the removal of

a system that is no longer required. It also involves some reconfiguration
of other software systems in order to remove the uninstalled system's files
and dependencies. This is not to be confused with the term "de-install"
which is not actually a word.
9.
Retire: Ultimately, a software system is marked as obsolete and support

by the producers is withdrawn. It is the end of the life cycle of a software
product.
14.9 SOFTWARE MAINTENANCE

Software maintenance in software engineering is the modification of a
software product after delivery to correct faults, to improve performance or
other attributes, or to adapt the product to a modified environment. ISO/IEC
14764:2006 describes the six software maintenance processes as:
1.
378
The implementation processes contain software preparation and transition

activities, such as the conception and creation of the maintenance plan,
the preparation for handling problems identified during development, and

the follow-up on product configuration management.
2.
The problem and modification analysis process, which is executed once

the application has become the responsibility of the maintenance group.
The maintenance programmer must analyse each request, confirm it (by
reproducing the situation) and check its validity, investigate it and propose
a solution, document the request and the solution proposal, and, finally,
obtain all the required authorisations to apply the modifications.
3.
The process considering the implementation of the modification itself.
4.
The process acceptance of the modification, by confirming the modified

work with the individual who submitted the request in order to make sure
the modification provided a solution.
5.
The migration process (platform migration, for example) is exceptional,

and is not part of daily maintenance tasks. If the software must be ported
to another platform without any change in functionality, this process will
be used and a maintenance project team is likely to be assigned to this
task.
6.
Finally, the last maintenance process, also an event which does not occur
on a daily basis, is the retirement of a piece of software.
Notes
There are a number of processes, activities and practices that are unique
to maintainers. For example:
Transition: A controlled and coordinated sequence of activities during
which a system is transferred progressively from the developer to the maintainer.
Service Level Agreements (SLAs) and specialised (domain-specific)
maintenance contracts negotiated by maintainers.
Modification Request and Problem Report Help Desk: A problemhandling process used by maintainers to prioritise, documents and route the
requests they receive.
Modification Request Acceptance/Rejection: Modification request work
over a certain size/effort/complexity may be rejected by maintainers and
rerouted to a developer.
A common perception of maintenance is that it is merely fixing bugs.
However, studies and surveys over the years have indicated that the majority,
over 80 per cent of the maintenance effort is used for non-corrective actions
(Pigosky 1997). This perception is perpetuated by users submitting problem
reports that in reality are functionality enhancements to the system.
Software maintenance and evolution of systems was first addressed by
Meir M. Lehman in 1969. Over a period of twenty years, his research led to
the formulation of eight laws of evolution (Lehman 1997). Key findings of his
research include that maintenance is really evolutionary developments and that
maintenance decisions are aided by understanding what happens to systems
379
Notes
(and software) over time. Lehman demonstrated that systems continue to evolve
over time. As they evolve, they grow more complex unless some action such as
code refactoring is taken to reduce the complexity.
The key software maintenance issues are both managerial and technical.
Key management issues are: alignment with customer priorities, staffing,
which organisation does maintenance, estimating costs. Key technical issues
are: limited understanding, impact analysis, testing, and maintainability
measurement.

Fill in the blanks.
1.
A common perception of maintenance is that it is merely
Software maintenance and evolution of systems was first addressed

by
_}
Activity-
Activity 2
List nine activities of project deployment.
\---v Summary
The important task in creating a software product is extracting the

requirements or requirements analysis. Customers typically have an
abstract idea of what they want as an end-result, but not what software
should do. Incomplete, ambiguous, or even contradictory requirements
are recognised by skilled and experienced software engineers at this point.
Frequently demonstrating live code may help reduce the risk that the
requirements are incorrect.
380
Once the general requirements are gathered from the client, an analysis
of the scope of the development should be determined and clearly stated.
This is often called a scope document.
Certain functionality may be out of scope of the project as a function of

cost or as a result of unclear requirements at the start of development. If
the development is done externally, this document can be considered a
legal document so that if there are ever disputes, any ambiguity of what
was promised to the client can be clarified.
Implementation is the part of the process where software engineers

actually program the code for the project.
Software testing is an integral and important part of the software

development process. This part of the process ensures that defects are
recognised as early as possible.
Deployment starts after the code is appropriately tested, is approved for

release and sold or otherwise distributed into a production environment.
Software Training and Support is important and a lot of developers

fail to realise that. It would not matter how much time and planning a
development team puts into creating software if nobody in an organisation
ends up using it. Maintaining and enhancing software to cope with newly
discovered problems or new requirements can take far more time than the
initial development of the software.
Several models exist to streamline the development process. Each one

has its pros and cons, and it's up to the development team to adopt the
most appropriate one for the project. Sometimes a combination of the
models may be more suitable. Some of them are Waterfall Model and
Spiral Model.
A software development process is a structure imposed on the development

of a software product. Similar terms include software life cycle and
software process. Some people consider a lifecycle model a more general
term and a software development process a more specific term.
Requirements analysis in systems engineering and software engineering,

encompasses those tasks that go into determining the needs or conditions
to meet for a new or altered product, taking account of the possibly
conflicting requirements of the various stakeholders, such as beneficiaries
or users. New systems change the environment and relationships between
people, so it is important to identify all the stakeholders, take into account
all their needs and ensure they understand the implications of the new
systems. Systematic requirements analysis is also known as requirements
engineering.
A functional specification in systems engineering and software

development is the documentation that describes the requested behaviour
of an engineering system. The documentation typically describes what is
needed by the system user as well as requested properties of inputs and
outputs
Notes
)Keywords
Issue: In computing, the term issue is a unit of work to accomplish an

improvement in a system.
Software architecture: The structure or structures of the system, which

comprise software components, the externally visible properties of those
components, and the relationships between them.
Software design: A process of problem-solving and planning for a

software solution.
381
Notes
Software testing: An investigation conducted to provide stakeholders

with information about the quality of the product or service under test.
Verification: The process of evaluating a system or component to

determine whether the products of a given development phase satisfy the
conditions imposed at the start of that phase.
Validation: The process of evaluating a system or component during or

at the end of the development process to determine whether it satisfies
specified requirements.
Software maintenance: The modification of a software product after

delivery to correct faults, to improve performance or other attributes, or
to adapt the product to a modified environment.
Activation: The activity of starting up the executable component of

software.
Deactivate: Shutting down any executing components of a system.

Version tracking: Version tracking systems help the user find and install
updates to software systems installed on PCs and local networks.
382
1.
What is software managlement process? Explain the activities in software

management process.
2.
Explain the software deyelopment process.
3.
What are the different software development models? Explain with

suitable examples.
4.
Differentiate between waterfall and spiral models for software projects.
5.
What is software development cycle? What are the steps in software

development cycles?
6.
What is Software Project Implementation? Explain the activities to be

undertaken for software project implementation.
7.
What is software testing? Explain the process of software testing.
8.
What is the importance of software testing? Explain the care to be taken

while software testing.
9.
What is software deployment? Explain the process of software deployment.
10.
What are the activities in software maintenance? Explain the process in

detail.
Notes

Fill in the blanks.
1.

implementing and monitoring the life cycle for software is ISO 12207.
2.
Bug tracking system tools are often deployed to allow development teams
to interface with customer/field teams testing the software to identify any
real or perceived issues.
3.
Risk management is the process of measuring or assessing risk and then

developing strategies to manage the risk.
4.
Agile processes use feedback, rather than planning, as their primary

control mechanism.

Fill in the blanks.
1.
The purpose of project monitoring and control is to keep the team and
management up to date on the project's progress.
2.
In computing, the term issue is a unit of work to accomplish an

improvement in a system

Fill in the blanks.
1.
The three types of activity included in requirements analysis are eliciting

requirements, analysing requirements and recording requirements.

Fill in the blanks.
1.
The two popular modeling techniques are Object-Oriented Analysis and

Design (OOADI and M del-Driven Architecture (MDA).

Fill in the blanks.
1.
A common perception of maintenance is that it is merely fixing bugs.
2.
Software maintenance and evolution of systems was first addressed by

Meir M. Lehman.
(
114' Suggested Reading
1.

McGraw-Hill.
383
384

Structure:
15.1 Best Practices in Projects
UNIT
15
15.2 Cross-Cultural Issues in Projects

15.3 Challenges in International Project Disputes
15.4 Resolving Conflicts in Projects
15.5 Cross-Cultural Communication
15.6 Project Management Software
15.7 Project Portfolio Management
15.8 Project Workforce Management
15.9 Subcontracts and Collaboration in Projects
Summary
Key Words
Suggested Reading
385
Notes
Objectives
Implement best practices in project
Identify cross-cultural issues in projects
Resolve project conflicts
Predict challenges in international projects
Prepare for cross-cultural communication for project success
Select, evaluate and use project management software
Evaluate subcontractors for projects
Explain project portfolio management
15.1 BEST PRACTICES IN PROJECTS

For any project to be successful, we can follow the past practices which
have resulted in successful completion of projects. We list down the skills sets
for this as detailed below:
1.
Organisational Practices: This involves practices that have a positive

impact at the corporate level.
2.
Team Practices: This contains practices that have a positive impact at

Group or Tribe level.
3.
Individual Practices: This contains personal practices that a single

individual can perform to make a positive impact to the Project.
The reasoning behind this classification scheme is as follows:

Maintain a Project Management perspective that involves people, tools,
and processes and Keep it simple such that it can be easily applied.
Certain best practices may be applicable to more than one classification
that would suggest an overarching best practice. The main intent is to understand
how a given skills set affects Projects at various levels such that we can be
aware of its effectiveness.
1.
Organisational Practices: The organisational practices involve practices

that have a positive impact at the corporate level. These are as follows:
386
Knowledge management: Perhaps the greatest benefit that can be

realized from the practice of Project Management is the knowledge
that is gained as a result thereof. Knowledge Management is one way
to provide others with experience that is known by the organisation.
It can help to dramatically mitigate risks by allowing the pitfalls
of previous projects to be exposed and understood. "Corporations
that embrace Knowledge Management for Project Management
can expect productivity of application development increases of

40%." (Murch, 2001) There needs to be a central repository for
Project Information so other Projects can benefit. This Body of
Knowledge also contains metrics on previous Project performance
and techniques used.
Notes
An analysis on the data for patterns of success and failure is

important to highlight but to also not rely on the pure "numbers"
and always apply common sense.
The result of Knowledge Management is to elevate the bench
strength of both the team and the organisation through feedback
mechanisms and leveraging experience. For example, the Time
Metric is used to analyse "the time" allocated to different areas of
the project and different tasks and the variance from the estimate
to the actual was used to revise upcoming tasks, and the Defect
Metric is used to help determine the expected number of bugs and
used as guidance to set lower bug targets by analysing why the
bug existed (then focusing on that area for correction). In practice,
getting the right set of metrics and actually the logistics of gathering
the information is the difficult part.
Continuous improvement: For continuous improvement to be

effective the processes that are in need of improvement must be
repeatable. Repeatability is an underlying principle that forms
process. A successful process is one that yields the same results
no matter which people are executing the process this is an ideal
scenario that is very difficult to achieve.
Corporate policies and governance: All organisations need

processes and procedures that provide guidance to individuals.
However, it should not be dogmatic in the face of common sense
and its application. Individuals must be aware of when to use
certain practices and abandon others otherwise the mandatory
exercise of following processes will yield undesirable results. A
Company cannot have ivory tower processes that must be followed
if they do not make "sense" or bring any value. DeMarco & Lister
(1999) stated, "The last project generated a ton of paper and it was
still a disaster so this project will have to generate two tons." The
enforcement of adherence and utilisation ofpractices and procedures
can be achieved through Governance. In order to be effective,
Governance needs to be supported by senior level management to
ensure that sufficient funding is in place so that governance can be
done well.
There must be accountability for the utilisation of processes at
multiple levels. The Project Management Office (or like body)
within the organisation should be responsible for the advocacy,
implementation, and continuous improvement of these processes.
387
As in everyday life, there is little value in having laws if they are not
enforced. With the support of senior management, the governance
process is more likely to receive the required resources to be
effective. While it can be anticipated that some Project Managers
may not embrace the idea of governance, fearing that they are being
unnecessarily policed, the project management purists are likely
to accept governance by recognising it as value rather than as a
constraint.
Notes
Scalability of practices: The project practices put in place by

organisations must scale in accordance with the size of the projects
that will leverage the practice. The overzealous deployment
of exhaustive practices often clouds the intended results of
implementing the practice in the first place. The practices employed
by organisations must be positioned so the intended audience can
embrace it. An exhaustive practice that is targeted towards very
large projects will often carry significant unnecessary overhead
with it when attempting to apply it to smaller projects. While the
intent of these practices remains consistent across all projects, it
will not be effective if the practice is abandoned due to excessive
size or complexity.
An example of a scalability problem is one that was evidenced in
one of the interviews. An individual works with an organisation that
is a subsidiary of a major Eastern based organisation that has grown
considerably over the past few years. When the individual first
started with this organisation, there were only a few employees and
there was a limited formal procedural structure this worked well.
This subsidiary has now become more established in the marketplace
more "formalised" procedures are becoming commonplace and
the level of structure that was introduced has helped to develop
organisational consistency. According to the interviewee, the
key to this successful transformation was the enhanced structure.
For instance, a "less regimental" structure that is effective for an
organisation with 100 employees may not necessarily work for the
700+ employees today. At the same time, the interviewee noted
that an ongoing struggle the firm is facing is trying to implement
"big company" policies and procedures, being dictated by its much
larger parent company, while the organisational infrastructure that
is needed to support this initiative is not ready.
38.8
Cross-functional teams: Future implementation of project teams

and organisation in a project management setting must include and
understand the importance of cross-functional teams. Pinto (2002)
cites evidence that shows cooperation "positively affects both task
and psychosocial outcomes", suggesting that cooperation promotes
better task performance as well as general positive feelings of
accomplishment from the project.
2.
Edification: Educating stakeholders regarding aspects of Project

Management will help in establishing expectations. A company
that has a policy of distilling information will foster better
communications, invest in people and improve overall company
bench strength.
Notes
Team Practices: This contains practices that have a positive impact at

Group or Tribe level. Team practices includes following aspects:
Focus: Getting mired in the details of the Project Management

process and not keeping a perspective and "seeing the forest through
the trees" creates its own set of problems.
Team members: An organisation's greatest asset is its people as

its performance has shown to be correlated with individuals who
can effectively assemble and collaborate (Meredith & Shafer,
1999). In essence, a "tribe" can outperform any company process
or procedure. There is another aspect that touches upon the
experiences (both successes and failures) of individuals that is seen
as wisdom and risk mitigation. The quality and depth of knowledge
provides diversity within the team and something unique that must
be leveraged. It is time well spent to identify, isolate, and exploit an
Individual's strengths while minimizing any weaknesses that has
the net effect of elevating the overall bench strength of the team.
Team processes - front-end planning: Without planning and

controls, the project will drag on. Integrating the definitive
stakeholders from the beginning of the process allows for more
time to identify a thorough outlook of the project interdependencies.
Initial software development estimates and schedules should be
looked upon as uncertain due to the lack of definitive information
available at the time. Thereafter, the estimates and schedules
should be refined as more information becomes available. At each
milestone, the estimate to complete (as long as it is not percentage)
and forecast should be presented to identify deviations from the
original cost and schedule baselines. It is recommended that each
deliverable within a deliverable breakdown structure (DBS) have
an associated cost estimate and schedule.
Team life: A major failing in projects is the lack of well-defined

requirements that is oftentimes subject to interpretations. Hence,
teams must have a clear objective that is continually aligned with
the project and the organisation. The team must also be innovative
in their approach by challenging status quo and trying something
different. However, creativity must be controlled to the extent that
it can be isolated. This would also include abandoning processes if
they are not working and knowing when to abandon them.
Good communications: An infrastructure that supports regular

communication between stakeholders through the project
389
development team is one tool for project success. Ensuring that

stakeholders are provided updates at milestones and that their
expectations are being managed is also critical for project success.
Furthermore, the use of an Account Manager can ensure that realistic
expectations of stakeholders are met. Finally, large corporations
must model inherent dynamics of small companies who make
certain that each member is being communicated to on a regular
basis.
Notes
3.
Risk registration and documentation: It sounds simple enough,

but there are risks that are "insignificant" at the beginning of the
project that becomes "catastrophic" due to neglect. Capturing all
risks in a risk register ensures at the very least there is a record of
it and it will not be lost. Furthermore, by documenting everything,
references are readily available for any disputes.
Individual Practices: If the spokes of a wheel become unaligned from

the hub, chances are that the wheel will not roll smoothly. Furthermore,
there will be much turbulence and swaying from the path. Similarly,
if an individual loses focus and aligns away from the objectives of the
project and organisation, chances are that the well-being of the project,
organisation, and individual will also be in jeopardy. In another words,
the individual must understand where he/she fits in the project scheme.
Hence, it becomes extremely important that an individual constantly and
consistently improve their personal processes both for the duration of
the project and professionally. The individual practices contain personal
practices that a single individual can perform to make a positive impact
to the Project.
Personal processes: Personal processes are intrinsic behaviours

and thought methodology of an individual. It is an individual's
acknowledgement and recognition of the relationship that exists
between personal values and values of the project. Therefore, each
individual, regardless of their role be it project manager, senior
consultant or junior analyst they must always be critical of their
behaviour. If the behaviour of such an individual hinders the project,
they must be held accountable. Subsequently, each individual must
be held accountable such that they can execute their responsibilities
more efficiently.
Personal processes also include an individual's recognition and
acceptance of personal strengths and weaknesses relative to
projects. A project implementation will rely heavily upon the skill
sets of its individuals and expect the individual to be able to operate
efficiently. Therefore, if an individual has not yet received training
to implement a high level software implementation, he/she must not
seek projects for personal gain this will be detrimental to both the
individual and organisation.
SAP (Sociology/Anthropology/Psychology) implementation:

The globalisation of markets, mergers of international companies,
and integration of managerial processes in corporations are
changing project management fundamentals (Eriksson et. al 2002).
Individuals within these organisations are now forced to adjust and
respond to diverse environments. Just as the Enterprise Resource
Planning vendor "SAP" offers an array of technological solutions
and practices for its clients worldwide, it has become pertinent that
individuals offer broad perspectives and diverse social competencies
for projects they work on as well. In other words, organisations and
individuals are required to manage diversity efficiently.
Notes
Diversity management is a strategically driven process whose 'emphasis

is on building skills and creating policies that will address the changing
demographics of the workforce and populations' (adapted from Svehla, (1994)
in Weech-Maldonado,2000). Diversity in the future will be driven by the
imperatives of competitiveness, demography, immigration, and globalization
(Gandz, 2001 update). Dealing with diversity at a global stage will require
individuals to be culturally competent. Cultural competence, as defined
by Marla Sutton (FPM magazine 2000) is where congruent behaviours,
attitudes and policies come together as a system to work effectively in crosscultural situations. It is representative of an integrated pattern of thoughts,
communications, actions, and beliefs of ethnic or social groups'. This means
understanding another individual's and teams social environment what shapes
that individual's and teams social beliefs the anthropological history of the
environment where the individual/ group resides (for example, if there is a joint
PeopleSoft implementation within an organisation in two countries Canada and
China many times, individuals are unaware of the Ilistories, mannerisms, and
cultural practices that enrich each country).
Dealing with loads of diverse information will be quite difficult at first.
All of this will require individuals to expand their cognitive abilities and
psychological thought processes. The diverse amounts of information that
individuals will be exposed to will result in cognitive dissonance.
Cognitive dissonance challenges our individual abilities to process and
understand information. The key is in understanding that individuals must
learn to strive for meta-cognitions, or coming over and above our ability to
process and understand information, i.e., coming over and above our way of
knowing, also known as praxis. Therefore, to stay competitive and maintain
an edge, individuals must increase their scope of understanding around social,
anthropological, and psychological issues.
15.2 CROSS-CULTURAL ISSUES IN PROJECTS

Basically human races came with different background - cultural
background. The way of doing things in one culture may not be the way in other
culture. What is good in one culture may be bad in other culture. Sometime the
391
Notes
activities are all the same in two different cultures, but two different meanings,
two different interpretations.
When a person from one cultural background, meets, interacts with,
understands and deals with a person from other cultural background, it is crosscultural management.
Some people are in favour of the world which is converging, all things are
going to be same. They are right. Some people are arguing still the world has
divergence. They are also right.
We shouldn't fight over this issue. We need to learn how to manage both
the convergence and divergence. That is the key to success.
Let us take an example. In USA, it is performance that counts, based
on which higher assignments and promotions are given. In Indian companies,
performance is not the main criteria. It is "organisational compatibility" that
counts, that is, the employee "fit" in to the organisation that counts. India is
a high-context society. The "fit" into the organisation has to be interpreted in
Indian way.
The business has different interpretation. In USA, doing business means
creating organisation wealth. In India doing business means "Individual
wealth". On recruitment, in USA it is the process of selection, in India it is the
process of rejection and the difference goes on...
Certainly, the differences are innumerable. Increasing an individual's or
an organisation's cultural intelligence is not an easy task.
One of the very important accomplishments of developing project
management as a field is that it is increasingly being informed by Project
Managers across the world. And while we can say that, on a fundamental level,
projects across the world see similar classes of threats and opportunities, we can
agree that the expression of those opportunities and threats are often different,
depending on where you happen to be.
The reason for this difference is not technical; it is cultural. What do we
mean here? Well, for example, some cultures tend to emphasise individual
performance, while others evaluate success based on team performance. Some
cultures invite very direct speech, while others tend to invite a reading between
the lines. Some cultures follow a very formal chain of command in terms of
project communications, while other cultures promote a more horizontal flow
of information. As a Project Manager, our project will work within a particular
cultural environment, and will necessarily thus reflect that.
Cultural influences are, of course, nothing new. Any of us who have
travelled even to a neighbouring country have likely encountered some form of
cultural influence different than their own. However, because project life is so
mobile, there's a good chance that if you venture into the field, you will either
find yourself working in a variety of cultures, or working with people who
reflect an array of multicultural perspectives. Being aware of these different
392
cultural horizons will not only make you a more successful Project Manager,
but much more importantly, it will make you a much better communicator and
listener, which will make our work both satisfying and meaningful.
Notes
The field of project management inherently involves many cultures.

This doesn't mean it must and always does. It does however tend to due to
globalisation. We now can hire the best organisation to do a certain project not
just from our local city or local region but from anywhere in the world. One
can also have projects where the members are scattered around the world for a
great number of reasons, varied skills, very specific skill not found elsewhere or
else simple outsourcing. Even projects done in the local region likely will have,
again due to globalization people of varying cultures.
We have identified several areas in which differing cultures will play a
large part in project management. First of all, there are two situations of note
which will foster cross-cultural difficulties most easily if not taken into account
and dealt with. These are: importing a manager from abroad, for example, a
Canadian project manager manages the construction of a bridge in China and the
opposite situation where technically skilled workers are imported to a project,
for example, German solar engineers working on a Mexican solar energy plant
in Mexico. There are of course many international project involving people
from dozens of countries.
As we know project managers need certain basic skills to be successful
in their endeavours. Cross-cultural context comes into play because these very
basic skills vary hugely between cultures. Communication and leadership were
the skills I identified by reading articles about project management. Obviously
language plays a large role in communication. Often the international language
of business is English but this is not always the case. Other languages can be
learned and translators can be used to mediate this problem. A less obvious
problem is simply the subtle differences of communications between cultures.
Using Hofstede's famous "Framework for Assessing Culture" we can
identify several areas that affect communication between two people of differing
cultures.
1.
Small vs. Large Power Distance: We find that some cultures have a steep
hierarchy where people do not communicate between levels much higher
or lower then themselves. In Slovakia someone would not communicate
directly with a project manager, they would talk to their supervisor and
relay the information up the hierarchy. As for leadership in these cultures
the leader is not questioned and consensus is not a tactic to be used. A
natural inclusive leader would have to become much more of a dictator
in leadership style. In small power distance countries as Denmark lower
down workers freely express question and concerns with much higher
project managers. Leaders are questioned in this culture and so may
have to be ready to defend reasons for doing something better than with
`because I'm the boss and I say so' which would be expected out of a
leader in the large power distance cultures.
393
Notes
2.
Uncertainty avoidance: Uncertainty avoidance is very important in

communication. Certain cultures have some problem with uncertainty
and change while others fear is immensely. This is very important to take
into account as a project manager to know what information can be and
how it should be communicated. As a leader one needs to be sensitive to
this as the planning stage might be different between the two opposing
cultures. A project plan in Japan would likely be set whereas the standard
deviations of the plan's time allow the dates to be very certain. In North
America we accept a loWer level of certainty for dates and the plan would
reflect this.
3.
Long vs. short-term orientation: Long vs. short-term orientation is

important as it relates to the importance of tradition and the idea of 'saving
face'. In Japan if questioned a leader if they do not know the answer will
often lie to save face. One must learn to present things in such a way that
allows someone to save face but not have to lie so that you get to a better
outcome/truth.
4.
Individualism vs. Collectivism: Individualism vs. Collectivism is

most important when it comes to organising projects and leading them.
Individualistic cultures tend to not need or want to be micromanaged and
put importance on the idea of initiative. Rewards should be individually
based or in small groups or teams. Collectivist cultures need and want
to be micromanaged in each task. Rewards should not be given to the
individual as this might be very embarrassing as the emphasis in this
culture is on the larger groups accomplishment.
5.
Language: Language i, of course, the biggest issue. Since English is

the common business language in most international projects, it certainly
helps if both sides spoke it fluently. However, this is often not the case
and it is more common for one or both parties to struggle with language.
This is especially true when the subtleties of contracts or interests are
at the center of the dispute. When one side fails to understand the other
and when one side feels that the other does not understand what they are
saying, tensions in the room can rise, and the parties to the negotiation
can retreat to the safety Of their own interests rather than taking that extra
effort to understand the other side.
Lack of understanding can escalate conflicts to full-blown disputes,
arbitration or even litigation. The importance of language cannot be
underestimated. Indeed it is so important that a major oil company in
South Korea brings in English tutors to work every week with those who
will be interacting and negotiating with customers and clients. It is also an
issue that has not gone unnoticed in South Korea, where the government
has been proactive in introducing English as a second language (ESL) to
its young people as a formal requirement in school.
6.
Culture: Culture is also critical in understanding why overseas projects

are so challenging. There are two issues. The first is power distance; how
people at different levels in the organisation relate and communicate with

each other. In high power distance countries, the top levels of management
have considerable power over their direct reportees and their word is law.
Project managers reporting to a boss in an organisation characterised by
high power distance may have relatively little room to compromise or
collaborate in achieving solutions to conflicts.
Notes
The second is the degree to which the people in a country can be

characterised as individualistic or collectivistic. In cultures that show a
strong preference for individualism, like the United States, individuals
take care of themselves and seek individual opportunities. Those in
collectivistic cultures, on the other hand, may prefer to associate with a
group and enjoy the sense of belonging and security that the group offers.
7.
Trust: In almost every culture, building trust is a slow process; it must

be earned. But in some cultures, especially in Asia, it is even slower,
and in many cultures, making a deal with the other side will not even be
considered unless trust has been established. The process of establishing
trust is complex but it begins with creating a relationship, respecting
the cultural values of the other side, and showing a willingness to
accommodate the other side's needs.
8.
Making headway: Here is the problem. Many times we hear complaints

that the other side in the dispute is very formal, that they only want to
talk about business, or that they are unwilling to engage socially. We hear
them say that the other side is just interested in persuading our side that
they are right.
But clinging to this perception of the other side can lead to a self-fulfilling
prophecy. In other words, just thinking this way can make it seem that attempting
to engage the other side in creating a better relationship is futile and a waste of
time. So the attempt is not made and this leads to an increase in tension between
both sides.
For starters, it might be appropriate to accept the other side's preference
for maintaining an arms-length relationship. At the same time, however, it might
be appropriate to take small but concrete steps to improve the relationship. To
do this requires attention to language, culture and trust building. These steps
might begin by asking the other side questions that uncover common interests
or it might begin by actively listening to the other side and then asking for
clarification. They will not always work, but when they do succeed the payoff
can well worth the effort.
As we can see from these examples cross-cultural issues have a large
importance in project management. Different cultures must be taken into
account throughout the life of the project to avoid everything from added stress
to outright failure. The best way to deal with anything is to gather as much
information as possible. There are many online sources that give overviews of
working in specific cultures. Take these differences into SERIOUS account as
they are not to be underestimated!
395
Notes
v iv
Att;
Activity 1
Select any two countries and list at least five cross-cultural differences
between them.
15.3 CHALLENGES IN INTERNATIONAL PROJECT

DISPUTES
Disputes are common in global projects and resolving them can be
difficult, especially if the decision-maker is not sitting at the negotiating table.
Here is an example of what can happen.
A contractor shipped industrial equipment from Asia to the Middle East.
During a major storm at sea the equipment was damaged. It was delivered to
the customer on time but it was not until the equipment was inspected that the
damage was discovered. The customer insisted that the goods were late because
they were of no use until repairs could be made. Referring to the contract, they
insisted that the contractor would be liable for late charges until such time as
the equipment was delivered in working order. The contractor, on the other
hand, insisted that the goods had been delivered on time and that the damage
was due to forces beyond their control. Damage of this nature, they contended
was covered under a category called Force Majeure a situation where damage
is beyond the control or 'responsibility of the contractor and for which the
contractor would not be held liable.
Both parties communicated their positions by email but failed to make
any progress in resolving the dispute. They agreed to a face-to-face meeting at
the customer's facilities in the Middle East.
At that meeting the contractor's team included the Engineering
Procurement Manager and Contract Manager. But before the contractor's team
traveled to the Middle East, the Project Director (PD) reminded both of them
that the profit margin on this project was thin and that their responsibility was to
persuade the client that the cause of the problem was beyond their control and
that no late penalties should apply.
The Customer was also represented by two people including the contract
manager and the operations manager. They had been directed by their boss not to
compromise with the contractor and that they must demand full payment of the
late charges as specified in the contract. Their boss further emphasised that the
damage was not due to rough seas rather it was due to negligence on the part of
the shipping company. He further maintained that it was the responsibility of the
contractor to collect damages from the shipping company, not the responsibility
of the customer to collect these damages. As a result the contractor must pay its
customer directly.
' 1396 7
The negotiating session, held at the customer's facility, was contentious.

Each side presented a very logical argument supporting its position. But the
competitive nature of the arguments only served to. escalate the tension in the
room. At the end of a four hour session nothing had been resolved. Frustrated,
they adjourned after agreeing to meet the next morning.
Notes
Is this realistic? Yes. It happens over and over again. Both sides sit down
at the table with instructions from top management not to give in. No one at
the bargaining table has the authority to bargain! As a result, the negotiation
degenerates into a competitive debate where one party tries to persuade the
other. They get nowhere and unless one side capitulates, the dispute is referred
to as arbitration.
There is, of course, a major downside to arbitration. It can be a costly
process, it can take time, and above all it can erode the relationship and trust
between parties. Furthermore, arbitration is risky because one party may end up
with much less than what could have been achieved had a negotiated settlement
been reached.
So, what can be done in these situations? EvFry effort must be made to
ensure that the decision-makers for both sides sit at the negotiation table. If this
is not possible, then every effort must be made to bring the decision-makers
into a later negotiating session, even for a short period of time. If this is still
not possible, then it might be possible to hold informal or special meetings with
the decision maker present. None of these may work, but they are worth a try.
Without a decision-maker, negotiators have one hand tied behind their back!
When a project conflict occurs between two parties, separated by distance
and culture, resolving that conflict is a challenge that can often end up in
arbitration or the courts. Following are the reasons why this breakdown occurs.
1.
Lack of Authority to Make Decisions: It is frequently assumed that

those who have been designated to sit around, the negotiating table have
the authority to engage in the give-and-take process necessary to reach a
mutually acceptable solution in a conflict situation. Too often this is not
the case. Those sitting around the table may simply be representatives
of the real decision-maker, a person at a higher level in the organisation.
This is especially true in high power distance cultures and high power
distance organisations. Instead, those at the table are expected to enforce
their organisation's position. They have no real authority. For example,
a sales manager, frustrated by a customer's failure to successfully install
new software, may insist that the salesperson assigned to that account
convince the customer that the software problem is not the vendor's
problem but the customer's problem. "We will not spend any more time
on their problem," he insists. "It's your job to make this clear to them."
Here the salesperson is simply the messenger and has no authority to
negotiate with the customer. When the person at the table lacks authority,
deals are difficult to make.
397
Notes
2.
Accepting the Status Quo of Relationships: Stereotypes are common. In

project management, stereotypes become a problem when they interfere
with the process of establishing working relationships between parties.
If those from the Middle East are considered too formal and demanding,
then the other side of the table may refrain from taking steps that could
lead to a better working relationship. They may look for every sign that
confirms their stereotype even when this behaviour is only a small part
of the other side's overall behaviour. The result is that they settle for
an arms-length relationship and miss the opportunity to develop a very
different kind of working relationship.
Stereotypes work very quickly to define relationships at the bargaining
table. The longer the relationships remain unchallenged, and the more
each side accepts the status quo, the more difficult it is to move away
from stereotypic responses.
In many cross-cultural conflicts, then, negotiations fail because the status
quo is never challenged. Seldom does anyone attempt to change the
atmosphere by acknowledging the inability of both sides to work together
and then following through by facilitating a transition to a problem solving
mode of behaviour.
3.
Failure to Shift Negotiations from Positions to Issues: It is common

for negotiations to be stuck on positions. One side tries to persuade the
other that its position is logical, supported by the contract, or represents
the standard way of handling problems of this type. Each side may be
convinced that it is right and that its role is simply to persuade the other.
As a result, very little progress is made. In one negotiation, the other side
kept insisting that their position was the only legitimate position and even
told our side once the negotiation was over that they were prepared to
argue until we were exhausted and gave in.
But situations like this are often characterised as win-lose negotiations and
are certainly not preferred, especially when they have the potential to damage
the working relationship between both parties and especially if the potential for
follow-on business between them is jeopardized.
A much better strategy is to shift the focus from an adversarial mode in
which positions are argued to a cooperative mode that explores the interests of
both sides. Consider this example. A client insists that only those vendors on
the original approved vendor list can be used to provide products and services.
The contractor, however, insists that they should have the option of using other
vendors. The argument over approved or non-approved vendors can go on and
on, but the real interests of both parties are to successfully complete the project,
on time and on budget. Shifting the discussion to common interests has a better
chance of expanding the vendor list than an argument in which both sides
simply argue positions.
Note's
11,
AGWAY
Activity 2
Enlist the reasons for a project conflict between two parties, separated by
distance and culture.
15.4 RESOLVING CONFLICTS IN PROJECTS

Thus, we have identified the challenges. But it is not enough just to
identify these challenges. Steps must be taken to address each one. Yet, in the
midst of a heated negotiating session it is very difficult to see that it is these
issues that need addressing before real progress can be made. What are those
steps? There are many, but here are a few suggestions.
Someone on the negotiating team needs to be assigned the role of process

monitor. In this role that individual keeps tabs on the progress of the
negotiation and is constantly evaluating ways to change course when an
adversarial process threatens to derail progress.
It might be that language is interfering with communication and it would

therefore be appropriate to ask the other side for clarification at several
points in the discussion. It might even be necessary to bring an additional
person into the session, one with fluent language skills.
If it is discovered that the decision-maker is not in attendance, it might be

useful to request that he or she attend one or more sessions.
When the negotiations are at an impasse and relationships are tense, the
status quo may have to be challenged. The goal is to improve working
relationships.
The discussion may have to be shifted from positions to common interests.

The goal is win-win. Both parties should leave satisfied that they have
been heard and satisfied with the outcome.
Yet every one of these steps is difficult to take. The fear is that the side
taking these steps will be seen as abandoning their own position and capitulating
to the other side. By opening the negotiation process some would see it as
`giving in'. But to the contrary, it is actually a deliberate move in the interest
of reaching a mutually acceptable solution to the problem. In international
projects, where the project is managed by a company in one country for a client
in another, contracts serve at least three purposes as:
Marketing Tool
Blueprint
Legal Document
First, it is a marketing tool to facilitate selling an organisation's products

or services. Second, it is a blueprint for planning, executing, monitoring,
controlling and closing the project. Third, it serves as a legal document to be
399
used when conflicts or disputes occur. Each purpose is different and that is
where the problem begins.
Marketing Tool: Consider the contract as a marketing tool. Consider the

example of a young couple where the man has just proposed marriage.
To ensure an answer of "yes" from his girlfriend, he promises a glorious
honeymoon, a 55 inch 3,-D flat screen TV, a new car, and three children.
It is a contract that is likely to end in a dispute or worse, divorce.
While the marketing department, during the contract phase, would be
expected to be considerably more professional than this young man,
there are surprising similarities. Both desire to make the sale and both
are willing to do whatever is necessary to succeed. So the marketing
department, as in this simple story, may overlook some of the details and
make concessions because their performance depends upon making the
sale.
Blueprint: The contract is a blueprint defining what has to be done over

the life cycle of the project. Ideally, it would include enough detail to
guide the planning, execution, monitoring, controlling and closure of
the project. And it would contain enough information to create the work
breakdown structure, schedules, quality metrics, and subcontracting
criteria.
Yet in any project, especially those that are complex, these details are
purposefully omitted or left vague because a contract created at the early
stage of a project is as much a marketing document as it is a blueprint for
execution.
Yet few contracts for complex projects can even consider the choices,
outcomes and problems that are likely to occur.
Legal Document: It is always better to prepare legal documents so that

the clarity is there for all the parties involved and in case of any dispute,
the legal standings will be clear.
r_
v" T, Activity 3
Vkott
Enlist the three purposes served by contracts in international projects.
.1
15.5 CROSS-CULTURAL COMMUNICATION

Cross-cultural communication (also frequently referred to as intercultural
communication, which is also used in a different sense, though) is a field of study
that looks at how people from differing cultural backgrounds communicate,
in similar and different ways among themselves, and how they endeavour to
communicate across cultures.
Cross-cultural communication tries to bring together such relatively

unrelated areas as cultural anthropology and established areas of communication.
Its core is to establish and understand how people from different cultures
communicate with each other. Its charge is to also produce some guidelines with
which people from different cultures can better communicate with each other.
Notes
Cross-cultural communication, as in many scholarly fields, is a

combination of many other fields. These fields include anthropology, cultural
studies, psychology and communication. The field has also moved both toward
the treatment of interethnic relations, and toward the study of communication
strategies used by co-cultural populations, i.e., communication strategies used
to deal with majority or mainstream populations.
The study of languages other than one's own cannot only serve to help
us understand what we as human beings have in common, but also assist
us in understanding the diversity which underlies not only our languages,
but also our ways of constructing and organising knowledge, and the many
different realities in which we all live and interact. Such understanding has
profound implications with respect to developing a critical awareness of social
relationships. Understanding social relationships and the way other cultures
work is the groundwork of successful globalisation business efforts.
Language socialisation can be broadly defined as "an investigation of
how language both presupposes and creates new, social relations in cultural
context". It is imperative that the speaker understands the grammar of a
language, as well as how elements of language are socially situated in order to
reach communicative competence. Human experience is culturally relevant, so
elements of language are also culturally relevant. One must carefully consider
semiotics and the evaluation of sign systems to compare cross-cultural norms
of communication. There are several potential problems that come with
language socialisation, however. Sometimes people can over-generalise or label
cultures with stereotypical and subjective characterisations. Another primary
concern with documenting alternative cultural norms revolves around the
fact that no social actor uses language in ways that perfectly match normative
characterisations. A methodology for investigating how an individual uses
language and other semiotic activity to create and use new models of conduct
and how this varies from the cultural norm should be incorporated into the
study of language socialisation.

1.
Cross-cultural communication is referred to as intra-cultural

communication.
Language socialisation is an investigation of how language both
presupposes and creates new, social relations in cultural context.
401
Notes
15.6 PROJECT MANAGEMENT SOFTWARE

Project management software is a term covering many types of software,
including scheduling, cost control and budget management, resource allocation,
collaboration software, communication, quality management and documentation
or administration systems, which are used to deal with the complexity of large
projects.
Tasks or activities of project management software:
1.
Scheduling: One of the most common purposes is to schedule a series of

events or tasks and the complexity of the schedule can vary considerably
depending on how the tool is used. Some common challenges include;
Events which depend on one another in different ways or

dependencies.
Scheduling people to work on and resources required by the various

tasks commonly termed resource scheduling.
Dealing with uncertainties in the estimates of the duration of each

task.
Calculating critical path.
In many complex schedules, there will be a critical path, or series of

events that depend ()A each other, and whose durations directly determine
the length of the wbole project (see also critical chain). Some software
applications (for example, Dependency Structure Matrix solutions) can
highlight these tasks, which are often a good candidate for any optimisation
effort.
2.
3.
Providing information: Project planning software can be expected to

provide information to various people or stakeholders, and can be used to
measure and justify the level of effort required to complete the project(s).
Typical requirement 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
Evidence
Historical information on how projects have progressed, and in

particular, how actual and planned performance are related
Optimum utilisation of available resource
Approaches to project management software
402
Desktop: Project management software can be implemented as a

program that 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 (see below),
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
only one user accesses it at a time. Desktop applications can be
written to run in a heterogeneous environment of multiple operating
systems, although it's unusual.
Web based: Project management software can be implemented as a

web application, accessed through an intranet, or an extranet using
a web browser. This has all the usual a6antages and disadvantages
of web applications:
Can be accessed from any type of computer without installing

software on user's computer
Ease of access control
Naturally multi-user
Only one software version and installation to maintain
Centralised data repository
Typically slower to respond than desktop applications
Project information not available when the user (or server) is offline
Some solutions allow the user to go offline with a copy of the data
4.
Personal: A personal project management application is one used at home,

typically to manage lifestyle or home projects. There is considerable
overlap with single user systems, although personal project management
software typically involves simpler interfaces.
5.
Single user: A single-user system is programmed with the assumption

that only one person will ever need to edit the project plan at once. 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.
6.
Collaborative: A collaborative system is deSigned to support multiple

users modifying different sections of the Ilan 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, some software tools using client-server architecture 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. Some tools allow team
members to check out their schedules (and others' as read only) to work
on them while not on the network. When reconnecting to the database, all
changes are synchronised with the other schedules.
Notes
403
Notes
7.
Integrated: An integrated system combines project management or

project planning with many other aspects of company life. For example,
projects can 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 Source Forge integrate project management software
with source control (CVS) software and bug-tracking software, so that
each piece of information can be integrated into the same system.
Criticisms of project management software

The following may apply in general or to specific products, or to some
specific functions within products.
404
May not be derived from a sound project management method. For

example, displaying the Gantt chart view by default encourages users
to focus on timed task scheduling too early, rather than identifying
objectives, deliverables and the imposed logical progress of events (dig
the trench first to put in the drain pipe).
May be inconsistent with the type of project management method. For

example, traditional (e.g., Waterfall) vs. agile (e.g., Scrum).
Focuses primarily on the planning phase and does not offer enough
functionality for project tracking, control and in particular plan adjustment.
There may be excessive dependency on the first paper printout of a project
plan, which is simply a snapshot at one moment in time. The plan is
dynamic as the project progresses the plan must change to accommodate
tasks that are completed early, late, re-sequenced, etc. 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
leveling 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. For instance, managing the
ongoing marketing for an already-released product is not a "project"
in the traditional sense of the term, it does not involve management of
discrete resources working on something with a discrete beginning/end.
Groupware applications now add "project management" features that
directly support this type of workflow-oriented project management.
Classically trained Project Managers may argue whether this is "sound
project management". However, the end-users of such tools will refer to it
as such, and the de-facto definition of the term Project Management may
change.
When there are multiple larger projects, project management software can
be very useful. Nevertheless, one should probably not use management
software if only a single small project is involved, as management
software incurs a larger time-overhead than is worthwhile.
Notes
activity Activity 4
List at least six activities that should be taken care of by any project
management software.
15.7 PROJECT PORTFOLIO MANAGEMENT
Project Portfolio Management (PPM) is a term used by project managers
and Project Management (PM) organisations to describe methods for analysing
and collectively managing a group of current or proposed projects based on
numerous key characteristics. The fundamental objective of the PPM process is
to determine the optimal mix and sequencing of proposed projects to best achieve
the organisation's overall goals typically expressed in terms of hard economic
measures, business strategy goals, or technical strategy goals while honoring
constraints imposed by management or external real world factors. Typical
attributes of projects being analysed in a PPM process include each project's
total expected cost, consumption of scarce resources (human or otherwise)
expected timeline and schedule of investment, expected nature, magnitude and
timing of benefits to be realised, and relationship or inter-dependencies with
other projects in the portfolio.
The key challenge for implementing an effective PPM process is typically
securing the mandate to do so. Many organisations are culturally inured to an
informal method of making project investment decisions, which can be compared
to political processes observable in the US legislature. However this approach to
make project investment decisions has led many organisations to unsatisfactory
results, and created demand for a more methodical and transparent decisionmaking process. That demand has in turn created a commercial marketplace for
tools and systems which facilitate such a process.
405
Notes
Some commercial vendors of PPM software emphasise their products'

ability to treat projects as part of an overall investment portfolio. PPM
advocates see it as a shift away from one-off, ad hoc approaches to project
investment decision-making.' Most PPM tools and methods attempt to
establish a set of values, techniques and technologies that enable visibility,
standardisation, measurement and process improvement. PPM tools attempt to
enable organisations to manage the continuous flow of projects from concept to
completion.
Treating a set of projects as a portfolio would be, in most cases, an
improvement on the ad hoc, one-off analysis of individual project proposals.
The relationship between PPM techniques and existing investment analysis
methods is a matter of debate. While many are represented as "rigorous" and
"quantitative", few PPM tools attempt to incorporate established financial
portfolio optimization methods like modern portfolio theory or Applied
Information Economics, which have been applied to project portfolios, including
even non-financial issues

Fill in the blanks.
1.
is a term .used to describe methods for analyzing and

collectively managing a group of current or proposed projects based
on numerous key characteristics.
15.8 PROJECT WORKFORCE MANAGEMENT

Project workforce management is the practice of combining the
coordination of all logistic elements of a project through a single software
application (or workflow engine). This includes planning and tracking of
schedules and mileposts, cost and revenue, resource allocation, as well as overall
management of these project elements. Efficiency is improved by eliminating
manual processes like spreadsheet tracking to monitor project progress. It also
allows for at-a-glance status updates and ideally integrates with existing legacy
applications in order to unify ongoing projects, Enterprise Resource Planning
(ERP) and broader organisational goals.
By coordinating these various components of project management,
workforce management and financials through a single solution, the process of
configuring and changing project and workforce details is simplified.
Project Workforce Management vs. Traditional Management
There are three main differences between Project Workforce Management
and traditional project management and workforce management disciplines and
solutions:
406
Workflow driven: All project and workforce processes are designed,

controlled and audited using a built-in graphical workflow engine
Organisation and work breakdown structures: Project Workforce

Management provides organisation and work breakdown structures to
create, manage and report on functional and approval hierarchies, and to
track information at any level of detail
Connected Project, workforce and financial processes: Unlike

traditional disconnected project, workforce and billing management
systems that are solely focused on tracking IT projects, internal workforce
costs or billable projects. Project Workforce Management is designed to
unify the coordination of all project and workforce processes, whether
internal, shared (IT) or billable.
Notes

Fill in the blanks.
1.

elements of a project through a single
coordination of all
software application.
15.9 SUBCONTRACTS AND COLLABORATION IN

PROJECTS
Subcontracting is a great way to extend the services or products that are
offered. We can use it to ease our production demar?d by delegating certain
portions of a project that require a lesser skill set or an extended or different skill
set than ours. We must remember that when subcontracting, we are liable for all
aspects of the subcontractors work, including quality, cost and timeliness. This
basically puts us in the "client" position with the subcontractor, a relationship
we should strictly maintain throughout the project.
Evaluating a subcontractor
As we progress through our career, we can build a network of trusted
associates from which we can draw for subcontracting. We may have even
contracted with some of them already. However, there is a first time for
everyone. When evaluating a new subcontractor, we need to get references and
follow up on them. We must review samples of their work or products. We
should ask them for an incentive for using them for the first time in the form of a
discounted rate or some other condition. We can pay them as they complete the
work but pay them promptly. As they gain our trust and loyalty, we can loosen
the reins a bit.
Specify Tasks for Price Quote
There are several guidelines for getting a quote from a subcontractor. You
should always provide a written specification for the work they are bidding
on and that you will be marking up. If it requires their input to spec out, have
them give you portions to include in your documents, but always be the keeper
407
Notes
of the specifications, as you will be the one to make sure the work fulfills your
obligation to your client. Ask for a price that allows you to make a profit without
driving the price too high or beyond what the market will bear for your client.
This is often referred to as a preferred customer rate or wholesale rate.
Managing Subcontractors
The following is a list of suggestions for managing subcontractors. These
depend on your relationship with your subcontractor, and many are understood
amongst experienced contractors.
Always maintain the client-subcontractor relationship for the duration of

the project.
This relationship may be reversed on other projects; you may be the

subcontractor to your associate on another project. Know your role and
play it.
Have a written agreement with first-time subcontractors and, for

larger projects, with all subcontractors. Boilerplate terms that include
your policies on expenses, client and subcontractor contact protocol,
production schedules and payment terms can reduce the time needed to
draft agreements.
Never let the subcontractor deal directly with your client without your
approval. These protocols should be specified in your subcontractor
agreement.
The client's perception of you and your subcontractors should be that of

one entity to avoid confusing the client.
Be the subcontractorl's advocate helps them when possible and be involved

with their process to make sure the production is on course.
Payment Terms
Terms of payment should always be agreed upon prior to any project
work. Smaller projects may only require an invoice from the subcontractor
larger projects may warrant full agreements with task completion and payment
schedules. Whatever method you deem appropriate, the most important item is
that a consensus on the agreement exist prior to starting any work. There should
be no question of intent or any other potential misunderstandings. Typical
models for payment terms with subcontractors are shown here.
A great deal of value can be gained in trading services with subcontractors
on projects, loyalty and trust among the most valuable. Trading services and
products usually applies to smaller tasks or portions of a project that would
not justify the work to establish a formal agreement, and are often collected
as payback for a favor from other projects. When proposing projects that rely
on this form of subcontracting, always have a backup plan, and if possible,
get a commitment for the trade. Never rely on large portions of a project to be
completed in trade with a subcontractor. It is better to exchange the money and
avoid any issues with the IRS or worse yet, potentially ruining a relationship
with a long-time associate due to informal agreements run amok.
408
Notes

Fill in the blanks.
1.
A great deal of value can be gained in

projects.
with subcontractors on
is a great way to extend the services or products that arc

offered.
ActivitY
Activity 5
List at least eight criteria that you would look at while selecting a subcontractor.
Summary
For any project to be successful, we can follow the past practices which
have resulted in successful completion of projects. The skills sets for this
are Organisational Practices, Team Practices and Individual Practices.
In projects we need to look at cultural aspects as human races come with

different cultural background. The way of doing things in one culture may
not be the way in other culture. What is good, in one culture may be bad
in other culture. Sometime the activities are all the same in two different
cultures, but two different meanings, two different interpretations.
Some cultures tend to emphasise individual performance, while others

evaluate success based on team performance. Some cultures invite very
direct speech, while others tend to invite a reading between the lines.
Some cultures follow a very formal chain of command in terms of project
communications, while other cultures promqte a more horizontal flow
of information. As a Project Manager, our project will work within a
particular cultural environment, and will necessarily thus reflect that.
The areas in which differing cultures will play a large part in project
management are small vs. large power distance, uncertainty avoidance,
long vs. short-term orientation, individualism vs. collectivism, language;
culture, trust etc.
Disputes are common in global projects and resolving them can be

difficult, especially if the decision-maker is nbt sitting at the negotiating
table. When a project conflict occurs between two parties, separated by
distance and culture, resolving that conflict is' a challenge that can often
end up in arbitration or the courts. The reasons why this breakdown
occurs are lack of authority to make concessions, accepting the status quo
of relationships with the other side and failure to shift negotiations from
positions to issues.
409
Notes
It is not enough just to identify these challenges. Some of the steps that can
be taken to address these are: assigning the role of process monitor, to ask
the other side for clarification at several points in the discussion, to bring
an additional person into the session, one with fluent language skills, to
request that the decision-maker is present at the time of discussion, look
towards to improve working relationships.
Cross-cultural communication tries to bring together such relatively

unrelated areas as cultural anthropology and established areas of
communication. Its core is to establish and understand how people from
different cultures communicate with each other. Its charge is to also
produce some guidelines with which people from different cultures can
better communicate with each other.
Project Portfolio Management process has an objective to determine

the optimal mix and sequencing of proposed projects to best achieve
the organisation's overall goals typically expressed in terms of hard
economic measures, business strategy goals, or technical strategy goals
while honoring constraints imposed by management or external realworld factors.
Project workforce management includes planning and tracking of

schedules and mileposts, cost and revenue, resource allocation, as well as
overall management of these project elements.
7 4Keywords
410
Cross-cultural communication: A field of study that looks at how people

from differing cultural backgrounds communicate, in similar and different
ways among themselves, and how they endeavour to communicate across
cultures.
Project management software: A term covering many types of software,

including scheduling, cost control and budget management, resource
allocation, collaboration software, communication, quality management
and documentation or administration systems, which are used to deal with
the complexity of large projects.
Project portfolio management: A term used by project managers and

project management organisations to describe methods for analysing and
collectively managing a group of current or proposed projects based on
numerous key characteristics.
Project workforce management: The practice of combining the

coordination of all logistic elements of a project through a single software
application.
nr Self-Assessment Questions
1.
Explain the best practices that can be used in projects for ensuring success.
2.
What are the different cross-cultural issues in projects? How do they

affect the success of projects?
3.
How can the different cross-cultural issues in projects be resolved?
4.
What are the challenges in international project disputes'? What are

reasons for the same?
5.
What are ways of resolving international project disputes? Explain with

suitable examples.
6.
What is cross-cultural communication? Give problems arising in crosscultural communication.
7.
What are the attributes of project management software? Explain with

suitable examples.
8.
What are the activities that should be covered by project management

software?
9.
What is the importance of project management software? Explain its

advantages and disadvantages.
Notes
10. What is project portfolio management? Explain the concept and

importance of the same.
11. What is project workforce management? What are the critical factors in
workforce management?
12. What is the importance of subcontracts and collaboration in projects?
How are the subcontractors selected and managed?

1.
False
2.
True

Fill in the blanks.
1.
Project portfolio management is a term used to describe methods for

analysing and collectively managing a group of current or proposed
projects based on numerous key characteristics.
411
Notes

Fill in the blanks.
1.

coordination of all logistics elements of a project through a single software
application.

Fill in the blanks.
1.
A great deal of value can be gained in trading services with subcontractors

on projects.
2.
Subcontracting is a great way to extend the services or products that are

offered.
Suggested Reading
1.
'41)2

McGraw-Hill.

SCDL Project Management Text Book

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

SCDL Project Management Text Book

Uploaded by

Copyright:

Available Formats

PROJECT MANAGEMENT

(FOR PRIVATE CIRCULATION ONLY)

COURSE DESIGN AND REVIEW COMMITTEE

Prof. Ashok Chaudhari

Prof. Ranjan Joshi

Prof. D.H. Joshi

Prof. Manisha Ketkar

Prof. Sudhir Deshpande

Prof. Madhup Gandhi

Prof. Safia Farooqui

Prof. Rajiv Shirke

Prof. Viraj Atre

Ms. Pieu Biswas

Published by Symbiosis Centre for Distance Learning (SCDL), Pune

Copyright 2013 Symbiosis Open Education Society

ABOUT THE AUTHOR

Project Management Process

2.1 Project Management An Introduction

Project Financing and Evaluation

6.1 Project Life Cycle

Networks for Project Management

7.1 Project Scheduling

Resource Levelling and Project Crashing

8.1 Project Resources

Project Implementation and Monitoring

9.1 Project Management Process

13.1 Understanding Project Quality Management

Introduction to Proj ects

1.3 Types of Projects

Explain the concept and meaning of project

Describe the characteristics of project

Assess the historical development of projects

Explain the types of projects

Discuss the concept of project management

Project objectives: The definition should clearly outline the major

Deliverables (these could be stage wise): They can be different at

Milestones or important points in the project life cycle: Completion of

Technical specifications and requirements: Detailed specifications of

Customer reviews: The team should clearly define the process of

Land development and complete roads

Complete factory shade measuring 2000 sq. metre

Utilities building measuring 500 sq. metre

Stores and logistics building measuring 1000 sq. metre

Security complex measuring 200 sq. metre

Completion of land development and internal roads

Completion of factory shade

Completion of utilities and stores

Completion of security complex

Land development within a level difference of 50 cm

Civil structures should be of fabricated steel

Flooring should be of Tremix grade 250

Roads should be made of bitumen and capable of taking loads

Limits and exclusions:

Buildings should conform to earthquake resistance level of 4 g.

Landscaping should be part of the development work.

Establishing the Priorities for Project

Define individual cost, time and specs for each activity.

Define the relation of each activity with the rest.

Assign the responsibility of each activity to various functions in the

Assign responsible person for each activity.

Set up monitoring mechanism.

Integrate each activity with the project structure.

Set up priorities for each activity.

utilised to reschedule certain activities for resource optimisation and balancing.