Four: Project Execution and Control

Process Descriptions

4.1 Conduct Project Execution and Control Kick-off

4.2 Manage Triple Constraints (Scope, Schedule, Budget)

4.3 Monitor and Control Risks

4.4 Manage Project Execution and Control

4.5 Gain Project Acceptance

4.1 Conduct Project Execution and Control Kick-Off

Roles

Project Manager

Project Sponsor and / or Project Director

Project Team Members

Steering Committee

Stakeholders

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 Execution and Control Kick-off ensures that the project is still on track and focused on the
original business need. Many new team members will be introduced to the 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 associated with Conduct Project Execution and Control Kick-Off

4.1.1 Orient New Project Team Members

4.1.2 Review Project Materials

4.1.3 Kick Off Project Execution and Control

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 projects desired outcome. If the Project Manager created a
Team Member Orientation Packet during Project Planning, the packet should already contain an
orientation checklist, orientation meeting agenda, project materials, and logistical information that will
again be useful.
The Project Manager should review the contents of the existing Team Member Orientation Packet to
ensure that they are current and still applicable to the project. Any changes needed to the contents of
the packet should be made at this time. Once updated, packet materials can 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.
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 Initiation, Project Planning (High Level), and
Project Planning (Detail Level).

Organization charts Project Team, Customer, Performing Organization

General information on the Customer

Logistics (parking policy, work hours, building/office security requirements, user id and
password, dress code, location 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 vacation policy)

4.1.2 Review Project Materials and Current Project Status

Before formally beginning Project Execution and Control, the Project Team should review updated
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 (High Level and Detail):
1. Project Charter, Project Initiation Plan
2. Triple Constraints (Scope, Schedule, Budget)
3. Risk Management Worksheet
4. Description of Stakeholder Involvement
5. Communications Plan
6. Time and Cost Baseline
7. Communications Management Process
8. Change Control Process
9. Acceptance Management Process
10. Issue Management and Escalation Process

11. Training Plan

12. Project Implementation and Transition Plan
See the sections on Project Initiation, Project Planning (High Level), and Project Planning (Detail
Level) for detailed descriptions of these deliverables.
This will serve to remind the team of what has been produced so far, to clarify understanding of the
work to be produced during 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. 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

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 acceptance of the work done so far, to validate expectations pertaining to the
deliverables to be produced during Project Execution and Control, and to clarify and gain
understanding of the expectations 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 / or Project Director, and any other Stakeholders with a vested interest in the status of the
project. This is an opportunity for the Project Sponsor and / or Project Director 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 important notes,
decisions, issues and action items. Following the session the meeting minutes should be distributed to
all attendees and should be added to the project repository.
A sample CPMM Project Execution and Control Kick-off Meeting Agenda may be found in the
appendix.

4.2 Manage Triple Constraints

Roles

Project Manager

Project Sponsor and /or Project Director

Project Team Member

Customer Representative

Steering Committee

Purpose
The Triple Constraints is the term used for a project's inextricably linked constraints: Scope, Schedule, and
Budget, with a resulting acceptable Quality. During Project Planning, each section of the Triple Constraints
was refined. As project-specific tasks are performed during Project Execution and Control, the Triple
Constraint will need to be managed according to the processes established during Project Planning.
The Triple Constraints is not static although Project Planning is complete and has been approved, some
components of Triple Constraints will continue to evolve as a result of the execution of project tasks.
Throughout the project, as more information about the project becomes known and the product of the
project is developed, the Triple Constraints are likely to be affected and will need to be closely managed.
The purpose of the Manage Triple Constraints Task 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 associated with Manage Triple Constraints

4.2.1 Manage Project Scope

4.2.2 Manage Project Schedule

4.2.3 Implement Quality Control

4.2.4 Manage Project Budget

4.2.1 Manage Project Scope

During Project Planning, the Project Manager, through regular communication with the Customer
Representatives and Project Sponsor and / or Project Director, 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.
The process to be used to document changes to the Project Scope was included in the Project
Initiation Plan. This process includes a description of the way scope will be managed and how
changes to scope will be handled. It is important that the Project Manager enforce this process
throughout the entire project, starting very early in Project Execution and Control. Even if a scope
change is perceived to be very small, exercising the change process ensures that all parties agree to
the change and understand 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 and / or Project
Director accustomed 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 Managers 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 considered 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 and / or Project Director 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 compromise 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 / or Project Director, and the appropriate
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 remaining Triple Constraints: Budget, Schedule and also
document and impact to Quality. Equipped with this information, the Project Manager and Project
Sponsor and / or Project Director will be able to determine if implementing the proposed change would
be beneficial. If it is determined, for 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 outcome of the project, approval and
funding for the change is secured. At this point, the Project Manager must follow the procedures
defined in the Project Plan to implement the change. (Managing the change control process is
described in detail in task 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
documented 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 communication between the Project Manager,
Project Sponsor and / or Project Director, and Customer Representative is crucial in managing scope.

4.2.2 Manage Project Schedule

During Project Planning (Detail Level), an agreed-upon baseline was established for the Project
Schedule. This schedule 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 project is on track.
Project Team members use the communications mechanisms documented in the Communications
Plan to provide feedback to the Project Manager on their progress. Generally team members
document the time spent on tasks and provides estimates of the time required to complete them. The
Manager uses this information to update the Project Schedule. In some areas there may be formal
time tracking systems that are used to track project activity.
The Project Manager must emphasize to the team the importance of accurate reporting, and must be
vigilant in collecting information at a detailed level. Using this information, 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
recommended 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.
After updating the Project Schedule, the Project Manager must take the time to review the status of the
project. Some questions 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 recommended that the Project Manager experiment with all available reports to find
those that are most useful for reporting information to the Project Team, Customer, and Project
Sponsor and / or Project Director.
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 execution 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 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 standards
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:

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 and / or Project Director 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 in Project Execution and Control 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.

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 information 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. The Appendix of this Guidebook
includes checklists for each process group of the project management lifecycle.

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 activity 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 is 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 process group, at least 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 and / or Project
Director 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 / or Project Director, 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 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 lifecycle 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 project will address, and
how the projects product will support the organizations 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 Initiation Plan define the project goals and objectives?

Does the Project Scope provide a list of all the processes that will be affected by the
project?

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?

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 mitigation 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 Process clearly define how issues will be captured,
tracked, and prioritized? 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?

Does the Implementation and Transition Plan describe how to ensure that all
Consumers are prepared to use the projects product, and the Performing
Organization is prepared to support the product?

Have all Project Management deliverables been approved by the Project Sponsor
and / or Project Director (or designated approver?)

Does the Project Plan contain all required components as listed in the Guidebook?

Are each Project Plan component 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?

Is the Project Status Report being reviewed with the Project Sponsor and / or Project
Director on a regular basis?

As new team members are introduced, are they being sufficiently 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 concerns or issues to the

Project Manager?

Do the Project Manager, Project Sponsor and / or Project Director and Customer
Decision Maker(s) share a consistent view of project status and issues?

Is the Customer Decision Maker(s) satisfied with deliverables provided by the

project?

Is the Customer Decision Maker(s) satisfied with the responsiveness 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 interviews and repository review, the auditor writes a summary report
documenting his/her findings and recommendations. This report is reviewed with the Project Manager,
who should immediately implement recommendations and corrective actions identified.
Every member of the Project Team must be committed to producing 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.

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.

As a result of implementing quality control, the Project Manager should be able to determine and take
the appropriate actions to increase the projects effectiveness and provide better service to the
Customer.

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
established early in the project management lifecycle
Part of the Project Managers 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 managed, 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!

There are several financial characteristics the Project Manager should monitor to determine if a project
is performing satisfactorily 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
budget-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 and / or Project Director.

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

tasks and materials in the project. The Project Manager must verify, validate, and assess the
impact of team member's revised estimates to complete tasks. 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 hours and 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, understand, and document the reason for
variance every time the Project Schedule is updated.

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 corrective actions need to be taken to maintain the projects
schedule. For example, if a negative variance results while a task is being executed, and more money
will be needed than planned for, the success of the project may be affected. 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
members 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 currency, accuracy, and viability of the
Project Schedule as the primary 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
variance. This information must be known by task, activity, project phase, resource, and deliverable. It
must be communicated to the Project Sponsor and/or Project Director as part of the Status Meeting.

4.3 Monitor and Control Risks

Roles

Project Manager

Project Sponsor and / or Project Director

Project Team

Customer

Steering Committee

Purpose
Risks are potential future events that can adversely affect a projects Budget, Schedule, Scope (Triple
Constraints) and the resulting Quality. In prior work, the Project Manager defined these events as
accurately as possible, determined when they would be likely to impact the project, and developed a Risk
Management Plan. As the impact dates draw closer, it is important to continue re-evaluating probability,
impact, and timing of risks, as well as 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 work
to anticipate project challenges, and to develop and apply new response and resolution strategies to
unexpected eventualities.

Tasks associated with Monitor and Control Risks

4.3.1 Monitor Risks

4.3.2 Control Risks

4.3.3 Monitor Impact on Triple Constraint

4.3.1 Monitor Risks

During Project 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 Project Manager must continually look for new risks, reassess old ones, and re-evaluate risk
mitigation plans. The Project Manager should involve the whole Project Team in this endeavor, as
various team members have their particular expertise and can bring a unique perspective to risk
identification. As the Risk Management Worksheet is integrated into the status reporting process, this
review and re-evaluation should take place automatically, with the preparation of each new status
report.
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 determine 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 the risk probability level is high enough to warrant incorporating the
Risk Management 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 actually 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 additional documentation to
prove compliance with state regulations. 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 circumstances 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 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 different perspective. The Project Manager needs to
understand 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 Management
Plan becoming the issues Action Plan.

4.3.3 Monitor Impact on Triple Constraint

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

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

4.4 Manage Project Execution

Roles

Project Manager

Project Sponsor and or Project Director

Project Team

Customer

Steering Committee

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 conducted and the majority of the Project Budget is expended. The purpose of
Manage Project Execution is to manage every aspect of the Project Plan as work is being done to make
certain the project is a success.

Tasks associated with Manage Project Execution

4.4.1 Manage Change Control Process

4.4.2 Manage Acceptance of Deliverables

4.4.3 Manage Issues

4.4.4 Execute Communications Plan

4.4.5 Manage Organizational Change

4.4.6 Manage the Project Team

4.4.7 Manage Project Implementation and Transition Plan

4.4.1 Manage Change Control Process

During Project Planning, the Project Manager, Project Sponsor and / or Project Director, 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

How requests for change will be initiated

How requests for change will be analyzed to determine if they are beneficial to the project

The process to approve or reject change requests

How funding will be secured to implement approved changes

Although changes can be expected to occur throughout every project, any negative effect on the
project outcome should be avoidable if the change control process is executed and managed
effectively.
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 discover their original effort estimates
were not accurate and will result in more or less time being required to complete their work. It is also
during Execution that the Project Sponsor and / or Project Director or Customer may realize that,
despite their best efforts to thoroughly document the Project Scope, the product being produced 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 member is not able to complete what was
documented in the Project Scope, because of lack of skill, time constraints, or other factors 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 documented 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 projects Triple Constraints 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 projects Triple Constraints, 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 project and the timeline and
cost.
During Project Planning, individuals authorized to be requestors, or 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
approver(s). (See Figure 3-6, CPMM Internal Change Order.)
The approver(s) review the information and make a determination 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 business benefit, the change request will most likely be
rejected. A signature is required of all approvers, whether they are accepting or rejecting the
deliverable. If the deliverable is being rejected, the approver must provide the reason. A signature of
approval on the Project Change Request indicates that the approver accepts the consequences
(impact) of the increased scope on the projects Budget, Scope, Schedule and resulting Quality.

Change Requests and their status are kept in the Change Request Log.

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 required tasks, estimated durations, dependencies, and
resources must be modified. If the change has a significant impact, 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.

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 nothing 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 Triple Constraints must
be documented. All correspondence, 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 process is to manage the acceptance of deliverables. You will need to

define the acceptance criteria for deliverables for your project

determine who will review the deliverables to assure the completeness of information and
quality of the work

identify the Customers designated to be approvers and have the authority to sign off on the
deliverable indicating acceptance

define any time considerations or escalation process your project may need to manage
acceptance of deliverables.

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 key to facilitating acceptance is first to understand
Customer expectations, and then to meet them.

The acceptance management process is not set in stone

and, 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 completed deliverable. 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
communication. But 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 expectations, 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 from a technical standpoint. After the review, they
should produce 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 designated 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!

Using input and recommendations provided by the reviewer, the approver reviews the deliverable
(most likely from a business standpoint) and decides if it meets the acceptance criteria documented in
the acceptance management process. He/she will indicate acceptance or rejection of the deliverable
on the Approval Form or Page of the document. Once again, this must be done within the turnaround
time documented in the acceptance management process. If the approver recommends 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 deliverable adjusted as
necessary and then resubmit it to the approver. This process should be followed for each person
designated as an approver in the acceptance management process. The Project Manager must
ensure that for rejected deliverables, specific corrective actions are defined, that is, "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 number 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 deliverable based upon its rejection? The
number of times a deliverable can be resubmitted to the approver was also documented 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 recognize 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 included as part
of the Status Report that is reviewed with the Project Sponsor and / or Project Director (see Appendix:
CPMM 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 formal
acceptance of the deliverable.

4.4.3 Manage Issues

Managing issues involves documenting, reporting, escalating, tracking, and resolving problems that
occur as a project progresses. During Project Planning (High Level), the Project Manager and Project
Sponsor and / or Project Director agreed upon and documented the process for managing issues and
included the process in the Project Initiation 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 and / or Project Director to foster an
environment where communicating issues is not only acceptable but strongly 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.
The Project Manager should be cautious about reacting to an issue that is communicated 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 members for its mitigation.

Consider implementing a reward system to recognize

individuals who communicate project issues. This will not
only increase morale but will encourage others to
communicate issues when they identify them.

The Project Manager is responsible for capturing and tracking issues as soon as they arise, using the
issues log (See Figure 2.10 CPMM Issues Log). High or Critical Issues should also appear in the
Issues section in the Project Status Report. Every issue, whether technical or business related, should
be documented. Below are some examples of project issues:

Computer system will be down for routine maintenance.

Project Sponsor and / or Project Director 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.

Staff is contemplating a strike.

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 highest priority should receive the
most and quickest attention.
The issues log should also include the date the issue is recorded, 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 (that is, the date cannot be "ASAP"). The responsible party must be a specific
individual, not a functional group (that is, an issue should not be assigned to the IT Department or the
DBA group).
While the issue remains open, its continuing impact and the status of its action plan should be
discussed at every status meeting. If appropriate resources or materials are not available to complete
the action items, or if there is disagreement about any 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 different 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 managed. 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 Communications 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 appropriate individuals at the appropriate times, and new or unexpected 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.

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 information. 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 communication mechanisms. These were defined during Project Planning and may
include:

Status Meetings

Status Reports

Memos

Newsletters

Executive Correspondence

Meeting Minutes

Executive Meetings

Steering Committee Meetings

Presentations to special interest groups

Customer Focus Group 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, status reporting is particularly useful for
communicating the performance of a project. Project Team members must complete Activity / Time
reporting to the Project Manager. These reports can serve a dual purpose as a reporting mechanism to
the Project Manager and also to the team member's immediate supervisor. Time reporting should
document detailed descriptions of actual work accomplished and include Team members estimates of
the time they feel will be required to complete tasks. Time reporting should also contain 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 CPMM Time Sheet). Note: Time Reporting is done by
automated tools or other special reports in some performing organizations and the process should be
documented in the communication plan.
Using the Activity / Time Sheet prepared by the Project Team, the Project Manager should complete a
Status Report to be presented to the Project Sponsor and / or Project Director. 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 / or Project
Director, and should contain the following information:

Status Summary indicating any significant impacts to the project

Major Accomplishments a list of the most important completed tasks, or a description of

work done toward their completion. (Other than project Milestones)

Project Milestone Report a high-level glance at the major project deliverables, with their
intended and actual start and end dates.

Issues analysis and Issue Response a running list of open and closed issues. (See
Manage Issues, Section 4.4.3.)

Change Request Analysis a running diary of actions taken toward acceptance of change
control. (See Manage Change Control Process, task 4.4.1.)

Risk Analysis Report any Risks that may be turning into a project issue and report on any
situation that occurred that resulted in the Project Team being unable to perform work.

Financial Commentary

Project Manager's Comments and significant planned accomplishments for the following
weeks.

Other project documents that may be attached to the Status Report include any Change Control
Requests or Change Control Log, Open Issues Log, Risk Plan, Deliverable Acceptance Forms,
Meetings Notes, the Organizational Change Management Plan and the Implementation and Transition
Plan.
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 and / or Project Director.

Conduct a regularly-scheduled meeting with the Project

Sponsor and / or Project Director, 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 / or Project Director and is the perfect 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
and / or Project Director 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
separate document. Regardless of its location, detailed
information should always be made available to the Project
Team, and will be invaluable to you if your Project Sponsor
and / or Project Director requests clarification or more
information.

The Project Manager should periodically assemble the Project Team to review the status of the project,
discuss their accomplishments, 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 necessary 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 teams Time 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
necessary for Team Leaders to meet regularly with the
Project Manager to ensure all communication lines remain
open.
It is important for the Project Manager to make an
appearance at meetings on a regular basis. This serves a
dual purpose it demonstrates the Project Managers interest
in the project and it also facilitates communication with the
Project Team.

As documents are gathered and generated during Project Execution, the Project Manager and / or
Team Leads are responsible for filing them in the appropriate location in the project repository. The
repository must be maintained on a continuous basis, as it represents a history of the project, from its
initial 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, e-mail, etc.

Meeting minutes, decisions and/or actions

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 promoted 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 and / or Project Director to be
actively involved in the change effort, and to proactively manage communications with the performing
Organization and Consumers. As specific changes are implemented 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.
The Organizational Change Management Plan 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 representatives and the external agencies
involved. These agencies may include the Department of Civil Service and the Governors
Office of Employee Relations. The Project Manager must work with all of these organizations
to 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 development. The redesigned processes and procedures must
align with the product and associated changes. The implementation 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 and / or Project Director and the Steering Committee 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 Organizations readiness for change,
the Project Manager can develop more specific action plans to increase the organizations
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
and / or Project Director, must be able to manage the specific activities that will adequately prepare the
performing Organization for the anticipated changes.

4.4.6 Manage the Project Team

In order to successfully meet the needs of a project, it is important to have a high-performing Project
Team made up of individuals who are both technically skilled and motivated to contribute to the
projects outcome. One of the many responsibilities 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 successfully fill these roles
helps distinguish good Project Managers from great ones.
To maximize the successful performance of the Project Team, the Project Manager must do the
following:
4.4.6.1 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 training is necessary, it should be added to
the plan. If it is determined 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, training 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.
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.

4.4.6.2 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 allocating 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
continuously 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 success 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. But the Project Manager must also be willing to communicate face-toface 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 member performance
issues.

4.4.6.3 Establish a Team Environment

Project Team members must learn to work together to achieve project goals. They must recognize
that there is more to teamwork than simply having team members feel good about each other.
High-performing Project Teams are disciplined. Team members participate in all required
meetings, even when they are tedious, are willing to suppress their egos for the good of the
group, take their assigned tasks seriously, and continuously strive to improve their skills. Highperforming Project Teams are either empowered to make decisions or are included in decisionmaking processes. This is the essence of project ownership.
Project Managers must develop sufficient management competencies 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 individuals 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 motivated
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 interacting 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.

4.4.6.4 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 informal, depending on the size and needs of the project. In all cases, changes to the Project
Team or Customer will most likely require updates to the Project Schedule. It is the way changes
are managed that will dictate how significant the updates will be.

4.4.7 Manage Project Implementation and Transition Plan

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 developed as the product of the project is
developed, and as specific 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.
The Implementation and Transition Plan 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 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 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
management system module-by-module, or moving to a new building floor-by-floor, or
implementing a new way of doing business 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 individuals to support the
specific products, and providing necessary training. The Project Manager must carefully
manage the point in implementation that the Performing Organization 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 produced. Examples of
documentation include:

User manuals

On-line help

Assembly or usage instructions

The Project Manager must be certain that every piece of documentation described in the
Implementation and Transition Plan is provided to the Customer and the Performing Organization
before the end of Project Execution and Control.
Overall, the Project Manager must be sure each required activity is carried out according to the
Implementation and Transition Plan and schedule, and to immediately communicate any discrepancies
to the Project Sponsor and / or Project Director.

Deliverables for Task 4.4 (Manage Project Execution)

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
and / or Project Director. The product of the project is the end result of Project Execution and
Control, and will be successfully transitioned from the Project Team to the performing Organization.

4.5 Gain Project Acceptance

Purpose
The purpose of this process is to formally acknowledge that all deliverables produced during Project
Execution and Control have been completed, tested, accepted, and approved by the projects Customer
Representatives and the Project Sponsor and / or Project Director, and that the product or service the
project developed was successfully transitioned from the Project Team to the Customers and Consumers.
Formal acceptance and approval also signify that the project is essentially over, and is ready for Project
Closeout.

Roles

Project Manager

Project Sponsor and / or Project Director

Project Team Members

Customer Representatives

Tasks associated with Gain Project Acceptance

4.5.1 Conduct Final Status Meeting

4.5.2 Gain Acceptance Signature from Project Sponsor

4.5.1 Conduct Final Status Meeting

Once the product of the project has been successfully transitioned to the Performing Organizations
environment, the Project Manager should prepare the final status report and conduct the final status
meeting. The Project Schedule must be up to date for all completed project and project management
lifecycle work. This is the final opportunity for all participants to confirm that the product of the project has
been successfully developed and transitioned. Any outstanding issues or action items must be transitioned
from the Project Team to the Performing Organization.

4.5.2 Gain Acceptance Signature from Project Sponsor and/or Project Director
As the deliverables of the project are produced and accepted, approval signatures are gained from the
Project Sponsor and / or Project Director and Customer Representatives. Following the final status
meeting, the Project Manager must obtain the Project Sponsor and / or Project Directors signature one final
time, indicating acceptance of the project to date, and indicating approval to proceed to Project Closeout
(see Appendix: CPMM Sample Project Approval Form.). If the Project Sponsor and / or Project Director do
not accept the project, he/she must indicate the specific reason(s) for rejection. The Project Manager is
then responsible for resolving the issues and seeking the Project Sponsor and / or Project Directors
acceptance again.

Continue to next section:

Checklist

Four: Project Execution and Control

Checklist
Use this checklist throughout Project Planning (High Level) to help ensure that 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.

Item Description

Completio
n Date

Comments

Conduct Execution and Control Kick-off

Ensure team members have whatever is

required to perform their tasks

Meet with each team member to convey

roles and responsibilities

Distribute copies of all project materials

and deliverables to all team members

Mentor or assign Team Leader to mentor

new team members

Hold orientation sessions for new

members

Review previous deliverables and

components of Project Plan

Schedule time and location of kick-off

meeting

Prepare materials for distribution at

meeting

Invite appropriate attendees

Prepare meeting presentation and

agenda

Designate meeting scribe

Conduct kick-off meeting

Distribute meeting notes to all attendees

Update the project

repository

Manage Triple Constraints

(Scope, Schedule, Budget)

Update and analyze the Project

Schedule as needed

Conduct peer review of deliverables, if

appropriate

Monitor and Control Risks

Review identified risks with Project Team

and Project Sponsor and/or Project
Director

Re-evaluate each risk

Update Risk Management Worksheet

regularly

Execute contingency plans or modify

them if necessary

Create new contingency plans to

accommodate new risks

Manage Project Execution

Ensure status meetings are being held

with the Project Team regularly

Acquire necessary physical space and

equipment to support the product

Conduct training for support personnel

Conduct training for Consumers

Communicate rollout information

Conduct training for Project Team

members and update Training Plan

Allocate and assign work to Project

Team members

Conduct team building activities

Reward team members

Manage Project Team member changes

Manage changes to Customers

organization

Transition product into Performing

Organization

Update the project repository

Gain Project Acceptance

Prepare final Status Report

Prepare formal Project Approval Form

Conduct final Status Meeting with

Project Sponsor and/or Project Director
and present

Four: Project Execution and Control

Measurements of Success
The ultimate measurement of success for Project Execution and Control is the product acceptance by the
Customer, and project acceptance by the Project Sponsor and/or Project Director.
Meanwhile, the Project Manager can still assess how successfully the project is proceeding through Project
Execution and Control by utilizing the measurement criteria outlined below. Because the processes in
Project Execution and Control (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 eventual success of your
project.

Process

Conduct Project
Execution and
Control Kick-off

Measurements of Success
Did you receive confirmation from ALL Project
Team 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?

Do your team members agree that the estimates

to complete for all open tasks are accurate?

Manage Triple
Constraints

Has your team implemented any lessons

learned from either the peer review or the
project audit process?

Is the Project Sponsor and/or Project Director

aware of the latest forecast total 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?

Has it been less than two weeks since any

deliverable was presented for which the
acceptance signatures are still outstanding?

Are all project issues recorded in the Issue Log in

the Project Status Report?

Has it been less than two weeks since you held

Yes / No

the last status meeting?

Is the status meeting being attended by more

than 70% of the Project Team?

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 Approval Form signed by

your Project Sponsor and/or Project Director
accepting the project?

Risks & Ways to Avoid Pitfalls

Project Execution and Control is where the rubber meets the road. In the immortal words of Yoda, its
"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, Project Execution and Control has the most pitfalls and the most areas for consideration. The
following table identifies processes and tasks which have pitfalls highlighted in this section.

Process

Manage Triple Constraints

Task

Why is it important?

Manage Project Schedule

Schedule slippage is the most visible

sign of a project in trouble.

Manage Issues

That malfunctioning little #@?*!, this

is all their fault. Maybe, maybe not.
But its still your responsibility to make
sure the actual problem is fixed.

Manage Project Execution

Manage Acceptance of
Deliverables

Don't be too proud of this

technological 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
Change / Manage Product
Implementation and
Transition

You may have created the most

awesome product in the known
universe, but what good 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, its hard to tell whos leading
whom. Don't let that happen to you!

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 everyones 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, lets figure out whats 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 warfare, 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 its probably your fault (at least for not managing it properly!).

Now lets tackle each problem in turn, starting with the most likely one.
Problem: Management shortcomings.
Solution: C3PO said, It's against my programming to impersonate a Deity! But many Project
Managers try, or feel they ought to. The tough part is that Project Managers 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 documenting 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 delivering assignments to all team members,
the result may appear 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 constantly 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 requirements 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 redirect all resources at your command to
re-define the requirements. 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 analyze the way you went about gathering, defining and documenting the requirements, and try to
improve it this time around.
In the second case, you need to have a chat with your Project Sponsor and / or Project Director.
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 (Budget, Scope,
Schedule and Quality), and, as a result, the Project Sponsor and / or Project Director 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!)
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; its just a process to manage enhancements as well as risks and mistakes. Changes
are often unavoidable, as in the case of legislative initiatives or technological advances, and change
control serves as a mechanism to assure everyone is aware of and agrees to all deviations from the
plan.

Problem: Project Team members dont 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, nobodys perfect. 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 cant 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 different, and some people react to certain management styles better 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 handled 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, immature, 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 and / or Project Director. Explain how the team is doing all it can
to deliver the product, but the support structure is failing you all around. Make specific suggestions 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 technologies altogether, but if you do get entangled in one, be
ruthless 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 somebodys half-baked product.

PITFALL #2 You Drop the Issue Ball

In the course of the project, many issues come up. By definition, issues have a potentially adverse impact
on the projects Triple Constraints. 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 Managers 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 youre not
going away. Keep asking them what you can do to help get the issue resolved, but keep tracking their
progress or lack thereof 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.
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 constantly 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 number 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 projects progress and potential problems.
The two most important questions the Project Status Report must answer are:

What is the latest, best available estimate for the remaining work, and how does it compare with the
schedule?

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 Managers 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? Thats 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 readiness assessment and transition
planning need to be done.

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 solutions to you.
As a reasonably intelligent person, you should be able to understand the concepts by listening and asking
questions. If, however, the technical folks can't explain to your satisfaction 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 (thats like hanging a
picture for your mother-in-law: A little more to the left. No, thats too far! Back a bit to the right. Hmm How
about a little higher? No, thats too high! etc., etc.) Or you may be chasing signatures in a circle, with
every person telling you that he can't sign until the other person does (thats 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 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 operational. 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 followed.
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.
But the next time, you will know the team members bias

unbridled optimism (forecasting too little),

gloomy pessimism (forecasting way too much) or

random dont-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 youre 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.