Copyright © 2012 Jay Roberds

All rights reserved, no part of this document may be reproduced

or transmitted in any form or by any means, electronic, mechanical,

photocopying, recording, or otherwise, without prior written

permission of the Author.

Table of Contents

Preface

Introduction

Vision, Scope, and Dealing with Unknowns

Choosing a Methodology

Quality Management

Work Breakdown Structure

Project Schedule

Including Subcontracted Deliverables in your Schedule

Work product approvals

Critical path and key activities

Responding to Change Requests

Contingency

Program Schedules

Communicating Expectations

Cost Management

Calculating costs

Cost objectives

Program Costs

Tracking expenditures
Base lines and Change Management

Reporting your Status

Closing your Project and Learning from your Experience

 Preface
Companies use projects to add value to their organization. Your
responsibility as the Project Manager is to meet this expected value

through agreed upon constraints in scope, schedule, and cost.

Initial success comes through leadership, relationship management,

basic project planning skills, and a good team.

Delivering a string of successful projects builds trust in your

abilities leading to assignments on larger, more complicated projects

(and promotions). Problems lead to concerns and deteriorate your

manager’s trust. Keeping your career on track requires continuous

awareness and training. Unfortunately, the tendency is to focus on

learning more advanced PM techniques at the sacrifice of the

fundamentals.
 During my 30 years of providing corrective action and advice to
troubled projects, the vast majority of root cause issues developed
by not adequately utilizing the fundamental PM processes. The

most common problem areas were scope, requirements, schedule,

risk, and change management.

“the vast majority of root cause issues developed by not

adequately utilizing the fundamental PM processes.”

This Project Management Advice series focus on these processes

and the balance a PM must consider in their application. They will

provide the most benefit to those in first few years as a PM, but

even my reviewers with 20 years PM experience mentioned learning

and understanding a few areas better.

 Introduction
Schedules are done in many different variations and at different
detail levels. Unfortunately, some PM’s think actual Project

Scheduling tools are too time consuming. Sure, small projects can
be done at a high level in tools such as PowerPoint, but as you add

more people and tasks, a project has too many interfaces,

dependencies, and communication requirements to execute without

a more formal mechanism. Most team members will know their

individual responsibilities, and some will have the foresight to

ensure they meet others’ dependencies, but this is a risky approach

on larger efforts. Schedule Management brings together all aspects

of planning your project to not only let people know their

assignments and expectations, but it also lets all stakeholders

understand when decisions should be made to optimally deliver

results. A detailed Project Schedule is a working document to help

you analyze your planning, communicate those plans to the

stakeholder, and closely monitor progress. You want enough detail

in your schedule to communicate plans and accurately monitor

progress without micromanaging your teams work.

Schedule Management will also help maximize the business value

of the projects deliverables if it has been properly constructed and

communicated. The business value in its simplest term is the

benefit provided by the deliverables less the cost of producing the

deliverables, so the relevant question becomes how your schedule

can maximize the benefit, while reducing the cost. Costs are

lowered as you compress your schedule and ensure allocation levels

are appropriate. On maximizing value, schedules ensure the right

people are making timely decisions with the right information.

Sure, change will happen and should be accepted when it adds

value, but if you plan design decisions to occur just prior or during

building your deliverables, you will minimize disruptions. One way

to verify you have included all prerequisites and dependencies is to

review your schedule in reverse order thinking about what

prerequisites each activity requires.

“On maximizing value, schedules ensure the right

people are making timely decisions with the right

information.”

Labor is often a major component in the project’s cost

calculations. As the schedule finalizes, you can include labor cost

estimates along with your other estimates including but not limited

to hardware, software licensing, and other contracts. Most

organizations push for formal value analysis that defines the costs

and benefits the project will provide in an effort to prioritize their

projects. Important to this prioritization is the opportunity costs in

committing your organization’s resources to this effort and not

others. Conflict occurs when not all stakeholders agree with the
priority.

This book will cover a recommended process for creating a project

schedule, and tips for analyzing your plan for higher probability of

success. There are many good training materials available to show

you how to use your selected tool, and defining all the terms and
formulas involved with creating and monitoring a schedule. I’ll

share insight and thought processes in the creation of a project

schedule and common mistakes PMs make. The examples will be

using MS Project simply because that is what I have it installed at

the moment, but the principles are the same for all tools. Find a

tool you are comfortable with and learn it.

 Vision, Scope, and Dealing with Unknowns
All projects have some level of uncertainty. The PM must decide
if the level allows for project success or more details must be

discussed. The concerns are gaps in the features and requirements

and missing activities necessary to deliver on your objectives. The

key is to recognize the difference between missing information and

unknown information. Missing information is usually a result of

rushed or poor planning. PM’s accepting that not all facts were

uncovered in their initial interview and planning process. In their

defense, PMs are often assigned after some initial planning and

high level scheduling has been done. Good PMs know they are

responsible for the project objectives and not just managing tasks.

They immediately start building a visual map of their final

deliverables with thoughts on complexity and quantity.

The project’s scope and requirements feed into the Work

Breakdown Structure (WBS). This WBS can form the basis for

your visual mapping by providing a context to better understand the

deliverables. You may also add a pictorial image / diagram to

represent the project deliverables. Spend time discussing these

deliverables as your stakeholders may have different perceptions on

the deliverables. Even the sponsor’s representatives often have

different opinions based on their individual responsibilities. Holding

a vision or design session, with all the stakeholders, should be

arranged once the deliverable image starts coalescing. This

prevents the various capability process or technical areas from

creating gaps and conflicts in your final deliverable. Too many

times, we assume those specifying their requirements have a fully

integrated solution.

Even with an aligned vision, you will still have unknown details

impacting your workload. As these details result from design work

once project execution starts, you must make assumptions.

Typically this relates to the quantity and complexity of the

deliverable components which impacts the scheduling of activities,

assignments, and duration. These assumptions act as planning

parameters in building your schedule and finalizing your Project

plan. As part of your vision session, discuss these parameters so all

stakeholders can assist in their validation. Hopefully, it will not be

the case, but you will be able to show any growth in expectations to

justify exceeding your baseline. Suppliers use assumptions to

control their contractual responsibility, especially on fixed price

agreements. Any remaining exposure and related risk is used to

establish their contingency to include in their pricing. The Sourcing

Management Guidebook will explain how eliminating these

unknowns for Suppliers will reduce your overall contract cost.

“These assumptions act as planning parameters in

building your schedule and finalizing your Project plan.”

Include time in the agenda for discussing any non-functional

requirements on the projects deliverables. Your deliverable may

need to operate within expected service level agreements, traffic

capacity, warranty, and continuity expectations. Your WBS and

schedule should include activities (meetings with operations staff,

disaster recovery, performance testing) and design (infrastructure,

monitoring, backup) to ensure all operational components fully meet

these expectations.

This session also helps your team understand the context of the

deliverables they are developing and reasons for the associated

constraints. This context may save documentation time and help

your team make better decisions when completing their

assignments. Finding the right detail for design work keeps your

upfront activities from slowing and improves team morale as they

are not as task oriented and aware how their assignments are

contributing to final deliverables.

 Choosing a Methodology
Nothing impacts your approach to delivering your objectives more
than your methodology. Some industries have a fairly set approach

to projects. Building business capability typically uses some

variation or combination of agile and waterfall. There are pros and

cons to all approaches, but in all cases, companies need to

understand the project investment they are making, so there is

expectation that your constraints (cost, schedule, and requirements)

will fulfill these expectations. It does not matter if you are

following a more traditional methodology, such as waterfall where

requirements are set, and cost and schedule are estimated, or a

newer agile methodology where cost and schedule is defined and

requirements are prioritized. In either case, your company needs a

solution that adds the expected value in the expected timeframe.

The key in both methodologies is adequate planning.

“even new agile approaches require substantial planning

information”

Be careful if you find yourself saying there are so many

unknowns you cannot plan the project in detail and need to use an

agile methodology. You may be correct in choosing agile, but this

attitude / situation is not the best in starting a project, as even new

agile approaches require substantial planning information. As

discussed earlier, if you can define enough deliverable attributes

and planning parameters to effectively schedule your project even

with unknowns, and should not by itself drive your methodology

choice. Projects building web sites know their planned user

interactions, roughly the flow of information, and number of

products / services that are being presented. All these can be used

to accurately estimate the quantity of unique objects and plan a

number of repetitions. For projects driven by regulatory

requirements, you can analyze the impacted process areas, seek

early clarity, and again fairly well estimate the required work.
Even in creating games, there are many known parameters you can

safely base your plans on. You probably know the number of game

levels, desired length of each level, scoring mechanism and graphic

goals. Yes, you may not know all the details of each

process/level/requirement, but you can reasonably create a schedule

based on the known parameters. Use Risk Management to

determine if any remaining gaps require mitigation.

Each methodology choice has its own specific requirements that

all stakeholders should understand to prevent issues from arising.

For example, any methodology requires time from the sponsor’s

organization representatives to provide design input and verify

results. Waterfall tends to concentrate this time into windows,

while agile spreads the commitment over the project.

“The fundamentals needed to produce the project

deliverables remain relatively the same for any

methodology.”
 The fundamentals needed to produce the project deliverables

remain relatively the same for any methodology. You need

planning, scope, requirements, design, build, verification, and

deployment. PMs successful in a particular methodology know how

to weave these fundamentals together, and organizations have

developed operational support for the projects using the

organization’s usual methodologies. Choosing a new methodology

requires more effort and coordination, so there should be a reason

for the new approach beyond some of the team want to try.

External dependencies on your deliverables must be considered in

your choice and planned into your schedule. All stakeholders and

operations must be on board with the decision, understand potential

risks, and commit as the intent should be to maximize the project’s

value contribution.
 Quality Management
This will be discussed with much more detail in the Quality
Management Guidebook, but quality related activities must be

planned into your schedule, designed into your deliverables, and

verified. Companies have varying expectations and requirements

for quality, higher for those involving safety (food, weapons, injury,

or other regulated industries). Best to have the appropriate quality

built into your everyday way of working, but at the very least use

exit criteria as control points. Realize waiting until the end of a

phase slows down any defect correction times, and allow a defect to

propagate into other artifacts. As the defect process includes

identification, analysis, prioritization, assignment, correction, and

verification, you can see where the quicker a defect is recognized,

the less time and disruption required. This is discussed more in the

Change and Defect Management Guidebook, but a PM should have

sponsor agreement on specific exit criteria such as what priority

defects must be closed.

“Best to have the appropriate quality built into your

everyday way of working”

Consider two different categories of quality when building your

WBS. First up is verifying your deliverables meet your design

expectations and provide accurate results. Next, ensure the

deliverables operate as expected once in operations. Operational

expectations are covered by the non-functional requirements

discussed in the Scope and Requirements Management Guidebook

and should be designed into your deliverables and verified. Include

the architectural and performance engineering activities to ensure

operational monitoring and availability, response times, and

capacity. Ensure your stakeholders understand these targets as the

natural tendency is building your deliverables to deliver peak

performance, but exceeding these SLAs requires more time,

hardware, and processes that add cost and time to your project.
You need to include activities for performance testing on these

capacity and throughput requirements. Also, include enough time

for your internal team verifications before sponsor verification and

acceptance.

Include defect correction process in your WBS final verification

process and plan for appropriate time allocation. Remember to not

release all team members before final acceptance. Organize your

final verification and testing phase in 3 cycles. First, eliminate any

show stopper defects that prevent overall process from executing.

Next, verify processing results meet expectations, and finally, a

clean run to satisfy entry criteria for sponsor acceptance

verification. Preparing for this verification runs parallel to

development in creating test scenarios and data necessary to

execute.

Most important to understand quality is a mental and regulatory

state that the industry, organization, and project team plans into its
processes. A project missing major exit criteria faces new doubt and

extra attention so ensure your team understands and has sufficient

time to meet expectations.
 Work Breakdown Structure
The WBS is a transitional work product that helps you bridge the
gap from your scope / requirements to your schedule. It should be

continually updated as information is discovered and decisions made

during the overall planning process. Notes from your vision session

and capability / process areas from your scope and requirements

drive developing a Work Breakdown Structure (WBS) consisting of

a hierarchy of deliverables / activities. The important information

to capture is the “Work” you must perform to produce your

deliverables kept in context of a hierarchy, “breakdown Structure”.

The intent is to keep each layer of heirarchy with approximately

the same topic detail determined first by business relationships, and

secondly by size and complexity of performing the task.

You should make multiple passes through the WBS to ensure you

have covered all the activities. This is a common failing point for
PMs. For every activity you miss, you are using up your schedule

float and add extra pressure to your overall team. This is the first

of many times you should trace requirements to their intended

deliverable. Tracing requirements is a Quality Management

technique to verify that your requirements are fully represented in

your work products. Check with both Business and IT specialists

confirming that requirements will be fully satisfied with the

deliverables. It will save time later if you note the requirements,

via the requirement id, being satisfied within each activity. This
allows for a faster verification that work products produced by an

activity meet a set list of requirements. It also provides more

information to person assigned the activity in your schedule

assisting them in producing a quality work product.

“some requirements are goals and even wish lists for

items that have pestered business operations for many

years and have never been successfully fixed”

This verification can be difficult if your scope is not defined or

requirements well written. Your vision session will help you a little,

but will not be a replacement through project. The importance of

good scope definition and requirements is covered in the Scope and

Requirements Management Guidebook. Remember, your schedule

and therefore success depends heavily on understanding your final

deliverables. Requirements that are a combination of random

brainstorming or interviews typically leave you with mixed bag of

high level capability processes and detail reporting goals (not

requirements). Yes, some requirements are goals and even wish

lists for items that have pestered business operations for many

years and have never been successfully fixed. Usually there is a

reason these “requirements” have not been implemented. There

may be a lack of consensus on the actual design, or there is a lack of

commitment/priority from all the stakeholder representatives so be

careful about accepting these into your scope if they cannot be

understood within your vision meetings.

 For the technical and deployment activities, it is best to copy
from another project, and use its schedule as preliminary list for
your own activities. Do analyze them thoroughly and review

lessons learned, as not many PMs update their schedule with

activities they missed or issues that arise. Ask specialists in

different areas to review, and share their experience on common

mistakes so you can add to your WBS. Ask the various support
groups regarding their expected lead times, and make note of these

dependencies.

Business Change Management is a frequently overlooked WBS

area, and can make a well implemented system fail in meeting its

objectives. It is not always the PM’s responsibility, but you should

ensure someone is covering it. Business Change Management

commonly includes documenting any operational process changes,

change communication, training of personnel, business side

deployment activities and administrative dependencies that must be

in sync (i.e. table updates, catalog entries, product descriptions, …).

Change is hard on some people, so there is a tendency to resist.

Your communications need to share reasoning and direction

gathering full support. If you are not directly responsible, add high

level activities in your schedule, to communicate the dependencies

and responsible assignments as many of these items have lead times

are required for the deliverable verifications, but remember, you are

still indirectly responsible as your project will not succeed if the

activities do not occur timely.

The WBS can be done in any hierarchical de-composition tools

(i.e. Visio) or outline (Word, Excel). There are plenty out there that

will help you manage the hierarchy, but MS Project provides a good
outlining mechanism with easy movement and copying of tasks. It

also allows you to insert levels, promote or indent activities as

necessary. It provides the ability to compress and expand portions

of WBS as needed to focus on a particular area, which is helpful in

workshops.

While developing the WBS, concentrate mainly on activity names

and more detailed descriptions, if extra details are needed. The

context of the hierarchy provides some information on the activity

or components. Do include enough detail in the name to understand

intent. Too many times activity lists only have 2 or 3 word names.

If you cannot reasonably get enough definition in the name, there is

a Notes field / column you can insert into MS Project for a longer

description, and then you can hide / show the column as needed.

Specify the artifacts resulting from the activity if you need to

further clarify expectations from the activity. You can even include

the person who is responsible for verification which will let the

assigned team member know who will be approving their artifact,

so they can ask for clarification.

 While these WBS discussions are fresh in your mind, highlight

certain activities for later consideration. First, highlight activities

without the same details (lower levels) as other activities, so you do

not forget to revisit in another pass of WBS. Second is to highlight

critical activities, those activities that at first glance seem critical to

your success. I’ll discuss this more in the critical path and activities
section.

And finally, for anyone wondering how or why to incorporate a

WBS into an agile organized project. A WBS as part of your

product backlog helps you plan better sprints by giving a context to

the sprint selected requirements. This planning results in more

efficient sprints providing more process oriented building blocks. By

driving your agile WBS one level below your use cases, repetitive

activities and dependencies are more recognizable. A WBS also

provides a place for pre- (architecture frameworks) and post-

(verification) sprint activities to be planned and monitored.

Reporting progress is much easier with a WBS showing progress

toward your final product deliverable. In agile projects not utilizing

a WBS, you will find the product backlog mixes a product hierarchy,

use cases, and product wide requirements.

 Project Schedule
The Project Manager has responsibility with team input to decide
the best way to organize the team’s planned activities into a

schedule. With a waterfall methodology, you can choose to

maintain the hierarchy of the WBS for basis of your schedule, or

group like activities together (all analysis, all development …).

Staying as close to a deliverable based grouping schedule as possible

between milestones merging the IT and Business activities

necessary for a deliverable together makes it easier to set

dependencies and to report progress in terms your sponsor will

understand. This also helps later in setting dependencies and

overlaps to compress your schedule duration. If your vision session

identifies too many knowledge gaps, you can allocate more time to

allow second pass for review and adjustments or extend the length

of a sprint. This can become a little complicated if you are forced to

have rigid milestones with go/no go decisions. This rigidity adds

float to your schedule, but some organizations have the culture.

Building an agile schedule, you schedule your pre- and post-

sprint activities and then prioritize your use cases into sprints. Do

not let anyone tell you there are no dependencies to be considered

nor that all use cases are the highest priority. They may be all

critical to your final deliverable, but they must be logically and

efficiently separated into sprints, and the first step is setting the

dependencies. As you read through this section and if your focus is

more on agile, think about the fundamental drivers and how to map

this driving need into an agile schedule.

One area where numerous projects have early problems is with a

Current State Analysis. While on the surface, it seems beneficial to

understand and document the current processes and data. Once

you enter this analysis activity, there is always more information

you can uncover that may or may not be relevant to existing

business processes but relics of previous operations. Documenting

this current state is very popular with consultants who need time to

learn the current business processes (and get paid for that time.) If

you truly need this step, be very focused on the areas and level you

are documenting. Let the level of your process updates drive this
research. You are only looking for enough information to plan new

design. Even in cases where you are completely replacing

something with a new technology, go one level at a time prioritizing

need for additional information on each pass.

Now, it is time to turn your WBS into the project schedule. You

have participated in many conversations during your scope

definition, requirements discussion, and WBS creation. Hopefully,

you have not delegated these conversations to others, as now you

use this knowledge to set dependency connections in your schedule.

Make a quick pass through lowest activity level making each task
dependent on prior task. This starts showing structure to your

Gantt chart. Make additional passes through your WBS setting

your dependencies at each level. Not all dependencies will be at the
same level. Try making the connection at the lowest appropriate
activity level, as this will help you later in compressing your
schedule with overlaps. In other words, if all the sub-level tasks are

dependent on an activity, make the connection one level up, but if

not make it to the appropriate lower level task.

Next step is to set initial assignment of tasks to your team

members. Get senior members’ input on assignments. As much as

possible you want a senior person owning a deliverable with more

junior members assisting. Higher performing teams have an

appropriate mix of senior, experienced, and junior level resources.

It actually creates more of team atmosphere with more

communication, mentoring, and oversight. Monitor your team’s

interactions ensuring they stay productive and not create conflict.

Insist everyone treats each other constructively and with respect.

“When making the assignments, consider your overall

staffing plans during ramp-up and ramp-down.”

When making the assignments, consider your overall staffing

plans during ramp-up and ramp-down. You want to ensure

continued availability of resources with knowledge on all your work

products. This is particularly important when ramping down

resource counts / costs as you proceed through the testing and

verification phases. For example, if you have someone that will be

leaving your project at the end of development, and they have 5

complex objects they are developing. You may want someone else to
do one of them, so the other person has enough knowledge to

resolve any defects during testing.

With the assignment process done, you can set durations based

on experience levels. Start your intermediate resources as baseline

with normal productivity, and assume a standard 10-20% reduction

in duration for your senior members and 20% more time for junior

members. The senior reduction is not as important as it provides

you a little embedded contingency, and provides some buffer time

for mentoring, but do not forget a learning curve for the junior

members.

I never allow an activity to have duration of over two weeks.

This makes monitoring and reporting status very difficult and leads

to schedule slippage. Problem with longer durations are most

people are overly optimistic with their completion estimates. They

will make rapid progress for the first 90%, but the last 10% carries

well past the deadline. My preference is to keep durations at one

week as a norm. Do this by adding more detail tasks under the

activity, and specify durations and assignments for these detail

tasks. This will help you distribute the work, create overlaps, and

shorten the overall duration. Basically it gives you higher degree of

control over both setting your baseline schedule, and accurately

monitoring progress, but yes, it is more work.

 At this point your scheduled end date is probably way past your
expected completion. Allocations and dependencies are two primary
areas that require editing at this point. Likely there will be both

those highly over-allocated and underutilized. Timeframes where

your team has overall low allocation is due to dependencies. You

have to look at the root cause of the dependencies, and decide lowest

level dependency, so you can overlap tasks. MS Project has 4

connection options including “start to finish” and “start to start”

with either positive or negative offsets to overlap tasks. “Start to

start” is good for cases where two activities are best worked

together. Becoming familiar with the various connection

possibilities will help you make these adjustments faster.

Some scheduling tools have automated ways to “correct” the

balance taking a combination of adjustments. You may not

recognize your WBS / schedule anymore, so save a copy before you

initiate this automated process. The undo command does not

always get you back. Manually, this is often a trial and error

process constantly referring back to the weekly allocated hours, but

gives you better control, and may identify erroneous planning data
impacting the schedule. In adjusting your assignments ensure your

senior members are not fully allocated. Odds are they will spend
more time mentoring and working issues, and providing more

challenging tasks to junior people helps with their motivation,

learning, and teamwork. If at all possible, keep your senior people

at 80 to 90% allocation level, and the rest of team fully allocated.

As a side note on Team Management, these senior people that are

interested in raising others competency levels often make the best

technical staff managers. Remember to plan holidays and vacations

into your scheduled allocations. MS Project has ability to set

holidays as a non-work day, but for vacations, add an

administration task group at end of schedule with a task at 100%

allocation for each vacation. Also provides a good place to record

training and other times when a team member is not working on

your project. This helps your allocating process and serves as a

reminder when monitoring execution that time-off may impact

other areas, and create issues that need attention. It is bad for

team morale and future performance if someone needs to work

twice as hard before and after their vacation to make up for your

oversight. For similar reasons, include a Project Management

grouping in this section showing PM deliverable responsibility, and

ensure you personally do not overcommit.

“add an administration task group at end of schedule

with a task at 100% allocation for each vacation”

 Understand the priorities for any team members that are
partially dedicated to your project. Difficult when a team
member’s Manager says yes, they promised 40 hours of allocation,
but not necessarily during the week you had planned. During

execution, send early planning reminders to them (and their

Manager as needed) during execution. This is a common conflict /

issue in projects that can be difficult to resolve. Consider carefully

before assigning partially allocated people with tasks on your

critical path.

Add your milestones to your schedule representing major

deliverables as designated by your methodology choice. Also, add

your external dependencies into your schedule, one milestone for

when external deliverable is needed, and another back in schedule

with enough lead time if any triggering action is required on your

part. Highlight and understand any dependencies other projects

have on you. Nothing becomes visible and escalated faster than

when you miss one of your own deliverables that negatively impacts

other projects or operations. It is good to know when you are on

other projects critical path. Unfortunately, many PMs will deflect

their schedule delays as waiting on your deliverable, even when

they are not ready to use your deliverable.

For larger projects, there are synergies that can be gained where

activities are performing similar, repetitive functions. A little more

quality time spent on first iteration, usually translates into

subsequent activities taking less time. This goes beyond code reuse
to just about every semi-repetitive activity such as page layouts,
test cases, reports.

Scheduling tools have some elaborate capabilities in adjusting

your schedule such as splitting tasks. Avoid using these as it overly

complicates your schedule, and if you have properly built your

schedule, tasks will be small enough they do not require splitting.

Often, it is easier to lower a person’s allocation instead of splitting.

Some people take schedule gaps very literal and plan other
activities in that time, even though in your mind the time should be

utilized to move forward.

 Including Subcontracted Deliverables in your

Schedule
Sourcing portions of your deliverables to third parties is discussed

in more detail in my Sourcing Management Guidebook, but there

are implications on your schedule. When a supplier is providing

individuals under a time and material basis, plan them into your
schedule as any internal team member. When any deliverable is

subcontracted to a supplier, request a detail schedule from them in

the contract to merge into your master schedule, so all

interdependencies are noted and planned. You will want same level

expectations and progress feedback from the supplier. If a supplier

resists providing milestone level information, consider this in your

supplier selection process. Many times, suppliers will not want you

seeing these details to understand more of their cost and pricing

structure. Apply these same considerations for all other PM

processes, so supplier supports your management efforts.
 Work product approvals
Throughout your project, there should be verification that the
work products / artifacts are meeting your quality objectives. As

mentioned in the Quality Management Guidebook, you need to find

defects as close to their introduction as possible. When a defect

propagates down into more detailed work products, the correction

will take longer and require more people / coordination / decision

making. This verification can range from informal review and

validation on interim work up to formal review and multiple

stakeholder acceptances on milestone related deliverables.

You will need to allow appropriate time and meetings for people

to review the deliverables. Most suppliers will include a defined

acceptance period (3 to 10) days in their contract. This should

always overlap where the rest of team continues to progress, but

assign early activities with less potential controversial tasks to

prevent need for rework if a defect is found in the base work

product.

“the work product approver should have provided input

during creation”

As often as possible, the work product approver should have

provided input during creation, and be familiar with the work

product; otherwise, you have risk the approver may have different

opinion on how a requirement should have been accomplished.

Even though both ideas may work fine, you will need to spend time

and effort resolving this conflict. And if you are resolving too many
conflicts, it can distract you from other areas that need your

attention. Just as you should worry about your team’s morale, plan

so you enjoy your work.

 Critical path and key activities
As much time as you spend on adjusting your allocations and
dependencies, some float remains in your schedule. Float being the

time available between the completion of one task and the start of
the next. Assuming you have adequately removed enough of this

float by adjusting allocations and dependencies, the remaining float

gives you some built-in contingency to handle problems. Trying to

remove all the float provides diminishing returns in moving your

end date earlier and will complicate your schedule.

There is always at least one chain of activities that does not

contain any float and signals your critical path. In other words,

when an activity on the critical path is a day late, that day follows

you to the end of schedule unless you can mitigate it by being early

on a subsequent activity. You will want to monitor these activities

closer than others, and in most cases have a senior team member
also overseeing the activities.

“there are typically 5 to 10 activities key to your project’s

success”

In addition to the critical path, there are typically 5 to 10

activities key to your project’s success. These may be those

highlighted during your WBS development representing overly

complex activities, unknown design details, or contain new

technology. These should also be monitored closely, but try very

hard to keep these critical activities off your critical path, as these

have the most inherit risk, and as such, the higher probability for
slipping your schedule. You will find a little float at the end of these

activities can be very positive, and that 10% unallocated time on

your senior team members schedule can be utilized to wrap up

unknowns. If you feel particularly uncomfortable with an activity,

add 10 or 20% contingency to your duration estimate. Another

recommendation is to place these critical activities as early in your

schedule as possible, so if there is any overall slippage, you have

more time to recover. Sponsors and Management will quickly

forget these temporary delays if you recover and deliver on

schedule. And finally, review these activities in detail during your

risk management process for any specific mitigation activity to

lower risk.

Monitor your schedule as your critical path may change over time

if delays occur in other areas of your schedule, and you need to

evaluate the impacts on project health. Hopefully, it is because

activities on your critical path are being completed early so your

project stays in good shape. More likely is some activities outside of

the critical path have slipped triggering a new critical path, and you

should evaluate this change. Analyze the cause of the slippage to

determine trends for additional schedule problems. Consider any

necessary mentoring or assignment changes if it looks like

someone’s past performance is a sign of future expectations.

 Responding to Change Requests
Learn to recognize and accept value additive change. In all but
the simplest cases, project change can be expected. With an

efficient Change Control process, your end deliverable will provide

more value to your company as your deliverables will evolve to

better meet current business situations. The best place for change

is during analysis, where any correction is more readily

accomplished and less disruptive. If you have done a good job with

scoping and vision workshops, your project should not be

overwhelmed with change unless it comes from an external source

such as competitive market challenges. Recognize change that adds

value in contrast to those of personal preference and make

recommendation to the Change Control Board (CCB). The CCB

being a small committee who can approve change requests and

corresponding impacts on your baseline constraints.

“Learn to recognize and accept value additive change.”

Expect some disagreement whether an item is a change, which

would qualify for an updated baseline, or a defect, which must be

covered under existing plans. Change is a common source of conflict

between your Sponsor Representatives and team members, and

conflict is best addressed quickly with all stakeholders to prevent

the discord from growing. It is best to have good teamwork with

your sponsor representatives where each of you considers the others

perspective. Building an adversarial relationship does neither party

any good over the project life.
 Contingency
Organizations and executives have different attitudes regarding
contingency in your schedule / cost or only cost. Sponsors trying to

control costs may request you eliminate all contingency built into
your schedule. Removal is easy if you have kept the contingency as

a separate budget line. A good practice is to ask your sponsor their

preference when you start planning, so you can adjust as necessary

for the risk and uncertainty levels. In this case, you should consider

adding time to your key activities and reviewing your risk log being
more proactive by adding more mitigation activities. The Risk and

Issue Management Guidebook explains defining an appropriate

balance between risk and issues. Other executives will ensure you

have appropriately planned it into your schedule based on their

experiences and intuition. This can be another conflict source when

your immediate manager wants the contingency included, but your

sponsor eliminates any they notice, leaving you to balance out the

differences.

The best way to calculate exactly how much contingency is

embedded in your schedule is to calculate total available hours from

your staffing plan, and compare to the total allocation in your

schedule. For example if the staffing plan shows you have assigned

resources for 10,000 hours, but your schedule shows only 8,000

hours, you have 25% extra time available. You may want to

research where exactly this extra time is, as you do not want people
with long periods of inactivity. Although, it is very difficult to

effectively use float as contingency if it is single days spread

throughout your schedule to different people. If this calculation

shows over 30%, you may want to further compress your schedule,

to lower it to a more realistic level. You may find errors in your

staffing plan where you have someone starting too early or staying

too late.
 Program Schedules
There is a distinct difference between a Program level schedule
and your detail project schedule. Some try to merge all project

schedules into one large master schedule, but on a major program,

this can overwhelm you with details and updates from the projects.

Keep your Program schedule focused on program level activities and

monitoring the project interdependencies. Program schedules

should concentrate more at the milestone level and those activities

with dependencies (both internal project interdependencies and

external to Program). For deliverables where there is synergy

across multiple projects, do not raise them to the Program level,

assign responsibility to the most likely project and insert the

dependencies. On large programs, color code milestones and

deliverables names on project schedules that are included at the

program level as a reminder to Project Managers necessary

integration points.

“Keep your Program schedule focused on program level

activities and monitoring the project interdependencies.”

Project dependencies determine the schedule order and resource

availability determines the overlapping of projects. Given your

project scope boundaries set during the program scoping process,

you should understand project prerequisites. Any project that

creates an entity / object must be completed before projects that

utilize them. It is risky to complete projects out of order as you

cannot verify results due to missing objects. Project deliverables

that must be idled waiting for another to finish have larger

exposure to change.

There are also program level activities impacting all projects and

necessary for the overall success of program. Common architecture

framework and technology decisions should be included. Include

sourcing decisions at the Program level to prevent fragmentation

across the projects as this can add another layer of complexity. Also

include integration tasks to verify interoperability between

individual project scope boundaries at earliest time possible.

Programs tend to have a major impact on business operations

and must incorporate the planning for these business changes.

Business processes and forms may be altered requiring

documentation updates. Training material must be prepared for

any new process interaction involved and finally Program level

acceptance and closure. Ensure there is no conflict of resource

scheduling between the project and Program. This is easier if there

is clear delineation and allocations between Program and Project

resources.
 Communicating Expectations
You have been interactively working with your team to build the
schedule, but when you feel the schedule is getting finalized, start

reviewing it with all stakeholders. The first review should always

be with your team members, giving them time to understand your

expectations, and providing them an open environment to discuss

any concerns. Obtaining your teams buy-in is critical for overall

team morale and performance. A senior mentor or external peer

reviewing your plans before the Sponsor can provide invaluable

advice. Understand that you will also want your overall project

plan to include your budget ready for Sonsor review, with available

suggestions / alternatives ready to discuss. As with all Project

Management working products, a schedule not fully integrated and

in context with other work products cannot be fully approved.

“Sharing your planned process in advance provides a

solid foundation for later discussions and may help

overcome any preconceived dates.”

Start communicating with your sponsor early. All sponsors have

a preconceived idea about expected delivery timeframe and cost.

Inform them how you are building your work breakdown structure

and estimating durations. Sharing your planned process in advance

provides a solid foundation for later discussions and may help

overcome any preconceived dates. Just as you have received buy-in

from your team on estimating durations, you then have opportunity

for a personal buy-in from your sponsor. Sponsors do not like

backtracking from statements made in public meeting without fully

understanding reasons as many times their peers are included in

communication. This personal interaction will give Sponsor time to

reflect and have both of you looking for right solution and balance

between cost, schedule, and requirements. Sponsors do not listen

very well when PMs repeatedly say in generic terms a date is not

possible, but most sponsors will reconsider with a well-planned

project schedule if there are no critical business reasons.

Follow with communicating the final schedule (and Project Plan)

to all your other stakeholders and Management involved. Review

the plans with both your management, and your Team’s Managers,

so they can understand their commitments. Ensure all external

dependencies and involved support organizations are aware of your

schedule.
 Cost Management
Providing detail advice on cost management is difficult as the
financial processes vary greatly by company. Along with the

different processes, companies have different tools and attitudes

regarding financial estimates and tracking. You should learn your

company’s financial data flow and charging processes, in particular

the timing of charges against your project. Once you understand, it

becomes more a question of when charges. Even if your company’s

financial systems produce the official project cost reports, you

should also track costs. At the very least ask for detail records

where you can confirm accuracy. Charges may show up under

wrong project codes. You costs may be tracking well, and then a

corrective posting is applied sending you over budget.

Just as you are monitoring your projects progress, your

organization is monitoring all projects so understand how your

success is measured. This is likely to save you time each month

justifying differences. Internal resource costs are usually payroll

costs are often charged to their organization’s payroll or cost

center. From there the costs are transferred to your project based

on an allocation process. This is typically based on an average

hourly or daily rate maintaining employee salary confidentiality and

the charges are applied to your project during monthly financial

cycles. The rates may include organizational overhead such as

management, facility, training, and computing. Periodically, these

rates may change and there should be a corresponding update to

your cost baseline. External costs have more variables on when the
charges are applied to your project. Some companies accrue

external project costs in the month they incur the expense.

Accruals are estimated postings coordinated between yourself, your

supplier, and the accountant. These accruals stay as charges

against your project until the suppliers invoice is received and the
accrual is reversed. Periodically confirm with your accountant the

amount of these accruals. Other factors impacting the timing are

usually documented as payment terms in the contract.

 Calculating costs
Most of the work necessary for calculating your labor costs was
done in your schedule development, and the development of your

staffing plan. A common mistake is using the allocated hours from

your schedule, but for those assigned 100% to your project, it is best

to use your staffing plan and include their 100% allocated costs,

only removing costs specifically for longer absences (vacation,

training). Even there, vacations and training are sometimes

cancelled. Assuming your schedule is well planned, and you manage

to stay on track, the labor costs are close to your baseline.

Variations can occur if overtime is required to stay on schedule.

There may be more unknowns in your other cost categories

during project startup such as hardware, software, project specific

training, etc. In each of these cases, an estimate can be done based

on your initial technical direction, with historical input from other

projects. Based on your vision sessions and non-functional

requirements, ask your senior team members to help prepare this

portion of the estimate. Your external costs will be more accurate if

you negotiate terms before your costs are finalized. Ensure your

supplier is aware of your company’s travel policy allowing for more

accurate estimates.

“For a cost / benefit analysis, you will also need to

estimate yearly operational costs.”

 For a cost / benefit analysis, you will also need to estimate yearly
operational costs. This again depends on how your organization
charges out for operational support. There may be scaling done

where additional licenses will be needed, more hardware

components as deliverable use expands. If a technology will be new

to your organization, there is a certain amount of time required for

building and maintaining competences in this technology. Even for

attendance to yearly technology conventions. The initial costs of

hardware and software should be included in the project budget, but

yearly maintenance fees should be included in this operational

estimate. Basically the project is assigned one-time costs during the

project duration, and operational costs include any recurring

charges such as yearly license fees.

Always calculate your costs at different levels for monitoring

purposes, so you will have project, milestone, and monthly period

level cost figures. Milestone costs can be difficult if you overlap

your phases. These calculations are necessary in tracking and

determining your adjusted latest estimate. Be as specific about

your expenditure events as your organization requires. Easiest on

the PM is where there organization simply spreads cost estimates

over the expected project duration and monitoring is done on an end

of period basis. On the other end of spectrum are those

organizations that require you to accrue your expected costs at the

beginning of the period, and you are being financially judged at both
the actuals vs. accruals and LE vs. Budget.
 Cost objectives
Understand your Sponsor’s and Management expectations on
your budget and the degree of error they view as acceptable. PMs

who minimize their budget to get necessary approvals are opening

their team to much frustration. Typical reason for this is a

marginal priority project that may not get funding. On the other

end of spectrum are the PMs who know their projects are high

priority and include higher than needed budget estimates. This

may help your individual success, but under a fixed organizational

budget it may prevent other projects from gaining approval. Follow

the same logic used in setting sufficient schedule contingency based

on risks and uncertainty in estimating your budget.

Organization units are infamous in their end of year

adjustments. Some feel they need to spend their excess in the final

fiscal month or reduce costs asking external resources to plan longer

vacations to save money to meet their budgets. The logic being if

they underspend, they run risk of having their budget cut for the

next fiscal period, or use the tightened spending justification for

increasing their spending. Projects can operate in the same

manner, especially if their success is measured by being close to

budget, + / - 10%, neither too low nor too high. There are these

informal processes you should understand from your management

or peers.

Your project budget will roll up into an organizational budget,

and your project duration may span multiple budget cycles. You

may be pressured into spending according to both your project

schedule and the organizational budget cycle. If you will be moving

costs forward or backward into different budget cycles, ensure your

Manager and Sponsor are aware of the move. They may advise on

a different plan if they are aware of confidential strategy changes.

“If you will be moving costs forward or backward into

different budget cycles, ensure your Manager and Sponsor

are aware”
 Program Costs
Calculating Program costs is basically aggregating all the cost for
projects and adding in the specific Program level resources discussed

in the Program Schedules section. The more difficult part of

estimating these costs is the future projects that have not been

adequately defined. As a Program sets the scope boundaries for

individual projects, normally there are priorities and dependencies

that must be planned meaning that projects with lower priority and

dependent on another project’s deliverables must wait. These

future projects often have a larger degree of estimate error.

Industry or supplier benchmarks are often helpful as a guide in

estimating your costs and serve as justification if there are

questions in the approval process.

Let your Program schedule decisions and responsibility matrix

drive whether costs will be included at the program or project level.

There are additional budgeting decisions involving whether the

Program or the Sponsor’s organization covers some costs. For

example, the Program would prepare the training material and

provide the Trainer, but does the program get charged for the

training participants time required in the class? Does the Program

pay for any new material replacing the obsolete? On the technical

side, when your deliverables are replacing older functionality, there

may be contractual requirements terminating service agreements

that need considering.

 Tracking expenditures
Again, monitoring your spend is dependent on your organizations
allocation principles and tracking tools, so based on those you will

need to calculate the charges against your project. If you have

suppliers, request them for their expected charges for your

reporting period. This requires knowledge of your contracted

payment terms as your payments may be by period, quarter, or

some milestone basis as needed when to book the costs. Tracking

requires communication to all your stakeholders and Management.

Often the PM does not actually place and approve the order so

dependent on your organization being on a cash or accrual basis,

you will need to check if an expense is expected and occurs during

the period.

Gather your spending information at least every month, more

often if your finances are tight, or your team is putting in overtime

to stay on schedule. In this case you may be staying within your

calendar commitments but easily exceeding your budget. Difficulty

of this task depends on the extent your organization’s allocation and

time reporting is automated. With automation, your team members

simply input their time, and you do a summary for your project

code, and apply the charge rates against the reported time. One

item to clarify for your team members is their time reporting

practices. Even though they may be salaried employees and not

receive overtime compensation, there may be unofficial

compensation time for this extra work, or they may simply report

their normal working hours. Many times a PM will convince their

team to not report these overtime hours, whether this is proper

depends on their organization’s policy. Do not make improper

demands on your team as it can build into resentment and affect

your reputation.

On a regular basis, compare your actual costs with actuals in the

financial systems as mistakes can occur by either party. They may

be off due to timing, but verify each detail line item is expected, no

extras, and none missing. Check your supplier invoices against

their delivery and payment terms in contract. If supplier work is

being done on a combination of new and warranty work,

communication gaps between supplier employees may end with you

being charged for warranty work. It is helpful to track warranty

work separately
 Base lines and Change Management
Once you have approval of your Project Plan, save an official copy
of these work products as your baseline, and if available, set the

baseline in your scheduling and budgeting tool. Maintain a

repository of all subsequent baselines and accepted work products in

your project administration library. This becomes the yard stick

against which your success is measured. The baseline should not be

changing very much or very often. You have some contingency

embedded so do not become a PM that at every mention of a change

or clarification, you bring out a change control form to get approval

to change your baseline. Remember to work effectively as a team

work with Sponsor’s Representatives. You will have higher respect

from your sponsor if you learn the difference between a change and

a clarification or detail. If a work product is approved, then a

clarification has come too late, and it becomes a change, but the
point is not to make this hard on your business stakeholders by

always holding their feet to the fire. Use your judgment on the

situation, but even if a change is using contingency, fill out a

change control form, and file it as documentation of the decision.

“Remember to work effectively as a team work with

Sponsor’s Representatives.”

Anytime you find yourself constantly updating your project plan

with changes, you have to get to the root cause. Now it may be

something overlooked when defining your scope and requirements,

but if you find that it is changing approved work products, and

mistakes should have been noticed earlier, you have a quality issue,

and you need to ensure stakeholders understand their

responsibility. Remember the need to identify issues as close to

their introduction as possible. The impact of change grows

exponentially the longer the defect remains.

“Even unapproved changes and discussions take time,

energy, and have the potential to create conflict.”

Even unapproved changes and discussions take time, energy, and

have the potential to create conflict. Change can be driven as grass

roots movement by team members or top down by executives. If

you are receiving many change requests that should raise concerns,

as there are even more change discussions occurring that are not
being documented. Recognize this extra time and understand

impact on morale. When an executive initiates change, there is less

discussion on if the change should be done, but usually more impact

to your baseline.
 Reporting your Status
Organizations or sponsors may have formal reporting windows.
Some sponsors will want interim reports, or early access to

information that will be communicated widely in the company.

There are decisions and administrative processes you need to make

on gathering team’s status. Do not make this a burden on your

team, as you may find accuracy goes down. Decide if written status

reports from everyone are needed. You should be most interested in

progress and exceptions (unplanned tasks and possible issues). You

should already know upcoming activities and dependencies to

consolidate into the project status. This will be information flowing

down from the PM unless you want to verify team is aware of their

future responsibilities.

You will want to collect your data as late as possible. Encourage

accurate feedback on activity status. Some PMs choose to give

team instructions to say estimate closest to 25/50/75%. It is hard to

say 100% without being completely done. While most consider this

simply as a management interruption, but a hidden gem to this

activity, if done right, is the short time when the team member

raises his thoughts from his details and thinks about what they

have done, what is remaining on plate, and plan accordingly.

“people inherently overestimate their percentage

completion”
 Some people inherently overestimate their percentage
completion, and you will quickly understand who, when activities
reach 90% complete, and just hang there. Maybe they will make

the next status show 92%, but remember you should only have

short duration tasks, so theoretically, an activity will never stretch

over 2 reporting periods. You will soon learn whose updates should

be questioned in more detail to verify. In agile methodologies, you

may want to report percentage complete on requirements being

worked on an individual sprint and keep an overall rolling progress

view. Now this is where an accurate earned value calculation would

be very beneficial. Being able to project future results based on past

progress would greatly help in alerting stakeholders. The problem

with achieving this is measuring a valid productivity factor. You

only know the time spent producing the artifact, not the quantity of

work involved or quality of work. Yes, there are various processes

to estimate quantity such as Lines of Code and Function Points.

At the same time, you are also reporting your schedule situation,

from your cost tracking process you are also reporting your budget

information. This usually includes the monthly cost actuals and a

Latest Estimate (LE) for the remainder of project. If you are

exactly or slightly ahead of schedule, the LE does not require

updating. However; if you are behind schedule or far ahead of your

schedule, you need to revise your LE. In case you are now

estimating spending less than budgeted check with your

management and sponsor, they may choose to leave the LE at

higher level or lower and use funds on another project. Helping

management resolve problems is just the recognition your career

needs.

Monitoring the health of your project starts with these schedule

and cost updates. After all, if you have prepared a good Project

Plan, tracking well against your schedule and allocated hours, and
the quality of work products are holding up, your project is in good

shape. When a project strays from the plans, a PM needs to

understand if a problem is unique or it is becoming part of a trend.

In your reporting, reflect status as individual items against your

baseline. Report percentage complete against expected percentage

complete (Schedule Variance), and the same for cost variance.

There are proponents of consolidated indicators like Earned Value

that creates a good bit of extra work including resource cost in your

schedule and tracking time to tasks. Your time may be better spent

on other value added activities. If your organization’s tools are

integrated to the point this does not create overhead, then it is easy

enough to do the calculations, and consistent across projects. But be

careful in reading too much into earned value’s implication that past

performance is an implied impact on future either positively or

negatively. Just as a project in itself is defined as unique, the

activities (analysis, development, testing) are unique and vary

throughout your project. Earned Value also has no direct

correlation to quality of the work products, requirement coverage,

or quantity of work performed. As such, it is like every other

performance measurement where results can be masking hidden

problems until too late. Another possible miscommunication about

earned value is it really has no correlation to the true benefit or

value your deliverables are providing as developed during your cost /

benefit analysis. It assumes that value is simply provided by the

correct ratio of schedule progress and cost expenditures.

With agile approaches, you can show areas where work is

progressing. Setting the degree of progress is a joint responsibility

between sponsor representative and the assigned team member for

components on both your WBS and Product Backlog. There will be

daily interactions as your team indicates progress and plans, and

there is a chance where multiple sprints fit within a reporting

period to assist in this process. As your sprints may not align with

your organizations reporting cycle, agree with your sponsor and

manager to report on the last completed sprint results. A mid-

sprint reporting has too much disruption.

Learn to quickly recognize and classify problems. Some you can

quickly recover internally without publishing. Slightly elevated

problems you may resolve yourself, but inform your management so

they are not caught unaware of your planned solution. And finally,
some problems become issues that have potential impact to the

project. These are covered in the Risk and Issue Management

Guidebook. You never want to surprise your Sponsor with late
notice on delayed deliverables as they have made commitments and
it reflects poorly on them as they are not appropriately managing
their work. Remember the value your project is providing, and

delays reduce this value.

Your status reports, written or oral, provide the outside

management structure a window into your project. Your

preparation and confidence goes a long ways in developing your

reputation. How easily you answer questions with complete details

adds to your professionalism. Managers ask these questions

determining if there are hidden problems with your project. In

most cases, poor answers on your part result in even more

questions. If you do not have an answer, it is better to say so and

give a time you will respond. A large meeting is not the place to

introduce your management and sponsor to a new problem. It is

also not the place to complain about an individual. On the other

hand, praising a team member about a specifically good

accomplishment is often mentioned back to the individual improving

morale.
 Closing your Project and Learning from your

Experience
At some point you will receive acceptance of your deliverables,

hopefully in line with your baseline and constraints, so plan in your

schedule a lesson learned session before you close and release your

team. This is important learning from both the organizational level

on its ability to execute and also your capability as the Project

Manager, so it is important to recognize and get feedback. Too

many times organizations view success by delivering on your cost

and schedule commitments when in reality, the team may have

been working a huge amount of overtime to meet the necessary

commitments. This cannot be viewed a success from the PM’s

perspective, and you should learn from the experience. After all,

your team members may have learned never to work with you on a

project again. Seek out constructive feedback and look to improve.

Also, as your team has been working on your project tasks, ensure

proper feedback and credit is provided to their management as part

of the closing process.

Much can be learned by analyzing your Project Plan work

products. The number and type of change requests gives some

indication on effectiveness of your scope and requirements. Defects

provide insight into initial quality, while issues are often

representative of your planning success and risk management.

Schedule and cost variances are often the most difficult to analyze
as so much of your planning areas impact these variances. The
basis for any project problems can come from any planning work
product and not just bad estimates or missed activities. As project
objectives are result of an organization’s people, processes, and

technology, lessons learned can come from any direction.