ENG211

ENGINEERING PROJECT
MANAGEMENT

1
What is Engineering?
Engineering is the profession in which a
knowledge of the mathematical and
natural sciences, gained by study,
experience, and practice, is applied with
judgment, to develop ways to utilize,
economically, the materials and forces of
nature for the benefit of mankind

2
 Engineering professions
• Agricultural Engineering • Environmental Engineering
• Architectural Engineering • Fire Protection Engineering
• Bioengineering/Biomedical • Industrial Engineering
Engineering • Manufacturing Engineering
• Ceramic Engineering • Mechanic Engineering
• Chemical Engineering • Metallurgy and Materials
• Civil Engineering Engineering
• Computer Engineering • Mineral and Mining Engineering
• Communications Engineering • Nuclear Engineering
• Electrical Engineering • Ocean Engineering
• Electronics Engineering • Telecommunication Engineering
Transportation Engineering

3
What is a Project?
A temporary endeavor undertaken to create a unique
product or service (PMBOK defn)
OR
A project is a planned undertaking of a series of related
activities for achieving a specific business objective.
Characteristics of Projects
 Temporary - every project has a defined beginning
and an end.
 Uniqueness – it may have been undertaken before but
the product or service is different in some
distinguishing way from all other products and
services. For example, it may be owned by different
people, have a unique design, unique location, unique
4
contractors, different time frame of creating it etc.
 Resources – people, finance (contained) in budgets,
information, materials, ideas, time etc.
 Customer or sponsor - Most projects have many
interested parties or stakeholders, but someone must
take the primary role of sponsorship.
 Uncertainty – Because every project is unique, it is
sometimes difficult to estimate how long it will take to
complete, or determine how much it will cost. External
factors also cause uncertainty e.g. supplier going out
of business, project team member falling sick etc.
 Progressive elaboration - Projects are often defined
broadly when they begin, and as time passes, the
specific details of the project become clearer.

5
 Schedules – plans for events over time for
resources and contingencies.
 Change – there is no practice or rehearsal and once
the project is completed, the team will ideally move
on to the next project.
 Quality – measured in terms of customer
satisfaction and the organization’s image.
 Objectives – projects have two sets objectives: the
one relating to accomplishing customer
requirements of scope (the deliverables), quantity,
quality and cost; and other relating to the
achievement of the organization’s objectives (the
business case), profitability, prestige etc

6
Examples of categories of projects:
 Developing or acquiring a new or modified information
system.
 Construction projects – These are usually implemented
on site sometimes far from the contractor’s office.
 Manufacturing projects
 Management projects – E.g. relocation from one office
to another.
 Running a campaign for a political office
 Marketing projects
 Research projects – Academic
7
Project Triple Constraint
Every project is constrained in different
ways by variables such as scope, time,
and cost goals. These limitations are
sometimes referred to in project
management as the triple constraint.
To create a successful project, a project
manager must consider scope, time, and
cost and balance these three often-
competing goals. He or she must
consider the following:

Scope: What work will be done as part of the project? What unique product,
service, or result does the customer or sponsor expect from the project? How will
the scope be verified?
Time: How long should it take to complete the project? What is the project’s
schedule? How will the team track actual schedule performance? Who can approve
changes to the schedule?
Cost: What should it cost to complete the project? What is the project’s budget?
8
How will costs be tracked? Who can authorize changes to the budget?
 Managing the triple constraint involves making trade-offs between scope,
time, and cost goals for a project. For example, you might need to increase
the budget for a project to meet scope and time goals. Alternatively, you
might have to reduce the scope of a project to meet time and cost goals.
Experienced project managers know that you must decide which aspect of
the triple constraint is most important. If time is most important, you must
often change the initial scope and/or cost goals to meet the schedule. If
scope goals are most important, you may need to adjust time and/or cost
goals.
 Although the triple constraint describes how the basic elements of a project
scope, time, and cost interrelate, other elements can also play significant
roles. Quality is often a key factor in projects, as is customer or sponsor
satisfaction. Some people, in fact, refer to the quadruple constraint of
project management, which includes quality as well as scope, time, and
cost. Others believe that quality considerations, including customer
satisfaction, must be inherent in setting the scope, time, and cost goals of a
project. A project team may meet scope, time, and cost goals but fail to
meet quality standards or satisfy their sponsor, if they have not adequately
addressed these concerns. The project manager should be communicating
with the sponsor throughout the project to make sure the project meets his
or her expectations. 9
 In management literature, this
equilateral triangle is also referred as
the “Quality triangle” of the project.

10
 What is Management?
• The word “Management” originates from Old
French ménagement “the art of conducting,
directing”, and from Latin manu agere “to lead by
the hand”.
• Management characterizes the process of leading
and directing all or part of an organization, often
a business, through the deployment and
manipulation of resources (human, financial,
material, intellectual or intangible).

11
What is Engineering Management?
• Engineering management is a specialized form of
management concerned with the application in
engineering, as a result of the unique
personalities and technical nature of engineering.
• Engineering management refers to the functional
management of technical professionals. Example
areas of engineering are product development,
manufacturing, construction, design engineering,
industrial engineering, technology, production, or
any other field that employs personnel who
perform an engineering function.

12
What is Project Management?
Is the application of knowledge, skills, tools and techniques to PJ
activities to meet PJ requirements (PMBOK, 2000).
PJ mgt can also be describe as the planning, organizing,
directing and controlling of assigned resources in order to
accomplish a given objective within the constraints of time, cost
and performance.
PJ mgt is accomplished through the use of processes such as
initiating, planning, executing, controlling and closing.
The PJ team manages the work of the PJ; and work typically
involves managing:
 competing demands for scope, time, cost, risk and quality.
 Stakeholders with differing needs and expectations.
 identified requirements.
The more you know about your project, the better you are able to13
• Successful project management is characterised
by:
• Good planning
• Minimised or clearly defined scope
• User involvement
• Strong management or executive support
• Clear business objectives
• Agile process
• Project management expertise
• Skilled resources
• Emotional maturity
• Tools and infrastructure

14
PROJECT STAKEHOLDERS
 Project mgt involves a number of people/ stakeholders.
 Stakeholders are individuals or organizations that are
actively involved in the project, or whose interests may be
directly or indirectly affected as a result of PJ execution or
PJ completion; they may also exert influence over the PJ
and its results.
 Stakeholders must be agreed on so that each one knows
his/her role; and decision making is defined. Note that these
roles may be known by other names or be undertaken by
more than one person or roles may be combined and
allocated to a single person, depending on the organizational
context and the size of the project.

15
NOTE:
 Stakeholders identification is a continuous process
and can be challenging.
 It is important to identify stakeholders with positive
or negative expectations in order to deal with them
appropriately – be professional at all times.
 Identify key decision makers (with influence)
among stakeholders; in some cases they may not
on top of organization chart.

16
Project Sponsor
•Owner of the PJ and has necessary power to make major decisions
• Is accountable for the project success or failure in meeting its
business objectives.
•Champions the project at initial stage for a buy-in at top mgt.
•Should be holding a senior position in the organization
Functions:
•Ensures sufficient funding and resource availability for the project.
• Responsible for the motivation and visibility.
•Provides justification of the project to senior management
•Defines project objectives and time, cost and quality performance
measures
17
Project Manager (PM)

 Is one responsible for the day-to-day management of

the project; and for the achievement of project
objectives by balancing project constraints; guide
development of PJ plans and its implementation.
 The PJ mgr must be good at managing; people,
budget and processes.
Functions of a PM
 Planning: The PM estimates resource requirements
and formulates a plan to deliver the target system.
Each task required to complete the project must be
planned. Some of the planning issues include: how
much time will be required? How many people will be
18
needed? How much will the task cost? Etc
 Organizing: Members of the project team should
understand their own individual roles and
responsibilities as well as their reporting relationship
to the project manager.
 Scheduling: This should be developed with an
understanding of the required tasks, task duration,
personnel assignments and inter-task dependencies.
 Directing: Once the project has begun, the PM directs the
team’s activities. Every PM must demonstrate people
management, skills to coordinate, delegate, motivate,
advise, appraise and reward team members.
 Controlling: The PM must monitor and report progress
against goals, schedule, and costs and make appropriate
adjustments when necessary.
19
• Scoping: Scope defines the boundary of the project. If you
cannot scope project expectations and constraints, you
can’t plan activities, estimate costs, or manage
expectations.
• Closing: Good PMs always assess successes and failures
at the conclusion of a project. They learn from their
mistakes and plan for continuous improvement of the
systems development process.
Note: All the above functions are dependent on inter-personal
communication among project manager, the team, and other
managers.

20
Project Owner
The individual who will eventually assume operational
responsibility/ownership for the end deliverable of the project.
The individual therefore needs to be involved throughout the
project lifecycle, until final signoff.
Functions:
 Effectively communicate business rules and define detailed
requirements for new the system to be developed.
 Review the design prototypes to ensure that they support
business functions.
 Conducts and witness acceptance tests to ensure that the
system meets the system requirements.
 Recommend changes and enhancement into the system
 Usually Subject Matter Expert (SME), different from sponsor.
21
The Power/Interest Matrix
Classifies stakeholders in relation to the power they hold and
their interests.
Can be used to indicate where political effort should be made
before instigating change

Interest

Low High

A B
Low
Update regularly Keep Informed
Power
C D
High
Keep satisfied Always consult
22
 Stakeholders in groups A & B are the easiest to deal
with.
 Those in group A need only Update Regularly
 Those in group B should be kept informed as they may
be able to influence more powerful stakeholders.
 Stakeholders in group C are important because they
are powerful. But low interest means their reaction
is predictable and expectations can be managed.
Generally expected to be passive, but may move
into group D on an issue of particular interest.
 Stakeholders in group D need most management
attention because they are powerful and reaction is
difficult to predict. May need ‘trial’ new strategies
with them. Their cooperation is of key importance

23
Conclusion
In many situations, the project is organized by the main roles
of project sponsor, project manager and project user.
However, in complex or larger projects other organizational
bodies may be encountered. A steering committee brings
together a variety of interested people such as users,
functional staff(e.g. finance, purchasing) and project
managers in order that all stakeholder views are taken into
consideration.

24
What is a Macro Project?
A project within an organization that is established to deliver a
specific objective; sub-divided into smaller projects or
manageable areas of responsibility called Sub-Projects, which
in turn can be sub-divided into Major Tasks.

Macro Project Manager

The individual selected with the accountability to lead and direct
a Macro Project, including the co-ordination of the Sub-Project
Managers, in a manner that will ensure that the project goals and
objectives are achieved within the overall scope.

Sub-Project Manager
The individual appointed with the responsibility for a Sub-Project
within a Macro Project.

25
Projects vs. Operational Work
 Organizations perform work to achieve a set of objectives. In
many organizations, the work performed can be categorized
as either project or operations work. These two types of work
share a number of characteristics as follows:
 Performed by individuals
 Limited by constraints, including resource constraints
 Planned, executed, monitored and controlled
 Performed to achieve organizational objectives or strategic
plans
 Projects and operations differ in the following ways:
 Operations are ongoing and produce repetitive products,
services, or results while projects are temporary and
unique.
 Project organisational structures are horizontal while
operational structures are vertical.
26
Project Management Knowledge Areas
Project management knowledge areas describe the key
competencies that project managers must develop.

27
The figure above shows the nine knowledge areas
of project management.
The four core knowledge areas of project
management include project scope, time, cost, and
quality management. These are core knowledge
areas because they lead to specific project
objectives.
 Project scope management involves defining
and managing all the work required to complete
the project successfully (100%).
 Project time management includes estimating
how long it will take to complete the work,
developing an acceptable project schedule, and
ensuring timely completion of the project. 28
 Project cost management consists of preparing
and managing the budget for the project.
 Project quality management ensures that the
project will satisfy the stated or implied needs for
which it was undertaken.
 The four facilitating knowledge areas of project
management are human resource,
communications, risk, and procurement
management. These are called facilitating
knowledge areas because they are the processes
through which the project objectives are achieved.
 Project human resource management is
concerned with making effective use of the people
involved with the project.
29
 Project communications management involves
generating, collecting, disseminating, and storing
project information.
 Project risk management includes identifying,
analyzing, and responding to risks related to the
project.
 Project procurement management involves
acquiring or procuring goods and services for a
project from outside the performing organization.

30
 Project integration management involves coordinating all
of the other project management knowledge areas
throughout a project’s life cycle.
 This integration ensures that all the elements of a project
come together at the right times to complete a project
successfully.
 Ensures that project processes are properly coordinated

Note: Project managers must have knowledge and skills in all

nine of these areas.

31
 Why Engineering projects fail
Engineering projects are considered to have concluded
successfully when;
 they are completed on time
 within budget
 and with the desired functionality.

This consists of two dimensions:

Product Scope: What is the product supposed to do?

Performance: How well does the provided functionality work?

•Both product scope and performance should be defined at the

start of the project and high quality is achieved when the project
delivers as specified.

32
•These three aspects of project success are not
independent from each other.
•On the contrary, typically improving one criteria
implies delivering short on one of the other criteria
- e.g. if one wants to execute the same project in
less time, one needs more resources (higher
budget) or one has to lower the specifications of
the deliverable.

•Recently, it has been argued that these three

success criteria are only a small part of a bigger
picture. Delivering to specification, does not
guarantee that the project actually produces value
to the stakeholders.
33
•A more general definition of a
successful project is one that
delivers business value.

•However, delivering value is not

only a matter of delivering the
product to specification, but also
delivering the right specification,
i.e. delivering the right product. 34
Some of the reasons for project failure include:

 Unclear requirements, targets, or scope.

 Shortcuts or sloppy work.
 Lack of co-ordination of resources and activities.
 Lack of communication with interested parties, leading to
products/services being delivered which are not what the
customer wanted.
 Poor estimation of duration and costs, leading to projects
taking more time and costing more money than expected.
 Insufficient measurable
 Inadequate planning of resources, activities, and scheduling
 Lack of control over progress so that projects do not reveal
their exact status until too late.
35
 Changes in culture. For example, some countries close
businesses for several hours every afternoon to have siestas.
Others countries may have different religious or secular
holidays at certain times of the year when not much work will
be done.

 Inadequate reaction to early signs of problems

 Insufficient testing or test procedures
 Failure to recognize activity dependencies
 Personality conflicts and employee turnover

36
Then what do we need to do???

For genuine commitment to the project, all parties must be

clear about why the project is needed, what it is intended to
achieve, how the outcome is to be achieved, and what their
responsibilities are in that achievement.
Companies/organizations must adopt the principles of good
project management to avoid the problems identified above
and so helps to achieve successful projects.
A good project management method will guide the project
through a controlled, well-managed, visible set of activities to
achieve the desired results.

37
 Introduction to Project
Management

1
 IMPORTANCE OF
MANAGEMENT

Some organizations have begun to ask their

contractors to provide only project managers
who have been certified as professionals by
The Project Management Institute.

2
 WHAT IS A PROJECT?

• “A project is a problem scheduled for

solution.” This definition forces us to
recognize that projects are aimed at solving
problems and that failure to define the
problem properly is what sometimes gets us
into trouble.

3
 What is a problem?
• A desired objective is not a problem by itself. The
key to a problem is that there is an obstacle that
prevents you from closing the gap.
• A problem is a gap(achieving your objective)
between where you are and where you want
to be, with an obstacle that prevents easy
movement to close the gap.
• Problem solving consists of finding ways of
overcoming or getting around obstacles.
4
 WHAT IS PROJECT MANAGEMENT?

• Project management is the planning, scheduling,

and controlling of project activities to meet
project objectives.
• The major objectives that must be met include
performance, cost, and time goals, while at the
same time you control or maintain the scope of the
project at the correct level.

5
 The scope of project
• The scope of a project should remain constant
throughout the life of the job.
• Unforeseen problems or an inadequately defined
problem is the most common reason for scope
changes that something was forgotten.
• In most cases the magnitude (scope) of the work
increases, as a result of overlooked details.

Continue to see more…

6
 …The scope of project
• Scope generally increases.
The only time project scope decreases is when the
budget is cut, and some of the originally planned
work is put on hold.
• The problem with scope changes is that they tend
to be small and incremental, if a number of them
occur, the project budget or schedule may suffer.
This is a fairly common cause of project failures.

7
 Project Manager & The Scope
• A project manager has a responsibility to
keep stakeholders informed about the impact
of scope changes on the project, protecting
them from surprises at the end of the job and
protecting the him/herself (project manager)
from being evaluated on original targets
rather than on revised ones.

8
 The Four Project Objectives are…
• Performance
• scope
• Cost
• Time

Continue…There are more!

9
 Performance, scope, Cost& Time
• Performance: The quality of the work being
done.
• Scope: The magnitude of the work to be
performed.
• Cost: The cost of project work, directly
related to the human and physical resources
applied.
• Time: The schedule that must be met.

10
The relation between the four project
objectives:

Cost=f(P,T,S)
To understand this eq. go on…

11
 Continue…What did the equation say?
• cost is a function ( f ) of performance (P), time (T), and
scope (S). As P and S increase, cost generally
increases.
• The relationship between time and cost, however, is
not linear. As a rule, cost increases as the time to do
the project decreases below a certain optimum time.
• If the duration is shortened, it is often necessary to
pay premium labor rates as a consequence. Further,
worker errors often increase, resulting in costs for
corrections, and productivity often declines. Move…

12
 Comment:

• Enough people are thrown at a project, it can be

completed in whatever time is desired. This is simply
not true. but the idea is the cause of many project
fiascos.

13
 THE HUMAN SIDE OF PROJECT MANAGEMENT

• Factors(components)affect the success of a project:

• The Right People
• The Right Type of Management

• One of the key ingredients is having the right people on the

job and managing them appropriately.

14
 STEPS IN MANAGING A PROJECT
• Define the problem
• Develop solution options
• Plan the project
• Execute the plan
• Monitor and control progress
• Close the project.
To see more about them the…↓

15
 Define the problem
• What client need is being satisfied by the
project?
• It helps to visualize the desired end result.

16
 Develop solution options
• How many different ways might you go about
solving the problem?
• Brainstorm solution alternatives (you can do
this alone or as a group).
• Is it more or less costly than other suitable
choices?

17
 Plan the project
• Planning is answering questions—what must
be done, by whom, for how much, how,
when, and so on.

18
 Execute the plan
• Once the plan is drafted, it must be
implemented. Interestingly, people
sometimes go to great effort to put together
a plan, then fail to follow it. If a plan is not
followed, there is not much point in planning,
is there?

19
 Monitor and control progress
• Unless progress is monitored, you cannot be
sure you will succeed. It would be like using a
roadmap to reach a destination.
• Control: What are you expected to do as a manager?
If a deviation from the plan is discovered, you
must ask what must be done to get back on
track, or—if that seems impossible—how the
plan should be modified to reflect new
realities.

20
 Strategy vs. Tactics
• Strategy: The approach being used to do
the project.
• Tactics: The steps taken to implement
the strategy or approach chosen.

21
 Close the project.
• The project is finished, but there is a final
step that should be taken.
• The point is to learn something from what
you just did.
• What was done well? What should be
improved? What else did we learn? We can
always improve on what we have done.

22
 The Project Management System
• In order to manage projects successfully, it is
necessary to have a system. A full project
management system consists of seven
components.
• If any one of the seven components is not in
place or does not function satisfactorily, then
you will have some difficulty managing
projects.

23
 The seven components are…
• Human Factors.
• Method.
• Culture.
• Organization.
• Planning.
• Information.
• Control. Continue…

24
 Human Factors
A project manager must be able to deal effectively
with all of the parts of this subsystem in order to
be successful.
• Leadership.
• Negotiation.
• Team building.
• Motivation.
• Communication.
• Decision making.

25
 Continue..The seven components

• Methods refer to the tools of your trade.

• The culture of an organization affects
everything you do.
• Organization: Every organization must deal with
the assignment and definition of each person’s
authority, responsibility, and accountability.
• Planning: Every organization needs a good
methodology for planning projects if it is to be
successful.

26
Continue… Information & Control
• Good historical data are needed for planning
projects.
• The control subsystem is supported by the
planning and information subsystems.

27
 As a Summary… Key Points to Remember

• A project is a problem scheduled for solution.

• If the problem is not defined correctly, you may
find the right solution to the wrong problem!
• Focus on desired outcomes. How will you know
when you achieve them?
• Try to learn from every project by doing a final
audit.
• If you have no plan, you have no control.

28
 Continue…Key Points to Remember
• The people who must execute the plan should
participate in preparing it.
• Keep all project documentation in a project
notebook, but back it up with an electronic
database if possible.
• Require signatures for changes in scope in order to
alert everyone as to the impact of the change on
project costs, deadlines, etc.
• Risk analysis is part of planning. For every risk
identified, develop a contingency plan, when
29
possible.
 Project Characteristics

Despite above diversities, projects share the following common

characteristics.
• Unique in nature.
• Have definite objectives (goals) to achieve.
• Requires set of resources.
• Have a specific time frame for completion with a definite start and
finish.
• Involves risk and uncertainty.
• Requires cross-functional teams and interdisciplinary approach
Project Life Cycle

• Every project, from conception to completion, passes through various

phases of a life
• cycle synonym to life cycle of living beings. There is no universal
consensus on the number of
• phases in a project cycle. An understanding of the life cycle is
important to successful completion
• of the project as it facilitates to understand the logical sequence of
events in the continuum of
• progress from start to finish.
Typical project consists of four phases
1. Conceptualization
2. Planning
3. Execution
4. Termination
Each phase is marked by one or more deliverables such as;
Concept note, Feasibility report, Implementation Plan, HRD plan,
Resource allocation plan, Evaluation report etc.
 Project Initiation

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Project Initiation
• Purpose of initiation phase
• Comparing project options
• Total cost of ownership
• The project charter

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
The Initiation Phase
• Business problem or opportunity defined
• Solution is defined
• Project is formed

• Business case created

• Project team appointed

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
The Business Case
• Problem or opportunity: Detailed description
• Introduction
• Problem/opportunity statement
• Assumptions and Constraints
• Alignment with organizational objectives
• solutions
• Analysis of benefits, costs, and issues for alternative solutions
• Description of the preferred solution
• Main project Requirements
• Potential risks
• Summarized plan for implementation
• Schedule
• Financial analysis

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Financial Considerations
• Can compare projects based on
• Net present value
• Internal Rate of Return (Return on Investment or ROI)
• Payback Analysis

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Net Present Value Analysis
• Considers the time value of money
• Costs for future years must be discounted to the
present time
• Tangible benefits also discounted to the present time
• Must identify an appropriate discount rate
• Take risk into consideration

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
NPV Calculation
Rt
(1 + i)t
• t is the time of the cash flow
• Rt is the cash flow at time t
• i is the interest rate

• Apply the above formula to each annual inflow and

outflow of cash
• Add all terms together to get the NPV

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
 NPV Analysis

If… It means… Then…

the investment would add value to the firm the project may be accepted
NPV > 0

the investment would subtract value from the project should be rejected
NPV < 0 the firm

the investment would neither gain nor lose indifferent in the decision
NPV = 0 value for the firm This project adds no monetary value.
Decision should be based on other criteria,
e.g., strategic positioning or other factors
not explicitly included in the calculation.

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Rate of Return

(Total benefits – Total costs) / Total costs

• Can be used to compare different options

• Organization may have a minimum acceptable rate of
return for projects

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Payback Analysis
• Compares cumulative costs to cumulative benefits
• Easiest to see in graphical format
• Time on horizontal axis, money on vertical

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Payback Analysis

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
The Project Charter

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Purpose of the Project Charter
When signed off, you have approval to proceed to
detailed planning, followed by carrying out your project.

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Organizational Process Assets
• Is there a standard format for project charters?
• Is there a standard process for developing and getting
approval for a project charter?
• What can the PMO do for you?
What does the PMO require of you?
• Are there applicable “lessons learned” available from
other projects?
• If you are inexperienced, is there a mentor available?
• Etc.

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Project Charter – Typical
Contents
• Identification section
• Project purpose or justification
• Measurable project objectives and related success criteria
• High-level requirements
• Assumptions and constraints
• High-level project description and boundaries
• High-level risks
• Summary milestone schedule
• Summary budget
• Stakeholder list
• Approvals

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Identification
• Name of the project—make it meaningful
• Name, title, department of project sponsor
• Name of project manager

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Clear Objective
• SMART
• Specific
• Measurable
• Acceptable
• Realistic
• Time based

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Business Need or Opportunity
A concise statement of how the project’s deliverables will
contribute to organizational objectives

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Scope
• Clearly defines what is in and out of the project

Major Milestones
• Identifiable points in time
• Target dates will be added LATER

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Major Deliverables
• Break down the overall objective into smaller
measurable units

Assumptions
• Things you are not certain of but can proceed if you
behave as if they are true

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Constraints
• Anything that limits your ability to deliver or the range
of acceptable solutions

Preliminary Cost Estimates

• How will the costs be defined and controlled

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Risks
• High-level statement about risks identified so far
• Include the risk of NOT doing the project

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Stakeholder List
• The stakeholders identified so far, including their roles

Approval
• A place for the project sponsor and the project manager
to sign

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
Project Initiation: Summary
• The first phase
• Relationship of project to business objectives is key
• Compare alternatives using weighted matrix
• Financial analysis: NPV, ROI, payback
• Project Charter is the primary output;
• it includes the stakeholder list
• Completion of Project Initiation is the signal that the
project has approval to proceed to the project planning
phase.

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
 Questions?

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 7: Project Initiation
 Key Performance Indicators
set of quantifiable measures that a company or
industry uses to gauge and compare
performance in terms of meeting their strategic
and operational goals

KPIs vary between companies and industries, depending on

their priorities or performance criteria. Also referred to as "key
success indicators (KSI)"
Why Use KPI’s
• Performance effectiveness.
• For the accuracy, actual reflection of the process, efficacy in delivering
the outcome.
• The effects of a change can be monitored reliably, repeatedly and
accurately by KPI.
How to design KPI’s
• KPIs should be clearly linked to the strategy, i.e. the things that matter
the most.
• KPIs have to provide the answers to our most important questions.
• KPIs should be primarily designed to empower employees and
provide them with the relevant information to learn.
Identifying the KPI’s
• Related to strategic aims.
• Identify what makes the project success or failures.
• Controllable and accountable.
• Qualitative and quantitative.
• Long term and short term.
• Consider Stakeholder needs.
• Identify important aspects.
• Establish Company Goals and KPIs.
• Select Performance Indicators and Metrics.
• Set Targets and Track Performance
Types of KPI’s
• Process KPIs - measure the efficiency or productivity of a business process.
Examples - Days to deliver an order.
• Input KPIs - measure assets and resources invested in or used to generate
business results. Examples - Dollars spent on research and development,
Funding for employee training, Quality of raw materials.
• Output KPIs - measure the financial and nonfinancial results of business
activities. Examples – Revenues.
• Leading KPI measure activities that have a significant effect on future
performance.
• Lagging KPI is a type of indicator that reflect the success or failure after an
event has been consumed. Such as most financial KPIs, measure the output
of past activity.
• Outcome KPI - Reflects overall results or impact of the business
activity in terms of generated benefits, as a quantification of
performance. Examples are customer retention, brand awareness.
• Qualitative KPI - A descriptive characteristic, an opinion, a property or
a trait. Examples are employee satisfaction through surveys which
gives a qualitative report.
• Quantitative KPI - A measurable characteristic, resulted by counting,
adding, or averaging numbers. Quantitative data is most common in
measurement and therefore forms the backbone of most KPIs.
Examples are Units per man-hour
Characteristics of a good KPI
• KPI is always connected with the corporate goals.
• A KPI are decided by the management.
• They are the leading indicators of performance desired by the
organization.
• Easy to understand
• Key Success Factors (KSFs) only change if there is a fundamental shift
in business objectives.
• Key Performance Indicators (KPIs) change as objectives are met, or
management focus shifts.
Defining KPIs
KPIs are usually developed following the well-
known S.M.A.R.T. criteria originally developed by George T. Doran
(Management Review, 1981) and popularized by Peter Drucker.
• Specific
• Measurable
• Achievable
• Result-oriented or Relevant
• Time-bound
Examples of engineering project KPIs
1. Project Scope KPIs
• Scope Variance: Measures the difference between planned and actual project
scope. For example, if a construction project was initially scoped to build 50 units
but ends up building 55, the scope variance would reflect that change.
• Change Request Frequency: Tracks the number of times changes to the project
scope are requested. Frequent changes might indicate issues with initial project
planning.
2. Time Management KPIs
• Schedule Variance (SV): Measures the difference between the planned timeline
and the actual progress. For example, if a project is supposed to be 50% complete
by a certain date but is only 40% complete, this KPI highlights the delay.
• On-Time Delivery: The percentage of project milestones met on schedule. For
example, delivering a design phase by the deadline.
3. Cost Management KPIs
• Cost Variance (CV): The difference between the budgeted cost and the
actual cost of the project. For example, if a project was budgeted at $1
million but costs $1.1 million, the cost variance would show a $100,000
overrun.
• Cost Performance Index (CPI): A ratio of earned value to actual costs. For
example, a CPI of 0.9 indicates that for every dollar spent, only 90 cents of
value has been earned, indicating a cost overrun.
4. Quality KPIs
• Defect Density: The number of defects found in deliverables per unit of
work, such as defects per 1,000 lines of code in a software project.
• Compliance to Standards: The percentage of project outputs that meet
predefined quality standards, such as adherence to ISO standards in
manufacturing.
5. Resource Management KPIs
• Resource Utilization Rate: The percentage of available resources
(e.g., labor, machinery) being effectively utilized. For example, a
utilization rate of 85% might be targeted for optimal productivity.
• Staff Turnover Rate: The rate at which project team members leave
the project. A high turnover rate might indicate issues with
management or work conditions.
6. Risk Management KPIs
• Risk Mitigation Success Rate: The percentage of identified risks that
have been successfully mitigated. For example, if 10 risks were
identified and 8 were mitigated, the success rate would be 80%.
• Number of Realized Risks: The number of risks that actually occurred
and their impact on the project. For example, a KPI might track the
number of cost overruns due to unforeseen risks.
7. Stakeholder Satisfaction KPIs
• Stakeholder Satisfaction Score: Collected through surveys, this KPI
measures how satisfied stakeholders are with project progress and
outcomes.
• Communication Effectiveness: Evaluated through feedback, this
measures how well communication is maintained between the
project team and stakeholders.
8. Safety KPIs
• Incident Frequency Rate: The number of safety incidents per 1,000
hours worked. For example, tracking the number of accidents on a
construction site.
• Compliance with Safety Protocols: The percentage of safety audits
passed or safety training completed by the team.
9. Sustainability and Environmental Impact KPIs
• Carbon Footprint: Measures the total carbon emissions generated by
the project, such as CO2 emissions from construction equipment.
• Waste Reduction: The percentage reduction in waste generated
compared to baseline levels, such as reducing waste by 20%
compared to previous projects.
10. Performance and Efficiency KPIs
• Overall Equipment Effectiveness (OEE): Measures how effectively
equipment is being used in production, combining availability,
performance, and quality metrics.
• Throughput Time: The total time taken to complete a process from
start to finish, such as the time to complete a manufacturing cycle.
Conclusion

•These KPIs are essential for monitoring

the success of engineering projects,
ensuring they meet their goals, stay
within budget, and deliver high-quality
results on time.
 Project Charter
What is the Project Charter?

A project charter, project definition, or project statement is a statement of

the scope, objectives, and participants in a project. It provides a preliminary
delineation of roles and responsibilities, outlines the project objectives,
identifies the main stakeholders, and defines the authority of the project
manager. It serves as a reference of authority for the future of the project.
•short (less than 5 pages)
•written in clear and concise language so that
anyone who reads it will have a clear
understanding of the project, regardless of their
technical background.
•Most project charters include a place at the end
of the document for approval sign-off by the
project sponsors
Purpose of the Project Charter
• informs the project manager about what skills will be required on the project team

• can be referenced by the project manager and stakeholders if some of the goals of the project are not met
or they are asked to do something outside the scope of the project.

• Provide an understanding of the project, the reason it is being conducted, and its justification.

• Establish early on in the project the general scope.

• Establish the project manager and his or her authority level. A note of who will review and approve the
project charter must be included.
•
What Should Be in the Project Charter?

At a minimum, good project charters will contain the following sections.

• Background
• Business case
• Goals
• Key Stakeholders
• Deliverables
• Major milestones
• Project Budget
Background
The background should provide a broad overview of the project and answer
the following questions:
•What is the purpose of the project?
•Where did the project originate? Have we conducted similar projects in the
past?
•Who is the project manager and what level of authority does the project
manager have?
Business Case
The Business Case describes why this project was selected over others and
answers the following questions:
•Why was this project selected to move forward (project justification)? What
selection criteria were used? (Project selection techniques are covered in a
later chapter.)
•What problems is this project solving or what opportunities is it creating?
What are the high-level requirements?
Goals
Listing the goals for the project ensures that the stakeholders will not be disappointed when the project is
completed. This section should answer the following questions:
•What are the broad goals of this project?
•How will we know if the project is a success (what are our metrics for success)?
•Are there industry standards that we are trying to meet or benchmarks for performance that we want this
project to attain?

Key Stakeholders
This section describes the key stakeholders and their interest in the project. This doesn’t have to be an
exhaustive list of stakeholders, but should contain a list of people who are interested in the project, as well
as people who will pay for, or benefit from, the project.

Deliverables
A project is said to have deliverables as products or services. They are things such as physical objects,
software code, or events that make up the project and they are written in the form of nouns, for example,
floor, walls, electrical…etc.
Major Milestones

A listing of any hard deadlines for the project should be included.

Milestones can relate to project work (when are major deliverables expected to be
complete?) as well as invoicing and payment deadlines.

Project Budget

The project budget section should provide a summary of the budget for the project and
information about how it was determined. It answers the following questions:
•What is the initial budget for this project?
•How was that budget developed?
•Are the numbers used for budgeting rough estimates based on top-down estimation
techniques, such as analogous or parametric estimating, or are they hard constraints?
•What contingency funds have been allocated?
Project Scheduling
 The classical approach of project management relies heavily on upfront
planning. We first plan everything prior to execution.
 Developing a project schedule can be broken down in following steps:
o Develop a work breakdown structure.
o Identify task relationships.
o Estimate work packages.
o Calculate initial schedule.
o Assign and level resources.
Work Breakdown Structure
 Definition: A work breakdown structure (WBS) is a visual,
hierarchical and deliverable-oriented deconstruction of a project. It is
a helpful diagram for project managers because it allows them to break
down their project scope and visualize all the tasks required to complete
their projects.
 A first step is to break down the work into smaller pieces of work which make it easier to
accurately estimate the required time and resources.

 This is typically achieved by developing the Work Breakdown Structure (WBS) of a project, which
is a tool for breaking down a project into its component parts.

 The work breakdown structure identifies all the tasks/deliverables in a project and can be set up
graphically or as an textual outline.

 Traditionally, a WBS focussed on tasks, more recently there has been a shift towards
deliverables.
Building a WBS helps to:
o Provide a detailed illustration of project scope.
o Monitor progress. The tasks on the WBS become the basis for
monitoring progress, because each is a measurable unit of work.
o Create accurate cost and schedule estimates.
o Build project teams as it provides clear work assignments to the
team members and provides an overview how his or her work fit
into the overall effort.
A WBS breaks all the work into separate tasks of which
two types exist:

• Summary tasks. A summary tasks includes several

subordinate tasks and is not actually executed. Its purpose is
to summarize more detailed tasks, called work packages.
• Work packages. These are the tasks that actually require
execution.
E.g. Creating manual can be the summary tasks which consists
of the work packages writing content, setting layout,
proofreading and printing manual.
WBS typically follows three steps:

 List the major deliverables or high-level tasks.

 Name all the tasks required to produce
deliverables.
 Organize the WBS.
WBS Step One: Start from the top

 A WBS is typically developed in a top-down approach. You can start from the deliverables mentioned
in the statement-of-work and turn them into the major summary tasks.

WBS Step Two: Identify all tasks required to produce deliverables

 The next step is to break down each task into lower-level, more detailed tasks required to produce
the deliverable.

 This is often the most difficult step in the planning process and requires a good understanding of
how to produce the project outcome.

 Give each task (work package and summary task) a name that describes an activity which produces
some specific output. Therefore, the naming of activities typically follow the “verb-noun” format.

 Try to avoid open-ended tasks such as “read literature” as these could go on indefinitely.

 Try to avoid tasks that don’t clearly describe the action which is required, such as e.g. “literature”.
WBS for computerized order-processing system project
 To ensure that the work packages are the correct size, following rules can be applied
as rule of thumb.
o No task should be smaller than 8 labour hours or larger than 80. (These limits
might need adjustment depending on the kind of project and availability of non-
stop working time).
o No task should be longer than the time between two reporting meetings.
o Break work packages down to smaller tasks if:
 It makes the task easier to estimate.
 It makes the task easier to assign.
 It makes the task easier to track.
WBS Step Three: Organize the WBS
 Once all the work packages are identified, rearrange them in the most
appropriate way.
 In this step, one often creates new summary tasks and put work packages in
new/other summary packages.
 Different ways of organizing work packages emphasizes different aspects of a
project.
 Make sure that summary tasks are meaningful as their sole purpose is for
communication or visibility. These summary tasks communicate what your
project is about.
 Also make sure that the work packages underneath the summary task add up to
the summary task. When one has completed all the work packages, the result
automatically be that the summary task is completed.
• In other words, a work breakdown structure serves as your map
through complicated projects.
■Gantt chart and CPM/PERT techniques can be useful.

■Computer software packages available, e.g. QM for Windows,

Microsoft Project.
 Elements of Project Management
Gantt Chart
■ Popular, traditional technique, also known as a bar chart -
developed by Henry Gantt (1914).

■ Direct precursor of CPM/PERT for monitoring work progress.

■ A visual display of project schedule showing activity start

and finish times and where extra time is available.

■ Suitable for projects with few activities and precedence

relationships.

■ Drawback: precedence relationships are not always

discernible which limits chart’s use for smaller projects

15-Dec-24 [Link] Sasidhar

 Gantt Chart
• Visual scheduling tool
• Graphical representation of information
• Show dependencies between tasks,
personnel, and other resources
allocations
• Track progress towards completion

15-Dec-24 [Link] Sasidhar

 Building a Gantt Chart
• List all tasks and milestones from the
project along the vertical axis
• List time frame along the horizontal axis
Activity 1
Activity 2
Milestone

Time Frame: day 1 day 2 day3

15-Dec-24 [Link] Sasidhar

 Building a Gantt Chart
• Activities: Create box the length of each activity time
duration
– E.g., activity one is scheduled from day1-day3

Activity 1
Activity 2

Time Frame: day 1 day 2 day3

15-Dec-24 [Link] Sasidhar

 Building a Gantt Chart
• Dependencies: Show dependencies between
activities with arrows
– E.g., activity 2 cannot start until activity 1 is complete

Activity 1
Activity 2

Time Frame: day 1 day 2 day3…

15-Dec-24 [Link] Sasidhar

 Sequence of Activities of The Project -
House Building
Number Activity Predecessor Duration
1 Design house and obtain -- 3 months
financing
2 Lay foundation 1 2 months

3 Order and receive materials 1 1 month

4 Build house 2,3 3 months

5 Select paint 2, 3 1 month

6 Select carper 5 1 month
7 Finish work 4, 6 1 month
15-Dec-24 [Link] Sasidhar
 Gantt Chart for House Building Project

15-Dec-24 A Gantt [Link]

chart Sasidhar
 Gantt Chart for House Building Project using QM for Windows

15-Dec-24 [Link] Sasidhar

 Gantt chart using Microsoft Project

Video tutorial:
[Link]
 Gantt Charts
 Establish a time-phased network
 Can be used as a tracking tool

Benefits of Gantt charts

1. Easy to create and comprehend
2. Identify the schedule baseline network
3. Allow for updating and control
4. Identify resource needs
 Gantt Charts – Example
Consider the Gantt chart shown below where the time scale is in
minutes and all activities are performed on an early start basis.
How much slack is available in the project?
• Answer: Nil

15-Dec-24 [Link] Sasidhar

 Gantt Charts – Resource Allocation Example
Use the Gantt chart and the activity list to determine when
resource 5 is free.
Activity Resources Activity Resources

A 1 F 1

B 5 G 2

C 4 H 5

D 3 J 3

E 2 K 4

A) between 0 and 15
B) between 15 and 30
C) between 30 and 45
D) between 45 and 60
Answer: ……………
 Gantt Charts – Resource Allocation Example
Use the Gantt chart and the activity list to determine when
resource 2 is free.

Activity Resources Activity Resources

A 1 F 1

B 5 G 2

C 4 H 5

D 3 J 3

E 2 K 2

A) between 0 and 15
B) between 15 and 30
C) between 30 and 45
D) between 45 and 60
Answer: …..
Project Time Management

Abok Tonny 1
 DSRDSC
Project Time Management
Involves processes required to ensure timely completion of a project.
Process Process Objective
Define Activities Identifying specific activities to be performed to produce
project deliverables. An activity or task is an element of
work normally found on the WBS that has an expected
duration, a cost, and resource requirements.
Sequence Activities Identifying relationships among project activities. Every activity
and milestone except the first and the last are connected to at
least one predecessor and one successor.
Estimate Activity Resources Estimating the type & quantities of resources (people, money,
facilities, material, equipment or supplies, information and
technology) to perform identified activities.
Estimate Activity Durations Estimating time required to complete activities based on
identified resources.
Develop Schedule Analyzing activity sequences, durations, resource requirements
and schedule constraints to create project schedule.
Control Schedule Monitoring the status of the project to update the project
progress and managing changes to the schedule baseline.
In practice, these processes overlap.
Abok Tonny 2
When scheduling, the difference between effort time and elapsed time should be considered.
 Activity Sequencing
Typical questions when scheduling activities in a logical way are:
Does a certain activity have to be finished before another start?
Can several activities be done in parallel? Can some overlap?
 Which activity immediately follows this activity?
Which activities control the start and finish?
Types of dependencies:
•Mandatory (Hard logic)- Are contractually required or inherent in the nature of
work being done on the project. E.g. a system can’t be tested before
development.
•Discretionary (Preferred/Soft logic) – Are based on best practices within an
application. Project management team must document their decision to avoid
future issues. E.g. Wiring a house can be done before fixing doors.
•External – Involves relationships between project and non-project activities;
usually outside the control of project team. E.g. Building a house may depend
on approval of architectural plans, NEEMA approvals.
Abok Tonny 3
Types of Relationships Between Activities:
Task Dependence Example Description

A Task A must finish before task B

Finish-to-Start B can start
(FS)
A
Start-to-Start (SS) Task A & B must start at the same
B time, irrespective of when they
finish
Finish-to-Finish A Task A & B must finish at the
(FF) B
same time, irrespective of when
they start

Start-to-Finish A
(SF) B Task B can’t finish until A starts.
(This type of relationship is rarely
Abok Tonny used). Example: A new payroll system must4be
running and tested prior to shutting down the old
Task Dependence Description

Finish:Start-x days the task will start x days before its

predecessor(ID6) is complete.
e.g. (6FS-2days)
Finish:Start + xdays the task will start x days after its
predecessor (ID6) is complete.
e.g. (6FS+2days)
The same apply to Start:Start-+X days.
Introduce lag and lead times

Abok Tonny 5
TOOLS AND TECHNIQUES FOR ACTIVITY SEQUENCING
There are 2 techniques for scheduling project activities:
Gantt/bar chart and Network diagram
Gantt/bar chart

• This is a simple horizontal bar chart that depicts project tasks

against a calendar. Each bar represents a named project task.
The tasks are listed vertically in the left-hand column. The
horizontal axis is a calendar timeline.
Example: Activity Dependency Duration
A - 2
B A 2
C - 6
D C 8
E B,DAbok Tonny 4 6
 Gantt Chart

A A
B B
C C
Activities

D D

E E

2 4 6 8 10 12 14 16 18
Duration
Abok Tonny 7
Exercise
Study the following dependency in the table below and represent it on a Gantt
chart
Tasks Dependency Duration (days)
A None 4
B A 6
C B 3
D C 2
E D 3
F A 4
G F 1
H D,G,I,J 8
I A 3
J A 3
K A 4
L A 2
M L 8
N M 5
Abok Tonny 8
O E,H,K,N 5
Network diagram (Network Analysis Diagram)
There are two types:
• Activity on Node (AON)
• Activity on Arrow (AOA) – Most commonly used
AOA:
What is involved in using AOA.
 @ activity is represented by an arrow.
 An event is a point in time at the start or completion of one or more
activities. The first event signifies the start of a project, and the last node
represents the end of a project.
 Events are represented by circles.
Networks should have one start event and one finish event.
 Activities should be neatly defined by their start and finish numbers.
 Dummy arrows are used to show interdependence between activities. It has
zero (0) duration. Abok Tonny 9
Network Diagram - AOA

B2

A2 E4
Dummy arrow Finish
(duration=0)
Start

D8
C6
Used to control the project – can be used to
identify current and potential problems by
using the critical path of the project. Such
that when the critical activity is running
behind schedule, alternative courses of
action are examined, e.g. adding more
resources.
Abok Tonny 10
Concepts when dealing with network diagrams
• Network analysis used to predict project duration.
• Determine critical path - series of activities that determines the duration of the
project. It is the longest path through the project. Critical path analysis can also be
used as an aid to allocating resources by identifying those activities that are critical
and therefore require additional resources to ensure they are completed on time.
• The earliest event time (EET) – the earliest start time by an activity leading into an
event. Calculate by means of a forward pass (by adding), using a specified start
date.
• The latest event time (LET) – the latest time by which an activity leading into an
event must be completed if the project has to be completed on time. Calculated by
means of a backward pass (by subtracting).
• Used to determine float/slack – the amount of time an activity may be delayed from
its early start without delaying the project finish date.
Float = LET - EET - Duration
• When EET equal to LET, it means that those activities are critical.
• When EET not equal LET, it means that a float exists.

Abok Tonny 11
In groups of 3, work out the following case studies:
1. Exercises 2, 3 and 4

Exercise on Dummy
Activity Dependency Duration

A None 6

B A 4

C A 5

D None 10

E C,D 6

F C 4

G E 5
Abok Tonny 12
4 PROJECT EXECUTION AND CONTROL

Purpose

The purpose of Project Execution and Control is to develop the

product or service that the project was commissioned to deliv-
er. Typically, this is the longest phase of the project manage-
ment lifecycle, where most resources are applied.

Project Execution and Control utilizes all the plans, schedules,

procedures and templates that were prepared and anticipated
during prior phases. Unanticipated events and situations will
inevitably be encountered, and the Project Manager and Project
Team will be taxed to capacity to deal with them while mini-
mizing impact on the project’s CSSQ.

The conclusion of the phase arrives when the product of the

project is fully developed, tested, accepted, implemented and
transitioned to the Performing Organization.

Accurate records need to be kept throughout this phase. They

serve as input to the final phase, Project Closeout.

List of Processes

This phase consists of the following processes:

◆ Conduct Project Execution and Control Kick-off, where
the Project Manager conducts a meeting to formally begin
the Project Execution and Control phase, orient new
Project Team members, and review the documentation and
current status of the project.
◆ Manage CSSQ, where the Project Manager must manage
changes to the Project Scope and Project Schedule,
implement Quality Assurance and Quality Control process-
es according to the Quality Standards, and control and
manage costs as established in the Project Budget.
◆ Monitor and Control Risks, where the Project Manager
and Project Team utilize the Risk Management Plan
prepared in previous phases, and develop and apply
new response and resolution strategies to unexpected
eventualities.

199
200 Section I:4 Project Execution and Control
NYS Project Management Guidebook

◆ Manage Project Execution, where the Project Manager

must manage every aspect of the Project Plan to ensure
that all the work of the project is being performed correctly
and on time.
◆ Gain Project Acceptance, where the Project Manager,
Customer Decision-Makers and Project Sponsor acknowl-
edge that all deliverables produced during Project
Execution and Control have been completed, tested,
accepted and approved, and that the product or service of
the project has been successfully transitioned to the
Performing Organization.

The following chart illustrates all of the processes, tasks, and

deliverables of this phase in the context of the project manage-
ment lifecycle.
 Section I:4 Project Execution and Control 201
NYS Project Management Guidebook

Figure 4-1

Project Planning Project Execution and Control Project Closeout

Conduct Post-
Conduct Planning Kick-off Conduct Phase Kick-off Implementation Review
Orient New Team Members Orient New Team Members Solicit Feedback
Review Project Materials Review Project Materials Conduct Project Assessment
Kick Off Project Planning Kick Off Project Execution Prepare Post-
Implementation Report

Manage CSSQ Perform

Refine CSSQ Administrative Closeout
Refine Project Scope Manage Project Scope
Provide Performance
Refine Project Schedule Manage Project Schedule Updated
Feedback
Project
Refine Quality Standards Implement Quality Control Schedule Archive Project Information
Refine Project Budget Manage Project Budget
Project Scope
Project Schedule
Quality Management
Plan
Perform Risk Assessment Project Budget Monitor and Control Risks
Risk
Identify Risks Monitor Risks
Management
Quantify Risks Control Risks Worksheet
Develop Risk Mgmt Plan Monitor Impact on CSSQ

Risk Management
Worksheet
Refine Project Plan
Manage Project Execution
Define Change Control Process
Manage Change Control Archived
Define Acceptance Mgmt Project
Manage Deliverable Acceptance
Define Issue Mgmt & Escalation Repository
Manage Issues
Refine Communications Plan Updated CSSQ
Execute Communications Plan
Define Organizational Approval Forms
Manage Organizational Change Issue Log
Change Management Plan
Manage Project Team Status Reports
Establish Time/Cost Baseline
Manage ProjectTransition
Develop Project Team Project Plan
Develop Implementation/
Transition Plan

Gain Project Acceptance

Conduct Final Status Meeting
Confirm Approval to Proceed Gain Acceptance Signature
Review/Refine Business Case Project Acceptance Form
Prepare for Acceptance
Gain Approval Signature Approval Form
202 Section I:4 Project Execution and Control
NYS Project Management Guidebook

List of Roles

The following roles are involved in carrying out the processes

of this phase. The detailed descriptions of these roles can be
found in the Section I Introduction.
◆ Project Manager
◆ Project Sponsor
◆ Project Team Member
◆ Customer
◆ Customer Representative
◆ Consumer
◆ Stakeholders

List of Deliverables

Project Execution and Control differs from all other phases in

that, between phase kick-off and project acceptance, all
processes and tasks occur concurrently and repeatedly, and
continue almost the entire duration of the phase.

Thus, the earlier concept of a “process deliverable” is not appli-

cable to this phase, and even task deliverables are mostly activ-
ities, not products.

Of course, there is the ultimate phase deliverable – the product

of the project, and it is formally recognized via the signed
Project Approval Form.

The following table lists all Project Execution and Control

processes, tasks and their deliverables.
 Section I:4 Project Execution and Control 203
NYS Project Management Guidebook

Figure 4-2
Processes Tasks Task Deliverables
(Outcomes)
Conduct Project Orient New Team Members Team Members Prepared to Work
Execution and Control
Review Outputs of Project Planning Project Planning Outputs Reviewed
Kick-off
Kick Off Project Execution and Control Kick-off Meeting Agenda
Kick-off Meeting Notes
Manage CSSQ Manage Project Scope Scope Under Control
Manage Project Schedule Updated Project Schedule
Implement Quality Control Quality Control Processes In Place
Manage Project Budget Updated Budget
Monitor and Monitor Risks Risk Management Worksheet
Control Risks
Control Risks Project Status Report
Monitor Impact on CSSQ CSSQ Managed
Manage Project Manage Change Control Process Updated CSSQ
Execution
Manage Acceptance of Deliverables Project Deliverable Approval Forms
Manage Issues Project Status Report
Execute Communications Plan Project Status Report and Other
Communication Tools
Manage Organizational Change Organizational Change Processes
Executed
Manage the Project Team High Performing Team
Manage Project Implementation and Product of the Project
Transition Plan
Gain Project Conduct Final Status Meeting Final Project Status Report
Acceptance
Gain Acceptance Signature from Signed Project Acceptance Form
Project Sponsor
204 Section I:4 Project Execution and Control
NYS Project Management Guidebook

4.1 CONDUCT PROJECT EXECUTION AND CONTROL KICK-OFF

Purpose

The purpose of Conduct Project Execution and Control Kick-

off is to formally acknowledge the beginning of Project
Execution and Control and facilitate the transition from Project
Planning. Similar to Project
Planning Kick-off, Project Roles
Execution and Control Kick-
off ensures that the project is
● Project Manager
still on track and focused on
the original business need. ● Project Sponsor
Many new team members ● Project Team Members
will be introduced to the
● Stakeholders
project at this point, and
must be thoroughly oriented
and prepared to begin work. Most importantly, current project
status is reviewed and all prior deliverables are re-examined,
giving all new team members a common reference point.

Tasks

4.1.1 Orient New Project Team Members

As in Project Planning, the goal of orienting new Project Team
members is to enhance their abilities to contribute quickly and
positively to the project’s desired outcome. If the Project
Manager created a Team Member Orientation Packet during
Project Planning, the packet should already
The tasks executed in support contain an orientation checklist, orientation
of Conduct Project Execution meeting agenda, project materials, and logisti-
and Control Kick-off are: cal information that will again be useful.
4.1.1 Orient New Project Team
Members The Project Manager should review the con-
4.1.2 Review Outputs of Project tents of the existing Team Member Orientation
Planning and Current Project Packet to ensure that they are current and still
Status applicable to the project. Any changes needed
to the contents of the packet should be made at
4.1.3 Kick Off Project Execution and
this time. Once updated, packet materials can
Control
be photocopied and distributed to new team
members to facilitate their orientation process.
The Project Manager or Team Leader should conduct one-on-
one orientation sessions with new members to ensure that they
read and understand the information presented to them.
 Section I:4 Project Execution and Control 205
NYS Project Management Guidebook

If the orientation packet was not created during Project

Planning and new team members are coming on board, the
Project Manager must gather and present information that
would be useful to new team members, including:
■ All relevant project information from Project Origination,
Project Initiation, and Project Planning
■ Organization charts – Project Team, Customer, Performing
Organization
■ Information on Project Roles and Responsibilities
■ General information on the Customer (what they do for a
living!)
■ Logistics (parking policy, work hours, building/office secu-
rity requirements, user id and password, dress code, loca-
tion of rest rooms, supplies, photocopier, printer, fax,
refreshments, etc.)
■ Project procedures (team member expectations, how and
when to report project time and status, sick time and vaca-
tion policy)

4.1.2 Review Outputs of Project Planning and Current Project Status

Before formally beginning Project Execution and Control, the
Project Team should review recent Project Status Reports and
the Project Plan. At this point in the project, the Project Plan
comprises all deliverables produced during Project Initiation
and Project Planning:
1. Project Charter
2. CSSQ (Scope, Schedule, Quality Plan, Budget)
3. Risk Management Worksheet
4. Description of Stakeholder Involvement
5. Communications Plan
6. Time and Cost Baseline
7. Change Control Process
8. Acceptance Management Process
9. Issue Management and Escalation Process
10. Project Organizational Management Plan
11. Project Team Training Plan
12. Project Implementation and Transition Plan

See the sections on Project Initiation and Project Planning for

detailed descriptions of these deliverables.
206 Section I:4 Project Execution and Control
NYS Project Management Guidebook

This will serve to remind the team of what has been produced
so far, to clarify understanding of the work to be produced dur-
ing Project Execution and Control, and to again communicate
the management processes that will be followed during the
remainder of the project.

4.1.3 Kick Off Project Execution and Control

As was the case for Project Initiation and Project Planning, a
meeting is conducted to kick off Project Execution and Control.
During the meeting, the Project Manager should present the
main components of the Project Plan for review. (See Figure
4-3, Project Execution and Control Kick-off Meeting Agenda.)
Other items to cover during the meeting include:
■ Introduction of new team members
■ Roles and responsibilities of each team member
■ Restating the objective(s) of the project and goals for
Execution and Control
■ Latest Project Schedule and timeline
■ Communications Plan
■ Project risks and mitigation plans
■ Current project status, including open issues and action
items
The goal of the kick-off meeting is to verify that all parties
involved have consistent levels of understanding and accept-
ance of the work done so far, to validate expectations pertain-
ing to the deliverables to be produced during Project Execution
and Control, and to clarify and gain understanding of the expec-
tations of each team member in producing the deliverables.
Attendees at the Project Execution and Control Kick-off Meeting
include the Project Manager, Project Team, Project Sponsor,
and any other Stakeholders with a vested interest in the status
of the project. This is an opportunity for the Project Sponsor to
reinforce the importance of the project and how it supports the
business need.

As at every formal project meeting, the Project Manager should

be sure that one of the Project Team members in attendance is
designated as the scribe for the session, to capture notes and
action items. Following the session, the notes and action items
should be compiled into meeting minutes to be distributed to all
attendees for review and approval, and should be added to the
project repository.
 Section I:4 Project Execution and Control 207
NYS Project Management Guidebook

Figure 4-3 Project Execution and Control Kick-off Meeting Agenda

Project: ______________________________
Project Execution
and Control Kick-off Date:________________________________
Meeting Agenda Time: From: ___________ To: ___________
Location: _____________________________

Invitees: List the names of individuals invited to the meeting

Invitees should include the Project Manager, Project Team, Project Sponsor, and any
Customers with a vested interest in the status of the project.

Attendees: During the meeting, note who actually attended. If attendees arrived late or
left early, indicating they missed some of the topics discussed, note their arrival or
departure time.

AGENDA
Use the following suggested times as guidelines–the time you need to cover agenda topics will
vary depending upon the needs of the project.
PRESENTER NAME TIME (MINUTES)
Introductions Project Manager 5 min.

Project Manager welcomes everyone and briefly states the objective of the meeting.
Allow individuals to introduce themselves, and provide a description of their role within the
Performing Organization and their area of expertise and how they may be able to contribute to
the project efforts.
The material to be presented by the following agenda topics should come right from the
Project Charter.

Sponsor’s Statement Project Sponsor 5 min.

After brief introductions, the Project Sponsor should describe the vision for the project, demon-
strate support, and advocate for its success, setting it as a priority for all parties involved.

Project Request & Background Project Manager 5 min.

Project Goals & Objectives Project Manager 10 min.
Project Scope Project Manager 10 min.
Roles & Responsibilities Project Manager 10 min.
When reviewing roles and responsibilities be explicit about expectations relative to stakeholder
availability and Project Sponsor commitment and support for the project.

Next Steps Project Manager 5 min.

Questions Project Manager 10 min.

ADDITIONAL INFORMATION:
Handouts:
Provide a list of the material to be distributed to the attendees.
208 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Figure 4-3 (Continued)

Project Execution Project: ______________________________

and Control Kick-off Date:________________________________

Meeting Time: From: ___________ To: ___________
Location: _____________________________

Be sure that one of the Project Team members in attendance is scribing for the session, captur-
ing important project-specific information that requires further review or discussion as well as
potential issues that could impact the project. At the end of the meeting, the Project Manager
and Project Team should review these points as well as any other notes captured by other team
members to identify any additional actions required. The notes will be compiled into meeting
minutes to be distributed to all the attendees and retained in the project repository.

DECISIONS

Decision Made Impact Action Required?

Document each project decision reached and its impact. Also indicate if the decision requires
follow-up actions. If so, these should be captured below.

ISSUES

Issue Description Impact Action Required?

Document any project issues identified and its impact. Also indicate if the issue requires follow
up actions. If so, these should be captured below.

ACTION ITEMS FOR FOLLOW UP

Action Responsible Target Date

Capture any follow up activities and the individual responsible for them as well as set a date as
to when the action needs/should be completed.
At the end of the meeting, the scribe should recap the action items. These should also be
included in the meeting minutes to be distributed.
 Section I:4 Project Execution and Control 209
NYS Project Management Guidebook

4.2 MANAGE CSSQ

Purpose

CSSQ is the acronym for a project’s inextricably linked quadru-

ple constraints: Cost, Scope, Schedule, and Quality. During
Project Planning, each section of the CSSQ was refined. As
project-specific tasks are
performed during Project Roles
Execution and Control,
CSSQ will need to be ● Project Manager
managed according to the ● Project Sponsor
processes established
● Project Team Member
during Project Planning.
● Customer Representative
The CSSQ is not static –
although Project Planning is complete and has been approved,
some components of CSSQ will continue to evolve as a result of
the execution of project tasks. Throughout Execution and
Control, as more information about the project becomes known
and the product of the project is developed, CSSQ is likely to be
affected and will need to be closely managed.

The purpose of Manage CSSQ is to:

■ Manage Changes to Project Scope
■ Control the Project Schedule and Manage Schedule
Changes
■ Implement Quality Assurance and Quality Control
Processes according to the Quality Standards Revised
During Project Planning
■ Control and Manage Costs Established in the Project
Budget

Tasks

4.2.1 Manage Project Scope

During Project Planning, the Project Manager, through regular
communication with the Customer Representatives and Project
Sponsor, refined the Project Scope to clearly define the content
of the deliverables to be produced during Project Execution and
Control. This definition includes a clear description of what
will and will not be included in each deliverable.
210 Section I:4 Project Execution and Control
NYS Project Management Guidebook

The process to be used to document changes to the Project

Scope was included in the Project Plan. This process includes
a description of the way scope will be managed
The tasks for
and how changes to scope will be handled. It is
Manage CSSQ are: important that the Project Manager enforce this
process throughout the entire project, starting
4.2.1 Manage Project Scope
very early in Project Execution and Control.
4.2.2 Manage Project Schedule Even if a scope change is perceived to be very
4.2.3 Implement Quality Control small, exercising the change process ensures
that all parties agree to the change and under-
4.2.4 Manage Project Budget
stand its potential impact. Following the
process each and every time scope change
occurs will minimize confusion as to what actually constitutes
a change. Additionally, instituting the process early will test its
effectiveness, get the Customer and Project Sponsor accus-
tomed to the way change will be managed throughout the
remainder of the project, and help them understand their roles
as they relate to change.

As part of managing scope change, one of the Project Manager’s

functions is to ensure that the project produces all the work but
ONLY the work required and documented in the Project Scope.
Any deviation to what appears in the scope document is consid-
ered change and must be handled using the change control
process. Sometimes, despite the best effort of the Project
Manager to carefully document what is in and outside of scope,
there is disagreement between the Project Manager and
Customer Representative or Project Sponsor regarding whether
something is a change. When conflicts occur, the Project
Manager and appropriate Customer must be willing to discuss
their differences of opinion and reach a compromise. If a com-
promise cannot be reached, it may be necessary to escalate the
issue to a higher level of management.

Once the Project Manager, the Project Sponsor, and the appro-
priate Customer Representative agree that scope change is
occurring, they all must take the time to thoroughly evaluate the
change. In order to effectively evaluate change, the Project
Manager must forecast the impact of the change on the remain-
ing three “quadruple constraints”: Cost, Schedule and Quality.
Equipped with this information, the Project Manager and
Project Sponsor will be able to determine if implementing the
proposed change would be beneficial. If it is determined, for
 Section I:4 Project Execution and Control 211
NYS Project Management Guidebook

example, that the cost of implementing a change outweighs the

benefit, the change should most likely be rejected or put aside
for future consideration.

When a scope change is determined to be beneficial to the out-

come of the project, approval and funding for the change is
secured. At this point, the Project Manager must follow the pro-
cedures defined in the Project Plan to implement the change.
(Managing the change control process is described in detail in
4.4.1.)

The Project Manager must incorporate any agreed-upon

changes or addenda into the deliverables produced during
Project Initiation and Project Planning. This ensures that all
project deliverables are in line with the revised Project Scope.
Any lessons learned from scope change control should be doc-
umented and included in the project repository for later use by
the current project and any other projects to be performed by
the organization.

Throughout Project Execution and Control, continuous commu-

nication between the Project Manager, Project Sponsor, and
Customer Representative is crucial in managing scope.

4.2.2 Manage Project Schedule

During Project Planning, an agreed-upon baseline was estab-
lished for the Project 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 the Project Manager can use
during Project Execution and Control to determine if the proj-
ect is on track.

Project Team members must use the communications mecha-

nisms documented in the Communications Plan to provide feed-
back to the Project Manager on their progress. It is recom-
mended that each team member prepare a Progress Report.
This report documents effort spent on tasks and provides esti-
mates of the effort required to complete them. (See Figure 4-4,
the New York State Progress Report.) Progress Reports are used
by the Project Manager to update the Project Schedule. For
details on the contents of a Progress Report and instructions on
how to prepare one, see 4.4.4, Execute Communications Plan.
212 Section I:4 Project Execution and Control
NYS Project Management Guidebook

The Project Manager must emphasize to the team the impor-

tance of accurate reporting, and must be vigilant in collecting
information at a detailed level. Using the information contained
in the Progress Reports, the Project Manager tracks work done
against the tasks in the Project Schedule. If the time remaining
to complete a task in the schedule differs from the estimated
time, the schedule should be updated accordingly. It is recom-
mended that the Project Manager update the Project Schedule
on a regular basis. Frequent updates to the schedule not only
save time in the long run, they also allow the Project Manager
to quickly spot potential problem areas. Small slippages on
individual tasks may combine to create significant issues with
other, dependent tasks.
 Section I:4 Project Execution and Control 213
NYS Project Management Guidebook

Figure 4-4 New York State Progress Report

New York State

Progress Report

To: Report Period Ending:

From: Project Name:

The tasks I completed this reporting period are:

■

The tasks I plan to complete next reporting period are:

■

I lost time due to: (Specify hours and cause):

■

Issues:
Description Date Impact
Identified

Scheduled Vacation/Training:
Description Start Date End Date # of Hours

Time Reporting by Task:

Task Description Original Hours ETC Hours
ID Estimate this Week to Date

Reporting Period Total

214 Section I:4 Project Execution and Control
NYS Project Management Guidebook

After updating the Project Schedule, the Project Manager must

take the time to review the status of the project. Some ques-
tions that the Project Manager should be able to answer by
examining the Project Schedule include:
■ Is the project on track?
■ Are there any issues that are becoming evident that need
to be addressed now?
■ Which tasks are taking more time than estimated? Less
time?
■ If a task is late, what is the effect on subsequent tasks?
■ What is the next deliverable to be produced and when is it
scheduled to be complete?
■ What is the amount of effort expended so far and how
much is remaining?
■ Are any Project Team members over-allocated or under-
allocated?
■ How much of the time allocated has been expended to date
and what is the time required to complete the project?

Most project scheduling tools provide the ability to produce

reports to display a variety of useful information. It is recom-
mended that the Project Manager experiment with all available
reports to find those that are most useful for reporting infor-
mation to the Project Team, Customer, and Project Sponsor.

When updating the Project Schedule, it is very important that the

Project Manager maintain the integrity of the current schedule.
Each version of the schedule should be archived. By creating a
new copy of the schedule whenever it is updated, the Project
Manager will never lose the running history of the project and
will also have a copy of every schedule for audit purposes.

The Project Manager should begin tracking actual work in the

Project Schedule as soon as the work commences, which is
usually as soon as the project is initiated and Project Planning
begins. Work done in parallel with planning, before the Project
Schedule is completed and approved, must be recorded.
Remember that updates to the Project Schedule are not limited
to tracking hours worked – ANY change resulting from the exe-
cution of the change control process will usually require future
tasks to be re-planned and the schedule to be updated! (See
Manage Change Control Process, task 4.4.1.) If the Project
Schedule is updated to reflect approved change control, a new
 Section I:4 Project Execution and Control 215
NYS Project Management Guidebook

baseline schedule must also be created. Updates must then be

made against the new baseline. The previous baseline should
be saved for historical purposes.

4.2.3 Implement Quality Control

Quality control involves monitoring the project and its progress
to determine if the quality assurance activities defined during
Project Planning are being implemented and whether the
results meet the quality standards defined during Project
Initiation. The entire organization has responsibilities relating
to quality, but the primary responsibility for ensuring that the
project follows its defined quality procedures ultimately
belongs to the Project Manager. The following figure highlights
the potential results of executing a project with poor quality
compared to a project executed with high quality:

Figure 4-5
Poor Quality High Quality
Increased costs Lower costs
Low morale Happy, productive Project Team
Low Customer satisfaction Delivery of what the Customer wants
Increased risk Lower risk

Quality control should be performed throughout the course of

the project. Some of the activities and processes that can be
used to monitor the quality of deliverables, determine if project
results comply with quality standards, and identify ways to
improve unsatisfactory performance, are described below. The
Project Manager and Project Sponsor should decide which are
best to implement in their specific project environment.
■ Conduct Peer Reviews – the goal of a peer review is to
identify and remove quality issues from a deliverable as
early and as efficiently as possible. A peer review is a
thorough review of a specific deliverable, conducted by
members of the Project Team who are the day-to-day peers
of the individuals who produced the work. The peer review
process adds time to the overall Project Schedule, but in
many project situations the benefits of conducting a review
far outweigh the time considerations. The Project Manager
must evaluate the needs of his/her project, determine and
document which, if any, deliverables should follow this
process, and build the required time and resources into the
Project Schedule.
216 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Prior to conducting a peer review, a Project Team member

should be identified as the facilitator or person responsible
for keeping the review on track. The facilitator should
distribute all relevant information pertaining to the
deliverable to all participants in advance of the meeting
to prepare them to participate effectively.

During the meeting, the facilitator should record informa-

tion including:
▲ Peer review date
▲ Names and roles of participants
▲ The name of the deliverable being reviewed
▲ Number of quality issues found
▲ Description of each quality issue found
▲ Actions to follow to correct the quality issues prior to
presenting the deliverable to the approver
▲ Names of the individuals responsible for correcting the
quality issues
▲ The date by which quality issues must be corrected
This information should be distributed to the Project
Manager, all meeting participants, and those individuals
not involved in the meeting who will be responsible for
correcting any problems discovered or for producing
similar deliverables. The facilitator should also solicit
input from the meeting participants to determine if
another peer review is necessary. Once the quality
issues have been corrected and the Project Manager is
confident the deliverable meets expectations, it may be
presented to the approver.
■ Use Quality Checklists – both the Project Manager and
Project Team members can create and make use of various
checklists to be sure items are not overlooked while a
product is being developed. Checklists may be simple hard-
copy lists of “things to do,” or may be generated using
more formal, electronic-based tools. In either case, a
checklist should be comprehensive and detailed enough to
ensure that the resulting product or deliverable has been
built to the level required to meet quality standards. An
example of a quality checklist is the End-of-Phase
Checklist found at the end of each project management
lifecycle phase in this Guidebook.
 Section I:4 Project Execution and Control 217
NYS Project Management Guidebook

Checklists can be refined and expanded over the course of several projects. This is
a great way to reuse best practices and maintain historical information.

■ Maintain and Analyze the Project Schedule – this activi-

ty should never be taken lightly, regardless of the size of
the project. Updating the Project Schedule on a regular
basis while keeping a close watch on the timeline and
budget is the primary mechanism to measure quality of the
schedule. If the project timeline or budget are not on
track, the Project Manager can determine why and take
immediate action to remedy the problem. (See Manage
Project Schedule, task 4.4.2.)
■ Conduct Project Audits – the goal of a project audit is to
ensure that the Quality Assurance activities defined in
Project Planning are being implemented and to determine
whether quality standards are being met. It is a process to
note what is being done well, to identify real or potential
issues, and to suggest ways for improvement. Audits
should be performed on a regular basis, depending upon
the size and length of the project. At a minimum, it is
recommended that an audit be performed at the end of
each phase, at lease once during Project Execution and
Control, and at the end of the project.
The individual(s) performing the audit can be a member of
a quality assurance department or team, if one exists, or
any Stakeholder determined by the Project Sponsor to be
unbiased toward the project. The individual should also be
very familiar with the quality standards and procedures in
place in the Performing Organization, but should have no
involvement in day-to-day project activities.
An auditor will most likely use a checklist questionnaire to
interview the Project Manager, selected Project Team
members, the Project Sponsor, and selected Customer
Representatives to gain insight into how the project is
progressing. One of the most important measurements the
auditor will look for during these interviews is Project Team
and Customer satisfaction. Poor satisfaction is an indicator
of an underlying problem that should be uncovered as the
auditor delves into the specifics of the project. In addition,
the project repository will be examined to determine if it
218 Section I:4 Project Execution and Control
NYS Project Management Guidebook

contains sufficient documentation. An auditor will look for

and review the components of the current Project Plan –
including the Project Scope, Project Schedule, and Risk
Management Worksheet. The questions listed below are
examples of what an auditor may be asking when reviewing
the Project Plan.

PROJECT DELIVERABLES
(Project deliverables will differ depending upon the project life-
cycle being used. Customize the following questions and add
others as necessary to properly and sufficiently evaluate the
deliverables specific to your project.)
Do the deliverables meet the needs of the Performing
Organization?
Do the deliverables meet the objectives and goals outlined in
the Business Case?
Do the deliverables achieve the quality standards defined in
the Quality Management Plan?

PROJECT MANAGEMENT DELIVERABLES

Does the Project Proposal define the business need the proj-
ect will address, and how the project’s product will support
the organization’s strategic plan?
Does the Business Case provide an analysis of the costs and
benefits of the project and provide a compelling case for
the project?
Has a Project Repository been established to store all project
documents, and has it been made available to the Project
Team?
Does the Project Charter define the project purpose, goals
and objectives?
Does the Project Scope provide a description of the project,
including its output, approach, and content?
In the Project Scope, is it clear as to what is “in” and “out” of
scope?
Is the Project Schedule defined sufficiently to enable the
Project Manager to manage task execution?
 Section I:4 Project Execution and Control 219
NYS Project Management Guidebook

Was a Project Schedule baseline established?

Is the Project Schedule maintained on a regular basis?
Does the Quality Management Plan describe quality standards
for the project and associated quality assurance and
quality control activities?
Has a project budget been established and documented in
sufficient detail?
Have project risks been identified and prioritized, and has a
mitigation plan been developed and documented for each?
If any risk events have occurred to date, was the risk mitiga-
tion plan executed successfully?
Are all Stakeholders aware of their involvement in the project,
and has this it been documented and stored in the project
repository?
Does the Communications Plan describe the frequency and
method of communications for all Stakeholders involved in
the project?
Does the Change Control Process describe how to identify
change, what individuals may request a change, and the
process to follow to approve or reject a request for
change?
Has changes to scope been successfully managed so far?
Does the Acceptance Management Process clearly define who
is responsible for reviewing and approving project and
project management deliverables? Does it describe the
process to follow to accept or reject deliverables?
Has the Acceptance Management Process proven successful
for the deliverables produced so far?
Does the Issue Management and Escalation Plan clearly
define how issues will be captured, tracked, and priori-
tized? Does it define the procedure to follow should an
unresolved issue need to be escalated?
Have issues been successfully managed up to this point?
Does the Organizational Change Management Plan document
how changes to people, existing business processes, and
culture will be handled?
Has a Project Team Training Plan been established, and is it
being implemented?
220 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Does the Implementation and Transition Plan describe how to

ensure that all Consumers are prepared to use the project’s
product, and the Performing Organization is prepared to
support the product?
Have all Project Management deliverables been approved by
the Project Sponsor (or designated approver?)
Does the Project Plan contain all required components as
listed in the Guidebook?
Are each of the Project Plan components being maintained on
a regular basis?

PROJECT MANAGEMENT PROCESSES

Does each Project Team member produce regular progress
reports, including actual effort expended on tasks and
estimates to complete them?
Are regular Project Team meetings conducted? Are meeting
minutes kept, disseminated after the meetings, and stored
in the repository?
Does the Project Manager produce a status report on a
regular basis that contains all recommended components
from the Project Status Report template (Figure 2-10)?
Is the Project Status Report being reviewed with the Project
Sponsor on a regular basis?
As new team members are introduced, are they being suffi-
ciently oriented to the project and working environment?

PROJECT TEAM AND CUSTOMER SATISFACTION

(To be completed only if Project Team members and Customers
have been interviewed as part of this review)
Are Project Team members satisfied with the way the project
is being managed?
Do Project Team members feel challenged and excited about
their work?
Do Project Team members feel comfortable in voicing con-
cerns or issues to the Project Manager?
Do the Project Manager, Project Sponsor and Customer
Decision-Maker(s) share a consistent view of project status
and issues?
 Section I:4 Project Execution and Control 221
NYS Project Management Guidebook

Is the Customer Decision-Maker(s) satisfied with deliverables

provided by the project?
Is the Customer Decision-Maker(s) satisfied with the respon-
siveness and flexibility of the Project Team?
Is the Customer Decision-Maker(s) satisfied with the skills
and capabilities of the Project Team?
Is the project currently free from serious Customer issues or
concerns?

Upon completion of the audit and repository review, the auditor

writes a summary report documenting his/her findings and rec-
ommendations. This report is reviewed with the Project
Manager, who should immediately implement recommenda-
tions and corrective actions identified.

Every member of the Project Team must be committed to pro-

ducing a quality product. Quality control cannot rely on
“adding” quality at the end of a process; quality must be built
into the work of each individual on the team. It is far more cost
effective to have Project Team members add quality into their
day-to-day jobs than to have an auditor find a problem after a
process has been completed.

As a result of implementing quality control, the Project Manager

should be able to determine and take the appropriate actions to
increase the project’s effectiveness and provide better service
to the Customer.

Successful quality control processes always strive to see quality through the eyes of
the Customer. The Customer is the ultimate judge of the quality of the product.
222 Section I:4 Project Execution and Control
NYS Project Management Guidebook

4.2.4 Manage Project Budget

The Project Manager must know the extent of his/her authority
to make budget decisions. For example, is the Project Manager
allowed to authorize work that requires additional hours of
salaried personnel time, or must employee time extensions go
through the same approval process as contract personnel or
equipment purchases? Often, the Project Manager must work
closely with fiscal and contract personnel in other divisions to
track and control costs. These relationships must be estab-
lished early in the project management lifecycle. For New York
State projects, project staff must record hours expended and
the Project Manager must use salary title and grade informa-
tion to determine the dollar cost of the personal services.

Part of the Project Manager’s job is to ensure that the project

is completed within the allocated and approved budget. Budget
management is concerned with all costs associated with the
project, including the cost of human resources, equipment,
travel, materials and supplies. Increased costs of materials,
supplies, and human resources, therefore, have a direct impact
on the budget. Just as task duration estimates are tracked
carefully against actuals, the actual costs must be tracked
against estimates. The same analysis should be conducted and
the same questions asked: What other aspects of the budget
were constructed based upon these estimates? Changes to the
scope of the project will most often have a direct impact on the
budget. Just as scope changes need to be controlled and man-
aged, so do changes to the Project Budget.

It is the responsibility of the Project Manager to closely monitor

the financial performance of the project and take responsibility
for addressing cost-related issues as they arise. In addition, the
Project Manager should always be aware of the effect his/her
decisions may have on the total cost of the project, both before
and after the product or service is implemented.

Monitoring the financial performance of your project on a regular basis is the only way
you can keep a handle on the Project Budget. Don’t let the Project Budget get away
from you – get into the habit of updating the schedule and analyzing the financial impact
on a regular basis. Taking the time to do these administrative tasks will save you countless
hours of reconciliation and balancing down the road, and warn you of impending cost
issues!
 Section I:4 Project Execution and Control 223
NYS Project Management Guidebook

There are several financial characteristics the Project Manager

should monitor to determine if a project is performing satisfac-
torily against its budget. Most often, these values are entered
into the scheduling tool by the Project Manager and calculated
and displayed using its corresponding capabilities. Some budg-
et-related characteristics the Project Manager should examine
each time the schedule is updated include:
■ Original Contract Value: the original estimated budget
(cost) that was approved by the Project Sponsor.
■ Total Approved Changes: the total cost of approved
changes as a result of change control.
■ Total Current Budget: the sum of the Original Contract
Value and the Total Approved Changes. This is the most
current approved Project Budget.
■ Cost to Date: the actual dollars (cost) expended to date
on all tasks and materials in the Project. The labor costs
can be calculated by the scheduling tool based upon the
time the Project Manager tracks against the tasks in the
Project Schedule.
■ Estimate to Complete: the dollars (cost) estimated to be
expended to complete remaining project tasks. The Project
Manager must verify and assess the impact of team
members’ revised effort estimates to complete tasks. The
Project Manager must also validate that the remaining
material costs are in line with the budget. These have a
direct effect on the Project Budget.
■ Forecast Total: the sum of the Cost to Date and the
Estimate to Complete.
■ Project Variance: the difference between all estimated
and all actual dollars. It is calculated by subtracting the
Forecast Total from the Total Current Budget. A positive
variance means that the actual cost of the product is less
than the budgeted cost. A negative variance means that
the actual cost of the product is greater than the budgeted
cost.

It is of utmost importance for the Project Manager to take the time to analyze, under-
stand, and document the reason for variance every time the Project Schedule is updated.
224 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Whether positive or negative, the Project Manager needs to

understand what is causing variance and take proactive steps
to keep it under control. The Project Manager must be able to
explain the cause of variance to others and determine if cor-
rective actions need to be taken to maintain the project’s budg-
et. For example, if a negative effort variance develops while a
task is being executed, then more money may be needed than
originally planned for, potentially impacting the success of the
project. On the other hand, some tasks may finish ahead of
schedule, freeing up money and offsetting the negative impact
of those that finish late. The Project Manager must remain
aware of such situations, working with the Project Team mem-
bers and Customers to determine the causes of variance and to
mitigate any associated risks.

It is the responsibility of the Project Manager to ensure the cur-

rency, accuracy, and viability of the Project Schedule as the pri-
mary mechanism for managing the budget. He/she must know
and be able to communicate exact project status relative to
budget, impact of changes, estimates to complete, and vari-
ance. This information must be known by task, process, phase,
resource, and deliverable and be communicated to the Project
Sponsor as part of the Status Meeting.

Deliverable

◆ The CSSQ Deliverables – the Project Budget, Project

Scope, Project Schedule, and the Quality Management Plan
are applied, monitored and updated during Project
Execution and Control.
 Section I:4 Project Execution and Control 225
NYS Project Management Guidebook

4.3 MONITOR AND CONTROL RISKS

Purpose

Risks are potential future events that can adversely affect a

project’s Cost, Schedule, Scope or Quality (CSSQ).
Roles In prior phases, the Project Manager defined these
events as accurately as possible, determined when
● Project Manager they would impact the project, and developed a
Risk Management Plan. As the impact dates draw
● Project Sponsor
closer, it is important to continue re-evaluating
● Project Team Member probability, impact, and timing of risks, as well as
● Customer to identify additional risk factors and events.

When the risk event actually occurs, the risk

(which is by definition a future, potential event) becomes an
issue (which is by definition a current, definite condition) and
issue monitoring and control takes over.

The purpose of Monitor and Control Risks is to deploy the

Risk Management Plans prepared in prior phases to anticipate
project challenges, and to develop and apply new response and
resolution strategies to unexpected eventualities.

Tasks

4.3.1 MONITOR RISKS

During Project Initiation and Planning, risks were remote
events with uncertain probabilities of coming true. In Execution
and Control, however, impact dates draw closer, and risks
become much more tangible.
The tasks for Monitor and
Control Risks during Project
Execution and Control are: The Project Manager must continually look for
new risks, reassess old ones, and re-evaluate
4.3.1 Monitor Risks
risk mitigation plans. The Project Manager
4.3.2 Control Risks should involve the whole Project Team in this
4.3.3 Monitor Impact on CSSQ endeavor, as various team members have their
particular expertise and can bring a unique per-
spective to risk identification. As the Risk
Management Worksheet is integrated into the status reporting
process, this review and re-evaluation should take place auto-
matically, with the preparation of each new status report.
226 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Because the Risk Management Worksheet places risks in order

according to their priority level, it is important to update all
quantifiable fields to portray an accurate risk landscape. The
risk probabilities may have changed; the expected level of
impact may be different, or the date of impact may be sooner or
later than originally anticipated – all of these variables deter-
mine which risks the Project Team will concentrate on first.

Likewise, the Risk Management Plan needs to be constantly

re-evaluated. Make sure the right people are still assigned to
mitigation actions and that the actions still make sense in the
context of the latest project developments.

Another consideration is whether a specific risk’s probability

level is high enough to warrant incorporating the Risk Manage-
ment Plan in the Project Schedule via the change control
process. If so, the risk should be removed from the worksheet.

Finally, the Project Manager must be constantly on the lookout

for additional risks. Reviewing the risks as part of regular
status reporting should involve the whole Project Team via bi-
directional communications.

4.3.2 Control Risks

Sooner or later, one of the events on the Risk Management
Worksheet – or an entirely new and unexpected risk – will actu-
ally occur. The Project Manager and Project Team members
must evaluate the risk event and invoke the Risk Management
Plan. There are generally three possible response scenarios:
1. If the risk occurred as expected, the existing Risk
Management Plan may be adequate for dealing with it.
Example: the project is being required to provide addition-
al documentation to prove compliance with state regula-
tions. However, that risk has been anticipated, and the
Risk Management Plan details where and how to get the
appropriate materials.
2. If the risk occurred in a different manner, or other cir-
cumstances have come to bear, the Risk Management
Plan may have to be modified. Example: a consumer
group brought pressure to examine the environmental
impact of the product of the project more closely. As a
result, the project is being required to obtain subject
matter expert statements. Since the need was not
 Section I:4 Project Execution and Control 227
NYS Project Management Guidebook

anticipated, the original contingency plan needs to be

modified to comply with the new requirements.
3. If the risk event was unexpected and unanticipated, a
whole new Risk Management Plan must be created to
address it. Example: The Federal Government issued a
mandate that challenges the project from a whole differ-
ent perspective. The Project Manager needs to under-
stand what the issue is, what response is required, and
how to obtain the desired result.

Regardless of the scenario, however, as soon as the risk event

occurs it ceases to be a risk (future, possible event) and
becomes an issue (current, definite condition). As a result, it
should transition from the Risk Management Worksheet and
onto the list of current project issues, with the Risk Manage-
ment Plan becoming the issue’s Action Plan.

4.3.3 Monitor Impact on CSSQ

During the entire risk management process, the Project
Manager should be especially vigilant regarding the effect on
the project’s Cost, Scope, Schedule and Quality (CSSQ). With
the proper risk management processes in place, many risk
events may come to pass without affecting (either positively or
negatively) the project’s defining parameters. However, when a
risk event occurs that threatens the project’s scope, quality
standards, schedule or budget, the Project Manager must
determine the proper course of action to protect the integrity of
the project.

Until CSSQ impact is certain, the Project Manager must, at a

minimum, introduce the event to the list of current project
issues. The issue’s Action Plan must reflect all the tasks
required to accurately determine what impact (if any) the event
will have on CSSQ. Once the impact is certain and quantifiable,
the Project Manager should transition the issue to the Change
Control process.

Deliverable

◆ Risk Management Worksheet – a record of risk variables,

impact, probability, date of impact, level of priority and
risk response actions which is continuously monitored and
updated, and its Risk Management Plans applied as part of
Project Execution and Control.
 228 Section I:4 Project Execution and Control
NYS Project Management Guidebook

4.4 MANAGE PROJECT EXECUTION

Purpose

Project Execution is typically the part of the lifecycle of a project

when the majority of the actual work to produce the product is
performed and the majority of the Project Budget is expended.
The purpose of Manage Project Execution is to man-
Roles age every aspect of the Project Plan as work is being
done to make certain the project is a success. This
● Project Manager process is performed concurrently with the Manage
● Project Sponsor CSSQ and Monitor and Control Risks processes. The
tasks in this process are performed concurrently and
● Project Team
repeatedly as various aspects of the product of the
● Customer project are constructed, tested, and accepted.

Tasks

4.4.1 Manage Change Control Process

During Project Planning, the Project Manager, Project Sponsor,
and Customer agreed on a formal change control process that
was documented and included in the Project Plan. The change
control process describes:
■ The definition of change and how to identify it
The tasks to Manage Project ■ How requests for change will be initiated
Execution are: ■ How requests for change will be analyzed to
4.4.1 Manage Change Control determine if they are beneficial to the project
Process ■ The process to approve or reject change
4.4.2 Manage Acceptance of requests
Deliverables ■ How funding will be secured to implement
4.4.3 Manage Issues approved changes
4.4.4 Execute Communications Plan
Although changes can be expected to occur through-
4.4.5 Manage Organizational Change out every project phase, any negative effect on the
4.4.6 Manage the Project Team project outcome should be avoidable if the change
4.4.7 Manage Project Implementation
control process is executed and managed effectively.
and Transition
The need for change is usually discovered during
Project Execution, as actual task work is being
performed. It is during Execution that the Project Team may
 Section I:4 Project Execution and Control 229
NYS Project Management Guidebook

discover their original effort estimates were not accurate and

will result in more or less effort being required to complete
their work. It is also during Execution that the Project Sponsor
or Customer may realize that, despite their best efforts to thor-
oughly document the Project Scope, the product being pro-
duced is not exactly what they need. It is the responsibility of
the Project Manager to keep a close watch on factors that could
introduce potential “scope creep” and take proactive steps to
prevent it from occurring, or to manage it as it occurs.

Sometimes change control is required if a Project Team mem-

ber is not able to complete what was documented in the Project
Scope, because of lack of skill, time constraints, or other fac-
tors outside his/her control. In most cases, these difficult to
manage situations often result in lost time in the Project
Schedule and can have a major impact on the project.

When someone does not do something he or she was supposed to do as docu-

mented in the Project Plan, the resulting change is called a “Non-Compliance” change.

Sometimes change is simply informational and will most likely

not affect the Project Scope or Schedule (e.g., the name of a
Project Team member or the physical location of the Project
Team offices may change). Changes that do not affect the pro-
ject’s CSSQ do not need to follow the formal change control
process, but should be documented in the Project Status Report
or any other appropriate communication mechanism.

However, for all changes that affect the project’s CSSQ, it is

vitally important for the Project Manager to implement and
manage the change control process in every situation. Not
doing so will cause confusion on the part of the Customer as to
what constitutes a change. The change control process also
helps maintain balance between the requirements of the proj-
ect and the timeline and cost.

During Project Planning, individuals authorized to be

requestors, reviewers, and approvers of change requests were
identified and information about them was documented in the
change control process. Change control begins when a
requestor completes a change request form and submits it to
the appropriate reviewer(s). (See Figure 3-6, New York State
Project Change Request.)
230 Section I:4 Project Execution and Control
NYS Project Management Guidebook

The role of the reviewer(s) in the change control process is to

analyze the request in terms of the level of effort and skill
required to implement it. The reviewer, typically an expert in
the subject area, will also make a recommendation to accept or
reject the change request based upon its feasibility from a tech-
nical or implementation standpoint. He/she will communicate
this information to the Project Manager and document it on the
Project Change Request.

One of the roles of the Project Manager in the change control

process is to analyze the reviewer’s recommendation, and
determine the overall effect of the requested change on the
Project Schedule in terms of effort, cost, and resource require-
ments and availability. This information will be documented on
the Project Change Request and presented to the approver(s).

The approver(s) review the information and make a determina-

tion whether to approve the change request based upon the
potential benefit of its implementation to the organization. If,
for example, the implementation costs far outweigh the busi-
ness benefit, the change request will most likely be rejected. A
signature is required of all approvers, whether they are accept-
ing or rejecting the request. If the request is being rejected, the
approver must provide a reason. A signature of approval on the
Project Change Request indicates that the approver accepts the
consequences (impact) of the request on the project’s Cost,
Scope, Schedule or Quality.

NEVER execute a change request without first obtaining all required approval
signatures!

Once a change request has been approved, the Project Manager

must incorporate the effect of the change into the Project
Schedule. All affected tasks, estimated durations, dependen-
cies, and resources must be modified. A new baseline should
then be created for the amended schedule and budget. These
become the new tools against which hours will be booked and
project performance measured going forward.
 Section I:4 Project Execution and Control 231
NYS Project Management Guidebook

REMEMBER: Make a copy of the new baseline schedule and archive it in the project
repository BEFORE you book new work to it! If you lose the baseline, you have noth-
ing against which to compare later updates to see if your project is on track!

In addition, if new deliverables will be produced as a result of

the change, their exact description must be included in the
Project Plan, either as appendices to the Project Scope, or as
separate attachments. In addition, any changes that affect the
remaining components of CSSQ must be documented. All cor-
respondence, supporting documentation and other information
pertaining to the change should be saved in the appropriate
location in the project repository.

4.4.2 Manage Acceptance of Deliverables

The goal of this task is to manage the acceptance of deliver-
ables according to the acceptance management process devel-
oped during Project Planning. The acceptance management
process is part of the Project Plan, and documents:
■ The definition of “acceptance”
■ The criteria that must be met for each deliverable to be
considered “acceptable”
■ The number and identity of Customers designated to be
reviewers of each deliverable – typically reviewers are
experts in the subject matter the deliverable covers
■ The number and identity of Customers designated to be
approvers – approvers have the authority to sign the
approval form, indicating acceptance
■ The number of business days in which deliverables must be
either approved or rejected by the reviewers and approvers
■ The number of times a deliverable can be resubmitted
■ The escalation process that will be followed if a timely
decision on approval or rejection of a deliverable is not
met
The acceptance management process must be followed
throughout the project. As with the change control process, the
earlier in the life of the project the process begins, the sooner
everyone will understand how it works and what to expect. The
232 Section I:4 Project Execution and Control
NYS Project Management Guidebook

key to facilitating acceptance is first to understand Customer

expectations, and then to meet them.

The acceptance management process is not set in stone…if, while executing the
process, you discover parts of it are not working as expected, adjust the process to
more closely fit the needs of the project. Just be sure to document your changes and get
Customer approval before implementing them.

Acceptance begins when the Project Manager presents a com-

pleted deliverable and Project Deliverable Approval Form to the
approver. (See Figure 2-13, New York State Project Deliverable
Approval Form.) When logistically possible, the Project
Manager must take the time to formally review the deliverable,
in person, with the approver. In some cases, the approver’s
geographic location or work shift prohibits face-to-face com-
munication. Where in-person communication is feasible, it is
recommended that the Project Manager not simply send the
deliverable via email or leave it on the approver’s desk. If the
Project Manager has done a very thorough job in setting expec-
tations, the approver may indicate acceptance at the end of this
face-to-face presentation. More likely, however, the approver
will prefer to have designated reviewers examine the document
or product and recommend a course of action.

The reviewers independently analyze the deliverable and pro-

duce a recommendation as to whether to accept the deliverable,
providing their comments and signature on the accompanying
approval form. This must be done within the turnaround time
documented in the acceptance management process. If a
reviewer recommends the deliverable be rejected, he/she must
provide the reason and forward the package back to the
approver. This process should be followed for each person des-
ignated as a reviewer in the acceptance management process.

Keep in mind that the review and approval process will take more time if several
reviewers or approvers need to get involved!
 Section I:4 Project Execution and Control 233
NYS Project Management Guidebook

Using input and recommendations provided by the reviewer, the

approver reviews the deliverable and decides if it meets the
acceptance criteria documented in the acceptance manage-
ment process. He/she will indicate acceptance or rejection of
the deliverable on the Project Deliverable Approval Form. Once
again, this must be done within the turnaround time document-
ed in the acceptance management process. If the approver rec-
ommends the deliverable be rejected, he/she must provide the
reason and forward the package to the Project Manager. It is
then the responsibility of the Project Manager to have the deliv-
erable adjusted as necessary and then resubmit it to the
approver. This process should be followed for each person des-
ignated as an approver in the acceptance management process.
The Project Manager must ensure that for rejected deliver-
ables, specific corrective actions are defined, i.e., “I would
accept this if...”

It is the responsibility of the Project Manager to be cognizant

of the time elapsing during the review and approval process, in
an attempt to complete the process within the maximum num-
ber of business days agreed upon and documented. Significant
delays in the process should trigger the Project Manager to
escalate the situation, following the documented escalation
procedure. Similarly, the Project Manager should be aware of
the number of times the acceptance process is being repeated.
How many times is the Project Team making changes to a deliv-
erable based upon its rejection? The number of times a deliv-
erable can be resubmitted to the approver was also document-
ed in the acceptance management process. If a deliverable is
rejected more than once, the Project Manager should take
immediate action to analyze the situation, resolve the conflict,
or exercise the appropriate escalation procedure to get it
resolved. A serious delay in the acceptance of a deliverable will
almost always result in project delays.

If the number of iterations becomes unreasonable, the Project Manager should rec-
ognize that a bigger problem may exist, and should take the appropriate action to find
out what it is and fix it!

The Project Manager should maintain a log of the activity that

transpires while a deliverable is going through the acceptance
management process. The deliverable acceptance log can be
234 Section I:4 Project Execution and Control
NYS Project Management Guidebook

included as part of the Status Report that is reviewed with the

Project Sponsor. (See Figure 2-10, the Project Status Report.)

Once a deliverable is considered acceptable, the Project

Manager should gain the appropriate signatures on the Project
Deliverable Approval Form. Signatures on the form indicate for-
mal acceptance of the deliverable.

4.4.3 Manage Issues

Managing issues involves documenting, reporting, escalating,
tracking, and resolving problems that occur as a project pro-
gresses. During Project Planning, the Project Manager and
Project Sponsor agreed upon and documented the process for
managing issues and included the process in the Project Plan.

The issue escalation and management process addresses the

following:
■ How issues will be captured and tracked
■ How issues will be prioritized
■ How and when issues will be escalated for resolution

Issues are usually questions, suggestions, or problems raised by

Project Team members, including the Project Manager and
Customer. They are different from changes in that they do not
usually have an immediate impact on the Project Scope or
Schedule. If issues remain unresolved, however, they are likely
to affect the Project Schedule or Budget, resulting in the need for
change control. It is, therefore, very important to have an issue
escalation and management process in place, and to execute the
process before change control procedures become necessary.

Anyone involved in a project in any way can and should inform

the Project Manager of issues. It is the responsibility of the
Project Manager and Project Sponsor to foster an environment
where communicating issues is not only acceptable but strong-
ly encouraged. Individuals should feel a responsibility to the
organization to voice their concerns. If individuals are fearful of
communicating issues, the resulting effect on the project can
be devastating.
 Section I:4 Project Execution and Control 235
NYS Project Management Guidebook

The Project Manager should be cautious about reacting to an issue that is communi-
cated by “shooting the messenger.” This sends the wrong message to the Project
Team. No matter how devastating the news or the issue, the Project Manager should thank
the person who raised the issue and solicit ideas from that individual and other team mem-
bers for its mitigation.

The Project Manager is responsible for capturing and tracking

issues as soon as they arise, using the issues log section in the
Project Status Report. Every issue, whether technical or busi-
ness related, should be documented in the report. (See the
Issues Log section in Figure 2-10, the Project Status Report.)
Below are some examples of project issues:
■ Computer system will be down for routine maintenance
■ Project Sponsor is taking another job
■ Project Team member start date may be sooner (or later)
than expected
■ There is a delay in approving or rejecting a change request
or deliverable
■ Severe weather is predicted in the area of the building site
Once the description of a new issue has been logged, the Project
Manager should estimate the potential impact the issue could
have on the project. Based upon potential impact, the Project
Manager prioritizes the issue in relation to all other open
issues. The goal of issue management is to resolve all concerns
completely and promptly, but in reality the issues with the high-
est priority should be addressed first.

The issues log should also include the date the issue is record-
ed, its anticipated closure date, and the name of the individual
responsible for resolving it or seeing that it is resolved. The due
date for closure must be a specific date (i.e., the date cannot be
“ASAP”). The responsible party must be a specific individual,
not a functional group (i.e., an issue should not be assigned to
the “IT Department” or the “DBA group”).

While the issue remains open, its continuing impact and the sta-
tus of its action plan should be discussed at every status meet-
ing. If appropriate resources or materials are not available to
complete the action items, or if there is disagreement about any
236 Section I:4 Project Execution and Control
NYS Project Management Guidebook

of the elements on the issues log, the Project Manager should

invoke previously-defined escalation procedures. Unresolved
issues are one of the leading causes of project failure, and the
Project Manager must pursue issue resolution relentlessly.

As progress occurs on the resolution of an issue, the Project

Manager should update the issues log to reflect what has
occurred. As issues are closed, they should be moved to a dif-
ferent section of the issues log. Along with a description of how
the issue was resolved, the Project Manager should document
who resolved the issue and the closure date.

When managing issues, document EVERYTHING (yes, EVERYTHING) that happens as

issues are resolved. Be sure to note what happened, when it happened and who was
involved. Don’t skimp on the details. Keep an issues “diary.”

When issues are closed, don’t delete them from your issues log – instead maintain the “diary”
of closed issues in a separate file or folder or section of the log. This “diary” will ensure that
you cover your bases, and the information included in it may become invaluable to you or
another Project Manager as lessons learned when resolving similar issues down the road!

4.4.4 Execute Communications Plans

During Project Planning, the Communications Plan was refined
to describe how project communications will occur, and
expanded to describe the way communications will be man-
aged. As a project progresses, events may occur to alter the
way information is accessed or change communications
requirements. During Project Execution, the Project Manager
and Project Team must again review whether the Communica-
tions Plan is still current and applicable to the project. If it is
determined that any portion of the plan is no longer applicable,
the Project Manager should update the document.

During Project Execution the Communications Plan is carried

out so that required information is made available to the appro-
priate individuals at the appropriate times, and new or unex-
pected requests receive a prompt response. Communications
must continue to be bi-directional during Project Execution.
The Project Manager must provide required information to the
Project Team and appropriate Stakeholders on a timely basis,
and the Project Team and Stakeholders must provide required
information to the Project Manager.
 Section I:4 Project Execution and Control 237
NYS Project Management Guidebook

In addition to having a solid Communications Plan in place, it is

the responsibility of members of the Project Team to exercise
good communication skills. When composing correspondence,
progress reports, meeting minutes, etc., and when speaking
with individuals face to face, the team members are responsible
for clear, unambiguous, and complete communication of infor-
mation. The receiver, in turn, must be sure information is not
only received correctly and completely, but that it is understood.

During Project Execution, the Project Manager, Project Team,

and Stakeholders will share information using a variety of com-
munication mechanisms. These were defined during Project
Planning and may include:
■ Status Meetings
■ Status Reports
■ Memos
■ Newsletters
■ Executive Correspondence
■ Meeting Notes
■ Executive Meetings
■ Steering Committee Meetings
This information is collected, stored and disseminated based
upon procedures established and documented in the
Communications Plan. While executing the plan, the Project
Manager must be aware of how the organization will use the
information, and whether the plan is effective. He/she must be
flexible and ready to modify the plan if portions of it are not
working as expected or communications needs change within
the Performing Organization.

Of the many mechanisms available to the Project Manager, sta-

tus reporting is particularly useful for communicating the per-
formance of a project. Project Team members must complete
Progress Reports providing regular feedback to the Project
Manager. These reports can serve a dual purpose – as a report-
ing mechanism to the Project Manager and also to the team
member’s immediate supervisor. Progress Reports should doc-
ument detailed descriptions of actual work accomplished and
include Team members’ estimates of the effort they feel will be
required to complete tasks. Progress Reports should also con-
238 Section I:4 Project Execution and Control
NYS Project Management Guidebook

tain information regarding work to be done in upcoming weeks,

and list any issues preventing completion of required tasks.
When correctly completed by the Project Team, the reports are
very useful to the Project Manager for updating the Project
Schedule, and for anticipating issues and proactively planning
ways for their resolution. (See Figure 4-4, the New York State
Progress Report.)

Using the Progress Reports prepared by the Project Team, the

Project Manager should complete a Status Report to be present-
ed to the Project Sponsor. In this report, the Project Manager
measures the “health and progress” of the project against the
Project Plan. It is the primary communication vehicle between
the Project Manager and the Project Sponsor, and should con-
tain the following information:
■ Summary of Progress to Project Schedule – a high-level
glance at the major project deliverables, with their
intended and actual start and end dates.
■ Issues and action items – a running list of open and closed
issues, including the name of the person responsible for
taking action to resolve them. (See Manage Issues, 4.4.3.)
■ Significant accomplishments – a list of the most important
completed tasks, or a description of work done toward
their completion.
■ Significant planned accomplishments for the following
weeks – a description of the most important tasks
scheduled for completion during the following weeks.
■ Deliverable acceptance log – a running diary of actions
taken toward acceptance of deliverables. (See Manage
Acceptance of Deliverables, 4.4.2.)
■ Change control log – a running diary of actions taken
toward acceptance of change control. (See Manage Change
Control Process, 4.4.1.)
■ Lost time – a description of any situation that occurred
that resulted in the Project Team being unable to perform
work.
Other project documents that should be attached to the Status
Report include any Change Control Requests, Deliverable
Acceptance Forms, Meetings Notes, and the Risk Management
Worksheet.
 Section I:4 Project Execution and Control 239
NYS Project Management Guidebook

The Status Report becomes the point of discussion for the

Status Meeting, the regularly scheduled forum where the
Project Manager presents the project status and discusses
issues with the Project Sponsor.

Conduct a regularly-scheduled meeting with the Project Sponsor, using the Status
Report to drive the agenda. If necessary, invite members of the Project Team who
have expertise in a certain area you plan to discuss. Use the meeting time wisely – it is a
great opportunity to have focused, dedicated time with your Project Sponsor and is the per-
fect forum for communicating the status of the project and planning ways to proactively
resolve any issues or concerns.

Even though information is presented to the Project Sponsor at a summary level, it is very
important to record and maintain ALL the detailed, supporting task-level information. Detailed
information can be included as an appendix to your Status Report, or maintained in a sepa-
rate document. Regardless of its location, detailed information should always be made avail-
able to the Project Team, and will be invaluable to you if your Project Sponsor requests clar-
ification or more information.

The Project Manager should periodically assemble the Project

Team to review the status of the project, discuss their accom-
plishments, and communicate any issues or concerns in an
open, honest, constructive forum. These meetings are ideal
opportunities for the Project Manager to gain insight into the
day-to-day activities of Project Team members, especially if the
team is large and individual interaction between the Project
Manager and each team member is infrequent.

The Project Manager should determine the frequency of status meetings based upon
the current state of the project and his/her good judgment. Weekly meetings may be
sufficient during times of normal project activity, but during “crunch times” it may be neces-
sary to gather more frequently. When a deadline is approaching and/or the Project Team
appears to be under stress, consider holding a quick “sanity check” at the beginning of each
day to ensure the team understands and remains focused on the important tasks for that day.

During the meeting the Project Manager should review the

Project Schedule with the team and verify with each member
the work that needs to be accomplished in upcoming weeks.
Part of the meeting should focus on the team’s Progress
240 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Reports, to verify estimates to complete tasks and to discuss

issues that may impact estimates. The Project Manager can
then use information communicated during the Project Team
meetings as input to the Status Report.

The regularly-scheduled Project Team meeting is also a good

forum to recognize individual accomplishments, and to reward
team members for outstanding work.

On large projects where gathering the entire team is prohibitive, Team Leaders can
assemble the appropriate Project Team members for meetings. It will then be neces-
sary for Team Leaders to meet regularly with the Project Manager to ensure all communica-
tion lines remain open.

As documents are gathered and generated during Project

Execution, the Project Manager is responsible for filing them in
the appropriate location in the project repository. The reposi-
tory must be maintained on a continuous basis, as it represents
a history of the project, from its inception through closure. It
will be used as a reference manual throughout the project and
should, therefore, be made available to every member of the
Project Team. At a minimum, the Project Manager should make
sure the following repository items are always current:
■ Project Schedule, including any project financials
■ Status Report, including:
▲ Change control log
▲ Issues log (open and closed)
▲ Deliverable acceptance log
■ Team member Progress Reports
■ Team member timesheets, if used
■ Risk Management Worksheet
■ All correspondence, including any pivotal or decision-
making memos, letters, email, etc.
■ Meeting notes, results and/or actions
 Section I:4 Project Execution and Control 241
NYS Project Management Guidebook

The project repository puts the history of the project at your fingertips, but only if it is
kept up-to-date! It ensures project continuity even if the Project Manager gets pro-
moted or reassigned.

4.4.5 Manage Organizational Change

During Project Planning, the Project Manager and Customer
developed an Organizational Change Management Plan, taking
into consideration the impact the product of the project will
have on the Performing Organization.

During Project Execution, as the product is being produced, the

Project Manager and Customer must evaluate the Organizational
Change Management Plan documented during Project Planning
to be sure it is still current. Because more information about
the specific changes to the organization in terms of people,
process and culture is known, it is quite likely that the plan will
need to be adjusted and more details developed.

It is extremely important for the Project Manager and Project

Sponsor to be actively involved in the change effort, and to
proactively manage communications with the Performing
Organization and Consumers. As specific changes are imple-
mented in advance of and in preparation for the final product of
the project, all involved parties must be made aware of the
anticipated timing of events to give them ample time to prepare
and participate as required.

Managing Organizational Change should include:

■ People: Planned workforce changes must be executed in
careful coordination with, and usually at the direction of,
the Human Resource department of the Performing
Organization, and in conjunction with appropriate
labor/management practices. Specific changes in job
duties, staff reductions or increases, and any changes in
the organizational structure itself should be performed in
accordance with the plan, and should include appropriate
coordination and communication with union representa-
tives and the external agencies involved. These agencies
may include the Department of Civil Service and the
Governor’s Office of Employee Relations. The Project
Manager must work with all of these organizations to
242 Section I:4 Project Execution and Control
NYS Project Management Guidebook

execute the changes as planned and scheduled, being

sensitive to minimize any impact to them.
■ Process: The redesign of existing business processes
affected by the implementation of the product of the
project, and the development of corresponding procedures,
must be managed in coordination with product develop-
ment. The redesigned processes and procedures must align
with the product and associated changes. The implementa-
tion of the new processes, and any associated training or
announcements regarding their introduction into the
Performing Organization, must be integrated with the
product implementation (to coincide with or precede the
product, as appropriate). The Project Manager must
manage these particular aspects of the schedule with
diplomacy and tact. The active involvement of the Project
Sponsor may be required as changes are implemented.
■ Culture: Specific plans were developed based on the
extent of the “culture shock” the product of the project was
expected to introduce into the Performing Organization and
its business strategy, established norms for performance,
leadership approach, management style, approach to
Customers, use of power, approach to decision making,
and employee roles. Using the results of the assessment of
the Performing Organization’s “readiness for change,” the
Project Manager can develop more specific action plans to
increase the organization’s readiness and ability to adapt to
the changes of the project. Most likely, these will include
education and training events that can be targeted to
specific audiences affected by the changes. The plans
should provide information about the changes well in
advance of implementation, so that affected Stakeholders
have ample opportunity to express their concerns. To the
greatest extent possible, the Stakeholders should be given
a “preview” of how the product will actually work. They
should also be given adequate training on how to adjust to
change, how to work in the new environment, or similar
“soft skills.”
The Project Manager, with the active participation and support
of the Customer and Project Sponsor, must be able to manage
the specific activities that will adequately prepare the
Performing Organization for the anticipated changes. (See
Leading the Change Management Effort, Section II:2.2 for addi-
tional information on organizational change management.)
 Section I:4 Project Execution and Control 243
NYS Project Management Guidebook

4.4.6 Manage the Project Team

In order to successfully meet the needs of a project, it is impor-
tant to have a high-performing Project Team made up of indi-
viduals who are both technically skilled and motivated to con-
tribute to the project’s outcome. One of the many responsibili-
ties of a Project Manager is to enhance the ability of each
Project Team member to contribute to the project, while also
fostering individual growth and accomplishment. At the same
time, each individual must be encouraged to share ideas and
work with others toward a common goal. The Project Manager,
then, must be a leader, communicator, negotiator, influencer,
and problem solver! The level of skills and competencies to suc-
cessfully fill these roles helps distinguish good Project
Managers from great ones. (See Section II:2, Leadership, for
more information on Project Manager competencies.)

To maximize the successful performance of the Project Team,

the Project Manager must do the following:

Execute the Training Plan

During Project Planning, the Project Manager evaluated the
skills of each team member to determine whether he/she met
the current and future needs of the project. For each team
member requiring training, the Project Manager established a
Training Plan. The Training Plan includes the method by which
each team member will be trained, and the corresponding
training schedule. During Project Execution, the Project
Manager must review the contents of the Training Plan to be
sure they are still applicable to the project. If additional train-
ing is necessary, it should be added to the plan. If it is deter-
mined that planned training is no longer necessary, it must be
removed from the plan. If new team members have joined the
project since the Training Plan was established, the Project
Manager must evaluate the skill level of the new members to
determine if additional training is needed. In all cases, train-
ing tasks must be added to or removed from both the Training
Plan and the Project Schedule, since they will affect the end
date of the project.
244 Section I:4 Project Execution and Control
NYS Project Management Guidebook

As training takes place during Project Execution, the Project

Manager should update the Training Plan with the names of the
trainees and actual training completion dates. This information
will be used to measure the success of the Training Plan, and
enable the Project Manager to provide input for evaluating
team members and preparing staff performance appraisals. In
addition, the Project Manager should mark the corresponding
Project Schedule tasks as complete.

Allocate Work Properly and Ensure Accountability

A basic responsibility of the Project Manager is to assign work
to the Project Team and ensure that the work is completed
according to the Project Schedule. The Project Manager (or
Team Leaders if the project is large) is responsible for allocat-
ing tasks to appropriate team members at the appropriate
times. A good Project Manager establishes and maintains a
Project Schedule that minimizes team member down time.
Along with the Team Leaders, the Project Manager must con-
tinuously communicate to each member of the team what is
required and by when, and then manage the performance of
each team member in meeting the requirements.

Since the Project Manager is ultimately responsible for the suc-

cess or failure of a project, he/she must direct Project Team
endeavors and encourage team members to be accountable for
their work. Accountability should be formally documented and
measured through the use of team member Progress Reports.
(See Figure 4-4, the New York State Progress Report.) But the
Project Manager must also be willing to communicate face-to-
face with the Project Team. Regular personal communication
is one of the most effective ways to gather input on the status
of project activities, discuss issues and concerns, recognize
good work, encourage and provide support to team members
who are struggling, and build relationships. It is also one of the
primary ways to discover and take action to resolve team mem-
ber performance issues.

Establish a Team Environment

Project Team members must learn to work together to achieve
project goals. They must recognize that there is more to team-
work than simply having team members feel good about each
other. High-performing Project Teams are disciplined. Team
 Section I:4 Project Execution and Control 245
NYS Project Management Guidebook

members participate in all required meetings, are willing to sup-

press their egos for the good of the group, take their assigned
tasks seriously, and continuously strive to improve their skills.
High-performing Project Teams are either empowered to make
decisions or are included in decision-making processes. This is
the essence of project ownership.

Project Managers must develop sufficient management compe-

tencies to be able to create an environment that encourages
team members to excel. The Project Manager may consider
implementing some of the following:
■ Team-Building Activities – these are actions taken
specifically to improve the performance of the entire team.
Activities can range from short items on a meeting agenda
to extended, off-site professionally facilitated sessions.
However implemented, team-building activities provide
opportunities for team members to improve their
interpersonal and working relationships.
■ Team Recognition and Rewards – these are actions
intended to promote, encourage, and reinforce desired
behavior or exceptional performance. Frequently they are
initiated by individuals at management level, but they are
also very effective when initiated by an individual’s peer.
In all cases, recognition programs must be documented
clearly enough so team members understand what level
of performance warrants an award.

Don’t underestimate the power of a box of donuts or a celebratory cake when the
team reaches a major milestone!

The primary objective for establishing an appropriate team

environment is to improve overall project performance. When
team members are encouraged to do their best and are moti-
vated about a project, they are more likely to do whatever is
necessary to improve their individual skills so they are more
efficient and effective in performing their assigned activities.
And when team members understand the importance of inter-
acting with each other, they are more willing to identify and
proactively deal with conflict. Resolving issues early leaves
team members more time for producing actual project work.
246 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Manage Personnel Changes

All organizations change. Personnel may transfer to different
assignments or leave their employers, new individuals may be
added to a Project Team or Customer organization, or the
nature of the project may change, forcing a change in project
responsibilities or reporting structure. A successful Project
Manager has a plan in place to minimize the effect these types
of changes may have on the outcome of the project or the
morale of the Project Team. At a minimum, this plan should
describe what to do when there are changes to the Project
Team, but it should also discuss the actions to take if the
Customers change. The process may be formal or very infor-
mal, depending on the size and needs of the project. In all
cases, changes to the Project Team or Customer will most like-
ly require updates to the Project Schedule.

4.4.7 Manage Project Implementation and Transition

During Project Planning, the Project Manager formulated and
documented a plan for implementing or deploying the product
of the project, and for transitioning the responsibility for the
outcome of the project from the Project Team to the Performing
Organization. During Project Execution and Control, this
Implementation and Transition Plan will be more fully devel-
oped as the product of the project is developed, and as specif-
ic activities in the plan are executed.

During Project Execution and Control, the Project Team will

gain a better understanding of the impact the resulting product
will have on the Performing Organization and Consumers.
Activities begin that are required to prepare the Consumers to
use the product, along with the tasks to prepare the Performing
Organization to support it.

Managing Implementation and Transition includes:

■ Monitoring and ensuring timely completion of all facilities
issues, such as acquiring the necessary physical space,
installing appropriate software, obtaining the appropriate
building permits, etc.
■ Coordinating Customer Acceptance Testing, including
logistics of when and how Customers will test the product
to confirm that it meets requirements before it is formally
implemented and transitioned. Customer testing is one
of the last opportunities for necessary changes to be
 Section I:4 Project Execution and Control 247
NYS Project Management Guidebook

identified and made to the product before rollout. Time for

sufficient Customer testing and any resulting rework that
will affect the Project Team must be incorporated in the
Project Schedule.
■ Managing the steps that need to be taken to ensure
Consumers will be ready to use the product once it is
implemented. These steps must be coordinated with the
Organizational Change Management Plan, and will include
training and orientation on the use of the product. Any
training for Customers or Consumers must be provided
according to the plan and coordinated with other aspects
of the implementation of the product.
■ Managing the detailed implementation. The Project
Manager must monitor implementation activities and make
any necessary adjustments. The implementation will vary
depending upon the needs of the Performing Organization
and the product of the project. Some implementations are
“done” at the flip of the final switch, such as opening a
new highway, or publishing a book. Others are phased
into implementation, like installing an inventory manage-
ment system module-by-module, moving to a new building
floor-by-floor, or implementing a new business process
location-by-location.
■ Managing the steps that need to be taken to ensure the
appropriate individuals are ready to support the product
once it has been implemented and is in use. This may
include negotiating with various internal organizations to
determine the appropriate timing of the transition of
responsibility, assigning specific organizations and individu-
als to support the specific products, and providing neces-
sary training. The Project Manager must carefully manage
the point in implementation that the Performing Organiza-
tion takes responsibility for production problems, “help” or
trouble calls, and for resolving the problems, and ensure
that all pre-requisites for transition have been met – for
example, performance standards, quality standards, etc.
■ Managing production of all necessary documentation. The
Project Manager must ensure that all documents or
records that will be provided with the product are pro-
duced. Examples of documentation include:
▲ User manuals
▲ On-line help
▲ Assembly or usage instructions
248 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Overall, the Project Manager must be sure each required activ-

ity is carried out according to the Implementation and
Transition Plan and schedule, and to immediately communicate
any discrepancies to the Project Sponsor.

Deliverable

◆ Product of the Project – at the end of Project Execution,

all required deliverables as documented in the Project Plan
have been produced by the Project Team and approved by
the Project Sponsor. The product of the project, successful-
ly transitioned from the Project Team to the Performing
Organization, is the end result of Project Execution and
Control.

4.5 GAIN PROJECT ACCEPTANCE

Purpose

The purpose of Gain Project Acceptance is to formally

acknowledge that all deliverables produced during Project
Execution and Control have been completed, tested, accepted,
and approved by the project’s Customers and the Project
Sponsor, and that the product or service the project developed
was successfully transitioned from the Project Team to the
Performing Organization.
Roles
Formal acceptance and
approval also signify that
the project is essentially ● Project Manager
over, and is ready for ● Project Sponsor
Project Closeout.
● Project Team Members
● Customer Representatives
● Customer Decision-Maker
 Section I:4 Project Execution and Control 249
NYS Project Management Guidebook

Tasks

4.5.1 Conduct Final Status Meeting

Once the product of the project has been successfully transi-
tioned to the Performing Organization, the Project Manager
should prepare the final status report and conduct the final sta-
tus meeting. The Project Schedule must be up to date for all
completed project and project management lifecycle phases.
This is the final opportunity for all participants to confirm that
the product of the project has been successfully developed and
transitioned. Any out-
standing issues or action The tasks to
Gain Project Acceptance are:
items must be transi-
tioned from the Project 4.5.1 Conduct Final Status Meeting
Team to the Performing 4.5.2 Gain Acceptance Signature from
Organization. Project Sponsor

4.5.2 Gain Acceptance Signature from Project Sponsor

As the deliverables of the project are produced and accepted,
approval signatures are gained from the Project Sponsor and
Customer Decision-Makers. Following the final status meeting,
the Project Manager must obtain the Project Sponsor’s signa-
ture one final time, indicating acceptance of the project to date,
and indicating approval to proceed to Project Closeout. (See
Figure 4-7, New York State Project Acceptance Form.) If the
Project Sponsor does not accept the project, he/she must indi-
cate the specific reason(s) for rejection. The Project Manager
is then responsible for resolving the issues and seeking the
Project Sponsor’s acceptance again.

Deliverable

◆ Signed Project Acceptance Form – a formal document

indicating Project Sponsor acceptance of all project deliv-
erables and approval to proceed to Project Closeout.
250 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Figure 4-6 New York State Project Acceptance Form

New York State

Project Acceptance Form

PROJECT IDENTIFICATION

Project Name: _______________________ Date: ________________________________

Project Sponsor: _____________________ Project Manager: _____________________

Enter the Project Name.

Enter the current Date.
Enter the name of the Project Sponsor.
Enter the name of the assigned Project Manager.

PROJECT SPONSOR INFORMATION

Project Sponsor Name: ______________________________________________________
Action: Approve: ■ Reject: ■
Project Sponsor Comments:

Project Sponsor Signature: ___________________________________________________

Date: _____________________________________________________________________

Provide the above information to the Project Sponsor. The Project Sponsor should either
accept or reject the project and include any comments. If the Project Sponsor is rejecting the
project, the reason for rejection must be provided. If the project is being approved, the Project
Sponsor must sign the form and enter the Date approved.

PROJECT MANAGER INFORMATION

___________________________________________
Name (Print)

___________________________________________ ___________________________
Signature Date

Once the project has been approved, the Project Manager should indicate agreement by
providing a Signature and Date.
 Section I:4 Project Execution and Control 251
NYS Project Management Guidebook

Project Execution and Control

End-of-Phase Checklist

How to Use
Use this checklist throughout Project Execution and Control to
help ensure all requirements of the phase are met. As each item
is completed, indicate its completion date. Use the Comments
column to add information that may be helpful to you as you
proceed through the project. If you elect NOT to complete an
item on the checklist, indicate the reason and describe how the
objectives of that item are otherwise being met.

Figure 4-7
Item Description Page Completion Comments Reason for NOT
Date Completing
Conduct Execution and 204
Control Kick-off
Ensure team members have 204
whatever is required to perform
their tasks
Meet with each team member to 204
convey roles and responsibilities
Distribute copies of all project 205
materials and deliverables to
all team members
Hold orientation sessions for 205
new members
Review previous deliverables 205
and components of Project Plan
Schedule time and location of 206
kick-off meeting
Prepare materials for distribution 206
at meeting
Invite appropriate attendees 206
Prepare meeting presentation 206
and agenda
Designate meeting scribe 206
Conduct kick-off meeting 206
252 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Item Description Page Completion Comments Reason for NOT

Date Completing
Distribute meeting notes to 206
all attendees
Update the project repository 206
Manage CSSQ 209
Update and analyze the Project 211
Schedule as needed
Conduct peer review of 215
deliverables, if appropriate
Implement quality checklists 216
Conduct project audits 217
Manage the budget by 222
monitoring financial
performance regularly
Update project repository 222
Monitor and Control Risks 225
Review identified risks with 225
Project Team and Project
Sponsor
Re-evaluate each risk 226
Update Risk Management 226
Worksheet regularly
Execute contingency plans or 226
modify them, if necessary
Create new contingency plans 227
to accommodate new risks
Update project repository 227
Manage Project Execution 228
Execute change control process 228
when necessary
Gain acceptance and approval 231
of all deliverables
Identify and resolve issues, 234
escalating them if necessary
Provide timely communications 236
according to Communications
Plan
Prepare Project Status Report 237
regularly
 Section I:4 Project Execution and Control 253
NYS Project Management Guidebook

Item Description Page Completion Comments Reason for NOT

Date Completing
Conduct status meeting with 238
Project Sponsor regularly
Ensure status meetings are 239
being held with Project Team
regularly
Conduct training for support 242
personnel
Conduct training for Consumers 242
Communicate rollout information 242
Conduct training for Project 243
Team members and update
Training Plan
Allocate and assign work to 244
Project Team members
Conduct team building activities 245
Reward team members 245
Manage Project Team member 246
changes
Manage changes to Customer’s 246
organization
Acquire necessary physical 246
space and equipment to
support the product
Transition product to 246
Performing Organization
Update the project repository 246
Gain Project Acceptance 248
Prepare final Status Report 249
Prepare formal Project 249
Acceptance Form
Conduct final Status Meeting 249
with Project Sponsor and
present Project Acceptance Form
Resolve any issues 249
Gain final project acceptance 249
signature from Project Sponsor
254 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Measurements of Success

The ultimate measurements of success for Project Execution

and Control are the product acceptance by the Customer, and
project acceptance by the Project Sponsor.

Meanwhile, the Project Manager can still assess how success-

fully the project is proceeding through Project Execution and
Control by utilizing the measurement criteria outlined below.
Because the processes in this phase (between Kick-off and
Acceptance) are iterative, continuous and concurrent, the
measurements for these processes need to be taken at regular
intervals – probably coincidental with project status meetings.
More than one “No” answer indicates a serious risk to the even-
tual success of your project.
 Section I:4 Project Execution and Control 255
NYS Project Management Guidebook

Figure 4-8

Process Measurements of Success Yes No

Conduct Project Execution Did you receive confirmation from ALL Project Team
and Control Kick-off members that they agree with their role descriptions,
and that they understand and agree with the project
objectives, risks and timetables as recorded in the
kick-off meeting notes?
Manage CSSQ Do your team members agree that the estimates to
complete for all open tasks are accurate?
Has your team implemented any “lessons learned”
from either the peer review or the project
audit process?
Is the Project Sponsor aware of the latest total current
budget for the project?
Is your schedule current?
Monitor and Control Risks Have you adjusted the risk priority level for any risks
on the Risk Management Worksheet?
Manage Project Execution Were all changes to the scope, schedule, cost or
quality parameters of the project made with a signed
Change Control Request?
Have all deliverables been presented to decision
makers with prior preview of the deliverable
in progress?
Is the deliverable approval cycle less than or equal to
the period of time identified in the Acceptance
Management Plan?
Are all project issues recorded in the Issue Log in
the Project Status Report?
Is the Status Meeting being held as often as indicated
in the Communications Plan?
If any Customer Decision-Makers are consistently
absent from the status meetings, have they
designated a replacement?
Are you confident that the organizational
preparedness for the project is proceeding according
to the plan you agreed to?
Are your team members showing no lost time in
their Progress Reports?
Gain Project Acceptance Do you have a Project Acceptance Form signed by
your Project Sponsor accepting the project?
256 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Phase Risks/Ways to Avoid Pitfalls

Project Execution and Control is where the rubber meets the

road. In the immortal words of Yoda, it’s “Do! Or do not! There
is no try.”

What are some of the key elements of Project Execution and

Control that require the most attention? Not surprisingly, this
phase has the most pitfalls and the most areas for considera-
tion. The following table identifies processes and tasks which
have pitfalls highlighted in this section.

Figure 4-9
Process Task Why is it important?
Manage CSSQ Manage Project Schedule Schedule slippage is the most visible sign of
a project in trouble.
Manage Project Manage Issues “That malfunctioning little #@?*!, this is all his
Execution fault.”
Maybe, maybe not. But it’s still your responsi-
bility to make sure the actual problem is fixed.
Manage Acceptance of “Don't be too proud of this technological
Deliverables terror you've constructed.”
Your product is only as good as your
Customer thinks it is.
Execute Communications Plan “Don't get technical with me!” Communicate
with your Customers as you would have them
communicate with you.
Manage Organizational You may have created the most awesome
Change/Manage Product product in the known universe, but what good
Implementation and Transition is it if the organization is not ready to utilize it?
Manage the Project Team “Who's the more foolish... the fool or the fool
who follows him?”
With some teams, it’s hard to tell who’s
leading whom. Don’t let that happen to you!
 Section I:4 Project Execution and Control 257
NYS Project Management Guidebook

PITFALL #1 – YOUR SLIP IS SHOWING (OR YOU WISH YOU WERE A

DAY LATE AND A DOLLAR SHORT!)
OK, the unthinkable has happened. Your project is actually
behind schedule. Every week, something seems to happen,
something quite outside everyone’s control. You analyze,
advise, reason, plead – and yet here you are, adjusting your
deliverable dates once again. And the worst part of it is, deep
down you really don’t know why or, more importantly, what you
can do about it.

Well, there is no need to panic. After all, you can always turn to
the wise old Project Manager in the office across the hall who
is ready and willing to help you, right? No? Oh well, then, you
can always panic.

But before you do, let’s figure out what’s wrong. There may be
myriad reasons why the schedule slips, but some of them are
much more likely to occur than others. Broadly speaking, the
fault may lie not in our stars, but in:
■ Our customers. They love to change their minds – all the
time!
■ Our teammates. They may not be prepared, or may not
have “the right stuff.”
■ Our environment. We may be camouflaged for desert war-
fare, but find ourselves fighting through the swamp.
■ Our selves. In the final analysis, the buck always stops
with the Project Manager. So whatever is going wrong –
it’s probably your fault (at least for not managing it
properly!).

Now let’s tackle each problem in turn, starting with the most
likely one.

Problem: Management shortcomings.

Solution: C3PO said, “It's against my programming to imper-
sonate a Deity!” But many Project Managers try, or feel they
ought to. The tough part is that Project Manager’s failures tend
to disguise themselves as something else. When the Project
Manager does not apply the right methodology to requirements
gathering, and does not apply the right discipline to document-
ing its outcome, the result may appear to implicate Customers.
When the Project Manager does not set up the right Project
Team structure, and does not apply the right discipline to deliv-
ering assignments to all team members, the result may appear
258 Section I:4 Project Execution and Control
NYS Project Management Guidebook

to imply an incompetent Project Team. When the Project

Manager does not select the right technology, or does not
secure enough support from the Performing Organization, the
result may appear to indicate an unfavorable environment.

But the odds are, when something is going wrong, you should
“start with the man in the mirror and ask him to change his
ways.”

Problem: The requirements are not clear, or they are con-

stantly changing.
Solution: Well, it takes no genius to realize that you can’t hit a
target you can’t see or catch. But what can you DO about it?
For starters, you need to figure out whether (a) the require-
ments were not defined clearly from the beginning or (b) the
Customers keep changing their minds.

In the first case, you need to hit the brakes hard, and then redi-
rect all resources at your command to re-define the require-
ments. Go back to the Customers, and re-confirm or figure out
what it is they REALLY want. Since the original requirements-
gathering process obviously did not work, first you need to ana-
lyze the way you went about gathering, defining and document-
ing the requirements, and try to improve it this time around.

In the second case, you need to have a chat with your Project
Sponsor. Explain that by not sticking to their agreement (you
do have their signature accepting the requirements, right?) the
Customers are jeopardizing the project in all its parameters
(Cost, Scope, Schedule and Quality), and, as a result, the
Project Sponsor has essentially three options: (1) stop the
requirements dithering, (2) expand the Project Budget to
accommodate the process (warning: you will still need option 1
eventually!) or (3) cancel the project now (with small overruns)
or later (with major overruns).

In either case, change control is key. As soon as you detect an

increase in scope, even if you still don’t know the full extent of
it, you need to start the change control process. Remember that
change control is not a bad thing; it’s just a process to manage
enhancements as well as risks and mistakes. Changes are often
unavoidable, as in the case of legislative initiatives or techno-
logical advances, and change control serves as a mechanism to
assure everyone is aware of and agrees to all deviations from
the plan.
 Section I:4 Project Execution and Control 259
NYS Project Management Guidebook

Problem: Project Team members don’t produce.

Solution: First, check to make sure that the fault is not with
the environment and/or management. It most probably is. But
it just may be possible that your folks do not have the right
skills, knowledge or tools to get the job done. Of course, that
should be no surprise to you, and you should have had your
team training plan going full swing, right? Well, nobody’s per-
fect. The important thing to do is to separate what you can fix
from what you can’t. For example, if the folks do not have the
right tools to do the job – that can be fixed, even if you have to
go to the ends of the Earth to get them. Likewise, if the team
members do not have the right knowledge – well, that can be
fixed too, although by now it may be too late. But if you find
that you are stuck with a turkey who just can’t do the job, you
have a bigger problem. The first thing to do is to try a variety
of managerial approaches with the person. Everyone is differ-
ent, and some people react to certain management styles bet-
ter than others. But if after deploying your whole managerial
repertoire the person still comes up short, the best thing to do
is to consult with your manager, or another “seasoned” Project
Manager, and understand how such situations have been han-
dled in your organization in the past.

Problem: The project environment is not what you expected.

Solution: This problem can take one of two flavors. One, the
Performing Organization may not be ready for your project, and
is not providing you with the support infrastructure you require.
Two, the technology you are trying to utilize is wrong, imma-
ture, or not properly implemented.

For the first eventuality, sound the alarms! This is when you
need that Organizational Change Management Plan, and your
Implementation and Transition Plan. You will need to have
another one of those chats with your Project Sponsor. Explain
how the team is doing all it can to deliver the product, but the
support structure is failing you all around. Make specific sug-
gestions as to what you need, and how it could be accomplished.

For the second eventuality, you must make a quick decision

whether the technology can be fixed, or needs to be replaced.
Some technological advances sound great in concept, but are
just not ready for prime time. Try to avoid “bleeding edge” tech-
nologies altogether, but if you do get entangled in one, be ruth-
less – going back and retracing your steps using an older, less
sexy but more stable technology may pay off in productivity
gains for the rest of the project, compared with slugging
through the immature mire of somebody’s half-baked product.
260 Section I:4 Project Execution and Control
NYS Project Management Guidebook

PITFALL #2 – YOU DROP THE ISSUE BALL

In the course of the project, many issues come up. By defini-
tion, issues have a potentially adverse impact on the project’s
CSSQ. Most of them are solved internally, within the Project
Team, but some require actions or decisions on the part of
other players with whom you may have little influence.

The important fact to remember is that project issues are the

Project Manager’s responsibility. No matter how clear you are
in communicating the issue, no matter how little say you have
in its resolution – it remains your responsibility. Identifying
another person as a party who can resolve the issue does not
abdicate your responsibility to follow it through. Even obtaining
consensus that another agency unit should, or a promise that
they would, resolve it does not remove your obligation to track
the issue to a successful conclusion.

One of the most natural pitfalls is to assume that once you have
successfully convinced everyone that someone else has to solve
the issue, you are done. On the contrary! Because it is now out
of your control, you must be all the more dogged in the pursuit
of its resolution. Tell the responsible parties that you’re not
going away. Keep asking them what you can do to help get the
issue resolved, but keep tracking their progress – or lack there-
of – on your status reports. Use all the tools in the project
Communications Plan to continuously shine light on the issue.

PITFALL #3 – YOU FALL INTO THE PROJECT BLACK BOX

Scene 1 – You employ the latest facilitation techniques to
extract all possible requirements from your Customers, even
requirements they did not know they had.

Scene 2 – Your team performs wonders to design the perfect

product, exactly as the Customers requested, and works like
the dickens to develop it exactly as envisioned.

Scene 3 – You beam with pride as you deliver your masterpiece

to an eager Customer.

Scene 4 – You slink away in shame as the Customer continues

to rant and rave about all the features that the product does not
have even though they told you about them all along.
 Section I:4 Project Execution and Control 261
NYS Project Management Guidebook

What happened? You “black-boxed” your project. The Customers

saw you when you were gathering the requirements. Then you
and your team went away into the project black box, and only
came out in time to show the Customer the finished product. The
problem is, things changed in the interim! The Customer cast of
characters may have changed. The business conditions may
have changed. The expectations may have changed. And you did
not keep in synch. Worse, you did not keep your Customers in
synch with your project. You just assumed that because you are
giving your Customers exactly what they originally asked for,
they would like it. But you know what happens when you
assume.

The simple remedy for the black box phenomenon is keeping

the Customers involved every step of the way. You should con-
stantly show select Customers project deliverables as they are
being developed. Not so they can change their minds but so
they know what to expect on delivery. You certainly want to
minimize the number of decision-makers who will accept and
sign off on your deliverables (chasing signatures of more than
a couple of people is a pain) but you want to maximize the num-
ber of people who review, or even preview your stuff.

PITFALL #4 – YOU REMAIN INCOMMUNICADO

Once the project really gets going in Project Execution, it is
very easy to focus internally – on Project Team dynamics, on
technical challenges, on deliverables and schedules – to the
exclusion of everything else; yet it is also important to pay
attention to the externals. After all, as Project Manager, you
are the main link between the project cocoon and the big
world outside.

Executing all aspects of your Communications Plan is your

responsibility, and nothing is more important than accurate and
frequent status reporting. A Project Status Report is the most
effective way for all Stakeholders to remain closely connected
to and aware of the project’s progress – and potential problems.

The two most important questions the Project Status Report

must answer are:
1. What is the latest, best available estimate for the remain-
ing work, and how does it compare with the schedule?
262 Section I:4 Project Execution and Control
NYS Project Management Guidebook

2. What issues have come up that may affect the project

Cost, Scope, Schedule, or Quality, and what is being done
about them?

These questions are far more important to the eventual success

of the project, and to minimizing surprises along the way, than
the usual dissertations on project status and enumerations of
immediate tasks at various levels – not that the status report
should not include them. But after collecting, analyzing and
evaluating the status information, the Project Manager’s job is
to make decisions or suggestions regarding changes to be made
– if necessary – to keep the project on track.

Of course, the best status report in the world will make no

impact if there is no one there to hear it. A regularly scheduled
status meeting, attended by as many members of the Project
Team as practical, dedicated to a thorough review of the status
report, is irreplaceable.

PITFALL #5 – YOU CONFUSE DESIRE WITH ABILITY

Your customers sincerely want what your project is developing.
They demonstrated their desire for it by committing funds to the
project; by allocating resources to the Project Team; and by
devoting time to meetings, reviews, and other project-related
activities. And yet they may be totally unprepared to actually
make use of it, or even to implement it at all.

But whose fault do you think it will be when they realize their
inability to utilize it? That’s right, yours. So it is up to you to
make sure that someone determines organizational readiness
for the product or service, and that someone prepares for a
smooth transition of the product from the Project Team to the
Performing Organization. Notice that it does not say you have
to do it – just that you have to make sure it gets done. And that
requires including in the Project Plan that organizational readi-
ness assessment and transition planning need to be done.
 Section I:4 Project Execution and Control 263
NYS Project Management Guidebook

PITFALL #6 – THEY BLINDED YOU WITH SCIENCE (OR TECHNOLOGY)

There is no law that says that a Project Manager must be a
master of whatever technology the project employs.
Nevertheless, you will be called upon to manage numerous
technical decisions on the project.

A frequent pitfall in those circumstances is over-delegating

those decisions to the more technical members of the team, or
accepting the recommendations of your technical experts on
blind faith, both of which result in unacceptable loss of control.
Instead, make the team explain the issue and alternative solu-
tions to you. As a reasonably intelligent person, you should be
able to understand the concepts by listening and asking ques-
tions. If, however, the technical folks can’t explain to your sat-
isfaction why they are advocating a certain position – watch
out! It is indicative of a position dictated more by desire than
by reason, or of poor understanding on the part of the supposed
experts. Get a second opinion, and trust your own instincts.

PITFALL #7 – THE ENDLESS APPROVAL CYCLE LEADS YOU

BY THE NOSE
You thought you were smart. You thought you were ready. You
knew how finicky your Customer was, so you built into your
schedule not one, not two, but three approval cycles – one for
an informal pre-screen, one for a formal review, and the last
one for formal approval. You built in time for re-work based on
the review. You even indicated in your acceptance parameters
that you were only willing to wait so many days for the
approval. Yet here you are, a month and a half past the first
scheduled deliverable – which your team presented right on
time – and you still don’t have the proper signatures on the
approval form. What happened?

Any of a number of things. You may be stuck in a never-ending

fine-tuning cycle (that’s like hanging a picture for your mother-
in-law: “A little more to the left. No, that’s too far! Back a bit to
the right. Hmm… How about a little higher? No, that’s too
high!” etc., etc.) Or you may be chasing signatures in a cir-
cle, with every person telling you that he can’t sign until the
other person does (that’s like trying to solve a problem with
your PC: “Install an updated driver before we swap the modem”
– “No, flash the chip set before we upgrade the driver” – “No,
update the operating system first!” – “Looks like you need to
replace the motherboard.”) Or the exalted Grand Poobah of the
264 Section I:4 Project Execution and Control
NYS Project Management Guidebook

Customer tribe may just be too busy to pay any attention to

your puny little project.

But the common thread among all the possibilities is that you
are just being too darned nice. You may have said that you
would only allow five business days for deliverable approval,
but what do you do after the five days expire? You may have
asked for particular signatures on the approval form, but what
do you do if the signatures do not appear?

You fight the approval war on two levels: tactical, and opera-
tional. Tactically, you should use two weapons: status report
and change control. Highlight the acceptance cycle in your
Status Report, and start the change control process when your
criteria are not met. Be tough, and insist on the rules being fol-
lowed. And finally, from the operational perspective, you
should just make such a nuisance of yourself that the approvers
would sign anything rather than be pestered by you again.

? Frequently Asked Questions

How can a Project Manager manage the Project Schedule

if team members don’t accurately report when they are
behind?

The key to accurate forecasting and precise reporting is the

“Estimate to Complete” column on the Progress Report. The
team members don’t have to report that they are behind; you
(and most likely, your team leaders) need to make sure that
they come up with an accurate estimate to complete, and the
math will tell you the rest. How do you know if their estimate
is accurate? Unless you (or your team leader) are involved in
the details of the task, and understand the technology used to
perform it, you won’t – the first time.

By next time, you will know the team member’s bias – unbridled
optimism (forecasting too little), gloomy pessimism (forecast-
ing way too much) or random don’t-have-a-clueism (forecasting
erratically), so you can “guide” them to a better estimate and
then hold them accountable for it.

The thing to remember is, you can’t just take what you’re given.
You have to question the estimate to complete, you have to
compare it with other tasks, and you have to get it to the point
where all of you are comfortable with it.
Team Building in Project Management
Introduction

One of the most important developments in management during the 1970's has been the
widespread application of project teams to a variety of complex tasks. Project managers quickly learn
the critical significance of the effective project team and the role of team building activities in
facilitating project management performance. In fact, the difference between successful and
unsuccessful performance can often be linked to the effectiveness of the project team. We expect
that the 1980's will surely witness an increased emphasis on team building.

Varney2 notes that the importance of developing effective teams comes from three major forces.
First, there are more specialists/experts within organizations whose talents need to be focused and
integrated into a larger task. Second, more organizational members want to become increasingly
involved in their total work environment. Third, the benefits of people working together can result in
important synergy and creativity. Increasing task complexity and complicated environmental
interfaces also encourage the development of effective teams. Effective team building also leads to
higher levels of job satisfaction.

Team Building Defined

Team building is the process of taking a collection of individuals with different needs, backgrounds
and expertise and transforming them by various methods into an integrated, effective work unit. In
this transformation process, the goals and energies of individual contributors merge and support the
objectives of the team.

The concept of team building becomes critically important as bureaucratic hierarchies decline and
horizontally-oriented teams and work units become increasingly important. In most cases, team
building involves relationships among peers with a wide diversity of expertise.

Major Barriers To Project Team Development

In a recent exploratory field probe with over 90 project leaders, we attempted to identify some of
the major barriers project leaders experience in building effective teams. The project leaders
represented several types of organizations and technologies. Most of the respondents to our probe,
however, were in research and development, construction, and engineering projects and computer
information system implementors. A more comprehensive study is planned to develop detailed data
on team-building barriers. Our purpose here is to illustrate some of the most common major barriers
to team-building efforts and suggest alternative approaches for handling these problems.

Differing Outlooks, Priorities, Interests and Judgments of Team Members

A major barrier is that team members often have different professional objectives and interests. Yet
project accomplishment often requires team members to place “what's good for the project” above
their own interest areas. When team members are reluctant to do so, severe problems develop in
building an effective team. This problem is compounded when the team relies on support groups
which have different interests and priorities.

Role Conflicts

1
Team development efforts also can be thwarted when role conflicts exist among the team members.
Role conflicts are most likely to occur when there is ambiguity about who does what within the
project team and between the team and external team support groups. Overlapping and ambiguous
role responsibilities are also major contributors to role conflicts.

Project Objectives/Outcomes Not Clear

One of the most frequently cited team-building barriers is unclear project objectives. As one project
leader remarked:

How can you implement a team building program if you're not clear on what the objectives for the
project really are? Let's face it, many teams are muddling along on fifty percent of their potential
because no one is really clear on where the project should be headed.

In R&D and computer systems projects, objectives may be formulated by managers or clients
external to the team. Moreover, if objectives are not explicit, it becomes difficult, if not impossible,
to clearly define roles and responsibilities.

Dynamic Project Environments

A characteristic of many projects is that the environments in which they operate are in a continual
state of change. For example, senior management may keep changing the project scope, objectives,
and resource base. In other situations, regulatory changes or client demands for new and different
specifications can drastically affect the internal operations of a project team. Disruptive
environments are frequently a characteristic of project teams. Finally, the rate by which a team
“builds up” to its full manpower base may present team-building barriers.

Competition Over Team Leadership

Initially we were somewhat surprised at the number of project leaders who mentioned competition
for a leadership position. They indicated that this barrier was most likely to occur in the early phases
of a project of if the project ran into severe problems and the quality of team leadership came into
question. Obviously, both cases of leadership challenge can result in barriers (if only temporary) to
team building. Frequently, these challenges were covert challenges to the project leader's ability.

Lack of Team Definition and Structure

One of the most frequently mentioned barriers of all was the lack of a clearly delineated team to
undertake a project. We found this barrier to be most likely to occur among computer system
managers and R&D project leaders. A common pattern was that a work unit (not a project team)
would be charged with a task but no one leader or team member was clearly delegated the
responsibility. As a consequence, some work-unit members would be working on the project but not
be entirely clear on the extent of their responsibilities.

In other cases, a poorly defined team will result when a project is supported by several departments
but no one person in these departments is designated as a team member and departmental
coordinator. Such an approach results in the project leader being unclear on whom to count for
support. This often occurs, for example, when a computer systems project leader must rely on a
“programming pool.”

Team Personnel Selection

Another barrier was centered on how team members were selected. In some cases, project
personnel are assigned to the teams by functional managers, and the project manager has little or no

2
input into the selection process. This, of course, can impede team development efforts, especially
when the project leader is given available personnel versus the best, hand-picked team members.
The assignment of “available personnel” can result in several problems, e.g., low motivation levels,
discontentment and uncommitted team members. We have found, as a rule, that the more power
the project leader has over the selection of his/her team members, the more likely team-building
efforts will be fruitful.

Credibility of the Project Leader

Team-building efforts were hampered when the project leader suffered from poor credibility within
the team or from important managers external to the team. In such cases, team members are often
reluctant to make a commitment to the project or the leader. Credibility problems may come from
poor managerial skills, poor technical judgments or lack of experience relevant to the project.

Lack of Team Member Commitment

Lack of commitment to the project was cited as one of the most common barriers. Lack of
commitment can come from several sources, such as; the team members’ professional interests lie
elsewhere; the feeling of insecurity being associated with projects; the unclear nature of the rewards
which may be forthcoming upon successful project completion; and from intense interpersonal
conflicts within the team. One project leader made this comment to us:

Let's face it—some personnel are not suited for project work. Some can't stand the ambiguous, fluid
nature of projects while others simply rather work alone or with a small group of colleagues they've
developed close working relationships with over a period of years.

As we suggested earlier, the nature of many projects requires the disruption of valued, existing
routine work relationships of team members. As a consequence, they may not feel committed to the
project.

Other issues which can result in uncommitted team members are suspicious attitudes which may
exist between the project leader and a functional support manager or between two team members
from two warring functional departments. Finally, we found that low commitment levels were likely
to occur when a “star” on a team “demanded” too much deference from other team members or too
much pampering from the team leader. One team leader put it this way:

A lot of teams have their prima donnas and you learn to live and function with them. They can be
critical to overall project success. But some stars can be so demanding on everyone that they'll kill
the team's motivation.

Communication Problems

Not surprisingly, we found that poor communication was a major enemy to effective team
development efforts. Poor communication existed on three major levels. First, several mentioned the
problems of communication among team members and between the project leader and the team
members. Often the problem was caused by team members simply not keeping others informed on
key project developments. Yet the “whys” of poor communication patterns were far more difficult to
determine. It can result from low motivation levels, poor morale, or carelessness. We also discovered
that poor communication patterns between the team and support groups could result in severe
team-building problems, as did poor communication with the client. Poor communication practices
often led to unclear objectives and poor project control, coordination, and work flow.

Lack of Senior Management Support

3
Many of the project leaders indicated that senior management support and commitment often were
unclear and subject to waxing and waning over the project life cycle. This behavior can result in an
uneasy feeling among team members and lead to low levels of enthusiasm and project commitment.
Two other common problems frequently noted were that senior management would not help set the
right environment for the project team at the outset, nor would they give the team timely feedback
on their performance and activities during the life of the project.

Overcoming Team Building Barriers

For each of the major team-building barriers identified, several suggestions can be advanced for
either minimizing or eliminating them. Table 1 lists the barriers and the suggested handling
approaches.

Table 1
Barriers To Effective Team Building And Suggested Handling Approaches

Barrier Suggestions for Effectively Managing Barriers (How to Minimize or Eliminate Barriers)

Differing Outlooks, Make effort early in the project life cycle to discover these conflicting differences. Fully
Priorities, Interests, and explain the scope of the project and the rewards which may be forthcoming upon
Judgments of Team successful project completion. Sell “team” concept and explain responsibilities. Try to
Members blend individual interests with the overall project objectives.

Role Conflicts As early in a project as feasible, ask team members where they see themselves fitting into
the project. Determine how the overall project can best be divided into subsystems and
subtasks (e.g., the work breakdown structure). Assign/ negotiate roles. Conduct regular
status review meetings to keep team informed on progress and watch for unanticipated
role conflicts over the project's life.

Project Objectives/ Assure that all parties understand the overall and interdisciplinary project objectives.
Outcomes Not Clear Clear and frequent communication with senior management and the client becomes
critically important. Status review meetings can be used for feedback. Finally, a proper
team name can help to reinforce the project objectives.

Dynamic Project The major challenge is to stabilize external influences. First, key project personnel must
Environments work out an agreement on the principal project direction and “sell” this direction to the
total team. Also educate senior management and the customer on the detrimental
consequences of unwarranted change. It is critically important to forecast the
“environment” within which the project will be developed. Develop contingency plans.

Competition Over Team Senior management must help establish the project manager's leadership role. On the
Leadership other hand, the project manager needs to fulfill the leadership expectations of team
members. Clear role and responsibility definition often minimizes competition over
leadership.

Lack of Team Definition and Project leaders need to sell the team concept to senior management as well as to their
Structure team members. Regular meetings with the team will reinforce the team notion as will
clearly defined tasks, roles and responsibilities. Also, visibility in memos and other forms
of written media as well as senior management and client participation can unify the
team.

4
Project Personnel Selection Attempt to negotiate the project assignments with potential team members. Clearly
discuss with potential team members the importance of the project, their role in it, what
rewards might result upon completion, and the general “rules-of-the-road” of project
management. Finally, if team members remain uninterested in the project, then
replacement should be considered.

Credibility of Project Leader Credibility of the project leader among team members is crucial. It grows with the image
of a sound decision maker in both general management and relevant technical expertise.
Credibility can be enhanced by the project leaders' relationship to other key managers
who support the team's efforts.

Lack of Team Member Try to determine lack of team member commitment early in the life of his project and
Commitment attempt to change possible negative views toward the project. Often, insecurity is a majo
reason for the Jack of commitment; try to determine why insecurity exists, then work on
reducing the team members' fears. Conflicts with other team members may be another
reason for lack of commitment. It is important for the project leader to intervene and
mediate the conflict quickly. Finally, if a team member's professional interests lie
elsewhere, the project leader should examine ways to satisfy part of the team member's
interests or consider replacement.

Communication Problems The project leader should devote considerable time communicating with individual team
members about their needs and concerns. In addition, the leader should provide a vehicl
for timely sessions to encourage communications among the individual team
contributors. Tools for enhancing communications are status meetings, reviews,
schedules, reporting system, and colocation. Similarly, the project leader should establish
regular and thorough communications with the client and senior management. Emphasis
is placed on written and oral communications with key issues and agreements in writing.

Lack of Senior Management Senior management support is an absolute necessity for dealing effectively with interface
Support groups and proper resource commitment. Therefore, a major goal for project leaders is to
maintain the continued interest and commitment of senior management in their projects
We suggest that senior management become an integral part of project reviews. Equally
important, it is critical for senior management to provide the proper environment for the
project to function effectively. Here the project leader needs to tell management at the
onset of the program what resources are needed. The project manager's relationship wit
senior management and ability to develop senior management support is critically
affected by his own credibility and the visibility and priority of his project.

Suggestions For Handling The Newly Formed Team

A major problem faced by many project leaders is managing the anxiety which usually develops
when a new team is first formed. This anxiety experienced by team members is normal and
predictable. It is a barrier, however, to getting the team quickly focused on the task. In other words, if
team members are suffering from anxiety, their attention consciously or subconsciously will be
focused on the resolution of their own anxieties rather than on the needs of the project.

This anxiety may come from several sources. For example, if the team members have never worked
with the project leader, the team members may be concerned about his leadership style and its
effect on them. In a different vein, some team members may be concerned about the nature of the
project and whether it will match their professional interests and capabilities. Other team members

5
may be concerned whether the project will be helpful or a hindrance to their career aspirations. Our
experience indicates that team members can also be highly anxious about lifestyle/work-style
disruptions which the project may bring. As one project manager recently remarked to one of the
authors:

Moving a team member's desk from one side of the room to the other can sometimes be just about
as traumatic as moving someone from Chicago to Manila to build a power plant.

As the quote suggests, seemingly minor changes can result in unanticipated anxiety among team
members.

Another common concern among newly formed teams is whether or not there will be an equitable
distribution of the work load among team members and whether each member is capable of pulling
his/her weight. In some newly formed teams, team members not only might have to do their own
work but they also must train other team members. Within reason this is bearable, necessary and
often expected. However, when it becomes excessive, anxiety increases and morale can fall.

We've found that certain steps taken early in the life of a team can pay handsome dividends in terms
of handling the above problems. First, we recommend that the project leader at the start of the
project talk with each team member on a one-to-one basis about the following:

1. What the objectives are for the project.

2. Who will be involved and why.

3. Importance of the project to the overall organization or work unit.

4. Why the team member was selected and assigned to the project. What role will he/she perform.

5. What rewards might be forthcoming if the project is successfully completed.

6. A candid appraisal of the problems and constraints which are likely to be encountered.

7. What are the rules-of-the-road which will be followed in managing the project, e.g., regular status
review meetings.

8. What suggestions does the team member have for achieving success.

9. What are the professional interests of the team member.

10. The challenge the project is likely to provide to individual members and the entire team.

11. Why the team concept is so important to project management success and how it should work.

A frank, open discussion with each team member on the above is likely to reduce his/her initial
anxiety. As a consequence, the team member is likely to be more attentive to the needs of the
project. Of course, the opposite reaction is possible, too. A frank discussion, for example, may
actually increase a team member's anxiety level. Often, however, the source of the anxiety can be
identified and dealt with in a timely manner.

The importance of dealing with these anxieties and helping team members feel that they are an
integral part of the team can result in rich dividends. First, as noted in Figure 1, the more effective
the project leader is in developing a feeling of team membership, the higher the quality of
information which is likely to be contributed by team members. Team members will not be reluctant
to openly share their ideas and approaches. By contrast, when a team member does not feel like part

6
of the team and does not believe he/she can trust others in team deliberations, information will not
be shared willingly or openly. One project leader emphasized this point as follows:

There's nothing worse than being on a team when no one trusts anyone else.. .Such situations lead
to gamesmanship and a lot of watching what you say because you don't want your own words to
bounce back in your face...

Second, the greater the feeling of team membership and the better the information exchange (flow)
among team members, the more likely the team will be able to develop effective decision-making
processes. The reason is that the team members feel committed to the project and they feel free to
share their information and develop effective problem-solving approaches. Third, the team is likely to
develop more effective project control procedures. Project control procedures can be divided into
two basic areas. The first is the quantitative control procedures traditionally used to monitor project
performance, e.g., PERT/CPM, networking, workbreakdown structures, etc. The second “control
procedure” (and perhaps the most important) is the willingness and ability of project team members
to give feedback to each other regarding performance. Again, trust among the project team
members makes the feedback process easier and more effective. Without a high level of trust,
project personnel are often reluctant to give negative or constructive feedback to fellow team
members.

Figure 1
Team Building Outcomes

7
Team Building As An On-Going Process

While we have directed considerable attention toward the role of team building in the critical early
phases of a project, it is a never-ending process. The project manager is continually monitoring team
functioning and performance to see what corrective action may be needed to prevent or correct
various team problems. We've found several barometers to be good clues of potential team
dysfunctioning. First, noticeable changes in performance levels for the team and/or for individual
team members should always be followed up. Such changes can be symptomatic of more serious
problems, e.g., conflict, lack of work integration, communication problems and unclear objectives.
Second, the project leader amd team members want to be aware of the changing energy levels of
team members. This, too, may signal more serious problems or that the team is tired and stressed.
Sometimes changing the work pace, taking time off, or selling near-term, more easily reached targets
can serve as a means to reenergize team members. More serious cases, however, can call for more
drasric action, e.g., reappraising project objectives and/or the means to achieve them. Third, verbal
and nonverbal clues from team members may be a source of information on team functioning. It is

8
important to hear the needs and concerns of team members (verbal clues) and to observe how they
act in carrying out their responsibilities (nonverbal clues). Finally, detrimental behavior of one team
member toward another can be a signal that a problem within the team warrants attention.

We highly recommend that project leaders hold regular team building meetings to evaluate overall
team performance and deal with team functioning problems.

The focus of these meetings can be directed toward “what are we doing well as a team” and “what
areas need our team's attention?” This approach often brings positive surprises in that the total team
will be informed on progress in diverse project areas, e.g., a breakthrough in technology
development, a subsystem schedule met ahead of the original target, or a positive change in the
client's behavior toward the project. After the positive issues have been discussed, attention should
be devoted toward “areas needing team attention.” The purpose of this part of the review session is
to focus on actual or potential problem areas. The meeting leader should ask each team member for
his observations on these issues. Then, an open discussion should be held to ascertain how
significant the problems really are. Assumptions should, of course, be separated from the facts of
each situation. Next, assignments should be agreed upon on how best to handle these problems.
Finally, a plan for problem follow-up should be developed. The process should result in better overall
performance and promote a feeling of team participation and high morale.

Over the life of a project, the problems encountered by the project team are likely to change and as
old problems are identified and solved, new ones will emerge. We recommend that a high degree of
effort be focused on problem avoidance in the entire process.

Team Building With Other Departments A Case Study

A variation of the team-building approach occurs when two separate departments or work units are
dependent upon each other for support but have intense conflicts which slow or even stop
intradepartmental coordination attempts. Consider the following situation which recently occurred
in a division of a large, high technology company. One of the authors served as a consultant to the
firm.

The case involved an R&D group and a marketing-directed project team. R&D's role was to develop
new technology and support the project team in its new product developments efforts. Over a
period of several months, relationships between the two groups deteriorated to such a level that the
division manager decided that an intervention into the situation was critical. One of the authors
entered the picture at this point. After reviewing several problems with the division manager, a
recommendation was made to take both groups to a “neutral” site for a two-day meeting. The R&D
manager and the project leader fully concurred with this decision. The meeting opened with a talk by
the division manager on the overall status of the division, the role and importance of R&D, and the
new product project team in effectively integrating their efforts. The division manager left the
meeting after the first short coffee break.

After reconvening the R&D and the project team members, the consultant asked each group to go to
nearby conference rooms and clearly establish how they perceived the other group. These
perceptions were to be limited to short statements and a general agreement reached on their
validity. The consultant noted that if 50 pecent or more of the members of a group believed that a
statement was an accurate reflection of the other group's behavior, then it would constitute a
general agreement. Complaints or perceptions about personalities were not allowed. The intent here
was to keep the two teams focused on detrimental behaviors rather than specific individuals.

9
After several hours the two groups were reassembled and each group was asked to give their
perceptions of the other. An abbreviated version of the results is presented in Table 2. This process
did produce an occasional emotional outburst but was handled by the consultant stressing that these
were perceptions and part of an overall problem-solving process.

Table 2 Team Perceptions Regarding Each Other's Behaviors: R&D vs New Product Project Team

Upon completion of the “mirroring” process, each group had a chance to respond to the perceptions
of the other group. This proved helpful in cooling down emotions.

The next morning, the two groups were reassembled and given this assignment: “What Can We Do
Together to Solve the Problems We've Identified.” The two teams were again asked to retire to their
separate conference rooms to work on the assignment. After a couple of hours, the groups were
brought together again to see what kind of suggestions had been developed and if an agreement
could be reached. The results of this phase are presented in Table 3. Overall, the session was a
success and it set the tone for regular meetings between the R&D group and the New Product
Project Team. In this situation, the “team” was the two interdependent groups working together.

Conclusions

Effective team building can be a critical determinant of project success. While the process of team
building can entail frustrations and energy on the part of all concerned, the rewards can be great.

Social scientists generally agree that there are several indicators of effective and ineffective teams. At
any point in the life of a team, the project manager should be aware of certain
effectiveness/ineffectiveness indicators. Several such indicators appear in Table 4.

As we progress through the 1980's, we anticipate important developments in team building. These
developments should not only lead to higher performance levels but also to increased morale. We
have noted on many occasions that the well developed, highly committed team can withstand
almost any kind of adversity. It is the poorly developed team which is likely to run aground when
storms appear.

Table 3
Resolution Plan: Outcome From Interdisciplinary Problem-Solving Session

10
 • Conduct Status Review Meetings to Monitor Progress for All
On-going Projects

• Hold Regular Product Concept Sessions to Screen New Product

Ideas

• Establish Priority System for New Product Development

Projects

• Project Team Members Will be Responsible for Facilitating

R&D/Customer Contact

• Develop Team Concept to Facilitate R&D/Project Group

Interaction (Matrix Approach)

• Continue These Sessions!

Table 4
Project Team Characteristics: Effective vs Ineffective

The Effective Team Likely Characteristics The Ineffective Team Likely Characteristics

• High Performance • Low Performance

• Professional Objectives of Team Members • Low Commitment to Project Objectives

Coincides with Project Requirements

• Clearly Defined Project Objectives Which • Unclear Project Objectives and Fluid
Are Accepted by Team Members Commitment Levels from Key Participants

• Team Members Highly Interdependent • Team Members Operate Independently/ Lack

of Coordination

• Conflict Encouraged When It Can Lead to • Conflict Avoided at All Costs

Beneficial Results

• High Trust Levels • Subtle Sabotage, Fear, Disinterest or

Footdragging

• High Interest in the Team and Team • Unproductive Gamesmanship, Manipulation of

Processes Others, Hidden Feelings

• High Energy Levels and Enthusiasm • Lethargic/Unresponsive

11
Project Stakeholder
Management

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Outline
• Definition of stakeholder
• Typical stakeholders
• Stakeholder management
• Stakeholder Analysis
• The stakeholder register

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Stakeholder definition
• People, groups or organizations that could impact or
be impacted by the project

Source: PMBOK Guide, Fifth Edition, Page 391.

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Stakeholder management
• Identify stakeholders, analyze stakeholder
expectations and their impact on the project, and
develop appropriate management strategies for
effectively involving stakeholders in project decisions
and execution.

Source: PMBOK Guide, Fifth Edition, Page 391.

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
The stakeholder register
• Used throughout the project
• A table used to manage interactions with the stakeholders
• Lists all stakeholders and stakeholder groups
• Information is added and updated throughout the phases of the
project:
• Interests, involvement, interdependencies, influence on project
success
• All interactions with each stakeholder or group, whether planned or
not, whether initiated by the project or by the stakeholder
• Who on the project team is responsible
• Closely related to the project communication plan

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Project Initiation: Identify
Stakeholders
• Top Management
• Your Manager
• Peers
• Resource Managers
• Internal Customers
• External Customers
• Government
• Contractors, Subcontractors, Suppliers
• Others (the public, landowners, interest groups,
business competitors)
This work is licensed under a Project Management
Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Stakeholder Analysis
• Who are they?
• What are their interests?
• Will their interest level vary throughout the project?
• Can coalitions be built?
• The power/interest grid

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Project sponsor
• The person or group responsible for enabling success.
• May be inside but is usually outside the project.
• Signs off that the project is complete—the one the PM
has to satisfy.
• The person responsible for escalating issues that are
beyond the control of the PM.
• Significant role in developing the initial charter and
project plan.

Source: PMBOK Guide, Fifth Edition, Page 32.

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Politics of Projects
• The environment
• The goals of each stakeholder or group
• Goals that are openly stated or clear
• Hidden agendas?
• Power

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Cultural influences
• Groups and individuals may differ with regard to:
• Communications
• Negotiations
• Decision-making

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Relationship building
• Analyze stakeholders
• Assess influence
• Understand expectations
• Define success
• Keep stakeholders involved
• Keep stakeholders informed

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Build respect
• Be honest
• Take ownership
• Be predictable and reliable
• Stand by decisions
• Take accountability for mistakes

Supportive stakeholders are essential

to project success!

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Stakeholder management
tools
• Power/interest matrix
• Cooperation-Threat matrix
• Stakeholder analysis template
• Stakeholder Register
• Communication Plan

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
The power/interest grid
High

Keep Satisfied Manage Closely

Power

Monitor Keep Informed

Low
Low Interest High

Source: PMBOK Guide, Fifth Edition, Page 32.

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Cooperation-Threat Matrix

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Engagement levels
• May classify in more detail than in Initiation phase:
• Unaware
• Resistant
• Neutral
• Supportive
• Leading
• For each stakeholder or group. Consider potential
movement from one level to another throughout the
project.

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Stakeholder management plan
• A component of the Project Management Plan
• Desired and current engagement levels with stakeholders
• Scope and impact of project on stakeholders
• Interrelationships between stakeholders
• Stakeholder communication requirements and plan
• Time frame, frequency, format and content of planned
communications to stakeholders
• Method for updating the stakeholder management plan

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Manage Stakeholder
Engagement
• Communicating and working with stakeholders to meet
their needs and expectations
• To increase support and reduce resistance from
stakeholders
• Increase the probability of project success

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
Stakeholder Management
Summary
• Stakeholders are people, groups or organizations that
could impact or be impacted by the project
• Managing stakeholders is a key success factor for
projects
• Analyze stakeholder interests and level of influence
• Build coalitions
• Communicate with Stakeholders

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
 Questions?

This work is licensed under a Project Management

Creative Commons Attribution 3.0 Unported License (CC-BY). Chapter 5: Project Stakeholder Management
PROJECT RISK
MANAGEMENT

1 Abok Tonny
 PROJECT RISK MANAGEMENT OVERVIEW
A risk is an uncertain event or condition that, if it occurs, has an effect on at
least one project objectives. Objectives can include scope, schedule, cost and
quality.
A risk may be positive or negative. Positive opportunities.
Project risk involves understanding potential problems that might occur on the
project and how they might impede project success.

What is Risk Management?

Project risk Mgt is the art and science of identifying, analyzing and
responding to risk throughout the life of a project in best interest of meeting
project objectives.

Or
Risk Mgt is an undertaking to lessen the impact of potentially undesirable events on
a project and amplify the impact of a positive event.

Abok Tonny 2
Example of negative risk.
A resource may be requiring a permit. The risk event is that the
permit may take longer than planned. If that uncertain event
occurs, there will be a consequence on the project cost,
schedule or quality.
Example of positive risk.
If there is an opportunity of completing a project earlier than had
been planned and reduce on headcount; the opportunity would
be to achieve the reduced cost possible through a lower-than-
planned headcount.
To be successful, an organization should have a risk management policy in place;
and all stakeholders must be committed to addressing risk management throughout
the project.
3 Abok Tonny
 RISK MANAGEMENT PROCESS

Risk Risk Identification

Management
Planning

Risk
Management
Process
Risk Monitoring & Risk Analysis
Control

Risk Response
Plan

Abok Tonny 4
 1. RISK MANAGEMENT PLANNING
Involves deciding how to approach and plan the risk
management activities for a project.
The main output of this process is a risk management plan.
This plan documents the procedures for managing risk through
out the project.
Risk management plan may include the following but not
limited to:
 Methodology – defines the approaches, tools and data
sources that may be used to perform risk mgt on this project.
 Roles and responsibilities – define the lead, support and
other membership for each identified risk.
Budget and schedule – What are the estimated costs and
schedules for performing risk related
Abok Tonny activities? 5
 2. RISK IDENTIFICATION
Involves discovering (or determining) possible risks that might
affect the project and documenting their characteristics.
A challenge here is that stakeholders many times protect some
situations as not being risks; and later on ends up delaying the
project schedule or costing the company more money. The
main output of this process is the start of risk register

Techniques for risk identification

• Brainstorming – This is the most frequently used technique.
The goal is to obtain a comprehensive list of risks to the project.
• Delphi technique – Is a way to reach a consensus of experts
on a subject.
• Interviewing – risks can be identified by interviewing
experienced Project Mgrs or SMEAbok Tonny 6
 Risk Categorization

Risks can be categorized based on its source :

Abok Tonny 7
 3. RISK ANALYSIS
 This is the process of assessing the impact (consequences)
and probability (likelihood) of identified risks.
 Risks are rated according to the formula:
Probability x Impact = Factor.
 Factor result is used to categorize the risk as being:
 High
 Medium
 Low

 For high risks a contingency plan may be drawn up so that,

if the risks do occur, immediate recovery action is possible.

Abok Tonny 8
 Risk Mapping Chart

Likelihood Risk Factor

0.9 0.09 0.18 0.27 0.36 0.45 0.54 0.63 0.72 0.81

0.8 0.08 0.16 0.24 0.32 0.4 0.48 0.56 0.64 0.72

0.7 0.07 0.14 0.21 0.28 0.35 0.42 0.49 0.56 0.63

0.6 0.06 0.12 0.18 0.24 0.3 0.36 0.42 0.48 0.54

0.5 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45

0.4 0.04 0.08 0.12 0.16 0.2 0.24 0.28 0.32 0.36

0.3 0.03 0.06 0.09 0.12 0.15 0.18 0.21 0.24 0.27

0.2 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18

0.1 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09

Impact 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Abok Tonny 9
 4. RISK RESPONSE PLANNING
 Involves steps to enhance opportunities and reduce threats to meeting
project objectives.
 It includes identification and assignment of individuals or parties (risk
owner) to take responsibility for each agreed risk response.

Techniques for risk response planning (risk response strategy)

 Avoidance – changing the PJ plan to eliminate risks (though difficult).
E.g. replacing potentially defective components with bought in
components of known reliability, clarifying requirements, obtaining
information, improving communication, avoiding unfamiliar
subcontractors, reducing scope to avoid high risk activities etc.
 Mitigation – seeks to reduce the probability of risk to an acceptable
threshold. Taking early action to reduce the probability of risk occurring
is more effective than trying to repair the consequences. E.g. designing
redundancy into a subsystem may reduce the impact that results from a
failure of a system.
Abok Tonny 10
 Transfer – shifting some or all of the negative impact of a threat, along
with ownership of the response, to a third party. Transferring the risk
simply gives another party responsibility for its management - it does not
eliminate it
 Acceptance – No response strategy in place (let it come !!!!!), however a
contingency allowance, or reserve including time, money or resources are
put in place.

Outputs of Risk Response Planning

Risk response plan (Risk register) should be written in detail and include:
 identified risk, their description, the area of the project affected, their
causes and how they may affect PJ objectives.
 risk owners and assigned responsibilities.
 agreed responses for each risk identified.
 Contingency plans and fallback plans. etc
Abok Tonny 11
 Risk Register Matrix - Sample

Likelihood Impact Factor

Risk Category
S. No. Risk Discription (Scale of 0.1 (Scale of 0.1 (likelihood x Risk Owner Mitigation Comments Status
Identified (L,M,H)
- 1) - 1) Impact)

2
3

Abok Tonny 12
 5. RISK MONITORING AND CONTROL
Involves monitoring identified and residual risks, identifying
new risks, carrying out risk response strategies, and evaluating
the effectiveness of the risk strategies throughout the life of the
project.
Why risk monitoring and control?
To determine if:
 risk responses are implemented as planned.
 a risk trigger has occurred. Triggers are indicators or
symptoms of actual risk events e.g. many requirements
change requests may be a symptom of unclear
requirements, cost overruns on early activities may be
symptoms of poor cost estimates.
 Proper policies and procedures are followed.
Abok Tonny 13
Techniques for Risk Monitoring and Control
 project risk response audits – risk auditors examine and
document.
 periodic project risk reviews – through walkthroughs.
 Earned Value Analysis – results from EVA may indicate
potential deviation of the PJ at completion from cost and
schedule targets.

Abok Tonny 14
Discussion questions.
1. Discuss the common sources of risks in Information Systems projects and
suggestions ways for managing them. Which suggestions do you find most
useful? Which do you feel would not work in your organization? Why?

2. You are required to discuss the nature and importance of risk management for an
organization undergoing organization changes. Identify an organization of your choice in the
public or private sector and do the following:
a) Discuss the meaning of risk and the need to manage it effectively.
b) Identify the various risks that the organization is facing or is likely to face.
c) Out of the risks identified, select four risks that pose a serious challenge for the organization.
d) Discuss to what extent the organization’s performance is or may be affected by the selected
risks.
e) Explain what strategies the organization can put or must put into place to address the risks.
f) Identify the problems that the organization may as it tries to lay strategies to address the
risks.

Abok Tonny 15
 PROJECT PROCUREMENT MANAGEMENT

1 [Link] Powered by POeT Solvers Limited

 PROJECT PROCUREMENT MANAGEMENT
WHAT DOES THE PROCUREMENT KNOWLEDGE AREA DO?

• Purchases or acquires products, services or results needed to perform project work

(internal or external to the performing organization)
• PMI uses the terms Buyer & Seller very often. Buyer is normally the performing
organization. Sellers can be Contractors, Sub-contractors, Service providers,
Suppliers/Vendors.
• Buyer can also be clients, customers, contractors, or purchasers.
• It is important to understand the situation/context and accordingly interpret – who is a
Buyer or Seller.
• A Seller may consider delivering you their project (which may be a subproject to you.
• If required, seek early assistance from Specialists in contracting, purchasing within the
legal framework (so as to be fair to both).

2 [Link] Powered by POeT Solvers Limited

 PROJECT PROCUREMENT MANAGEMENT

Contracts
 Contracts are formal. Also named as Agreements, Subcontracts, or
• Purchase orders. Letters of intent are not considered as Contract.
• Contract is defined as an agreement between competent parties, for valid (effective,
well-grounded, logical and producing desired results) consideration, to accomplish a
lawful purpose with clearly defined terms.
• Contracts are a method of transferring risk for a fee (a strategy used in Risk Response
Planning).
• If internal to the Project Team’s organization, a non-contractual formal agreement is
prepared in form of an MOU (with other departments).
• PM team should prepare a tailor-made contract based on specific project needs.
• PM must know the contents of the contract & the purpose.

3 [Link] Powered by POeT Solvers Limited

 PROJECT PROCUREMENT MANAGEMENT
PROCUREMENT PROCESS DEFINITIONS

1. Plan Procurements
• Make a Procurement Management Plan: that defines What, When & How to buy goods
and services for the Project. Then, prepare a SOW defining the purchase needs.

2. Conduct Procurements
• Document the requirements (for products, services & results from outside the project
organization)
• Identify potential Sellers

4 [Link] Powered by POeT Solvers Limited

 PROCUREMENT PROCESSES

12.3 Control Procurements

• Obtain Information, Quotes, Bids, Offers or Proposals
• Review the Offers; Select the best out of the potential Sellers; negotiate a written
Contract.
• Manage the Contract & contract changes; the relationships between Buyer and Seller.
• Review & document the Seller performance.
• Manage contractual relationship with outside Buyer of the Project.

12.4 Close Procurements

• Complete & settle each contract
• See the Process flow diagram in page 359.

5 [Link] Powered by POeT Solvers Limited

 PROCUREMENT PROCESSES
PROCESSES BY PROCESS GROUP
Planning Executing Monitoring Closing
and
controlling
12.1 12.2 12.3 12.4
Plan Conduct Control Close
Procurements Procurements Procurements Procurements

6 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS
HOW DO WE PLAN PROCUREMENTS?

Identify which project needs that can best be:

• project needs which can be, must be, met by acquiring products, services or results
outside the Project organization.
• accomplished by the project team during project execution.

The process
• involves consideration of whether, how, what, how much & when to acquire.
• includes reviewing the risks involved in each make or buy decision.
• includes reviewing the type of contract planned to be used with respect to
mitigating or transferring risks to the Seller.

7 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS
TOOLS & TECHNIQUES
• Make-or-buy analysis
• Expert judgement
• Market research
• Meetings

INPUTS
• Project mgmt. plan
OUTPUTS
• Requirements documentation
• Procurement management plan
• Risk register
• Procurement statements of work
• Activity resource requirements
• Make-or-buy decisions
• Project schedule
• Procurement documents
• Activity cost estimates
• Source selection criteria
• Stakeholder register
• Change requests
• Enterprise environmental factors
• Project document updates
• Organizational Process assets

8 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS
INPUTS
Enterprise Environmental Factors
• Marketplace conditions: what products, services & results are available, at what
prices, under what terms & conditions?
• If the performing organization does not have a purchasing or contracting group,
then project team will have to supply both resources & expertise to perform all
procurement activities.
Organizational Process Assets
• Formal & informal procurement-related policies, procedures, forms, guidelines &
management systems that are considered in developing Procurement Management
Plan & selecting contract types to be used.
Existing organisation policies frequently constrain procurement decisions. Though
many a times those policies are devised based on lessons learned from past projects.
9 [Link] Powered by POeT Solvers Limited
 PLAN PROCUREMENTS - INPUTS
Requirements Documentation
Requirements documentation may include:
• Important information about project requirements that is considered during
planning procurements.
• Requirements with contractual and legal implications that may include health,
safety, security, performance, environmental, insurance, intellectual property
rights, equal employment opportunity, licenses, and permits – all of which are
considered when planning for procurements.

10 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS - INPUTS
Risk Register (Section [Link])

Activity Resource Requirements (Section [Link])

Project Schedule

Project Management Plan

Stakeholder Register (section [Link])

11 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS – INPUTS
Activity Cost Estimates
• Cost estimates developed by the procuring activity are used to evaluate the
reasonableness of the bids or proposals received from potential sellers
Enterprise Environmental Factors
EEF that can influence the Plan Procurements process include, but are not limited to:
• Marketplace conditions;
• Products, services, and results that are available in the marketplace;
• Suppliers, including past performance or reputation;
• Typical terms and conditions for products, services, and results or for the specific
industry; and
• Unique local requirements.

12 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS - INPUTS
Organizational Process Assets
OPA that influence the Plan Procurement process include, but are not limited to:
• Formal Procurement policies, procedures, and guidelines.
• Management systems that are considered in developing the procurement management
plan and selecting the contract types to be used.
• An established multi-tier supplier system of pre-qualified sellers based on prior
experience.

13 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS -T&T
TOOLS & TECHNIQUES
Expert Judgment

Make or Buy Analysis

Price is not the only consideration. Also consider:
• Exposure of proprietary information
• Difficulty in defining deliverables and communicating externally
• Is this work your core competency?
• Work you want to do in parallel
• Amount of change contemplated
• Time to manage several procurement processes/find sellers
• Skills available within your team/company and their moral if you outsource
• Special resource requirement-time duration for training, learning curve etc.

14 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS -T&T
Questions on Make or Buy decisions: can include buy or lease questions like
this.
It costs $300/day to lease an item. It would cost $2000 plus $100/day on maintenance to
buy it. When will lease and purchase costs be equal (in Days)?

Lease cost = $300/day Investment =$2000 + $100/day

D = # of days when purchase & lease costs will be equal

$300D =$2000 + $100D (No. of days)

$300D - $100D = $2000 + $100D - $100D (subtract $100D from both sides)
$200D =$2000
D =10 i.e. 10 days

15 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS -T&T

16 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES
Contract Types
FIXED-PRICE (FP) CONTRACTS

Firm Fixed Price Contracts (FFP)

• Seller to complete the job within a fixed total price.
• The Product has to be well defined ( both seller & buyer are at risk )

Fixed Price Plus Incentive Fee -FPIF

• Seller completes within a fixed total price, plus an extra incentive for meeting or
exceeding certain objectives
e.g. fixed price of $100,000 + $25,000 for completing by a target date

17 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES

Fixed Price Incentive Fee Contracts (FPIF)

• Incentive is based on sellers performance tied to achieving agreed to metrics.
• Typically such financial incentives are related to cost, schedule, or technical
performance of the seller
• In FPIF contracts, a price ceiling is set, and all costs above the price ceiling are the
responsibility of the seller, who is obligated to complete the work.

18 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES

Fixed price with Economic Price Adjustment (FP-EPA)

• The contract type is used whenever the seller’s performance period spans a
considerable period of years, as is desired with many long-term relationships.
• It is Fixed price contract, but with a special provision allowing for pre-defined
final adjustments to the contract price due to changed conditions, such as inflation
changes, or cost increases (or decreases) for specific commodities.
• The EPA clause must relate to some reliable financial index which is used to
precisely adjust the final price. The FP-EPA contract is intended to protect both
buyer and seller from external conditions beyond their control.

19 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES
COST-REIMBURSABLE (CR) CONTRACTS
• Involves payment (reimbursement) to the seller for seller's actual costs, plus a fee
typically representing seller profit
• May also include financial incentive clauses whenever the seller exceeds, or falls
below, defined objectives such as costs, schedule, or technical performance targets.
• Three or more common types in use are as given below:

Cost Plus Fixed Fee (CPFF)

• Buyer pays all costs plus a fixed fee
• Cost over runs will not increase the fixed fee
• e.g. cost of $100,000 + fixed fee of $15,000 (as profit)

20 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES
Cost Plus Incentive Fee (CPIF)
• Buyer pays all costs plus an incentive to beat some criteria
• Criteria might be a cost or time target with a certain formula
• e.g. cost of $100,000 + a pre-determined fee $5000 as incentive for early delivery

Cost Plus Award Fee contracts (CPAF)

• The seller is reimbursed for all legitimate costs, but the majority of the fee is only
earned based on the satisfaction of certain broad subjective performance criteria
defined and incorporated into the contract.
• The determination of fee is based solely on the subjective determination of seller
performance by the buyer, and is generally not subject to appeals.

21 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES
TIME & MATERIAL (T&M) CONTRACTS
• Hybrid type of contractual agreement that contains aspects of both cost-
reimbursable & fixed-price contracts.

• The full value of the agreement and the exact quantity of items to be delivered is
not known when the agreement is made (like a cost reimbursement contract)

• Based upon unit rates or hourly rates as pre-set by the Buyer & Seller for a specific
resource category (like a fixed-price contract)

22 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES
Question

Contract cost is estimated to be $210,000 and a fee of $10, 000 is offered to the supplier
for completing the contract on or before time.

If the contractor beats the cost, both the buyer and the seller will share the savings at
40:60 ratio.

If the actual cost of the work comes out to $180,000, what will the Seller get if the
contract is completed before time?

23 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES
ANSWER:

Target cost" $210,000

Seller's fee" $10,000
Sharing ratio = 40% buyer /60% seller
seller Actual cost" $180,000

Cost savings = $210,000 - $180,000 = $30,000

Seller's profit = $10,000 + ( $30,000 X 60% ) = $28,000
Final price to buyer = $180,000 + $28,000 = $208,000

24 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES

25 [Link] Powered by POeT Solvers Limited

 CONTRACT TYPES
Spectrum of Risk
• Contract type should be chosen based on the degree of risk (do you know what will it
cost to deliver?)
• Risk increases if scope is not well defined. So defining the scope better will get you a
better contract with less risk for all.
• Risk can affect any/or all of them - time, cost, quality & scope

Contracts - buyer on high risk

• Buyer pays for what it costs to deliver if costs go up, buyer's price increases, but seller's
costs are always covered.

Contracts - seller on high risk

• Buyer pays for agreed price no matter what it costs to deliver
If costs go up, seller has to absorb them, but buyer has fixed price & isn't affected.
26 [Link] Powered by POeT Solvers Limited
 PROCUREMENT DOCUMENTS
Procurement Documents
RFP (Request for Proposal or Request for Tender) - requests a price and details on how the
work will be carried out, time frame, who will do it, biography of the team, company
experience, etc.

IFB (Invitation for Bid or Request for Bid) - requests one price for all the work.

Request for Quote (RFQ) - requests a price quote per item, on hourly or per unit basis.

27 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS - OUTPUTS

Procurement Management Plan

• Describes how the procurement processes will be managed from developing
procurement documentation through contract closure
• The procurement management plan can include guidance for:
• Types of contracts to be used;
• Risk management issues;
• Whether independent estimates will be used and if they are needed as evaluation
criteria;
• Those actions the PM team can take unilaterally, if the performing organization
has a prescribed procurement, contracting, or purchasing department;
• Standardized procurement documents, if they are needed;

28 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS - OUTPUTS

Procurement Management Plan (Contd.)

• Managing multiple suppliers;

• Coordinating procurement with other project aspects, such as scheduling and
performance reporting;
• Handling the required lead times
• Handling the make-or-buy decisions, etc.

29 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS - OUTPUTS

Procurement Statements of Work

• Describes the procurement item in sufficient detail to allow prospective sellers to

determine if they are capable of providing the item.
• Written to be clear, complete & concise.
• Information included in a contract SOW can include specifications, quantity desired
quality levels, performance data, period of performance, work location & other
requirements.
• Include description of any collateral services required, i.e. performance reporting or
post-project operational support for the procured item.
• Contract SOW can be revised as required as it moves through the procurement process
until incorporated into signed contract. Seller may also modify the SOW by suggesting
more efficient approach or a less costly product than that originally specified.

30 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS - OUTPUTS

Procurement Documents
• Used to seek proposals from prospective sellers e.g. RFP/RFQ/IFBetc.
• Terms such as bid, tender or quotation are generally used when the seller selection
decision will be based on price;
• RFP is used when other considerations such as technical capability or technical
approach are paramount)
• These documents include,
- Procurement SOW
- Any required contractual provisions
- With government contracting, some or all of the content and structure of
procurement documents can be defined by regulation.

31 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS – OUTPUTS

Make-or-Buy Decisions

Source Selection Criteria

Selection Criteria are often included as a part of the procurement solicitation documents.
Such criteria are developed and used to rate or score seller proposals, and can be objective or
subjective (the proposed Project Manager should be a Certified PMP) or subjective (previous
experience on similar projects)
Other selection criteria to support an assessment of a complex products, services, or results
may include:

32 [Link] Powered by POeT Solvers Limited

 PLAN PROCUREMENTS – OUTPUTS
• Understanding of need

• Overall or life-cycle cost

• Technical capability

• Risk

• Management approach

• Technical Approach

• Warranty

• Financial capacity

• Production capacity and interest

• Business size & type

• Past performance of sellers

• References

• Intellectual property rights

• Proprietary rights

33 [Link] Powered by POeT Solvers Limited

 PROCUREMENT PROCESSES
PROCESSES BY PROCESS GROUP

Planning Executing Monitoring Closing

and
controlling
12.1 12.2 12.3 12.4
Plan Procurements Conduct Control Close
Procurements Procurements Procurements

34 [Link] Powered by POeT Solvers Limited

 CONDUCT PROCUREMENTS
WHAT HAPPENS IN CONDUCT PROCUREMENTS?

• Conduct Procurements is the process of obtaining Seller responses, selecting a seller, and awarding a contract (see
Figures 12-4 and 12-5 in page 371 & 372 of PMBOK)
• In this process, the team will receive bids or proposals and will apply previously defined selection criteria to select
one or more sellers who are qualified to perform the work and acceptable as a seller.

• On major procurement items, overall process of requesting responses from sellers and evaluating those responses
can be repeated.

• A short list of qualified sellers can be established based on a preliminary proposal. A more detailed evaluation can
then be conducted based on a more specific and comprehensive requirements document requested from the sellers
on the short list. In addition, tools and techniques described here can be used alone or in combination to select
sellers. For example, a weighting system can be used to:

• Select a single seller that will be asked to sign a standard contract, and
• Establish a negotiating sequence by ranking all proposals by the weighted evaluation scores assigned to each
proposal.

35 [Link] Powered by POeT Solvers Limited

 CONDUCT PROCUREMENTS
TOOLS & TECHNIQUES
• Bidder conferences
• Proposal evaluation techniques
• Independent estimates
• Expert judgement
• Advertising
• Analytical techniques
• Procurement negotiations

INPUTS
• Procurement management plan
OUTPUTS
• Selected sellers
• Procurement documents
• Agreement
• Source selection criteria
• Resource calendars
• Seller proposal
• Change requests
• Project documents
• Project Mgmt. Plan (updates)
• Make-or-buy decisions
• Project document (updates)
• Procurement statement of work
• Organizational process assets

36 [Link] Powered by POeT Solvers Limited

 CONDUCT PROCUREMENTS - INPUTS

INPUTS

• Procurement Management Plan

• Procurement documents
• Source selection criteria
• Seller proposals
• Project documents
• Make-or-Buy Decisions
• Procurement statement of work
• Organizational process assets
37 [Link] Powered by POeT Solvers Limited
 CONDUCT PROCUREMENTS – T&T
1) Bidder Conferences
Meeting with all prospective sellers and buyers prior to submittal of a
bid or proposal (Read page 375)

2) Proposal Evaluation Techniques

On complex procurements, where source selection will be made based
on seller responses to previously defined weighted criteria, a formal
evaluation review process will be defined by the buyer’s procurement
policies. The evaluation committee will make their selection for
approval by management prior to the award.

38 [Link] Powered by POeT Solvers Limited

 CONDUCT PROCUREMENTS – T&T

3) Independent Estimates

4) Expert Judgments

5) Advertising

6) Analytical Techniques

7) Procurement Negotiations

39 [Link] Powered by POeT Solvers Limited

 CONDUCT PROCUREMENTS – T&T
• Procurement Negotiations
Clarifies the structure & requirements of the contract so that mutual
agreement can be reached prior to signing the contract.
Subjects covered include:
• Responsibilities & authorities
• Applicable terms & law
• Technical & business management approaches
• Proprietary rights
• Contract financing
• Technical solution
• Overall schedule
• Payments
• Price

40 [Link] Powered by POeT Solvers Limited

 CONDUCT PROCUREMENTS – OUTPUTS

Selected Sellers
• Those sellers who have been judged to be in a competitive range based upon the
outcome of the proposal or bid evaluation, and
• Who have negotiated a draft contract that will become the actual contract when an
award is made.
• Final approval of all high-value, high-risk procurements will generally require
organizational senior mgmt. approval prior to award.

41 [Link] Powered by POeT Solvers Limited

 CONDUCT PROCUREMENTS – OUTPUTS

Agreements
• A procurement agreement includes terms & conditions and can also be called a
contract, subcontract, or a purchase order depending upon the application area.
• The contract can be in the form of simple purchase order or a complex document.
• Regardless of the document’s complexity, a contract is a mutually binding legal
agreement that obligates the seller to provide the specified products, services, or
results, and obligates the buyer to compensate the seller.
• A contract is a legal relationship subject to remedy in the courts.

42 [Link] Powered by POeT Solvers Limited

 CONDUCT PROCUREMENTS – OUTPUTS
• The major components in a contract document will vary, but will sometimes
include the following;
• Statement of work or deliverables,
• Schedule baseline,
• Performance reporting,
• Period of performance,
• Roles and responsibilities,
• Seller’s place of performance,
• Pricing,
• Payment terms,
• Place of delivery

43 [Link] Powered by POeT Solvers Limited

 CONDUCT PROCUREMENTS – OUTPUTS
- Inspection and acceptance criteria,
- Warranty,
- Product support,
- Limitation of liability,
- Fees and retainage,
- Penalties
- Incentives,
- Insurance and performance bonds,
- Subordinate subcontractor approvals,
- Change request handling, and
- Termination and alternative dispute resolution (ADR)
– mechanisms. The ADR method can be decided in advance as a part of the
procurement award.
44 [Link] Powered by POeT Solvers Limited
 CONDUCT PROCUREMENTS – OUTPUTS
Resource Calendars

Change Requests

Project Management Plan (Updates)

Elements of the project management plan that may be updated include, but are not limited to;
Cost Baseline,
Schedule Baseline,
Scope Baseline,
Communication Management Plan, and
Procurement Management Plan

Project Documents (Updates)

45 [Link] Powered by POeT Solvers Limited

 PROCUREMENT PROCESSES
PROCESSES BY PROCESS GROUP

Planning Executing Monitoring Closing

and
controlling

12.1 12.2 12.3 12.4

Plan Conduct Control Close
Procurements Procurements Procurements Procurements

46 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT
HOW DO WE CONTROL PROCUREMENT?
• It is the process of managing procurement relationships, monitoring contract
performance, and making changes and corrections as needed (see Figures 12-6
and 12-7 in page 379 & 380).

• Both the buyer and the seller will control procurement contract for similar
purposes.

• Each must ensure that both parties meet their contractual obligations and that
their own legal rights are protected.

47 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT
• The Control Procurements process ensures that the seller’s performance meets
procurement requirements and that the buyer performs according to the terms of
the legal contract.
• The legal nature of the contractual relationship makes it imperative that the
project management team is aware of the legal implications of actions taken when
controlling any procurement.
• Due to varying org. structures, many organizations control procurement
contract/agreement as an administrative function separate from the project
organization. While procurement administrator may be on the project team, this
individual typically reports to a supervisor from a different department. This is
usually true if the performing organization is also the seller of the project to an
external customer.

48 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT
TOOLS & TECHNIQUES
• Contract change control system
• Procurement performance
reviews
• Inspections & audits
• Performance reporting
• Payment systems
• Claims & administration
• Records management system

INPUTS OUTPUTS
• Procurement documents • Project management plan (updates)
• Project management plan • Project documents (updates)
• Agreements • Work performance information
• Work performance reports • Change requests
• Approved change requests • Organizational process assets
• Work performance data (updates)

49 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT- INPUTS
1. Procurement Documents

2. Project Management Plan

3. Agreements

4. Work Performance Reports

5. Approved Change Requests

6. Work Performance Data

50 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT- T&T
TOOLS & TECHNIQUES

Contract change control system

• Defines the process to modify a contract
• Includes paperwork, tracking systems, dispute resolution procedures & approval
levels necessary for authorizing changes, i.e. work authorization system

Procurement performance reviews

51 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT- T&T

Inspections and audits

• Required by the buyer & supported by the seller as specified in contract
documentation.
• If authorized by contract, some inspections and audit teams can include
buyer procurement personnel.

52 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT- T&T
• Performance Reporting
How effectively the seller is achieving contractual objectives

• Payment systems
Payments to the seller are typically processed by the accounts payable
system of the buyer after certification of satisfactory work by an
authorized person on the project team. Payments are strictly as per terms
of contract.

53 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT- T&T
• Claims administration
Contested changes and potential constructive changes are those requested
changes where the buyer and seller cannot reach an agreement on
compensation for the change, or cannot agree that a change has occurred.
These contested changes are variously called claims, disputes, or appeals.
Preferred method of claims/dispute settlement is through negotiation.

• Records management system

It is used by the PM to manage contract and procurement documentation
and records (it is a part of PMIS, section [Link])

54 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT- OUTPUTS
OUTPUTS

1) Procurement documentation
It includes, but not limited to, the procurement contract with all supporting
schedules, requested unapproved contract changes, and approved change
requests. It also includes any seller-developed technical documentation and
other work performance information such as deliverables, seller
performance reports, warranties, financial documents including invoices
and payment records, and the result of contract-related inspections.

55 [Link] Powered by POeT Solvers Limited

 CONTROL PROCUREMENT- OUTPUTS

2) Organizational Process Assets (updates)

Read page 386

3) Change Requests

4) Project Management Plan (updates)

- Procurement management plan
- Baseline schedule (must be updated to reflect the current expectations)

56 [Link] Powered by POeT Solvers Limited

 PROCUREMENT PROCESSES
PROCESSES BY PROCESS GROUP

Planning Executing Monitoring Closing

and
controlling

12.1 12.2 12.3 12.4

Plan Conduct Control Close
Procurements Procurements Procurements Procurements

57 [Link] Powered by POeT Solvers Limited

 CLOSE PROCUREMENTS
WHAT HAPPENS IN CLOSE PROCUREMENTS?

• Close procurements process supports the close project process

• Verifies that all work and deliverables were acceptable
• Administrative activities, such as update records to reflect final results and archive
them for future use
• In multi-phase projects, the terms of a contract may only apply to a given phase of
the project.
• Unresolved claims may be subject to litigation after close procurements.
• Contract terms & conditions can prescribe specific procedures for close
procurements.
• Early termination of a contract is a special case of close procurements & can
happen when the buyer & seller mutually agree or when there's contract default
58 [Link] Powered by POeT Solvers Limited
 CLOSE PROCUREMENTS

TOOLS & TECHNIQUES

• Procurement audits
• Procurement negotiations
• Records management system

OUTPUTS
INPUTS • Closed procurements
• Procurement management plan • Organizational process assets
• Procurement documentation (updates)

59 [Link] Powered by POeT Solvers Limited

 CLOSE PROCUREMENTS - INPUTS

INPUTS

• Procurement Management Plan

• Procurement Documentation

60 [Link] Powered by POeT Solvers Limited

 CLOSE PROCUREMENTS – T&T

TOOLS & TECHNIQUES

Procurement Audits
• Structured review of all the procurement process from Plan
Procurement process through Administer Procurements
• Objective is to identify successes & failures that warrant recognition
in the preparation and administration of other procurement
contracts on the project, or on other project within the performing
organization.

61 [Link] Powered by POeT Solvers Limited

 CLOSE PROCUREMENTS – T&T
Procurement Negotiations
• In all procurement relationships the final equitable settlement of all
outstanding issues, claims, and disputes by negotiation is a primary goal.
• Whenever settlement cannot be achieved through direct negotiation, some
form of alternative dispute resolution (ADR) including mediation or
arbitration may be explored.
• When all else fails, litigation in the courts is the least desirable option.

Records Management System (see section12.3.2.7)

62 [Link] Powered by POeT Solvers Limited

 CLOSE PROCUREMENTS - OUTPUTS
OUTPUTS
Closed Procurements
• The buyer, usually through the authorized procurement administrator,
provides the seller with formal written notice that the contract has been
completed
Organizational Process Assets (Updates)
• Procurement file - a complete set of indexed records
• Deliverable acceptance (or rejection)
• Lessons learned documentation

63 [Link] Powered by POeT Solvers Limited