Transition to Execution

FROM PLAN TO WORK

In this chapter, we’ll talk about the transition from planning to execution.
We must get approval for the plan, establish a performance measurement baseline
(PMB), acquire any resources we need that we don’t already have, build our
team, and lead that team to perform the work.

Projects change as they move forward. Sometimes the change is driven from within
the project: we discovered our planned approach didn’t work and must now try a
different avenue, or we uncovered a surprise that affects how we move forward.
Other times, change comes from stakeholders, either because their needs have
changed or because they’ve simply changed their minds. To make sure those
changes are handled properly, requires a change management system.

Project execution includes deciding when and how to execute contingency plans,
corrective actions, and workarounds.
PLAN APPROVAL
Get your plan approved by key stakeholders to avoid potential miscommunication
about objectives and deliverables, help stakeholders understand the costs and risks
associated with the project, and ensure that you and your stakeholders are in
alignment.

The two methods of getting plan approval are to provide a written plan and to conduct
a briefing or presentation—or both. Make sure you communicate the plan in ways
your audience can understand. Not all stakeholders are necessarily familiar with
project management, and a bewildering array of network diagrams and PERT
calculations can confuse rather than illuminate.

It’s cheaper and easier to resolve issues in planning than to find out after the fact that
what you did (brilliantly, on time, and under budget) turns out not to be what they
really wanted. Always confirm plan approval in writing.
PERFORMANCE MEASUREMENT BASELINE

The performance measurement baseline (PMB) is the summation of the plan. It’s
the metric that will show project status and reveal any discrepancies. The PMB
must cover all the triple constraints: are we on schedule, are we on budget, and
are we getting the work done? Although it’s technically not part of the plan, it should
be presented along with the plan and approved by stakeholders.
Schedule
A tracking Gantt chart can serve as a schedule baseline. If you can read an
ordinary Gantt chart, a tracking Gantt is easy. Instead of one bar representing an
activity, you now have two. The first bar represents the schedule. Underneath it, a
second bar represents the actual start, finish, and duration of completed activities.
For activities not yet started, the tracking Gantt shows when they will start and finish
based on what’s happened to early activities.

The gray bars represent the original schedule, the black bars represent actual
performance, and the striped bars are a forecast based on results to date. The
dotted line represents where we are in the project: the end of Week 24.

You’ll notice that Task B finished two weeks ahead of schedule, and Task C finished
one week behind schedule. Task D, which was dependent on both, still started two
weeks early because only Task B was critical. Task E, dependent on Task C, started
and finished a week late.
You’ll notice that Task B finished two weeks ahead of schedule, and Task C finished one week behind
schedule. Task D, which was dependent on both, still started two weeks early because only Task B
was critical. Task E, dependent on Task C, started and finished a week late.
Notice that Task D is in progress as of Week 24. We know when it started, but we can only
forecast when it will finish. That’s why the bar changes from solid black to striped. Assuming
Task D takes as much time as scheduled, it will finish two weeks early. It’s on the critical path,
which means all remaining tasks are expected to start early, and we forecast that the project
will end two weeks ahead of schedule. But that’s not the final word. If we encounter problems
in the second half of Task D or in subsequent tasks, we could consume those two weeks and
more. Still, it’s good news that as of right now we are ahead of schedule.
Scope Verification
The tracking Gantt chart tells us about the schedule, but it doesn’t indicate what has
been done. The process of scope verification involves whatever steps are necessary
to ensure that the work is done and done in line with requirements. Each work
package creates some sort of deliverable, whether it’s a final deliverable to be
handed to the customer, or an interim deliverable that will support another activity or
work package within the project.

You can use the WBS as a tool to manage scope verification. Depending on the level
of work maturity and the difficulty or sensitivity of the work, you must decide how
carefully you need to check that the work is being done. For some work packages,
the word of the person you assign may be fully satisfactory.
In other cases, you may need to perform in-depth analysis and inspection.
If the output requires full-blown testing, it’s usually smarter to make the test a
separate activity or work package.
Cost Baseline

Different projects and organizations require different ways of tracking Project costs. You may need to
review reports from the financial office to classify all project expenses against specific accounting
categories, or prepare detailed budget vs. actual spread sheets. However, the best way to track a cost
baseline is with an “s-curve” chart showing cumulative sunk costs to date, as shown below.
This baseline describes a project that has a budgeted cost of $25,000 and will take place over twelve
weeks. As with the tracking Gantt chart, you can add a second line representing the actual money
expended to date as the figures come in.
As we learned in the discussion of the earned value method in the previous week, you can use the cost
baseline as a performance measurement baseline PMB for all three constraints. We spend the money
in the plan to accomplish specific elements of work, so the Money spent to date parallels the work
accomplished to date. We spend the Money over time, so the money spent to date also tracks whether
we’re accomplishing the work according to the schedule.
The cost baseline can’t distinguish between critical and noncritical activities, and it can’t indicate how
well the work was completed, but it’s a good proxy for showing overall performance.
Costs

Weeks
TEAMS AND OTHER RESOURCES

Who will be on the project team? What do you have to do to get hold of the money?
How will you acquire (obtain) any necessary equipment, tools, or other resources?
As part of the transition from planning to execution, you must acquire any people or
resources you don’t already have. Normally, the authority to do so should be spelled
out either in the project charter or as part of obtaining plan approval. In some cases,
you may need to negotiate with stakeholders or resource owners to acquire what
you need.
Acquiring the Team
You may have been assigned a project team at the beginning, but negotiation may be
possible. Your responsibility assignment matrix (RAM) will reveal any gaps in skill
or knowledge that may exist, and when your schedule is loaded, it will reveal cases in
which the work you need to do exceeds the resources available with which to do it.

Depending on the gaps, you may need additional full-time people for the duration of
the project, full-time people for phases or elements of the project, or part-time people.
In addition to existing staff, you can consider hiring permanently (if you’ll have a long-
term need for the skill), arranging training or coaching to expand the skills of existing
staff), hiring consultants or part-timers (especially for cases in which you need highly
specialized skills for short durations), or requiring overtime.

If specific team members have a difficult time working together, you may be able to
swap them for more congenial and cooperative replacements. If your team has people
in high demand, don’t be surprised if other projects or operations take them away.
That’s a common risk, and should be addressed in your risk management plan.
Team Development
Project managers often aren’t the permanent supervisors of their team members.
Many team members have regular positions and official supervisors. As a result, you
don’t have the same type and level of power. That’s not necessarily harmful. One of
the simplest and best definitions of a leader is “someone who gets followed.” We follow
people for all sorts of reasons, ranging from attitude to skill to persuasiveness to
rewards. The importance of official supervisory status may be less than you think.

The subject of team building has filled hundreds of books, and a full discussion is far
beyond the scope of this volume. The AMACOM Self-Study program includes a course
called Making Teams Work, along with numerous other courses in leadership and
supervision, and there are hundreds of courses and workshops in team building
offered around the world. Your success as a project manager usually rests on the
backs of your team members, so developing a high performance team is a core project
management need. That doesn’t merely help you succeed on today’s project, but
builds a reputation that will help you manage larger and more important projects in the
future.
Kickoff Meeting
Many project management authorities recommend a kickoff meeting as a way to get a project
started. The kickoff meeting should include team members, project sponsors, customers, and
other important stakeholders. A kickoff meeting is the first meeting with the project team and
the client of the project. This meeting would follow definition of the base elements for the
project and other project planning activities. This meeting introduces the members of the
project team and the client and provides the opportunity to discuss the role of team
members.Review the plan, identify and share the roles that each participant will review, and
start the project with a burst of high energy.
Work Management
Because team members on a project must perform certain activities in a certain
sequence, on more complex projects it becomes all too easy to overlook work or forget
important details. Always keep some sort of record of who has been assigned to what activity
as a fundamental part of keeping track of Project progress.

If the project is particularly large or complicated, details are critical, and you have a large
team, consider using a work management form, often called a WBS (Work Breakdown
Structure) Dictionary.
Fundamentals of Change Management
The purpose of a change management system is to ensure that changes are
documented, analyzed for impact on the project, approved (or disapproved) by the
appropriate person(s), and implemented into the project plan.

Establish a clear change management policy in writing and make sure all stakeholders
know about the process. It shouldn’t be your goal to make changes difficult, but it is
important that a process be followed. The person wanting the change should submit a
change request in writing. The change request explains the change, may provide a
rationale for the change, and gives any supporting information. The project manager
enters every change request into a change log.

Every change needs to be analyzed, and that’s usually the job of the Project manager,
who’s often in the best position to do so. What new activities will need to be
performed? Which planned activities will need to be changed or dropped? Will other
work on the project be affected? What will the change cost? Will it take additional time?
A change management policy needs to specify who approves changes. It could be
you as project manager, the project sponsor, or the customer. Sometimes, the level
of approval depends on the impact of the change: if it’s minor, the project manager
may simply approve it, but if it’s going to have a big impact on the rest of the project,
higher levels of the organization may want to have a say.

A change can be approved, rejected, conditionally approved, or deferred

(postponned). If a change is approved, note it in the change log, notify the requester,
and update the project plan. If a change is rejected, note it in the change log and
notify the requester.

A change can be conditionally approved. For example, you might make the change if
the requester will pay for it. A change can also be deferred, especially if you need
additional information or more analysis is required. Keep the requester informed and
keep the change log updated.
Change Control Boards and Configuration Management
In large engineering and (Information Technology) IT projects, it’s often the case that
a seemingly harmless change can have catastrophic ripple effects elsewhere in the
project. If you want to change a component on an airplane, for example, there are
several layers of Federal Aviation Administration (FAA) approval that you need before
you can go ahead.

Configuration management is an advanced type of change management used in this

kind of project. Configuration changes, no matter who requests them, go through
intensive review before they can be approved. Along with configuration management,
such systems often establish a change control board to issue final approval. The
project manager may chair the change control board, or serve as its secretary.
SOLVING PROBLEMS
As we discussed earlier, risks are future tense, but problems are in the present. No
matter how well you plan, sometimes threats turn into problems. Three types of
problem solving activities belong in project execution: implementing contingency
plans, corrective actions, and workarounds.

Contingency (Emergency) Plans

For many of our risks, we modified the project plan to include our risk response. For
some risks, we chose to develop contingency plans: things we will do if and only if the
issue actually occurs or sends a warning signal that it is about to occur. Some
contingency plans exist because we’re really hoping to avoid a large expenditure to
address a rare event—but if that event happens, we’re stuck with the bill.

Every contingency plan must have a trigger (sign), which is an event that tells us that
we should put that plan into operation. As part of project execution, you need to watch
for those triggers, and when appropriate, launch contingency plans.
By their nature, contingency plans are effectively project changes. They consume
resources and time, and may alter scope. Though you don’t necessarily have to
enter these into the change log, you may need to rebaseline parts of the project
once the emergency has passed.

Evaluate the performance of the contingency plan. Is it solving the issue

appropriately? Now that you see it in the real world, could it be improved?

Could we have addressed the underlying risk more effectively?

Corrective Actions and Work arounds
Risk management is proactive: we plan and act in advance of the actual need.
We implement preventive actions. Problem solving is reactive: we deal with the problem at
hand with the tools we have available. We develop and implement corrective actions and
workarounds (a way of dealing with a problem or making something work despite the problem,
without completely solving it, but it may expire some hints about the solution). There are many
strategies for effective problem solving. Depending on the subject matter of your project, the
type of problem, and its importance, consider the steps presented below.

Problem Solving Strategy

1. Define the problem.
2. Identify the underlying cause or issue.
3. Brainstorm multiple solutions.
4. Decide on the best solution.
5. Plan how the solution will be implemented.
6. Verify that the solution has been effective, or repeat if not.
7. Document the issue and response for lessons learned review.
8. Recognize contributors to solving the problem.