Managing Cost-Reimbursement Contracts Scheduling and Cost ...elearning.esi-intl.com/BlendedLearning/ILT/BVZ_v4... · What Is Scheduling and Cost Control? Scheduling and cost control

Scheduling and Cost Control

Managing C

ost-Reim

bursement C

ontractsC

UR

:CO

U:E

N:000 ver. 0.0

Scheduling and Cost ControlPMC:BVZ:EN:000 ver. 4.1

© TwentyEighty Strategy ExecutionMarch 2016All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of TwentyEighty Strategy Execution.

Strategy Execution grants federal government users "Restricted Rights" (as the term is defined in FAR 52.227-14 and DFARS 252.227-7013). Use, reproduction, or disclosure of these materials is subject to the restrictions set forth in the MOBIS, FSS, or contract under which the materials were provided.

All material from A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is reprinted with permission of the Project Management Institute, Four Campus Boulevard, Newtown Square, Pennsylvania 19073-3299, USA, a worldwide organization of advancing the state-of-the-art in project management. Phone: (610)356-4600, Fax: (610)356-4647.

PMI® did not participate in the development of this publication and has not reviewed the content for accuracy. PMI® does not endorse or otherwise sponsor this publication and makes no warranty, guarantee, or representation, expressed or implied, as to its accuracy or content. PMI® does not have any financial interest in this publication and has not contributed any financial resources.

The names of all companies and characters used in these materials are purely fictional. Any resemblance to any existing or no longer existing company or living or dead person is not intended, and is purely coincidental.

PMI, PMBOK and PMP are registered marks of the Project Management Institute, Inc.

TwentyEighty Strategy ExecutionArlington, VA USA

Module 1Project Definition

Introduction

Module OverviewThis module introduces the fundamentals of scheduling and cost control in a project.

Project Definition

Project DefinitionAn often-cited reason for project failure is requirements are not clearly understood, agreed upon, or documented, or are misinterpreted. It is no surprise that any form of planning should start with reaching a good understanding of purpose, objectives, and requirements; scheduling and cost control also begins with establishing customer (or stakeholder) needs and requirements and ensuring that they are accurately interpreted, clearly documented, and approved.

A requirements analysis is not a difficult process, but it does require considerable attention to detail and adequate involvement with customers and other key stakeholders. If the project is a result of a contract, then requirements are generally more clearly stated and understood. A contracting process is usually preceded by proposal writing and, often, face-to-face interchanges with the customer. This forced necessity of finding and interpreting requirements to write the proposal significantly improves the understanding of the purpose of the project. Even then, misunderstandings between the buyer and seller can easily arise, especially if there has been inadequate analysis or a poor process of communications prior to project initiation.

However, a bigger problem in defining requirements occurs when a project is internal to an organization. Few internal projects have written statements of work (SOWs) or other documents that define the project; often they are started only with verbal directions. This results from a need (which may or may not have had a detailed needs assessment) or an urgent situation.

This module focuses on the importance of performing detailed needs and requirements analyses, regardless of whether the project is external or internal to the organization, and it describes those processes, tools, and techniques that are available and necessary to accomplish this. Although the discussion generally will not be new, it should be helpful when

Module 1: Project Definition

©2016 StrategyExecution PMC:BVZ:EN:000 ver. 4.1 1

applying the techniques and principles with a project team for better monitoring and control of projects.

Scheduling and Cost Control

The Nature of Scheduling and Cost ControlBefore describing ways of monitoring and controlling projects, there are two questions about scheduling and cost control that need to be asked and answered:

What is scheduling and cost control?Why do scheduling and cost control?

What Is Scheduling and Cost Control?Scheduling and cost control refers to the four aspects of project work that are primary concerns for the project manager and team:

Directing progressDirecting actionsControlling resultsConserving resources

Directing Progress—Refers to the efforts involved in directing a project’s progress against the project plan, particularly to those efforts that affect the cost, time, and scope. Almost everything a project team does and every project decision that is made potentially affects one or all of these components. Cost, for example, affects both time and scope; time affects cost and scope; and scope affects cost and time. Directing progress in a way that minimizes negative impacts or takes advantage of positive impacts is vital to successful project management.

Directing Actions—Involves taking the proper actions to keep actual progress in line with plans or minimizing the variances between planned results and actual progress made. For example, if a project is determined to be over budget, then some action is required to bring the spending back into line with the planned budget. Most times, the action taken requires some adjustments to the schedule or to the scope, but every action taken will have a ripple effect—that is, other components of the project will be affected, and this itself will require additional actions.

Controlling Results—Any action taken must have a strategy or tactic to control the impact it will have on the project as a whole and on its time, cost, or scope. No benefit exists if actions taken push the project in an undesired or unchecked direction. Being able to predict and control the results of the actions taken ultimately will enable a project manager to move the project back onto its planned track.

Conserving Resources—This is one element of project management that is most troublesome to the project manager. There are almost never enough results available to implement and run a


2 PMC:BVZ:EN:000 ver. 4.1 ©2016 StrategyExecution

project properly. As a result, a project manager is responsible for apportioning and conserving resources in the best way possible. Otherwise, the project is doomed before it ever begin

The Project Constraints

Scope is the total of all work required to deliver the product or service, and only the work necessary to get the project done. Nothing extra.

Cost/Budget is the total funds needed to obtain project approval, which includes labor, materials, equipment, and other direct and indirect costs to complete the project.

Time/Schedule is the planned dates for performing the work and other activities, including milestones along the way.

Risk is the collection of possible events that might occur along the way. They may impact the project either in a positive or negative manner.

Quality is the degree to which the product or service must meet to be considered acceptable and ready for use.

Resources are what allow the work to be done, from skilled people/human resources, equipment, supplies, and materials to even necessary funds.



Strategy is the guiding framework in which the project exists, either from the organization, the local or regional government, the methodology used, or a combination of many other factors.

What then is the “constraint”? The constraint is how each factor affects the others. For example, if a decision is made to speed up the schedule and complete a project earlier than originally planned, this will have repercussions. It may require the assignment of more resources or a reduction in the scope of the project lessening the quality. If project managers can make their managers and clients understand the project constraints, they will avert or solve many potential problems.

The classic example of having to compromise to keep the project constraints balanced arises when the project schedule must be accelerated. If a project manager develops a reasonable schedule to complete a project within two months, but is required to finish in half the time, one of the things will have to happen: The project will either cost more, because it will require added or more costly resources to complete on time; the end product’s scope or quality will suffer; risk increases regardless; or some combination of these consequences will occur.

The concept of the “constraint” can be used early in the planning stages to understand the need to consider each factor and how it relates to the particular project. It can also be used during the course of the project to deal with changes, contingencies, and other unforeseeable issues that may arise.

The important thing to remember—whether you are thinking about processes, phases, or something else related to project management—is that they all take place against the backdrop of the project constraints.

The Project Life Cycle

The Project Life Cycle OverviewEvery project has a life cycle that is comparable to a biological life cycle, beginning slowly and quickly building as the project work starts to produce deliverables. As the project reaches its final days, activity slows down and tapers off. A project life cycle shows the project effort (and costs) as the work takes place and maps it over time, often in graphic form.

One observation that is worth noting is there are no “standard” life-cycle models. Each industry uses its own model and, even within an industry, variations of the model are found. Moreover, the names used for each model’s phases are not always the same, differing in different industries or even according to an organization’s preference. For example, one organization may refer to the first phase as the “Initiation” phase, whereas another may call it the “Concept” phase; some industries use four life- cycle phases for their projects, whereas others use seven or more. Regardless of what the phases are named or how many exist, the project management activities and the tools and techniques available are generally very much the same across all industries.



In the following life-cycle model, the four phases are Initiation, Planning, Implementation, and Closeout. Each of these phases has its own subphases, steps, or stages, and these usually are defined by an organization to suit the way it engineers its projects.

Generally, the activities for each phase can be described as follows:

Initiation—This is the data-gathering phase. The project is just beginning and the project manager and team members have not yet been determined. (NOTE: There usually has been a previous phase for selecting the project; in almost every case, a project manager is not involved in project selection. Rather, a project is handed to the project manager after decisions have been made to pursue the project and for what purposes.) During the Initiation phase, the project manager will determine, to the best extent possible, what the requirements are and what the resource commitment needs to be.Planning—This phase takes the Initiation phase into the details of planning in which a more specific WBS is prepared, schedule and cost estimates are developed, and the project plan is written. It is also the phase during which the project team is organized. Blueprinting of the project occurs in this phase. The project conducts design meetings as needed to gather all information necessary to create the design documents. The project manager, subject matter experts (SMEs), and/or select stakeholders must review and approve the design document before development occurs. The actual work on the project deliverables, or project products, starts and takes place during this phase. The key functions of scheduling and cost control occur here, inasmuch as variances from the plan (or baseline) are measured, and control strategies are implemented to keep actual progress as close to the plan as practical.Implementation—The implementation of the project deliverables, or project products, takes place during this phase. The project manager continues to monitor variances from the plan and implement strategies to keep the project on course. The problems need to be resolved so a successful closeout can occur.



Closeout—This is often the most difficult phase because a project manager loses team members to other projects as the project seems to be winding down. Furthermore, many organizations don’t support the activities of this phase as strongly as they should because they are moving on to other projects. Yet this phase is critical to the project’s success in a way different from all other phases: This is the phase that delivers the final efforts to customers. It is concerned with conducting a scope review to determine that everything planned (or promised) has been accomplished and delivered, obtaining customer acceptance of deliverables, and closing out administrative and contractual paperwork. It is also the time for developing lessons learned documentation, without which process improvement is made less effective.

Requirements ReviewReviewing what is involved in developing requirements is important and adds value. A most-mentioned reason for project failure is poorly stated or unclear requirements. Moreover, even with clearly stated requirements, the project team can misinterpret what the customer means or wants.

Writing clear requirements is truly an art. You can name the many instances that you thought you understood a person to say one thing when in fact he or she said or meant something else entirely. With requirements, it is always wise to list all the requirements as you understand them and then reexamine each one with the customer to ensure you haven’t missed anything and to get the customer’s agreement that you have correctly interpreted them.

The requirements review is also the time to identify the project stakeholders. Stakeholders are those people in organizations who have an interest in the project, who are affected by some or all of the project’s activities, or who, by virtue of their positions, can make or break the project. A serious mistake that inexperienced project managers often make is overlooking those people or organizations that think they are stakeholders, even though they may not fit the strict definition of the term. If in doubt, it is far better to include a person in the stakeholder analysis than to exclude someone who may have the power to negatively affect the project if they feel left out or snubbed.

Of course, the real reason for doing a requirements analysis is to determine what needs to be accomplished. However, just as importantly, without a complete understanding of the requirements, it is impossible to develop the cost, time (schedule), and scope targets—that is, the baselines against which project progress will be measured.

Finally, when performing a requirements review, it is imperative that the project manager includes acceptance criteria and obtains a sign-off on them from the customer. Acceptance criteria are a statement of what will be used to conclude whether the project meets its desired outcomes or objectives. Without a mutual and agreed understanding of the “measuring sticks” for completion, the project manager cannot ascertain when the project activities are actually complete. As such, it could easily become a never-ending project.



Scheduling and Cost Control Documentation

Overview of Documentation Important in Scheduling and Cost ControlThe basis for a solid scheduling and cost control system is the use of key tools. As with any aspect of project management, the development of good analyses, detailed documentation, and accurate estimates (to the extent possible) is key to successfully completing a project. In the case of scheduling and cost control, documentation tools can add good value and should be kept in mind for use throughout the project, and especially during the planning process:

Project Charter—A document signed by the senior manager, who has functional authority over all the resources and organizations working on the project. The principal function of the project charter is to name the project manager and authorize him or her to lead the project. The project manager usually prepares the project charter because he or she knows more about the project than anyone else. However, a senior manager signs it, usually along with all the functional managers who have joint responsibility for supporting the project.Scope Statement—Depending upon what other documentation accompanies the project (such as a contract, specifications, and engineering drawings), the scope statement can range in detail from a high-level statement of the work to a complete description of the project requirements.Project Requirements Document (PRD)—A document used to identify each of the requirements, assumptions, deliverables, and constraints, as well as several other pertinent facts. Because senior managers also sign the PRD, many people are confused about why it is necessary to sign off on both the project charter and the PRD. To simplify this distinction, the project charter deals with people, that is, who is performing the project; the PRD, on the other hand, deals with what the project is about. Therefore, senior management should sign both documents to formalize the authority of the project manager and to indicate organizational commitment to performing the project.Work Breakdown Structure (WBS)—Often considered the single-most important tool for a project manager. With a fully developed WBS, every other project management tool and plan can be developed. This tool is so important to scheduling and cost control, and project management in general, that it is discussed in more detail in the WBS section of this reference material.Time and Cost Estimates—These estimates rightly follow the WBS because it is from the WBS that a network analysis (using precedence diagramming) can be developed, leading to the final schedules. The word “schedules” is used because a project can have many schedule types: a master schedule, task schedules, milestones, meetings and reports, and so on. After a practical schedule is developed, then the cost of the project can be determined.Responsibility Matrix—A good tool for determining the key people responsible for each task, the responsibility matrix documents who is responsible for the task in lead, approval, or support positions; keeps track of who is doing what task and is particularly useful as a “management by walking around” document; and acts as a good communication tool:



During status briefings or as a supplement to status reports, it shows which stakeholders are responsible for various project tasks.Risk Management Plan—Although this plan is one of many that are part of a project plan, it is highlighted here because it is probably the most important of all ancillary plans. Risk analysis and planning begin with the WBS and are performed throughout the entire project’s life. Without good risk planning, a project is certainly more exposed and has an increased likelihood of failure.Change Control—In general, change control keeps control of scope creep; without it, scope creep is inevitable. Scope creep usually occurs when customers or other stakeholders want to add small enhancements to the project. But unless these changes are made in a formalized fashion, scope will grow (creep) without an attendant increase in schedule (time) or budget (cost). (Remember the project constraints?) Change control is a vital part of scope management, and available forms assist in the overall change control process (discussed in greater detail in Change Management Within the Project).Others?—The “art” side of project management dictates that project managers must determine what tools, techniques, documents, or other aids are available and required to successfully control the schedule, cost, and scope baselines. Thus, as you progress in your journey of gaining experience in the project management world, you will find there are many other documentation tools that will make your job easier, adding to your ability to successfully complete a project. Unfortunately, there is no prescription for success in project management, only suggestions and a few important tips. There will be other aids that you are bound to discover for yourself.

Work Breakdown Structure (WBS)

Overview of the WBSThe WBS is a "hierarchically structured grouping of project elements that organizes and defines the total scope of the project. Each descending level is an increasingly detailed definition of a project component. Project components many be products (a product-oriented WBS) or tasks (a task-oriented WBS)."1 In the simplest terms, it identifies all work—and only the work to be done—on a project. The work is broken down to a level that can be assigned to a person or group.

It is viewed as the single-most important tool in a project manager’s toolkit. With a fully developed and detailed WBS, every other tool can be developed and a project plan can be created. In short, the WBS is the basis for scheduling and cost control.

In practice, the WBS can be developed either with a product-oriented or a task-oriented “flavor,” and one should be very careful about how each is used. The product-oriented WBS has its place particularly for high-level estimating, communication purposes, or for understanding a “high-tech” project by starting off with its deliverables. When it is necessary to estimate accurately schedules and costs, as well as to manage the project, a WBS needs to be

1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: TwentyEighty Strategy Execution, 2008, p. 470.



developed in detail, showing the task or the work package level.

Although a WBS should be developed in the manner and to the level of detail that facilitates managing the project, thereby making it an individual resource, there are some key “rules” that are helpful in organizing a WBS. First, the WBS is used to define the project. If created properly, the WBS will define the project’s—

Scope—What the project is all about and what the deliverables areTasks—What has to be done to produce the deliverablesWork packages—The lowest level of work effort needed to complete the tasks

A WBS is a vital tool to achieve realistic estimating of schedules, resources, and costs. It should be broken down to a level that allows assignment of resources and responsibility.

All in all, the primary objectives in developing a WBS are to describe completely the project’s work and to develop it to a level that will provide comfort for the project manager. Remember, if it is not in the WBS, it is not a part of the project.

WBS ReviewA WBS should be consistent in its construction. As such, although every subcategory need not be broken down to the same level, the work package level should be seen as a prime result of the WBS.

If a WBS is constructed using a product-oriented approach, essentially describing the project deliverables, the entries should be written as nouns (or specific deliverable “objects”). For example, if the project is to build a car, then one of the deliverables would be an “Engine.” Continuing to break down a WBS will reach a point where the tasks can be specified, and then these would be written as work packages. As such, a work package should be written starting with a verb, as in “Build Carburetor.” It is important to ensure that each work package, when aggregated, completes its deliverable or accomplishes a discrete work element.

The WBS is a major input to project planning and management. This document is essentially the scope baseline for work to be performed during the project. Any work not included in the WBS should be considered out of scope.

The WBS is decomposed to a level that is assignable to a team or individuals. For each work package, the work is decomposed even further into "activities" or "tasks" that form the schedule. We can also use the WBS to determine how much the project will cost, how many (and what types of) resources will be needed, and how long it will take to complete.

For more information on building a WBS, please see Appendix A: Project Management Program Fundamentals Prep Pack.



Module Summary

Module SummaryCost, time, and scope are indicators used to measure project management success.Initiation and Planning are the first phases of the project life cycle.Without clear requirements, one can never control a project.One should have documentation and must have issues resolved before embarking in serious scheduling and cost control.Scheduling and cost control requires a WBS.



Module 2Resource Allocation and Estimating

Introduction

Module OverviewResource Allocation and Estimating introduces the tools and techniques you can use in resource allocation and estimating.

Resource Allocation and Estimating

Resource Allocation and Estimating OverviewOne major challenge in project management is allocating resources across projects within the organization and estimating, with any accuracy, schedules and costs. There are tools and techniques available that help the project manager to accomplish this activity, and this module discusses them in some detail. However, any successful resource allocation and estimating effort always begins with the requirements analysis.

Resource PlanningPlanning for the resources needed to complete the project will help to improve a project's chances for success. Consider all types of resources: The skills and people, equipment, materials, and facilities.

When the resource planning effort begins, there are some very fundamental questions that need to be answered. These questions are all derived from the requirements analysis:

What needs to be done? This question goes right to the heart of the project requirements. Simply put, what are the deliverables? Only when you know what you are to do can you then determine who and what equipment and materials you need.Who and what do you need? When you firmly have identified the deliverables, you then can assess the skill sets, experience levels, and the equipment requirements. You can also determine whether the organization has the required expertise and if not, where you can get it outside the organization.Who can do the work? Identifying the skills and experience requirements is only half the battle; marrying the skills and experience with those available to work on the project is the

Module 2: Resource Allocation and Estimating


challenge. Organizations optimize their resources so that no one is idle, at least not for extended periods. Consequently, finding people with sufficient skills and experience can become a project in itself.What can do the work? Many projects are labor-intensive, whereas some require capital equipment, special machinery, and other materials. This question addresses those issues and is important to the overall costing and schedule effort.Who and what can you get? Needing particular skills, experience, and equipment doesn’t mean you can get them! They may not be available at the moment (that is, allocated to other projects) or they may not be present in the organization. The trick is to balance what you need with what is obtainable in such a way that they don’t jeopardize the project.What level of excellence and competence is essential? This question really addresses three separate issues: the basic skill sets and experience levels needed to accomplish the job; the minimum level of skill sets and experience needed to meet the quality standards of the project; and the level of skill and experience needed to accomplish the work in the time that the customer requires.How will you use the resources? After resources are identified, a decision must be made about resource utilization. For example, if the people assigned to the project don’t possess the desired skill and experience level, is it necessary to fill in with senior-level or experienced resources? Do you need to work more or longer shifts?How will the resources affect schedules and costs? Regardless of the resource mix, it is a fact that the schedules and costs will be directly affected. If you use senior people—even for short periods—the costs will rise; on the other hand, if you use less-skilled and -experienced people, the schedule will be longer, which also increases cost.

Clearly, resource planning is key to optimizing the schedule and costs, but there are other considerations to resource management as well.

Other Resource Planning ConsiderationsAfter resources are identified and assigned, a project manager should take some immediate actions. One is to develop a resource/ responsibility matrix and the other is to use the resources in developing estimates.

Resource/responsibility matrix—A management tool to help the project manager determine “who is doing what;” it is a matrix with key personnel matched against the WBS tasks. Normally, only the key task people are listed on the matrix (which appears as the Roles and Responsibilities Matrix tool in this course), but it can be expanded as needed. It is essentially a management tool that can be as detailed as necessary for monitoring and controlling the project.

At a minimum, a responsibility matrix will identify the WBS task and each task’s lead, but it is always a good idea to identify key support, and review and approve personnel as well. With a detailed matrix, a project manager easily can track where work resides and when it is expected to move to the next level.One suggestion is to use the following terms when assigning roles, also known as RACI:



R=Responsible: the individual resource responsible for completing the work for that work packageA=Accountable: the resource(s) to be held accountable to ensure the work is done well and on timeC=Consult: the resource(s) that should be consulted or who would support the work being doneI=Inform: the resource(s) that should be informed of decisions made during the work or who would need to know that the work is done

Resources as sources of estimating—A vital source of information about how long and how much effort the task will take. There is a push by the Project Management Institute (PMI) and other organizations to rely more on estimating tools or expert judgment than on individual team members. The rationale is that people within an organization tend to err on the side of pleasing management; or worse, they fear that they may not be able to achieve their estimates and, therefore, inflate them. The truth is probably somewhere in between. People responsible for a task generally will have a better understanding about how long it will take and how much it will cost. You should accept their input, but you should also validate it with other methods, such as estimating tools, expert advice (if available), and above all, historical or lessons learned data. Estimating is not a trivial pursuit; it should not be performed by using only one method or tool. Rather, the more methods and techniques you have at your disposal, then the more accurate the estimate will be. A simple caution: If an estimate turns out to be 100 percent accurate, then someone was either lucky or had some exceptional information!Estimating of durations—The age-old battle to settle on a consistent definition of time. The problem with considering durations is that almost everyone has a different view of time. Generally, when estimating how long it will take to accomplish some task, everyone is optimistic:

Risk tends not to be considered.It is assumed that there are no interruptions or phone calls.It is believed all the resources will be available.There is a tendency to ignore or forget that everyone needs personal time.No matter how good each of us is, each is productive for only a particular amount of time per day.

So, when estimating durations, ensure that the project team and the stakeholders all agree on working calendars, hours per shift, and holidays, and allow for such concerns as sick leave, vacation, and productivity in the estimate. Otherwise, the estimate will begin by appearing to be too optimistic, which is usually the case in almost every project, regardless of the industry.

What, then, are some of the duration issues to consider in estimating schedules and costs?

Duration ConsiderationsIt is amazing how many duration estimates are inaccurate due to a lack of consistent definitions in an organization or even across an industry. One explanation is that everyone defines the various duration terms according to his or her own definition, and few take the time to ensure



consistency. This problem, however, is easily eliminated—all it requires is an agreement of definitions of the following key (and somewhat troublesome) terms and using them across an organization:

Effort hours—The number of hours required to complete a task or project. Depending on their context, effort hours are normally expressed in days or weeks, or months or years. This means that an estimate of effort is made to accomplish something, such as a task, which can then be expressed in terms of resource hours or days. For instance, if a task is expected to take 16 hours of effort, then it could take two resource days.Working period—The amount of time available to do work in a day or week. The organization or team defines and establishes the working period before the project begins. (Of course, working periods can be changed depending on the need to make up schedule slippage). A standard workday is eight hours; a standard workweek is 40 hours. But the project defines the working period as needed. Shortened or lengthened working periods do not affect the effort hours. Rather, they merely shorten or lengthen the time it takes to complete the work.Elapsed time—The actual time that passes. Including weekends, holidays, breaks, vacation, and so on, it is simply calendar time—everything being inclusive.Productivity—This is a measure of efficiency and the rate at which one performs work. Everyone works at a rate that they can accomplish a task. Generally, the more-skilled and more-experienced people will exhibit a higher productivity rate; however, skill and experience does not guarantee greater productivity. Yet, measuring productivity across an organization is not difficult. In many industries, 75 percent is commonly used as the average productivity rate, but this figure can vary significantly across industries and organizations.Availability—When and whether a resource is available for work. It really doesn’t matter whether a person is 100 percent productive if he or she is not available to do the work because the work won’t be done.Interruptible durations—Work time that is not contiguous. If you are building a house, there is no real harm in putting up one wall on one day and another wall on the next. You can even build half a wall per day and not jeopardize the integrity of the house structure.

Although all definitions and concepts listed here are important, two are seldom considered in estimating a schedule—productivity and availability. Yet, these two concepts must be understood and applied when estimating.

Productivity and AvailabilityAssigning individual productivity rates to individual workers risks litigation. To be safe, it is better to assign an average productivity figure across the entire organization when making time and cost estimates. However, to demonstrate the following formulae, it is beneficial to view how productivity and availability affect cost and time by contrasting three workers with three different productivity levels and three different availability times.

The formulas for determining cost and schedule are—

Cost = (Effort/Productivity) x Unit Cost



Where

Effort = Project or task resource hours required

Productivity = Percentage (expressed in decimals) that one is productive during a day

Unit cost = Labor cost in dollars per hour for the resource

For example, suppose you want to know the labor cost for Worker #1 whose hourly rate is $25, whose productivity rate is 80 percent, and where the effort is projected to take one week (40 hours). However, Worker #1 is only available for 75 percent of the time. The cost of using Worker #1 would be—

Cost = (40/0.80) x $25

Cost = $1,250

To determine how long it will take Worker #1 to perform the task, use the formula for calculating the time required:

Time = (Effort/Productivity)/Availability

Time = (40/0.80)/0.75

Time = 67 hours

Thus, although the effort required is for 40 hours, it will take 27 hours longer to complete the task using Worker #1 (who is 80 percent productive, which is quite good, and who can only spend 75 percent of his or her time on the task due to other project commitments).

It is easy to see that if you were to follow your instincts by providing cost and time estimates based solely on an individual’s base hourly rate and assuming 100 percent productivity and availability, then the estimates would be 40 hours to perform the work and a cost of $1,000 ($25 x 40 hours). These are obviously impractical, and this is one major reason for errors in estimating.

In the beginning of this section, it is stated that assigning individual productivity rates risks litigation. This is because assigning individual productivity rates can lead to or be perceived as discrimination. However, for the sake of further demonstrating the power of and need for using productivity and availability rates, consider another example. Suppose you want to compare the cost and time of another individual with the example above. Worker #2 has an hourly rate of $30, a productivity rate of 90 percent, and is available 80 percent of the time. For Worker #2, the cost is—

Cost = (40/0.90) x $30

Cost = $1,333.33



The task will take Worker #2—

Time = (40/0.90)/0.80

Time = 55.6 hours

Comparing the two workers, who would be the better choice for the task? That decision depends upon whether cost or schedule is the driving factor. If it is cost, then Worker #1 would be better (cheaper). However, if schedule is the driving factor, Worker #2 can accomplish the task about 11 hours faster, or almost 1.5 days faster, for an additional cost of little more than $83.

A standard for figuring productivity is 75 percent based on a 40-hour week. This rate is determined by recording the actual amount of time an average individual spends on assigned tasks and taking into account the amount of time required for meetings, administrative work, breaks, and other normal office interruptions. Availability is determined by assessing how much time a person would have for a particular task given the amount of time already committed to other work activities.

After the task or project effort has been determined, resources have been identified and assigned, and productivity and availability rates have been calculated, the job of estimating the costs and schedule can begin in earnest.

Estimating

Estimating OverviewEstimating costs and schedules are not easy tasks. Traditionally, all project costs and schedules are optimistic; that is, the project is usually over budget and over schedule in the end. Although this overestimating is more prevalent in some industries than in others, it occurs everywhere. This section discusses different approaches to estimating, some tools and techniques for developing estimates, and suggestions on improving the estimating results.

Estimating ActionsTwo terms—estimate costs and determine budget—require definition. They often are used incorrectly and interchangeably, probably because people tend to think of “costs” as one category and “price” as another. Among other things, this section will explain these confusing elements of the estimating, proposing, and budgeting process.

Estimate costs: Estimating actions to develop an approximation of the financial resources needed to complete project activities

Determine budget: To develop a quantitative expression of the total cost of the project, including an aggregation of the estimated work packages and activities, used to create the authorized cost baseline.



The principal reason for making this distinction is that the process of allocating amounts to specific tasks provides a basis for tracking how well the project is performing against the budget. Cost estimating can be accomplished in several different ways and not just from the task level. Hence, in the case where an estimate is developed at a higher level, it is only when the budget is allocated to each individual task that a clear picture of how good the estimate is begins to emerge. A cost estimate alone is not sufficient to baseline the project and to track and manage the work as it progresses.

Three Levels of EstimatesEstimates can be grouped into one of three categories within the WBS: top levels, middle or summary levels, and all levels of the WBS. Within each of these categories, several estimate names are used commonly in the estimating and organizational environment as shown in the following chart.

WBS Level

Estimate Name(s) Industry Standard Precision and Range

When to use

Top levels Order of magnitude: Portfolio, conceptual, factored, quickie, feasibility

+75, –25% When only very basic information is available or needed (project selection)

Middle summary levels

Budgetary Preliminary, design, appropriation

+25, –10% When resource materials, expense, and overhead information are available and the objective is identified

All levels Definitive: Finalized, expense, grassroots engineering

+10, –5% When detailed information is available

There are two important points regarding this chart. First, the three levels have vastly different degrees of accuracy associated with them. As the estimating methods or techniques drill down from the top to the lowest level of the WBS, the accuracy improves. Second, note the precision and range of accuracy associated with each of these levels. These ranges, developed from studies published by PMI, represent the accuracy of projects from a number of industries and many organizations. There are three noteworthy points about the different ranges:

Variance decreases as the estimate type becomes more detailed.The different ranges clearly indicate the tendency to err on the optimistic side of the estimate.Whenever possible, it is better to give an estimate range when providing cost data.

Estimating RecommendationsBelow is a summary of the most important tips or recommendations about preparing estimates:



Use the most accurate estimating method available.Use two or more methods if possible to validate the estimated costs.Involve the entire team and any other experienced personnel available to develop the estimates.Base the estimates on lessons learned, which, if properly documented, will provide data to refine estimating techniques.Record all assumptions.Communicate the level of precision of the estimates to the stakeholders.Do not pad the estimates (use contingency costs if there is a risk potential, but clearly identify the contingency strategies as separate costs).

Estimating Tools and TechniquesThere are many tools and techniques available to the project manager and the project team, but most of them fall within the ones mentioned below.

If a project is labor-intensive (basically consisting only of the labor effort such as a service contract), then the costs are generally not too difficult to determine. It is merely a matter of determining the length of the service effort and then multiplying that by the number of resources and their individual labor rates to calculate the total. But unfortunately for most, estimating a project’s costs is not that easy. It usually takes a combination of several different tools and techniques to arrive at an accurate estimate. Two techniques to estimating a project’s cost are the top-down and the bottom-up estimating approaches.

The top-down approach is usually—but not always—less accurate. Top-down estimating starts at the top of the WBS and proceeds downward to progressively lower levels. This approach is a function of how experienced the estimators are, and what methods are used to arrive at the top-down figures. Generally, a top-down estimate is less detailed, relying principally on analogies for its results. It often is used for selecting a project, generating a rough indication of a project’s cost, or determining what a bid price might be, and determining general strategies and planning approaches.

A bottom-up approach, on the other hand, is more detailed because it goes to the very lowest levels of the WBS and costs the individual work packages. As each work package is assigned a cost and duration, the costs are “rolled up” to the next higher level of the WBS until all activities are assigned a cost. The final “rolled-up” number is the aggregated cost of the entire project.

Within each of these approaches, there are several tools and techniques available:Analogy—Comparing one project or subelement to another similar project or subelement. The analogous estimating technique is “also called top down.” This is a very misleading statement because it implies that these two are synonymous. The fact is that analogy can be used at any level of cost or schedule estimating.

Example: Suppose you are contracted to build a house similar to one you built last year. To



get a rough estimate of the cost of the new house, you compare the size, location, and general amenities of the two and come up with a comparable cost.Parametric modeling—One measure in terms of another. Parametrics are used in your everyday life. For example, when you buy wallpaper, you look at how many feet or yards there are per roll. You also consider how much the rolls cost in terms of dollars per roll. Both these measures are parametrics (feet per roll and dollars per roll) because one measurement is expressed in terms of another. Parametric estimating also is called a cost estimating relationship (CER) because of the relationship of one measurement in terms of another.

Example: Suppose you build concrete driveways. Over the past three years, you have collected enough data that you can estimate the cost of a driveway by applying the parametric, one yard of concrete costs $50 per yard. If you are contracted to pour a new driveway that requires 200 yards of concrete, your estimate is $10,000 (200 x $50).Vendor bids—Compares the bid price of one vendor against another. Notice that you use the word “price” here. The difference in cost and price is that profit is added to “cost” to obtain “price.” (This will be discussed in further detail shortly.) When evaluating vendor bids, total price is considered a part of cost.

Example: Suppose you are buying 50 computers and three vendors bid on the contract to supply them. If you have accurately presented the requirements and specifications (that is, computer capability, time and place of delivery, service, reliability, and so on), then the discriminator in the evaluation of the bids is cost. If all else fits the specifications and the bid prices are $100,000, $95,000, and $98,000, then the winner would be the lowest one, $95,000.

It is also important to understand cost categories and types of costs. It is not enough merely to determine the different costs in a project; you must also allocate them to the correct “pot” of money because of accounting and financial restrictions and standards.

Cost Categories and Types of Costs

Cost OverviewBasically, there are two categories of costs: direct and indirect, and they are allocated accordingly.

Although the distinction between direct and indirect costs is not always clear, there are some characteristics of each type that typically define them.

Direct Costs—Typically defined by the following three characteristics:1. The cost is clearly associated with the project or product. For example, if a deliverable of the

project is a chair, a machine operator’s time that is associated directly with producing the various parts of the chair is a direct cost. However, the time of the person who maintains the



lathe, although just as important to the accomplishment of the task, would be considered an indirect labor charge because that person maintains the lathe for projects other than producing that chair. In other words, the maintenance costs cannot be allocated directly and exclusively to the product being produced.

2. The cost is associated readily with the project or product. This characteristic is a subtle twist on the first. Suppose the chair in the first example is to have some special primer or finish applied. If this special primer or finish is applied only to that chair, then it is a direct cost. If, however, this priming or finishing process also is used with other products produced by the company, then it probably would not be cost-effective to determine how much of the cost is actually attributed to one particular product. In that event, both the labor and the material used probably would be considered indirect costs.

3. The cost is important enough to be measured and identified. If the costs are important enough to be measured and identified as direct costs, then they can have a significant impact on the project cost and the overall company’s indirect rates. For example, suppose the finish on the chair in the second example is a special paint manufactured by only one company in the world. Then the paint cost will be significant and definitely worth measuring and allocating against the product. In that case, it is classified as a direct cost.

Indirect Costs—Those costs that cannot be assigned to a particular contract or the production of a particular product. In accounting terms, these costs are not identifiable with a specific cost objective (that is, a particular contract or project).

Costs cannot be identified with a specific cost objective when they are incurred for the benefit of two or more cost objectives. In many cases, it simply is not practical to track some costs against a specific cost objective. When that occurs, it is easier to classify these costs against an indirect cost pool.

There are two types of indirect costs, overhead (OH) and General and Administrative (G&A). Some companies identify three types of indirect costs, OH, G&A, and benefits. However, benefits are a part of corporate overhead and are considered separately for tracking and cost control.

OH—Costs associated with the health and well-being of the employee. Examples include facility cost or rent, lights, air conditioning/heating, desks, carpets, computers, and the taxes and insurance associated with these items. Also included in the overhead category are fringe benefits, which include tuition reimbursement, training, profit sharing, medical benefits, employer’s matching of social security payments, and perquisites (or “perks”).G&A—Costs associated with the health and welfare of the company. Examples are salaries of executive officers and the cost of the support staffs; other support staff costs, such as accounting, legal, new business development and marketing, and public relations; bid and proposal costs; and the taxes and insurance associated with these various expenses.

Within both the direct and indirect cost categories, costs are classified as one of three types: fixed, variable, and semi-variable.

Fixed costs—Specific costs associated with the project. For example, in construction projects, some equipment is required for every building project. Each time a high-rise building is begun, there is a fixed cost associated with transporting a crane to the building site.



Variable costs—Costs that vary with consumption. Lumber, materials, travel, and labor are examples of variable costs because their cost depends on how much and when they are used.Semi-variable costs—Costs that change only under certain conditions. Examples include disposal fees for certain items, such as oil or car tires, which cost a set base fee when a car is serviced. As the repair cost of the car increases, some other charges may increase over the base fee, but the environmental disposal fee doesn’t increase in proportion to the repair costs.

Besides costs, there is one other very important area in the overall cost/budget consideration: project reserves.

Project Reserves

Project ReservesReserves historically take two forms: contingency reserves and management reserves. This subject is addressed in more detail in The Baseline, but it is useful to introduce the concept here as part of cost estimating. Reserves are used to ensure that the project stays on track. If something happens (such as risk events), then there are money or schedule contingencies in place to get it back on track.

PMI once differentiated between contingency reserves and management reserves. However, they have discontinued that practice for two reasons. First, unless you constantly deal with these terms, they are confusing because it is difficult to distinguish between the two. The second, and probably the most important reason, is that many organizations don’t distinguish between the two: They just lump all reserves into one category. Nevertheless, it is important to distinguish between the two because some customers are very selective about using reserves, especially in the federal sector.

Contingency reserves—Normally, reserves of money, but also can be schedule reserves, to use if identified risk events occur. These risk events are identified during the Planning phase, resulting in the development of contingency strategies. Should the risk events occur, funds are available to implement the strategies and to get the project back on track. Contingency reserves are planned into the project budget and are usually, but not always, under the control of the project manager.Management reserves—Reserves that set aside for unknown risks. These reserves usually are determined by applying some percentage factor to the overall project contract and are controlled by senior management. They are not a part of the project budget. They usually are accessed by briefing the senior management on the need and then obtaining their approval to tap into the reserves.

Make sure that you understand that reserves are not a buffer. Buffers are the same as padding the budget, which PMI, most organizations, and certainly the customer do not consider as acceptable practice.



Finally, there is the question of what to do when you really don’t know the cost of a task. In virtually every project, there comes a time when you can only guess about the cost or the schedule. Having a tool that takes into account this subjectivity in determining the cost or duration would be useful, and the program evaluation and review technique (PERT) estimating formula is such a useful tool.

Estimating Formulas

IntroductionMany estimating techniques are available when dealing with uncertainty. Two worth noting are three-point estimate and PERT.

Three-Point EstimatesA three-point estimate (triangular distribution) is an estimating technique that allows for uncertainty in estimates by defining the distribution of possible estimates, defined by three separate estimates: The optimistic (best case), the most likely case, and the pessimistic (worst case).

Estimate = O + ML + P3

The three-point estimate (a simple average) does not lend greater weight or credence to any possible estimate. Instead it allows each possibility to equally influence the outcome, and tends to push most analysis to later/longer estimates. While it may seem like a good idea to project managers attempting to defend longer schedules and later dates, this analysis cannot be coupled with statistical analysis and standard deviation, which would provide a level of confidence in the estimate.

The PERT Estimating Formula OverviewEveryone who formally has studied or read about project management and its tools knows about PERT. PERT was an early diagramming method developed to mitigate risk in estimating schedules. The same method also can be used to mitigate the risk in estimating costs. As such, it is important to review the concept here to estimate deterministic schedules and costs.

The PERT formula is—

Estimate= (Optimistic + (4 x Most Likely) + Pessimistic)/6

Simply stated, this formula says that if you can estimate three times or three costs (that is, the most optimistic and pessimistic times and the most likely time), then you can determine a time that mitigates, to some degree, the risk of a guess.

This formula is actually a beta curve, but it approximates a bell curve distribution, which is more



familiar to most people. Two engineers compared hundreds of Department of Defense (DOD) contracts, project plans, and their results to derive the formula for a more accurate estimate. The PERT formula above is the result of their research.

The formula is easy to use. Generate three estimates, usually from the lead person or team members doing a task. Suppose they optimistically think the task can be done in 10 weeks and, at the outside, in 18 weeks. However, the most likely time will be 16 weeks. (Keep in mind that instead of duration, these can be estimates of costs as well.) Using the PERT formula, a reasonable duration for planning is—

Estimated time = (10 + (4 x 16) + 18)/6

Estimated time = 15.3 weeks

To understand this result completely, some points need to be recognized. First, it uses a weighted average. The reason that the most likely estimate is multiplied by 4 is that the developers of the formula realized that this number needed to be more heavily weighted, and if viewed from the perspective of a bell curve, weighting the most likely number moved it closer to the mean. The second point that needs to be recognized and planned for is that the estimated time of 15.3 weeks falls near the mean of the bell or beta curve, which is what the PERT formula describes. Therefore, there is only a 50 percent chance of achieving that time. Consequently, there must be a method for improving the chances or decreasing the risk of your estimates. This is the concept of the standard deviation.

Standard Deviation in PERT Estimates

Standard Deviation in PERTThe way to improve on this estimate involves the statistical determination—the standard deviation (σ)—of how far removed you are from the mean. This is easily seen from the following graphic.



The formula for the standard deviation away from the mean is—

Standard deviation (σ) = (Pessimistic time (or cost) – Optimistic time (or cost)/6)

Therefore, in this example, you can determine the σ:

σ = (18 – 10)6

σ = 1.33

If you study the graphic closely you can see that by adding 1 σ to the mean, you can improve the chances of hitting the schedule, in this case, to about 85 percent. Notice on the graphic that 50 percent of all data points fall to the left of the mean and 34 percent fall between the mean and the + 1 σ point, for a total of 84 percent. You use “approximately 85 percent” because a favorite question from PMI on the PMP®1 certification exam is, “Below what point on the bell curve do approximately 85 percent of all data points fall? Or, alternatively, above what point on the bell curve do approximately 15 percent of all data points fall?” The answer, of course, is + 1 σ.

If you add 2 σs to the mean, then you increase the probability of hitting the schedule to about 98 percent. So, to improve the probability to 85 percent for the previous example, the schedule should be 15.3 + 1.33 = 16.63 weeks; to increase probability to 98 percent, it should be 15.3 + 2 x 1.33 = 18 weeks (rounded off).

Remember that to determine the σ for a path, you must calculate the path deviation, not just add up the individual deviations for the tasks on the path. The σ for a path, such as the critical path, is given by this formula:

(and so on for all tasks on the path)

1 PMP is a registered mark of the Project Management Institute, Inc.



For example, suppose the three tasks shown in the following table define the critical path of a project. How do you calculate the σ for the path?

Tasks Optimistic Estimate (O)

Most Likely Time (ML)

PessimisticEstimate (P)

Estimated Time (Te)

Task StandardDeviation (σ)

A 10 16 18 15.3 1.33

B 8 12 14 11.7 1

C 14 18 22 18.0 1.33

Total Duration 45.0

The σ for the path is—

σ = 1.332 + 12 + 1.332

σ = 4.53

σ = 2.1weeks

Therefore, to increase the chances of hitting the project schedule to 85 percent, you would add 2.1 weeks to the critical path duration for a new schedule duration of 47.1 weeks. To increase the chances to 98 percent, you would add 4.2 (2.1 x 2) for a new duration of 49.2 weeks. To increase the chances to 100 percent, you would add 6.3 weeks (2.1 x 3) for a new duration of 51.3 weeks.

After you complete an estimate, you must ensure that you have not overlooked anything:Check everything.Redefine what the requirements are and ensure that you have included everything.Closely study the assumptions and constraints and ensure that they make sense and have been considered.Validate, to the extent possible, data sources and ensure that all stakeholders are in agreement about the methodology and precision characteristics.Identify the cost drivers and determine whether changes can be made that will reduce them and still make the estimate within the target costs.Ensure that whatever the cost is, it meets the customer’s expectations and budget constraints.



Module Summary

Module SummaryDifferent resources will drive significantly different outcomes.Planned resources and assessed costs help project managers build an honest estimate.Models are only as good as the information that went into developing them.A different interpretation of working time versus elapsed time can make a large difference in a project manager’s schedule.Standard deviation gives a good sense of how good or bad things can become.



Module 3Scheduling

Introduction

Module OverviewOf all the activities in project management, schedules are most potent in terms of their effect on the project as a whole. Scheduling discusses the tools of scheduling.

Scheduling

Scheduling OverviewScheduling a project requires both a scientific and an artistic touch. It should be scientific because the schedule must reflect the WBS tasks in a logical and interrelated way to optimize resources across the organization. It should be artistic because tasks not only are technically dependent or interrelated, they also often are driven politically, thus requiring finesse and interpersonal skills.

Of all the activities in project management, schedules are most potent in terms of their effect on the project as a whole. If you consider that a schedule is developed so that it reflects when a task is accomplished relative to all other tasks, as well as when the appropriate resources are planned for the work—which puts in place a mechanism for developing the project costs—a change to the schedule, then, has a profound effect on resource allocation and costs, not to mention the impact on the capability of delivering results on time.

Too many project teams fail to understand the significance of developing schedules that optimize these important project components. Instead, they simply develop schedules that fit the customer’s time frame.

In this module, the tools of scheduling and the considerations necessary for optimizing schedules are discussed in detail.

Module 3: Scheduling


Key Steps in Developing Scheduling

Key Steps OverviewAlthough data to develop accurate and workable schedules derive from a variety of sources, many project teams, unfortunately, only focus on one, the scope statement or customer-established time of delivery. Since there are other key sources of data, many or all of them should be used, when practical, in developing a schedule.

Defining ActivitiesConsider using as many of these sources as you can:

Scope statement—Contains information about the project deliverables and usually contains assumptions and constraints as well. The scope statement or accompanying documents, such as contracts, specifications, and drawings, also provide important information that affects the schedule.WBS—Identifies every task in the project. If it isn’t in the WBS, then it is not in the project. Therefore, ensure that every requirement is identified and described in the WBS.Historical information—Contains information about other, similar projects and collected metrics that are useful in refining estimating techniques. This historical information should be collected in the lessons learned files of each project.Constraints and assumptions—Provides a guide to the limits or educated guesses that are used to develop a schedule. Constraints usually are in the form of specifications (and customer-imposed delivery dates) or are developed due to limited resources and technology capabilities in the organization. Assumptions are best guesses made when precise data are not available. All constraints and assumptions need to be documented and regularly validated.Expert judgments—Provide an experienced and objective opinion about some or all of the above data and their sources. Not every organization can afford the expense or the time to hire experts from outside the company, but many companies have resident experts whose experience is seldom tapped. When a draft schedule is developed, ask senior functional, technical, and managerial personnel to review it and offer comments and recommendations. Be sure to provide them with the data sources used; your estimate of the data accuracy, constraints, and assumptions; and the objectives of the project so that it is clear how the schedule(s) was developed.

Network SchedulingThe basis for a schedule is the WBS. (It should contain the work packages, which are then broken down into schedule activities to be accomplished in the project). The first step in creating the schedule is to develop a network layout of the schedule activities because the network



depicts the interrelationships of project tasks. The following graphic demonstrates the relationship between the WBS and the network.

Some key points need to be made about the fundamentals of network development and what elements of the WBS are needed to construct the network.

As mentioned previously, the tasks in the network are derived from the work packages of the WBS. Work packages are emphasized because the network must be based on the schedule activities derived from those work packages. The network cannot be based on summary levels. Identifying specific or potential problem areas in the project (that is, risk points and overallocated resources) would not be possible if the network were to contain only higher-level summary activities.

It cannot be overemphasized that all of the schedule activities supporting WBS work packages must be included in the network, because they must be accounted for in the schedule. Omitting even one task from the network could change the overall schedule duration, estimated costs, and resource allocation commitments.

The WBS is not a schedule, but it is the basis for it. On the other hand, the network is a schedule, but it is used primarily to identify key scheduling information that ultimately is used in “user-friendly” schedule tools.



Interpreting and Using Network Diagrams

Interpreting and Using Network Diagrams OverviewThe network provides important information to the project team. Network information details how the tasks are related, that is, whether they can or need to be accomplished sequentially or in parallel, where risk points are in the schedule, how long it will take (as currently planned) to finish the project, and when each task needs to begin and end.

Validating the Time FrameOne key benefit of the network is that it immediately shows the shortest duration within which the project work can be finished. Bear in mind that, at a minimum, the first time when the network is created, it will be developed on assumptions about resource availability and estimated durations of each task, as well as on judgments about how tasks are interdependent. Some or all of these assumptions may have to be reassessed after the network analysis reveals total project duration, as well as a desired schedule for resources (that may not be physically available when a schedule assumes they need to be available).

If a customer dictates a firm due date, project duration should fit within that time frame, although the network duration may indicate a different end date. Therefore, all assumptions going into the network layout need to be reassessed to determine how to optimize resourcing and activity sequencing. Some tasks could be done in parallel rather than sequentially, more resources may be needed, the task duration estimates may be incorrect, and there may be a need to renegotiate project scope.

Considering Risk in Schedule EstimatesRisk should be considered as early in the project as possible. The first time potential risk events become noticeable is during WBS development because the tasks are described and resource needs begin to emerge. For the project manager, the first chance he or she can perceive potential risk events and risk points is with the network diagram. Because the network shows task interdependencies, the timing for allocating resources becomes apparent, thus requiring some balancing of available resources in projects across the organization.

One crucial risk point occurs when network paths converge. The risk of schedule slippage occurs wherever two or more network paths come together because, if the points do not converge as planned, then all subsequent tasks will be late.

The network provides an opportunity to identify risks early and to incorporate contingencies in the form of time or money. As such, contingency should be entered in the network as a task so that it is accorded the same importance and managed in the same way as any task. However, like tasks, because the characteristics of contingency reserves will change over the life of the



project, it is important to reduce or eliminate these reserves when risk events do materialize (or do not).

Note that reserve is not padding. It is a valid and recognized project management tool to mitigate project risks. Before one can have reserve, he or she must build a case for it by recognizing risks and documenting them.

Whenever risk is identified in the network, it should be documented and a strategy should be developed to deal with it. In that regard, another important aspect about a network is that it can help to evaluate the importance of the risk. That is, if one considers where in the schedule a risk event is likely to occur, then a more realistic assessment of its seriousness can be made. For example, even a high-risk event with a significant impact may be considered low risk if there is sufficient schedule duration remaining. But a low-probability, low-impact risk event that occurs during the final month of the project should be considered a medium to high risk. Thus, it is important to consider the percentage of schedule expended or remaining when determining the risk impact.

Network Diagrams

Network Diagrams OverviewIf some fundamental rules of thumb regarding network development are followed, then networks generally are not difficult to develop. It is beneficial to review these rules before any actual examples are provided.

Network Diagram Rules of ThumbIf you follow these simple tips, you can immediately begin developing and analyzing network diagrams:

There is a starting and ending point—one of the most frequently missed items when developing networks is not including a “Start” and “End” point for the whole project. In other words, the entire network should emanate from a single point and end at a single point.There are predecessors and successors for all tasks—from the starting point until the end point, each task will have tasks or events before it (predecessors) and each task will have tasks or events after it (successors). This is an important point to remember because it essentially means that every task must be connected to some other task or event, or otherwise it is left hanging in space (called a hanger) and the network analysis cannot be completed.The network must be updated and current—just as the project plan is a dynamic plan, so, too, is the network. It will change. Moreover, the network logic (that is, the placing of the tasks relative to each other) must be reviewed and updated constantly because the logic ultimately defines when each task begins and ends. Before the advent of computer software to aid in network generation, networks were updated rarely because they were so



cumbersome and difficult to develop. However, with software tools, the network can be updated quickly and often with little work.There are no loops—every task must be connected to some other task(s) or event(s). But be careful that the connections do not result in a loop—that is, a path that closes on itself.

Network Diagram TypesAlthough there are many types of networks, the most common is activity-on-node (AON). The original network diagram was called activity-on-arrow (AOA), but it has fallen out of use.

The AOA, which is used in the program evaluation and research technique (PERT) and critical path method (CPM) techniques, is the historical basis for all network diagramming. (It was developed in the 1950s by various organizations, including the Department of the Navy, to aid in monitoring and tracking the very large and complex Polaris program.) The AON is referred to commonly as the precedence diagramming method or PDM.

The following graphic shows these two types of networks with the AOA network on the left half of the graphic and the PDM on the right half.

Precedence Diagramming Method (PDM)In PDM, the nodes indicate the activities or tasks and the arrows show dependencies, so it is an AON diagram.

Some PDM advantages over the AOA method are as follows:PDM does not need dummy activities. (The arrows represent dependencies and can be inserted whenever they are required to show interdependencies.)PDM can accommodate any kind of activity relationship, including—

Start-to-startStart-to-finishFinish-to-startFinish-to-finishLeads and lags

Because PDM is the most-used network diagramming method, all project management software supports it. In contrast, fewer and fewer software tools support AOA as well.

All network diagramming methods share a few major disadvantages: Not everyone understands them, and they are sometimes difficult to update (depending on the number and frequency of



changes and complexity of the project). However, they are excellent tools for planning, risk assessment, tracking, management, and communication.

Gantt and Milestone Charts

Gantt and Milestone Charts OverviewPerhaps the most-recognized and most-used tool in project management is the Gantt chart, followed closely behind by the milestone chart. Every member of an organization should recognize and use these two tools.

Gantt ChartsGantt charts are bar charts that depict the beginning and end dates of tasks. Gantt charts have numerous benefits. First, they clearly depict the beginning and ending times for activities. Second, they show interrelationships and the critical path. Third, they remain one of the best communication tools available to the project manager because they are simple, clear, and understandable to almost everyone.

Milestone ChartsMilestone charts, likewise, are unambiguous and comprehensible to almost everyone. In fact, some organizations even try to manage projects using milestone charts as the major management tool. (However, this is not recommended because it is not possible to track between milestones to the level of detail necessary to discern what actually is happening in a project.)

Although milestone charts can be developed using software packages, it is important to remember the following when developing milestones:

Milestones have zero duration because they are only points in time.Milestones are those events that can be described in the past tense. For example, “Getting the project charter signed” is not a milestone; it is a task. But “project charter signed” is a milestone because it is a point in time.Milestones are significant events but consume no time.Milestones are events that consume no resources or effort.Milestone charts are good communication tools because they are easy to use for relaying a sense of progress to senior management by showing milestones that were met on time.

The WBS and network are two tools that ultimately lead to every other project management tool.



Techniques for Compressing the Schedule and Leveling Resources

Methods for Compressing the ScheduleWhere a schedule shows a completion date later than that desired by the customer or management, then the schedule needs to be compressed. There are two primary techniques for compressing a schedule: fast-tracking and crashing.

Fast-tracking—Involves reexamining the tasks to determine whether any that were considered to require sequencing can indeed be done in parallel. In other words, it is often decided that an activity cannot be started until a particular predecessor is finished (sequencing), but upon closer inspection, this may not be entirely true. For example, suppose you have a project that requires some sophisticated technology. Your first thought is to perform a technology survey to ensure that you have the latest technology available. However, if you need to shorten your schedule, you examine the requirement for a technology survey. You may realize that you did such a survey just a month ago, and your designers usually keep current with technology changes. Thus, a decision might be made to perform the survey, but to start the next step (design) at the same time. You’ll still use the survey to validate our design, but performing both tasks in parallel could shorten the schedule.This scenario is played out every time a project is begun. It is, therefore, a good practice to review periodically all activity relationships in this way to determine whether you can risk running some of the activities in parallel. The operative word here is “risk” because fast-tracking adds risk to the project. In the scenario above, if the technology has not changed since the last survey or if the designers truly are up-to-date on the changes, then the new plan of running the two tasks in parallel will help the schedule significantly. If, on the other hand, there was a major change in the technology that the designers did not catch, then when the survey is completed, it may indicate that a total redesign of the system is required.Crashing—Involves looking at each activity on the critical path to reduce its duration (by reducing the durations of one or more of the activities on the critical path). The critical path is the longest path in the network, and it is the path having no slack or float. Although it is good practice to reduce only one activity duration at a time, to achieve the amount of schedule relief necessary, it sometimes may require more duration refining than one activity can tolerate. The example in your participant guide, repeated below, clearly demonstrates this concept.



There are several key points to remember about crashing schedules.Choose activities on the critical path. Reducing durations of activities that have slack (which is the amount of time an activity may be delayed from its early start without delaying the project end date) won’t help the overall schedule.Reduce the duration by one unit of measure at a time. In other words, if the schedule is measured in days, reduce the activity by a day; if in weeks, try to reduce it by a week, and so on.Realize that reducing duration usually means adding resources, which could add cost to the project. Thus, how much the duration is reduced has a direct impact on the cost of the activity, and there must be a balance between the two.

In summary, there are two primary ways to reduce the schedule: fast-tracking and crashing the schedule. Generally, neither method is better than the other. In fact, many project managers try to combine the two wherever possible. Nevertheless, it is important to remember that fast-tracking usually adds risk to the project and crashing usually adds costs.

Leveling ResourcesOne major benefit of network analyses is their resource-leveling aspect, although seldom used for this purpose.

In most projects, there is always some point during the project's life when the number of resources needed is greater than the resources available. It just isn’t possible to do work requiring 12 people with only nine people and keep the project on schedule. So what can you do? Perhaps nothing, but sometimes resource leveling can alleviate the problem, if not eliminate it completely.

Leveling resources basically involves using the float or slack within a project to reduce the number of resources needed at particular time periods. This isn’t always successful because there may not be enough float to move the tasks enough to achieve the desired results. But it certainly is worth the effort. Although the process of resource leveling is discussed here, it is important to study closely the section on resource leveling to understand fully how it is done.



Resource leveling involves a pattern with the following steps:1. Develop the logic. Draw the network diagram for the project or part of the project that needs

leveling.2. Determine the early schedule. Decide what are the earliest possible times that each task

can begin and end.3. Draw a modified Gantt chart showing when each task begins at its earliest time and when it

ends. Be sure to include float periods and depict them as tasks on this modified Gantt chart.4. Develop the resource loading. For each activity in the modified Gantt chart, develop a

resource loading chart that illustrates exactly how many resources are needed for each period.

5. Develop the resource loading histogram or bar chart for a clear picture of how many resources are needed and when. Normally, the problem of resources occurs during part, but not all, of the time. A resource loading histogram is excellent for focusing on the critical time periods.

6. Determine the late schedule. In this case, you are interested in identifying the latest time each activity can begin and finish.

7. Draw a modified Gantt chart showing when each activity begins and ends at the latest possible time.

8. Develop the resource loading as before (in step 4 above).At this point, you have some options. If using either the earliest schedule or the latest schedule reduces the resource loading requirements to a level that is supportable, then all you must do is follow that new schedule. However, the most likely scenario is that neither the early nor late schedule resolves the problem. Instead, it is more likely that a schedule that falls somewhere between the two is required. As a result, you need to use the available float to “average” the early and late schedules.

To level the resources, maintaining the same overall schedule and not increasing the number of resources requires that you judiciously place the float (that is, start some activities later) so that the total numbers of resources required during a particular period of time are reduced.

Leveling is like a puzzle. You have to place the float where it requires the highest concentration of resources during a particular time frame and not on a given activity. In that way, the project can still end at the planned finish date, but operates within the given resource requirement.

Reference is made to the slides from Scheduling of your participant guide, and it is worthwhile to study the example provided there. One example depicts how the total resources can be reduced by using the float available.

Yet what happens if resources cannot be leveled without changing the due date(s)? What can be done?



Finishing the Scheduling Effort

Finishing the ScheduleLeveling resources takes place at different times in a project. It actually first occurs during planning, and it becomes clear when drafting the first plan whether sufficient resources exist for the project (or during specific times during the project). In other words, resource leveling does not just happen when there are suddenly not enough resources to accomplish the job. Rather, it should be a routine part of optimizing the project plan.

If no way exists to optimize the resource load to a level that the organization can support, then it is time to review the WBS and determine whether the project was analyzed and documented correctly and/or whether there is a need to renegotiate the project scope. If renegotiating the scope is unsuccessful, perhaps a new, more realistic due date can be renegotiated. After there is agreement on the final WBS, then two more project management tools—the Gantt chart and the milestone chart—are useful.

Module Summary

Module SummaryThe network does not contain activities that are not in the WBS.All work packages are in the network.Project managers must consider risk for every project.A variety of tools can evaluate and map out schedules.Milestones are significant events that consume no time or resources and complete no work.



Module 4The Baseline

Introduction

Module OverviewThis module discusses what a project baseline is, when and if it can be changed, the components of a baseline, and how it is used to control a project's progress.

The Baseline

The Baseline OverviewEveryone understands the general concept of a “baseline”: It is a starting point. However, what many people do not understand is what a project baseline is, if and when it can be changed, the components of a baseline, and how it is used to control a project’s progress.

This module defines “baseline” and its components. It also discusses how to determine these various baseline components using some fundamental estimating processes or techniques, how to interpret data gained from time-phased distributions of the project cost information, and then how to establish a project’s baseline. What many project managers do not understand is that there actually are three baselines that collectively define the overall project baseline. This module will discuss all these issues in some detail.

The Baseline DefinedBaselines are critical to project success because they establish the expectations of both the customer and all other stakeholders. In short, a baseline is a reference model against which the project will be tracked and deliverables will be built. The Dictionary of Project Management Terms by J. LeRoy Ward defines a baseline as the—1. “Original plan (for a project, work package, or activity), plus or minus any approved

changes. May be used with a modifier (for example, cost baseline, schedule baseline, performance measurement baseline)."1


Module 4: The Baseline


2. "Nominal plan with which deviations will be compared.”2

The first definition is important because it takes into consideration that there is more than one baseline. The definition shows that the overall project baseline has embedded in it three distinct, but intricately related, baselines: technical, cost, and schedule. Together, they form the performance measurement baseline.

It is important to note that a baseline represents the WBS and any approved changes. In other words, the baseline is what the project is all about and how it is going to be accomplished; both the customer and the key stakeholders approve it. Once a baseline is established, it is changed only through a formal change order process, and the customer and key stakeholders must approve such changes. These baseline components, along with the performance or project baseline, are depicted in the graphic below.

Technical BaselineThe technical baseline is in many ways the most crucial of the three because it describes the “what” of the project—that is, the deliverable(s). It is very important to establish buy-in from the customer that what you describe in your plan is actually what the customer wants because this buy-in (or sign-off) is obviously critical. Just as critical is buy-in from the organizational stakeholders because they have to support the effort and, in most cases, provide the resources and technical expertise to make it happen. The problem is that project managers and team members are seldom involved in the early definition of the technical baseline. Marketing or business development personnel, in conjunction with the customer, often define the technical baseline before it ever becomes a project. Consequently, it falls to the project manager to provide the details of the technical problem and to determine whether the organization even has the expertise or resource capability to accomplish it. That is why the technical baseline becomes so important and why the project manager must define it completely and then get final buy-in from both the customer and other stakeholders.




Cost BaselineThe cost baseline is derived from the estimates of the work to be done. It usually is represented as a cumulative cost or budget curve of all the tasks and associated support (including people) expected to be incurred during the life cycle of the project. Cost estimates are derived from the WBS and are developed in conjunction with schedule development. Many practitioners contend that costs are determined first and then schedules are built to support the costs; others hold that the schedules are determined first, followed by the costs. The fact is that costs and schedules are best determined together because organizations try to optimize their resources, which requires some subtle (and sometimes not so subtle) shifting and sharing of resources from one project to another. This means that resources and schedules must—out of necessity—be played against each other to obtain the most efficient and cost-effective baselines possible.

Accordingly, cost estimating begins by breaking down the WBS to the work package level, assigning resources to it, and determining the cost and the duration for the work. Every work package is treated this way. As a result, the overall cost of the project is determined by “rolling up” the individual work package cost from the bottom to the top of the WBS. Once the overall costs are determined, then the process of optimizing them begins by changing resources and durations of individual work packages to arrive at the best and most practical budget and schedule.

Schedule BaselineThe schedule baseline is developed in the same general fashion as the cost baseline: The WBS is developed to the work package level and durations are estimated for each. Next, a network analysis is developed to show the interdependencies of each task so that a reasoned decision can be made regarding the viability of pursuing this project as it is currently structured. Whether



an adjustment to the sequence of task work is required becomes a function of whether one or more of the tasks could be done in parallel or if they absolutely must follow each other sequentially; whether the planned task work conflicts with other projects in the organization; and whether the expertise exists to perform any of the work at all. All these factors are considered in the development of each task’s duration. Furthermore, the skill level and experience of the resources on each task must be considered in the duration estimate. Clearly, highly skilled and experienced people can accomplish the work sooner than those less skilled and experienced; but in the end, it could cost more.

Cost Baseline Components

Cost Baseline OverviewThe cost baseline, unlike the schedule baseline, has several important components that the project manager needs to understand because each is used in different ways and in some cases, is not used by the project manager at all. In contract work, using these components has a legal significance that can cause serious problems for the organization if they are not used in accordance with standard accounting practices or federal guidelines. Generally, this does not pose too much of a problem for the project manager, but it is wise for him or her to know how the cost baseline is developed using its various components. The different cost components are illustrated below.

Performance Measurement BaselineThe performance measurement baseline is made up of the other three baselines, but the costs have been obtained based on decisions made about the technical approach, as well as the



schedule for accomplishing the technical baseline. For accounting and tracking convenience, these costs are divided into two categories. The active account is called distributed budget and the inactive account is called undistributed budget. But before looking at these two categories, it is beneficial to review what is meant by a cost account.

Cost Account—A defined work package for which actual costs can be accumulated and compared against the plan. In other words, this category represents the costs that have been estimated for each of the work packages in the WBS.

Distributed Budget—Those accounts that are used for the open work packages, that is, the work packages that have active work being done. Using the distributed budget category allows the project manager to track quickly and easily the actual expenditures against the planned expenditures for the active tasks.

Undistributed Budget—The budget reserved for those tasks that have not begun. This budget covers tasks for future work because, in the accounting context, any open account number or budget technically can be charged against the budget. Thus, having these tasks in an undistributed and unopened category prevents any unexpected use of the funds that have been specifically set aside for the tasks.

ReservesAlthough there are two types of reserves used in project budgets, the distinction between the two is not always clear. In the federal sector, the two types are generally well-defined and consistently used; in the private sector, however, organizations often do not delineate between the two nor do they use them consistently. Nevertheless, it is important to understand the two types, how they are typically apportioned, and what the project manager should know regarding how his or her organization defines and uses reserves.

Contingency Reserves—Normally, the amount of money (but can be other resources including time) set aside for those risks that can be identified and are likely to occur. These reserves are typically a part of the cost baseline and final budget. Most organizations authorize their use to the project manager.

Management Reserves—An amount of money that senior management sets aside for unknown circumstances. The amount in this pot of money varies from organization to organization but usually is calculated on some percent of the overall project cost based on historical data from similar projects. For instance, an organization may have experienced enough unknown risk occurrences that it knows to expect a 15 percent increase over planned costs. The senior management controls the management reserves, which are not usually accessible to the project manager. To access these reserves, the project manager would, therefore, have to make a case to senior management for using the money and then obtaining the authority and funds. (It is worth noting in passing that federal sector customers usually do not approve management reserves in the negotiated project contract because they view this as “gold plating.” Actually, it also is difficult to get approval for contingency reserves in a federal sector contract unless there are clearly definable potential risk events. In the private sector, however, both types of reserves are very common.)



To complicate the subject of reserves even more, private sector organizations often don’t delineate between contingency and management reserves. Rather, they opt just to set aside funds (or other resources) and simply refer to them as “reserves.” Whether the project manager or senior management controls this category is determined by the organization.

Module Summary

Module SummaryThere is no way to evaluate the relative progress or success of a project without a baselineThe project manager is responsible for action when a project is off the baseline.The project manager must work to prevent risks before setting the baseline.The baseline is only changed when change is authorized and approved.



Module 5Evaluation and Forecasting

Introduction

Module OverviewEvaluation and Forecasting discusses tools that develop evaluation and forecasting skills to help determine what is going to happen in the near and far future of projects.

Evaluation and Forecasting

Evaluation and Forecasting OverviewEarned value management (EVM) has been used for measuring project progress since 1968. Before this time, tracking project progress essentially consisted of monitoring the actual cost against the budget and the actual schedule against the estimate. But no method was available that assessed the combined impacts of costs and schedule, nor were there any standards for analyzing and reporting these data until the Department of Defense (DOD) developed instructions for their contractors to—

Develop work breakdown structuresDevelop certain key planning elements, such as baselinesDefine cost allocations and procedures for collecting and reporting cost dataAnalyze budget and schedule variances and predict future project costsPrepare performance reports

One of the most beneficial components of this DOD instruction is the method of analyzing project progress known as EVM. Only the DOD and its contractors used EVM until the late 1980s or early 1990s when the private sector began to adopt it as the analysis tool of choice. The method can be used on small and large projects and is independent of the type of contract that is executing the project.

The concept of EVM is an apparent anomaly: Schedule is measured in terms of dollars instead of time. Because measuring schedule in this fashion goes against intuition and experience, some people focus on the language rather than on the concepts of EVM. The result is that learning EVM analysis techniques is perceived as more difficult than it actually is.

Module 5: Evaluation and Forecasting


The key to understanding EVM is in comprehending three terms:1. Budgeted cost of work scheduled or the planned value (PV) of work2. Actual cost (AC) of work performed3. Budgeted cost of work actually performed or the EV

Once you understand these terms and the concepts they represent, all the other terms and components of EVM are easy to remember and use. This module explains EVM and demonstrates how it is used to track a project task’s progress. But first, just what is meant by evaluation and forecasting?

Understanding Evaluation and Control in Project ManagementEvaluation is an official examination and verification of project progress, status, and financial health. An official as opposed to a casual process, evaluation is performed as a requirement of the project manager’s or project team’s responsibility for determining the progress of the project, and it is usually done as a part of the status review and reporting process. It is official, too, because it has the weight of both the project manager’s and the customer’s organization behind it. In fact, evaluations can be official solely because the customer requires them by contract.

Control is the process of comparing actual project performance with planned performance. Control also involves analyzing performance data to determine whether corrective action is appropriate. One major tool used to determine whether a project is in or out of control tolerance is the control chart, which can be constructed around any relevant parameters. Although control charts are widely used to track quality measures, they equally can be effective tracking other project data as well. Some uses of control charts are discussed and demonstrated later in the module.

Control is performed on a regular basis (in fact, daily), whereas evaluation is performed periodically, often in a formal manner such as monthly project reviews and weekly WBS summary element reviews. In other words, evaluation looks at the whole task or project context, and control is the day-by-day actions taken as a result of the evaluation. Finally, control actions are relatively inexpensive and are the actions that project managers generally perform, however poorly. Using a formal evaluation process makes the control actions more complete, focused, and effective.

Controlling Schedule and Cost

Scheduling and Cost OverviewIn its simplest form, scheduling and cost control means—

Comparing planned and actual project progress and costsComparing tasks accomplished to the schedule



Determining a strategy for limiting variation from the schedule and cost baselinesManaging the activities required to maintain the schedule and costs within acceptable limits

“Acceptable limits” is a relative term because some organizations set very tight limits within which a project must progress; other organizations, however, are less stringent. Studies show a project that diverges as much as 15 percent or greater from its baseline (either schedule or cost) can never be recovered to closer than 10 percent of its original plan. In other words, a maximum of about 10 percent away from the baseline should be the limit within which a project manager works to maintain control of the project.

Performance Control ChartsPerformance control charts come in many forms, but the most common and most useful one for scheduling and cost control is the one shown below.

The chart has three curves on it. The middle curve on the graphic is the cumulative cost curve for the entire project. It is the estimated cost of all the tasks summed to represent the expected cost over the life of the project. The very top end of this curve, if measured against the Dollars axis, is the budget at completion or the total cost of the project. The bottom curve of the graphic is a plot of the actual costs spent over time. These two curves were, before the advent of EVM, all that were used to measure how a project was performing against its plan. It is interesting to note that if only those two curves were used, it would immediately be assumed that the project is under budget and doing quite nicely. The problem is that the information from those two



curves does not tell us anything about how the project is performing against its schedule. That information is provided by the third curve, the top one, which plots the EV or actual work accomplished against the plan. It happens that the project example shown in this graphic is in fact doing very well, but that would not be obvious without the EVM curve data.

The curve information also is shown in tabular form on the graphic because the project manager will most likely be required to use both these representations for analysis and for communication with the stakeholders. Tabular data are easier to highlight and explain because the curves mean less to the stakeholders than the tabular information, unless the stakeholders are familiar with EVM.

What Is Earned Value Management

EVM OverviewAs mentioned in the module overview, EVM was developed when the DOD set guidelines for its contractors to collect, analyze, and present financial and progress data. Although EVM has been used for more than 40 years in the federal sector, the private sector has only embraced it from the late 1980s and early 1990s. PMI deserves much of the credit for “legitimizing” EVM in the private sector because PMI recognized its major benefits in tracking and controlling project performance early and pushed its use in the project management world. EVM is now recognized worldwide and in every industry as an accurate and useful monitoring and controlling technique.

What exactly is EVM? It is a management technique that integrates scope, schedule, and resources as a project progress-measuring tool. Because EVM provides a standard way to calculate progress, it is a consistent measurement for use across an organization and across industries. The great advantage of EVM is that actual progress can be compared with planned progress.

In addition, EVM offers a way to compare planned costs, actual costs, and schedule progress on the same graph. This is a major benefit because if actual spending exceeds the budget, an evaluation of the actual progress made may show that the project is ahead of schedule.

Despite its wide acceptance, some project managers and organizations still view EVM as an administrative burden that isn’t worth the time it takes to calculate it. The truth is that the EVM technique is not that difficult to set up. Usually, it already is a part of project management software. All that is required is the input of the percentage of work completed for each work package. The greatest difficulty in implementing the technique is collecting actuals at the work package level of the WBS. This deficiency in the reporting system has nothing to do with EVM and should be resolved in any event.

EVM is usually implemented using monetary values. However, on labor-intensive projects, all the calculations may be performed in hours or other labor equivalents. This is particularly useful if actual cost data were not available. Time spent on the project can be tracked outside of the formal accounting system and used for EVM calculations.



Key EVM TerminologyPlanned value (PV), actual cost (AC), and earned value (EV) are the three terms that must be understood before using EV analysis. Problems with EVM usually occur because the concepts behind these three terms are not understood clearly.

Planned Value (PV): The baseline schedule represented in monetary terms. This is a significant concept in EVM. Accomplishment of the schedule is dependent on resources being applied to work packages in the WBS at the time scheduled. If the resources are applied at the planned time and do exactly the amount of work they were planned to do, the project will be on schedule. Pricing—multiplying the resource unit by the appropriate rate—transforms the resource plan into monetary units.

A plot of the PV curve, performance measurement baseline, is traditionally shown as the cumulative cost curve. Planned value is not a new concept for project planning and control; it is merely a different term. Often, PV simply is called the budget.

The PV is taken from the time-phased performance measurement baseline budget for each WBS element (work package, summary task, and intermediate summary or total project) through the same point in time where the EV is assessed and actual cost incurred. An alternative method is to multiply the percent of the work that was planned to be completed by the total planned value for a task. In either case, the PV is associated with the performance measurement baseline. The PV represents the amount of work planned to be accomplished through a given point in time. Note that PV is always related to a point in time.

Remember that PV is the amount of work that should have been done through a given point in time. At the scheduled end of the task, the PV will represent 100 percent of the work to be done. Therefore, at the planned end of a task PV = total budget or the BAC (discussed later in this module) for a WBS element. This is the necessary tie between PV and the budget. In other words, PV is the time-phased budget. The budget is the estimated cost of any WBS element that has been approved by management. This is why the term “planned cost” is sometimes seen in place of PV.

Actual Cost (AC): The amount of money expended during the task or project performance. It is the amount paid for labor, materials, and all other direct costs. This also is not a new concept; it is simply the actual project costs or actuals. The original DOD system used the term actual cost of work performed (ACWP). The original terms are mentioned because the terms may still be in use in some places or may be encountered in older literature, reports, or documents.

The comparison of budget and actuals traditionally has been used to measure project performance. The major problem is that budget and actuals data alone do not reveal anything about schedule progress. This module later discusses how with “earned value” schedule progress can be incorporated into the analysis of a project. When EVM is used, budget is compared to actuals as a status indicator.

Earned Value (EV): The value of the work accomplished on the project through a point in time. The value is based on the budget. The original DOD system used the term budgeted cost of work performed (BCWP) for EV. Like all the “old” terms, it is far more descriptive than the “civilianized” terms.



For example, suppose you have a small project that is estimated to last five months. Assume that the project is made up of five sequential tasks, each one-month long and each requiring the same amount of effort. You negotiated a progress payment agreement, and the customer agreed to pay you at the end of every month for the work completed that period.

If each task is estimated to cost $200, the total budget for the project would be $1,000 (five tasks at $200). At the end of the first month you planned to complete one task worth $200. The planned value for month one is $200. If you actually complete the task on time, then the customer will pay you the $200 because you earned it by completing what you had planned to do for that period. The EV is also $200. That is the value of the work you performed. You are also on schedule because you planned to do one task and did one task.

Suppose at the end of the second month when you ask the customer for your progress payment, you have finished only 50 percent of the second task. The half of the second task you completed is worth $100. That is your EV for month 2. Adding that to the $200 earned in month one, the total project EV is $300. You have a concern because you planned to have been paid the full $400 but only collected $300.

The $100 not collected represents work that was not done in month 2, which also means you are behind schedule. To complete the project on time you must catch up by doing more than the $200 planned in the remaining three months. It you can’t do that, the project will finish late.

Until now, EV has been used in terms of what percentage of the work was actually done. In other words, EV is determined by multiplying the percentage of work actually completed by the total task estimated budget, which is also known as the budget at completion (BAC). BAC can be expressed by the following formula:

EV = % Complete x BAC

Sometimes, AC and EV are confused. AC has absolutely nothing to do with EV, or for that matter, PV. AC consists of the actual expenses for the work done, such as labor, materials, and so on. EV, on the other hand, is the budgeted value of the work actually done.

Other Key EVM TermsSome other key terms follow:

Budget at completion (BAC): The approved total budget for any element of the WBS including the total project. The budget is the approved task estimates for the each WBS element.Cost variance (CV): The difference between the budgeted value of the work completed (EV) and the cost incurred to perform the work (AC).Schedule variance (SV): The difference between the estimated value of the work completed (EV) and the planned value completed (PV). Note that the schedule variance is expressed in dollars. Remember that PV represents resources scheduled to be used in a given time period.



Percent complete (PC): The amount of work completed to date expressed as a percentage of the budget for the total work to be done (BAC).Percent spent (no acronym): The amount spent to do the work completed to date expressed as a percentage of the budget for the total work to be done (BAC).Cost performance index (CPI): Performance on the money spent. CPI measures how well the project is performing by comparing the amount of work completed against the amount spent to do the work. It can be considered as the value of the work completed per each dollar actually spent.Schedule performance index (SPI): Performance against the money planned to be spent, PV. SPI measures how well the project is performing by comparing the amount of work completed against the amount of work planned for completion during the same period. It can be considered as the value of work completed per each dollar planned to be spent.

With a working vocabulary, the techniques of EVM calculation and analysis can be examined.

Applying EVM: An Example

EVM ExampleThe best way to understand the EVM calculations and analysis techniques is by studying an example, such as the graphic below.

This is an uncomplicated project that has three tasks and will run for nine months. But this simple project is sufficient for us to demonstrate how the EVM calculations and analysis techniques are used.



Additional information about the example project is in the table below:

Task Budget at Completion

Percent Complete

Earned Value

PlannedValue

Actual Cost

A 1,000 50% 500 520 485

B 1,500 20% 300 260 310

C 800 40% 320 150 380

Totals 3,300 1,120 930 1,175

It is critical that all three numbers are for the same period in time. In this case, the data is through month 3. This date often is referred to as the reporting date or data date.

The EV is the percentage of the work that actually has been completed. It is shown by the shaded area in the graphic and recorded in the fourth column of the table. For example, EV is calculated for task A as follows:

EV = 50% x $1000 = $500

With this basic data, the EV analysis can be calculated.

EVM Analysis: Formulas and Their Interpretation

Variance MeasurementsCV and SV are the most-used and most-useful project performance measures and are also the simplest to calculate and easiest to understand.

Both are numbers calculated by comparing EV with planned value or actual cost. CV is, as previously defined, the difference between the value of the work actually completed and the amount of money actually spent for the work. CV is calculated by the formula:

Metric Formula Calculation Result

Cost Variance CV = EV – AC 1,120 – 1,175 = (55)

The negative value indicates that the project is over budget. If it were a positive value, the project would be under budget; and if it were zero, the project would be exactly on budget. As a general rule in EVM, negative numbers are considered “bad” and positive “good.” Zero variance is considered impossible.



Note that negative numbers are shown in parentheses. This is good business practice because a small "–" is easy to overlook. Monetary unit designators also are omitted. When reviewing large amounts of data the designators only clutter the tables and reports. A single note on the report or one symbol at the top of the column indicating the monetary units used generally is sufficient. Many organizations report in order of magnitude figures such as thousands or millions. This is indicated by notation at the top the report. Common examples are ($000) or (£M).

Schedule variance is the difference between the value of the work completed (EV) and the amount of work planned to be done (PV). SV is calculated as follows:


Schedule variance SV = EV – PV 1,120 – 930 = 190

Thus at the time of the data date or reporting date, the project is over budget. But it is ahead of schedule because a positive SV indicates being ahead.

The numeric value of a variance is useful only in comparison to the value of the WBS element in question. An index is used to give additional meaning to the variance and compare the performance between different WBS elements. Senior management (particularly those managing financials) generally can relate better to an index that shows performance relative to actual expenditures or planned progress. As a result, the cost and schedule performance indexes are especially good for communicating progress to such stakeholders.

The indexes are calculated using the same numbers used for the variances. The CPI is calculated by dividing the value of the work actually performed by the actual cost of the work.


Cost performance index CPI = EV ÷ AC 1,120 ÷ 1,175 = 0.95

Performance Indexes

This number means that every dollar spent on the work is generating only 9 cents value in return. A CPI of less than 1.00 indicates that more is being spent than is being returned in value; a CPI greater than 1.00 signifies that the project is worth more than is being spent; and a CPI of 1.00 means that the project is exactly on budget.

CPI is a practical forecasting tool because it can be plotted and trends can be determined from the data. Many project managers develop a control chart layout for the CPI data. They use it as a controlling mechanism by maintaining the CPI curve within an agreed-upon upper and lower control limit, much like quality control charts with their upper and lower standard deviation lines.

The SPI is calculated by dividing the value of the work actually performed by the planned value for the work.




Schedule performance index SPI = EV÷ PV 1,120 ÷ 930 = 1.2

This index value shows how well the project is performing against the plan. If SPI is greater than 1.00, the project is ahead of schedule; if less than 1.00, the project is behind schedule; if equal to 1.00, the project is on schedule. So, again, these indexes show that although the project is over budget, it is ahead of schedule.

Like indexes, percentages allow comparison without regard to the value of the figures and are useful in comparing between projects. As such, they may be particularly valuable to upper management and the customer.

PC is calculated by dividing the value of the actual work performed (EV) by the project BAC. Because the percent complete is known at the work package, this calculation generally is performed at the total project or summary levels for the project. For the example project:


Percent complete = EV ÷ BAC 1,120 ÷ 3,300 34%

Percent Complete and Percent SpentThe percent spent is calculated by dividing the AC by the BAC. For the example project—


Percent spent = AC ÷ BAC 1,175 ÷ 3,300 = 36%

Comparing what has been completed with the amount spent for the effort provides a quick comparison of the magnitude of any variance. It is far easier to recover if the percent spent is only 2 percent higher than it is if the gap is 10 percent.

Completion EstimatesThe project team and senior management need three key completion estimates:

Estimate to complete (ETC): The estimate of how much money is needed to operate the project from today until the end of the project. The estimate to complete or ETC is particularly important to the controller or other financial officers in the organization because they will use that number to plan future cash flows. Moreover, that number includes the potential budget increase and, therefore, it becomes the basis for replanning the budget, if required.

The ETC is calculated by estimating the cost of completing the remaining work for each work package. The ETC can also be calculated by the following formula:




ETC BAC - EV 3,300 - 1,120 = 2,180

The ETC lets management and finance know the funds needed to complete the project.Estimate at completion (EAC): The current best estimate for any element of the WBS. When the project begins, the EAC is usually the same as the BAC because the BAC is based on the task cost estimates. However, as the project continues, project performance, changes in assumptions, or other factors may result in a change to the EAC. The most common method of calculating the EAC is to add the actual cost expended to date (AC) to the estimate to complete (ETC) the task. The project EAC, like the original estimate for the project, can only be done at the work package level and rolled up to intermediate WBS levels and finally to the total project.

Using the AC for task B from the example data table and an ETC calculated by ETC = BAC – EV, or 1500 – 300, the current estimate for the remaining work of $1,200 is—


EAC for task B EAC = AC + ETC 310 + 1,200 = 1,510

For tasks that have not started, AC= 0; so the ETC is the same as the EAC.

When variances are considered atypical of future performance, a good method for calculating EAC is EAC = AC + (BAC – EV), or 310 + (1,500 – 300) = 1,510.

Another method of calculating EAC is based on the formulaEAC = BAC ÷ CPI. This formula often is used by practicing project managers because it provides a quick, easy, and relatively accurate result, especially when there are small variances between the planned and actual budget and schedule.

But a more accurate calculation of EAC when current variances are seen as typical future variances is made by—


EAC for Task B EAC = AC + [(BAC - EV) ÷ CPI

310 + [(1,500 - 300) ÷ 0.96]

= 1,560

Over forecast CPIs of less than 1.00 will result in the EAC being larger than the BAC and vice versa.

All calculations in this section have been rounded to the nearest dollar. Although the calculation could be carried out to the penny, that would indicate a precision beyond the reality of the estimates.



Variance at completion: The difference between the original estimate and the new estimate at completion of the project ($3,474). In our example, this variance at completion or VAC is calculated by—


Variance at Completion for Task B VAC = BAC – EAC 1,500 – 1,510 = (10)

Calculations are fine and necessary. But what do they all mean? How can they be portrayed so that these various elements in schedule and cost control can be viewed relative to one another? The following graphic depicts each of the key measures defined above.

The diagram also indicates one additional financial term: the contract budget base or CBB. As you can see, CBB is the BAC plus reserve.

Estimating Percent Complete

Estimating Percent Complete OverviewThe most difficult part of EVM is estimating with any real accuracy a task’s percent complete. If the project consists of manufacturing parts or building chairs or anything that can be counted,



then estimating percent complete is uncomplicated. For example, if the project is to install 100 linear feet of fence in five days, then 20 feet of fence must be installed per day. At the end of each day, the percent complete for the total project can be calculated easily.To-Complete Performance Index (TCPI)

TCPI or to-complete performance index is a way to predict the probability of completing a project on time and on budget given the current status of the project. It is calculated by dividing the work remaining by the budget remaining. In circumstances when the project is over budget and behind schedule, TCPI gives a prediction of how much the productivity of the project must improve to meet the initial budget and schedule. If the CPI (a measure of productivity—essential work performed for dollar spent) is 0.85 and the TCPI is calculated as 1.10, it means that the team must improve their productivity by more than 25% to meet goals. In most circumstances, the probability of this occurring is pretty low.

The 50–50 Rule

Some tasks are difficult to estimate. As a result, the DOD long ago suggested to its contractors a way to simplify the percentage complete problem. It is called the 50–50 rule.

How does it work? Under the 50–50 rule, the task is considered to be50 percent complete the instant when work is begun, and it remains at 50 percent complete until the task is finished. Therefore, although the actual percent complete on a task may be 10 percent, for calculating PV and EV it is considered to be 50 percent complete.

There are some obvious inaccuracies in this method of estimating completeness, and they would be considered significant on a small project with few tasks. But the method is actually quite accurate when averaged over a number of tasks, and particularly accurate if all the tasks are of a short duration. While tasks can be estimated at various lengths, 45 to 60 days should be the maximum duration. Some systems control the number and duration of work packages by limiting the number of hours. Sixty hours is often used as a limit; this is the basis for the so called “60-hour rule.” This rule often is misunderstood as mandatory for all work packages, but it is not.

In addition, although the 50–50 rule is the most common technique of this type, other weighting techniques can also be used. For example, 0–100, in which no credit for percent complete is given until the task is finished; 80–20, in which 80 percent complete is assigned at the beginning of the task (particularly applicable to tasks with heavy front-end costs); 20–80; and so on. The point is that the most appropriate percent complete estimating technique can be used for any individual project. No matter what estimating method is used, make sure that it is documented and distributed to all the stakeholders so that everyone can evaluate the EV analysis from a common perspective.



Analyzing Variance

Analyzing Variance OverviewEVM is an exceptional monitoring and controlling technique that uses excellent tools to measure variances from the baseline. However, variance by itself is not useful until the reason for and impact of the variance can be identified and understood.

A project has variance for many reasons:Estimating errors. Inaccurately estimating the schedule and cost is probably the biggest reason for project variances. Because the baseline is built around estimates, care in estimating, constantly improving estimating techniques with lessons learned data, and updating costing models and databases will reduce variance size greatly.Technical problems. Technical solutions often have to be revised or changed as more is learned about the project requirements and available technology and as the design itself evolves. Sometimes technical problems do not surface until article testing begins, which can cause a significant rework of the product.Management problems. The skill level and availability of personnel have a significant effect on whether a project can be kept on track. Too few people or people with less experience and skill than planned will cause a divergence from the plan. Even organizational changes, particularly in stakeholders, procedural and policy changes, and process changes or deficiencies, greatly will affect whether the project remains on track.Economics and market fluctuations. Changes in cost, as well as in the market demand for a product, can create a need to redefine the project scope and baseline, which causes significant variances from the original plan.Acts of nature. Unknown or unexpected events can throw a project off track completely, even to the point of stopping the project altogether. Such incidents as tornadoes, fire, and floods cause large variance spikes.Subcontractors and vendors. Without a subcontract management system that keeps subcontractors and vendors on track, the project schedule and costs variances will suffer. When you put a subcontract into place, ensure that there is a requirement for status reports, which supports your own status reporting system and data format. This is the only way to receive schedule and cost information in a timely way and in a format that is compatible with your own.Lead times. Planning for component and material lead times must be done early in the project. For most projects, lead times are not a problem; however, sooner or later everyone will encounter a project that has some unique materials requirement or some technology or component that necessitates extra time to find, design, build, or ship. Planning well ahead so that lead times do not affect the schedule can make the project run more smoothly.

The final step in the variance analysis process is to document the results and distribute them to the appropriate stakeholders.



Reporting StatusUltimately, communications in the project environment will determine the extent of a project’s success. If no communication plan is in place or if it loosely is defined, then the chances of success are reduced greatly. Status can be reported using a variety of different vehicles, including e-mail, telephone, formal and informal reports or memoranda, formal and informal meetings, and so on. The form is not as important as the fact that everyone understands when and how status will be communicated.

As part of the overall project plan, the communications plan contains the people who will receive reports, how much information they will receive and with what frequency, and how this information is to be transmitted. The communications plan is formally documented and distributed to all stakeholders so no doubt exists about what information they will be receiving and when they will receive it.

One excellent tool for collecting the project data in a usable and understandable fashion is the Earned Value Management Report, which is found in the Tools section of this reference manual.

This report contains all the information discussed in this module. Most project management software packages include these reports as part of the report generation module, and although the layout might vary slightly, generally all such reports contain the same information.

One key thing to remember about the EV report is that not all stakeholders know how to interpret the information. Therefore, it is wise to deliver personally the report and explain what the data denote, at least the first time a report is presented. Another way of ensuring that everyone understands the results of EVM is to present and explain the data in a formal meeting.

Understanding Control and Management

ControlControl, in its basic form, entails implementing strategies to keep the project true to its baseline. However, projects—especially complex projects—are not simple to control. Luckily, there are steps that can be taken that make controlling the project at least manageable. The diagram that follows shows the steps and techniques of a control process, which is applicable to any project, either simple or complex, as well as to any industry.



Basis of Control and ManagementControl of a project baseline is not possible without the timely and accurate data from the two top boxes in the diagram. The project plan is developed using cost and schedule estimates based on the technical requirements of the project. Because the baseline is only as good as the estimates, constant replanning is necessary. Actual costs are needed to measure how the project is performing against the budget, and task leaders must provide accurate assessments of their progress against the schedule.

Plan and Actuals—Real-time information about the costs and schedule is imperative to determine how well the project is performing against the plan. One dilemma facing project managers is not having access to a management information system that can deliver actual expenditures and schedule changes in a timely manner, which is why many project managers do their own tracking. Actually, it is a good idea to maintain a tracking system within the project just to have a backup in the event the accounting system can’t deliver the cost reports when needed.



Variances, Trends, and Forecasts—Using the actual expenditure figures, particularly as the project progresses, a trend analysis can help the project team forecast how the project is likely to progress. Comparing the actuals against the plan provides information about how the project is performing against the baseline, that is, if there are variances and if so, what they are. Therefore, the variances, along with the trends and forecasts, are vital for planning future control strategies.

Variance Analysis—Variance analysis can be accomplished using earned value management, which is discussed in detail in the next module. (Other techniques, such as gap analysis, are also available for analyzing variance, but they are not discussed in this course.) Variance analysis is the assessment of exactly how close the actual costs and schedule are to the plan, and, more important, why there is a variance. Depending on project performance, variance can be good or bad. If the project is over budget, that is usually bad; but if the project is ahead of schedule, being over budget at some point might not be bad at all. Thus, the analysis must examine the variance, the cause of the variance, and whether the variance indicates an adjustment is needed.

Action Plan—Once the variance and trend analyses are complete and you have a sense of where you expect the project to be within the next reporting period, it is time to develop an action plan or make decisions about how to correct the variances. The action plan depends entirely on the circumstances at that time. That is, if the variance analysis warrants it and the trend appears to worsen, then drastic measures are in order: Add resources, hire consultants, and renegotiate scope changes. Normally, if the project team conscientiously has tracked the project's progress, variances are relatively small and require only managerial tightening of the procedures and processes. However, like Murphy’s Law, risk events do occur and projects do tend more toward instability than stability. As a result, constant variance vigilance is crucial in the control process.

Replanning—The project plan must be constantly revised. The early, original plan will not be sufficient or accurate for the project's duration because with progress, more is known about the requirements, risks, technical approach, and so on. Therefore, at each assessment point in the project, the plan must be validated, and usually it must be changed.

This controlling and managing process is the normal, day-to-day process for addressing changes and variances that occur merely due to the work stresses of developing and delivering the product. What happens then when changes are conscientiously introduced? Those changes fall under the purview of the project change management process.



Module Summary

Module SummaryEVM numbers are relative to the magnitude of the project.Project progress is measured by control and the use of the performance measurement baseline.Control charts organize and summarize information and present results.CPI is a practical forecasting tool.



Module 6Change Management Within the Project

Introduction

Module OverviewChange is probable in any project simply because of the number of people involved. This module provides a plan for dealing with change within a project.

Managing Change

Managing Change OverviewThe potential for change is always present in a project simply because of the number of people involved. Because every stakeholder and every person working on any part of a task can influence or even directly change the project scope, it is crucial that a formal change process be in place. Actually, there should be two change processes or procedures for every project. The first is a part of the contract that deals with scope changes the customer initiates. The second is an internal organizational process that deals with recommended changes to the product as the design and development matures.

Within the organization, change management generally occurs at two levels. At one level, the project manager recommends modifications directly to the customer if they don’t affect the budget or schedule above some predetermined level, which is set by senior management. At the second level, a change control board considers all other recommended modifications. The key is to have a project change management processes in place and communicated to the customer, all stakeholders, and all team members when the project begins. The project manager should have a thorough understanding of all the processes in order to eliminate scope creep and to aid in general project control. It is important, however, that the project change management process is viewed in the proper perspective and that it is understood how change management fits into the project control and management structure.

Module 6: Change Management Within the Project


Understanding the Project Change Management Process

Sources of ChangeChanges, unfortunately, can come from anywhere and potentially from anyone associated with the project. Even a person writing new code can change the project scope by adding enhancements that weren’t called for or by stripping functions that seem unnecessary. Some of the most usual sources of change are—

CustomersProject team membersGovernment agenciesEnvironmental agencies or interest groupsProduct obsolescenceChanges in managerial or organizational objectivesTechnological changesFunding changes

All the changes affecting a project are generally handled by one of two processes. The first process is established in the contract by the customer and deals with actual contractual/legal changes. The second process is the internal change management process that considers recommended changes to the project scope and/or product.

A change process outlined in the original contract handles those modifications that are outside the realm of the project, that is, changes from the customer or outside influences that indicate a change to the contract. The usual method for these modifications is a formal notice from the customer alerting the provider to the change and asking for an impact analysis. If the modification has an increased effect on both the budget and schedule upward, then the customer requests a proposal, which is evaluated, negotiated, and either accepted or not. If, however, the change requires reducing the scope of the original project, then the provider is asked for an analysis of the damages to the company. In this case, damages would include such items as costs of hiring additional resources, renting facilities, buying equipment, and so on, and the company could receive fair compensation for the damages.

These kinds of modifications to the project are made in accordance with the procedures that the customer sets forth. A project change management process that the organization establishes and the customer approves, or at least evaluates and accepts, handles modifications that are recommended from within the organization. However, it should be noted that the customer also can use this process and will use it, depending on the significance of impact to the project. How this overlapping of change processes works out will be clarified in the discussion of the project change management process and its purpose.



The Project Change Management Process

Project Change Management Process OverviewAlthough the project change management process is very straightforward, if it is not followed, the results can be significant and occasionally disastrous. The objective of the project change management process is to ensure a central control point for all recommended changes to the project. Note that it’s “all recommended changes.” The implication is that no changes are made without them first going through a rigorous recommendation and evaluation process. This process is designed to eliminate scope creep and gold plating and to maintain the integrity of the project plan.

The project change management process is depicted in the graphic below. A detailed discussion of each step follows.

Identifying a Change Request and Evaluating Its Effect on the ProjectAnyone can recommend changes. Often, as the project matures, it becomes obvious that certain functions don’t work well or that additional or different functions might work better. When this occurs, a change recommendation should be documented with some very specific information, such as who is making the recommendation, what is the recommended change, when should it be done (that is, at what stage of the product development), what its value will be, and what the estimated impact is on the project. In some organizations, the project manager can assess the recommended change and make a decision to go to the customer for approval. Normally, this kind of authority is granted based on some level of estimated impact on the project’s schedule, budget, and/or scope. Above that level of authority, however, the project



manager is required to make an assessment and send it to a change control board (CCB), which is an ad hoc committee of three to five members. In all cases, the recommended change(s) should funnel through the project manager.

One excellent tool for documenting the change request or recommendation is the Change Control form.

Generally, the person recommending the change has a good sense of what effect the change will have on the project because he or she most likely is who will make the change if it is approved. This is not always true, however; sometimes the impact of a change is not fully understood by the person who requests it. In all cases, the project manager should assess the change request and its effect on the triple constraint of cost, time, and scope for the CCB’s consideration. But other considerations are equally important, such as the effect on other functional areas, stakeholder interests, organizational politics, the team and its workload, quality, and the management of the project itself.

If the CCB accepts the recommendation for a change to the project, its decision does not mean that the change is automatically put in place. Rather, it means that the CCB or its designated representative will present the recommendation to the customer for approval. The customer’s acceptance of the change is formalized by a contract amendment.

When making a recommended change to the project, the customer sometimes assumes the role of a stakeholder or team member. This is done within the project change management process rather than through the contractual process because it may not be known how much (if any) impact there will be to the project schedule, budget, or scope. The process then follows its normal course through the CCB, and the customer makes a decision to pursue it or not, depending on the results of the impact evaluation and the CCB’s recommendation.

Up to now, what has been discussed is the process involved when a change is approved. What is the process if the change is not approved? The process is the same through CCB consideration. If the change is not approved, however, the request and the reasons for its rejection are documented, the person making the request for change is notified with an explanation for the change rejection, and the documentation is added to the project binder for historical purposes.

Coping with Approved Project ChangesWhen a modification is approved and implemented, what does that mean to the project manager and the project plan? Every time the project is changed, the project plan must be updated. This primarily means there is an amendment to the WBS. Remember, if it isn’t in the WBS, it is not a part of the project. Thus, if there is a change to the scope—no matter how small the change—then the WBS must reflect this change.

Once the modification becomes effective and the WBS is amended, every stakeholder must be informed. No changes occur without a complete document and communication update. Unless everyone is aware of the change, it cannot be fully implemented. Likewise, if the modification is not approved or incorporated, the person initiating the change request must be notified and the



action must be recorded. Changes, whether implemented or not, become a part of the project documentation for future reference.

Updating the PlanWhen a change is recommended and approved by the customer, the plan must be updated. Often, an accepted, recommended modification involves contractual amendments. In some ways, changing the contract is a great benefit to the management process because a formal amendment addition to a contract forces a plan revision. Regrettably, this formalization is not usually present in internal projects, and it often is left to the project manager to ensure that all of the proper documentation and plan updating are accomplished. Because the lack of a formal contractual process sometimes means that a change to the project is not adequately incorporated, project managers need to remember that it is their responsibility to ensure that the change is properly presented, accepted (or not), and updated in the project plan.

Updating the project plan starts with an update to the WBS. Every modification to the project should be reflected as a task in the WBS; the network analysis, schedules, budgets, and so on can thereafter be refreshed.

The next step in the project change management process is to communicate the action of the recommendation to the appropriate people.

Communicating Project ChangesCommunicating the modification is just as important as making the decision to change in the first place. The key roles in the communication process fall to the customer’s project manager and the organizational project manager. The customer’s project manager will inform the customer stakeholders and will ensure that all documentation, direction, funding, and all other contractual obligations are in place. The project manager who is responsible for the project work informs all the organizational stakeholders about the change.

There are two useful tools for the communication step. One is the Change Responsibility document and the other is the Document Control form.

The Change Responsibility document is a form used to record the change. One form is used for each change to ensure accurate tracking. The form lists the individuals involved in the change, their responsibilities for ensuring the change is properly made, and a description of the change itself.

The Document Control form is used to track the communications (in this case, a change form). Its specific importance is to record the historical events relative to the modification. This form is not only important for the lessons learned archive, but it also can be crucial in the event of litigation after the project ends. Accordingly, being able to show the sequence of events may be as important as the event itself.

The process of change management is not difficult, but it is important. Without both the contractual change process and the internal change request process in place, the project manager’s ability to control scope creep can be quite difficult.



Module Summary

Module SummarySources of change are verbal or written, direct or indirect, external or internal, and legally mandated or optional.Change control is the responsibility of the project manager, who must evaluate the significance of change through project team input.Project managers use the WBS, schedule, budget, and specification baselines to help control the project.Project managers must document all change requests.



Module 7The Exit Strategy: Closing the Project

Introduction

Module OverviewThe Project Closeout (or the exit strategy) addresses what can be the most difficult phase of the project: the closeout.

The Exit Strategy

The Exit StrategyClosing out a project can be a difficult activity. Project team members are concerned about whether they have a new project to proceed to or whether they are being actively moved from your project to other project work.

In instances where a project has been a long-term endeavor and the project environment has become a “home” for the team members, people have actually been known to sabotage their work by dragging it out to prevent the project from ending. Distractions such as these occur while the project manager is busily trying to complete the deliverables and take care of the administrative and contractual requirements of closing out a project.

At first glance, the number of activities required to close out a project seems relatively small, as compared, for example, to the customary number of activities required in the Planning phase or the Implementation phase. But the number of activities is not the primary concern for closeout, rather the activities in the project that need to be done and the criticality of performing these activities accurately and completely.

The project team needs to be aware of and be prepared to achieve three objectives:Determine when and if the project is completeAppraise the project plan in the context of the project completionProvide concrete measurements of project success at its completion

This module discusses how each of these objectives is accomplished.

Module 7: The Exit Strategy: Closing the Project


Project Closeout

Project Closeout IssuesNo matter how well you control the project up to this point, there are three activities that, if not handled properly, will destabilize the project and can actually result in the project being considered unsuccessful. These three activities involve—

Validate scope and obtain customer final acceptanceClose contracts and procurementsClose project or phase

Validate scope—A formal acceptance by the stakeholders and customer that the team has completed what the customer requested and what was documented in the project plan. Validating scope occurs at the end of tasks, phases, and, most importantly, at the end of the project. This is the time to determine that everything has been completed as advertised, communicated, agreed to, and documented. The scope is a de facto “contract” specifying performance and deliverables. Closeout is the last chance for a project manager to ensure that the customer obtains what was expected and is satisfied with the results.

Close contracts and procurements—An administrative closure of all the contractual requirements, including special terms and conditions; financial audits to ensure bills have been paid and invoices issued; a verification that all deliverables, reports, and documentation are complete; and customer acceptance of the product.

Close project or phase—finalizing all activities to formalize project completion, including verification that all reports, including and especially the final project report, are written; all information is disseminated to the stakeholders; and the project is closed formally. All assets and inventories need to be accounted for, and the project accounting cost center code needs to be closed out.

Although these three activities are the key ones that must be accomplished, the project manager also has other activities to complete. One of the most important is to reassign equipment and resources. Often, a project involves buying or renting equipment and facilities or even obtaining equipment from the customer. All this equipment must be accounted for and returned to its rightful owner. As far as project team members are concerned, the project manager is responsible for either reassigning them if he or she has that authority or, at the minimum, making recommendations for their future use within the company. While the work of closing the project is neither easy nor trivial, it can proceed more smoothly when there is an exit strategy process in place.



Exit Strategy Process

Steps to Project CloseoutEvery project should have a formalized exit strategy because missing even one step in the process could spell failure for an otherwise successful project. Although the diagram that follows depicts a process/checklist that can be adapted for any kind of project, the user must fill in the activity details that best meet the needs of his or her industry and organization.

If done for a customer external to the organization, the steps in this process should be designed to examine every aspect of the project and the contract; if done for an internal customer, the same rigor of closing is required but the documentation is different. You will be scrutinizing your organization’s internal project documents, such as the statement of work, memorandum of understanding, and memorandum of agreement to ensure that all project work is complete. The steps also should be designed to ensure that all the stakeholders are involved with project closure and that their expectations have been met. To understand more fully how the process works, it is beneficial to examine each step in some detail.

Fulfill Contractual ObligationsIf one of the exit strategy steps is more important than any other, it would be this one. One difficulty in completing this step is that contract terms can be verbal or written (although written ones are easier to enforce), and correspondence generated throughout the project’s life can assume the force of a legal document. Consequently, a thorough internal review of the project requirements, written and verbal promises, and deliverables is crucial.

Along these lines, it is worthwhile to mention that a detailed record of all interactions with the customer is critical, not just for the sake of ensuring everything promised is delivered, but for the protection of both the customer and the provider. For example, if a team member attends a meeting with the customer and promises or agrees to something during the meeting, that



promise—even if verbal—has the weight of the project manager and the organization and can be enforced by the customer. If the team member fails to report the promise and it is not recorded, then a final review of the project’s deliverables may reveal a nasty surprise. In fact, it is this kind of occurrence that is a large contributor to scope creep.

In addition to handing off project deliverables, there are two other very important required activities. The first activity is a financial review to ensure that the bills have been paid and, very importantly, that the customer receives the final invoice. The second activity is that the customer must accept the deliverables in writing; otherwise, the project cannot end. The first and second steps in the process actually overlap, but it is useful to consider them separately so that the importance of each is clearly understood.

Conduct Final WBS ReviewConducting the final WBS review serves many purposes. As previously stated, the WBS is a crucial tool in project management. It is particularly important during closeout of a project because it documents all the tasks and the individual work packages required to design, develop, and deliver the product. That said, the final review is designed to determine whether every single work package is complete, and if it isn’t, why not and whether it now needs to be completed.

Because the project scope can change during a project’s life, the WBS should be kept up-to-date to reflect any modifications and their effect on the project. The final WBS review will reveal whether the WBS was changed to reflect differences between the original scope and the final one. (Incidentally, this technical audit also can be used to check the financial audit. In that regard, revisiting each work package permits the project team to determine whether the bills have been paid and every legitimate charge has been invoiced.)

Organize FilesIt is a good idea to keep an index or content list of all your files for future use. The Project Binder Content and Update Guide tool is excellent for this purpose.

Data in project files vary from formal, such as status of progress reports, to informal, such as the project manager’s notes from a team meeting. Generally, all records are important because they provide a trail that supports any actions taken to achieve the project results. Furthermore, they may substantiate whether verbal agreements were made during meetings with the customer or other stakeholders.

Generally, project data will fall into three broad categories, each important to the success of future projects: working or day-to-day, contractual or legal, and lessons learned documents.

Working or day-to-day documents—All documents needed to run the project.These include Gantt charts, schedules, analyses, status reports, progress reports, change management, and so on. Keeping these data together facilitates any technical reviews or audits.

Contractual or legal documents—All documents that relate to an external contract or to the statement of work, charter, and memoranda with the customer.



Lessons learned documents—An analyses of what “went right” and what “went wrong” in the project. These analyses are particularly important to future projects because they can improve the estimating process and also mitigate risks. They are a source of vital information for estimating and updating best practices.

Most companies do reasonably well with the first two types of documentation, but almost none do a good job with lessons learned. The problem is that by the time a lessons learned session can be scheduled, most of the team members have been reassigned. Nevertheless, the importance of collecting lessons learned cannot be overemphasized. Some project managers conduct a lessons learned session at the start of a project to at least collect some lessons learned from previous experience; however, these sessions are not as successful as those scheduled at the end of a project when ideas are fresh.

Although organizing files is very important, don’t lose sight of the continuing customer relationship!

Conduct the Transition Meeting“Finalizing” is actually the wrong word since the relationship should be ongoing. After all, one key corporate objective for any project is that the results make the customer so happy that he or she will want to come back with other projects. But “finalize” customer relationships really means that this is the time to ensure the customer is happy with and eager to accept the project deliverables. It is also the time to talk about bridging the gap between product acceptance and signing up for some ongoing maintenance, if that is appropriate for the project. At the very least, it is the time to establish a relationship that allows for periodic discussions regarding how the deliverables are serving the customer’s needs and to ask the customer if he or she is willing to provide a reference for the project manager and team.

A project often has an option or contract clause that specifies continuing maintenance and service. Usually in these cases, a different corporate group is responsible for this function. If that is the case, this step is the appropriate place to make sure the project is handed off properly and the customer is aware of who the key contact and players are, as it is only good project management procedure and good business.

Celebrate SuccessIt is a mistake not to celebrate the success of the project. Many organizations miss out on this opportunity to close out the project as a team and to acknowledge everyone’s hard work properly. Celebrating the project’s close and success serves three main purposes: It marks the official end of the project for the project team; it provides the opportunity to acknowledge everyone and each individual contribution to the project’s success; and as a leader, the project manager can only gain from this show of appreciation, which will be apparent the next time that he or she heads up a project and needs a new team.

The lessons learned review often takes place during this celebratory time, making it also a good time to collect additional lessons learned data. However, the essence of the lessons learned effort should have been completed before this time because team members are already thinking



about their next assignments. Still, the astute project manager will take the opportunity of the celebration to record the members’ recollections of what went right and what went wrong.

Closeout Project or PhaseThe final step in the exit strategy process is to close out the project or phase formally. Three activities remain in closing out a project: reassigning the personnel who have worked on the project; redistributing any materials or equipment used in designing, developing, and producing the project; and circulating and archiving project documentation.

Reassigning personnel is not always an option for the project manager. Most often, the team members and all those who have supported the project work actually report to a functional manager and not directly to the project manager. Consequently, the project manager may not have the responsibility or authority to reassign personnel. If that is the case, the project manager should produce written recommendations for all team members so that both they and their functional managers know how they performed on the task work. This serves two purposes. First, feedback, especially constructive feedback, is helpful to the person and to his or her manager for purposes of career advancement. Second, and just as importantly, this evaluation serves to identify those who should do good work on future projects. This feedback, therefore, benefits the organization as a whole. This function is in the project manager’s unique purview to perform.

Redistributing materials and equipment can be an arduous and time-consuming task. Many projects use government- or customer-furnished equipment to aid in developing project products. All this equipment must be accounted for and returned to the proper owner. Moreover, because many projects also require that facilities be rented and provisioned, it is the project manager’s responsibility to ensure that all facilities and any equipment are properly distributed or closed out.

The final act in this process is to circulate the appropriate documentation, particularly the final project report, and to archive project documentation. The project binder, which contains technical documentation, contractual documentation, and lessons learned, must be located where it can be easily retrieved for future reference.

Module Summary

Module SummaryCloseout is a process—not an event.Project managers must ensure that all steps are taken to close out the project properly.Many stakeholders are involved in project closeout.Conducting lessons learned reviews is critical to future project and organizational success.



Documents

Managing Cost-Reimbursement Contracts Scheduling and Cost ...elearning.esi-intl.com/BlendedLearning/ILT/BVZ_v4... · What Is Scheduling and Cost Control? Scheduling and cost control