Fabricant Manufacturing Project and begin tasks related to initiation Paper

Module Three: Project Scope, Planning, and Time Management

Copyright © 2014 MindEdge Inc. All rights reserved. Duplication prohibited.

Module Three: Project Scope, Planning, and Time Management

Before they can begin to tackle a project, project team members and key stakeholders must have a sense of what the project's results will look like and when those results are expected. An ability to understand the scope of the project, to appropriately plan the project's work, and to correctly structure its schedule are vitally important to help practitioners meet the requirements of the project.

In a project's Planning stage, project practitioners will generate a comprehensive project management plan to show how they'll complete project work and how they'll deliver the results the project was designed to achieve.

They will use the project charter, the stakeholder list, and the milestone chart from the project's Initiating stage as the foundation for creating the project's deliverables. They will design documents to show what work the project entails, to track project progress, and to uncover and monitor the risks that could affect the project. They will connect the people in the project to the project work, and they'll develop a strategy to monitor changes and track contract performance across the project.

By applying effective project scope, planning, and time management practices, project participants will be able to deliver appropriate results in the time frame expected to satisfy the project's objectives and to meet its stakeholders' needs.

Learning Objectives

After completing this module, you should be able to:

1. Design an effective scope statement to create boundaries for the project 2. Describe the characteristics and inputs to a comprehensive project plan 3. Describe the purpose of a work breakdown structure and how it supports the project

management plan 4. Demonstrate how a project schedule network diagram is created

Planning the Project

A common challenge that project practitioners face is resisting the temptation to move directly from initiating their project into executing it—a shortcut commonly described as "Ready, Fire, Aim." Jumping too quickly into the Executing stage can endanger a project and limit its chances of survival and success.

Doing project planning and developing a good project plan is critical to avoid the common problems—like scope creep, unclear work assignments, and uncontrolled risk—that could occur later in the project. The true benefit of planning is that it improves the chances of getting the project to where it needs to go.

Planning a project is much more than filling out forms and templates. The act of gathering the information needed to produce good project plans will help participants understand the project in much greater detail than they would by diving directly into project work.

Tailoring Plans

But no matter how well a project is planned, the plan will not be "watertight"; changes will occur on the project. Good planning will help practitioners avoid many problems, but not all of them; a situation might change unexpectedly or an unforeseen problem may arise. Furthermore, every project is unique. What worked well on one project may not work so well on another.

Because each project is different and because changes will occur that will need to be dealt with, the project plan will need to be tailored to the project and allowed to evolve to meet the demands of the project. By keeping the plan up-to-date project participants will be in a better position to adjust the project to changes as they occur.

Creating an Appropriate Plan

The Planning portion of a project is really about making a plan that will define and govern the work. But in doing so, project leaders will need to be sure to develop the plan to an appropriate level. Too much planning can bog down a project with too many planning activities and could cause the project team to spend too much time away from doing what the project is designed for—delivering results. But too little planning can cause confusion if the team fails to uncover enough detail to complete the work.

Whatever amount of planning the project needs, it is very important to include the people who do the work in planning the work. The people who do the work are the ones that know the most about it—they're the ones who will be able to uncover risks that others may not think of or provide more-accurate estimates for the project. And if they participate in the creation of the project plan, they are more likely to buy-into it to a greater degree.

The Project Plan

The central component of the Planning phase is the project plan. As the project team develops the project plan, they will document the actions and activities they'll need to define, prepare, integrate, and coordinate all of the project components.

The project plan should include the following items to help manage the tasks, scope, time, costs, risks, and changes for the project:

A project scope statement

The scope statement describes what is in scope and out of scope for the project—in other words, what the project will contain and what it won't contain. The project charter frames the project's scope so it should be very helpful in developing the scope statement. The scope statement, along with the work breakdown structure, serves as the scope baseline for any questions about project scope.

A work breakdown structure

The work breakdown structure (WBS) is a hierarchical breakdown of all of the work needed to complete a project. Work is broken down into smaller pieces that can then be assigned to individuals or groups for completion. A completed WBS will show all of the project deliverables included in the project and will enhance planning activities by ensuring that work is not missed.

A network diagram

A network diagram acts as the schedule for the project. It is more detailed than the milestone chart in that it shows the sequence of project activities and the dependencies among those activities. Because the network diagram will serve as the schedule baseline, it is important to make sure that all of the necessary activities are included in the diagram. Reviewing the milestone chart from the project's Initiating stage will help ensure that important activities and due dates are not missed.

Change management plans

The project plan should include thoughts on how any change requests or unexpected changes that may affect the project will be managed. Practitioners will need to decide who will compile these requests for changes to the project, how they will analyze the impact of those changes, and who is responsible for accepting or rejecting those requests.

A responsibility assignment matrix

A responsibility assignment matrix (RAM) helps to assign responsibility for project work to project participants. The RAM will ensure that the project team knows who is responsible for the completion of specific tasks as well as who needs to be informed of problems and progress.

A risk register

The team will use a risk register to track project risks, the planned responses for those risks, and the results of implementing those responses. Risk registers are important documents that must be reviewed and updated regularly to ensure that projects proceed with minimal delays and disruptions.

A budget

The budget is an aggregation of the expected costs to complete the project. Project participants will compile estimates of costs into an S-curve that will act as the cost

baseline; results can then be compared to the S-curve to ensure that the project stays within project cost boundaries.

Plans for dealing with contracts and vendors

The project leaders will need to decide if additional resources to complete project work are necessary and, if so, how those services will be procured. These leaders should also consider the types of contracts that will work best and develop a strategy for monitoring compliance.

The Major Elements of a Project Plan

The plan created for the project should match the needs of the project so it is important to not limit the project plan to only the items listed above. The project team will need to reference this plan as they execute the project so it should include as much information as necessary to adequately shape the project. If more information is needed in the plan to successfully complete the project, the team should feel free to add it to the plan.

The A3

Some project teams, especially those that follow Lean practices, choose to combine elements of the project charter and project plan into a single document called an A3. The A3 includes background information and project goals (much like the project charter) as well as proposed countermeasures and a plan to reach the goal (like the project plan). The A3 is highly adaptable and the act of gathering information about the problem at hand is as important as the document itself.

Using Tools and Techniques to Plan Your Project

Planning is where the project manager defines the important things that will need to be accomplished on the project and explains how those things will get accomplished. It takes a significant amount of effort to develop an effective strategy but giving this portion of the project extra effort upfront will help avoid the need for costly and time-consuming changes and rework later on in the project.

As the project is planned, project practitioners need to be sure to review the lessons learned from previous projects once again to see if there are things can be adapted—or if there are things that should be avoided—in the execution of the project.

Project participants will also need to consider how various elements—communications, quality, risks, procurement, human resources, and scope—all contribute to the identification of baselines for the schedule, budget, and scope of the project.

At a minimum, the project plan should include the tools discussed in the last assignment:

the scope statement the work breakdown structure the risk register the responsibility assignment matrix the network diagram budget baselines change management plans contracting and vendor management plans

In managing projects, practitioners will need to become familiar with and to utilize these tools to make planning their project easier. These tools will be explored in greater depth in the subsequent assignments of this module as we explain how they can be used to execute and monitor projects.

Planning from an Agile Perspective

The traditional approach to project management with its focus on documentation and procedures can be modified at least partially if the project manager uses a few of the "light" Agile project management techniques.

An Agile approach to project management focuses on people and interactions, rather than documents and procedures. A basic tenet of Agile is that constant interaction and communication on the team will produce a more-fluid project environment that can adapt to change more quickly than non-Agile project management practices.

The challenge of using an Agile approach to Planning, as well as in other stages of the project, is in balancing the level of detail captured in the project documents and activities. If project participants spend too much time and effort tracking minute details, they risk shifting focus away from delivering results. If not enough attention is paid to detail and project planning is insufficient, they may not have enough information available to complete work well.

Defining Scope Through the Scope Statement

A scope statement defines a project by detailing the project's major deliverables, its key objectives, and the work needed to meet those objectives. The scope statement will describe the complexity and magnitude of the project and will account for all the work, time, and cost needed to complete the project successfully. As work progresses and new issues arise, the scope statement will serve as a constant reference for future project decisions.

Scope statements may include other elements as well, as summarized in the chart below:

Other elements of a scope statement

Product scope description

The requirements of the product as described in the project charter

Acceptance criteria

The process and criteria for accepting completed products

Deliverables A list of the outputs required for project success. Deliverables may include documentation that will help the team complete the project.

Exclusions A specific statement that explains what is not included in the project

Constraints Anything that may limit the project (including budget limitations or imposed dates)

Assumptions A list of the beliefs underlying the project and their potential impact if they prove to be false

By delineating what needs to be accomplished, the scope statement—along with the work breakdown structure—will serve as the scope baseline, which will help to determine if a project is on track and continuing to meet the objectives for which it was designed. Any deviations from the accepted scope of the project—a phenomenon known as scope creep— could negatively impact the project by consuming the time and resources of the project and should be avoided.

The Work Breakdown Structure

In the Planning stage the milestones developed in the Initiating stage (which are really just large events or activities in the project) are separated into individual work components in a work breakdown structure.

The work breakdown structure (WBS) is a hierarchical chart that divides project milestones into smaller units and arranges project work activities into related areas. The WBS helps project participants get a firm grasp on what they need to deliver to meet project goals. It is essential for designing the project schedule, and it helps in creating the budget and selecting the staff for the project.

The WBS helps:

Identify the major segments of the project so that the work to do is clearly defined

Organize the work sequentially so that it can be scheduled efficiently

Identify what work to assign to which team members

Determine what resources will be required to complete the work so that the team can develop a budget

Clarify the work to do so that it can be clearly communicated to team members

Work Packages

The WBS is often shown as a tree diagram that moves from levels of generality (deliverables, stages, or subprojects) to more detail (work packages).

A work package is the most basic work activity that has both time and cost associated with it. It is a manageable (and assignable) "chunk" of work that, when combined with other work packages, represents a unique deliverable. A set of work packages might represent the handlebars on a bike, the operating system for a mobile phone, or the delivery channel for customer services.

Work packages vary in their level of detail, but they should be broken down to a level that can be easily executed, monitored, and controlled. Work packages should be small enough so that reliable estimates can be made about their cost and scheduling requirements but when teams break the work down excessively, inefficiency of management efforts and planned work can result.

The Parts of a WBS

A WBS may be broken down in a number of ways, but one of the most common forms separates the structure into subprojects, milestones, activities, and work packages.

For large projects with many layers and dollars allocated, a WBS can become quite complex; it is up to the project manager to determine how many subprojects, milestones, major activities, and work packages the WBS and project need.

Developing the WBS

The following steps can be used to create a WBS to support a project and help identify important project parameters:

1. Put the project milestones into a logical order according to when they should occur during execution. (Consulting with subject matter experts on and off the team can prove essential at this point.)

2. Break the milestones into major activities, then into work packages that can be assigned and scheduled. Define the work packages to a level of detail that is appropriate for the project. (Remember that each work package is associated with a deliverable and a time for completing that deliverable.)

3. Look at the entire work breakdown structure and make sure that completion of all of the work packages will result in the completion of all of the project goals and objectives defined in the project plan.

As a project evolves, practitioners learn things that they didn't know at the start of the project. This new information should be used to update and revise the WBS in ways that make it more accurate and robust. Keeping the WBS—and all Planning documents—current will, in turn, support the utility and functioning of the project plan.

The Risk Register

Defining Risk

To run a project effectively, practitioners need to identify the risks that could impact the project and develop plans to deal with them. In project management terms, a risk could be a negative event that adversely affects project work or a positive event that provides an opportunity that the project team should pursue to enhance project results.

Every project entails a certain amount of risk; the question is whether the people involved in the project will be able to properly identify and manage it. To be effective, project managers or project leaders will have to identify the risks, analyze their impact, prepare responses, and monitor the project to keep it on track. They will need to ensure that the project stays within acceptable risk levels. And they'll have to limit the impact of negative events while, at the same time, increasing the impact of positive events.

Risks and the Project Life Cycle

Different types of risk occur throughout the project life cycle. For example, in the Initiating stage, risks could include unclear objectives or key personnel being unavailable for the project team. In the Planning stage, risks may include vague specifications or rushed planning practices. And in the Executing and Monitoring/Controlling stages (where the greatest number of risk events typically occur), risks can range from scope creep to schedule changes to unexpected weather.

The level of risk will also fluctuate throughout a project. Early in the project the level of risk is high because the process of identifying, analyzing, and planning risk responses is just getting underway. The financial impact of risks is low because less has been invested and other options remain open.

Later in the project, during the Executing and Controlling stages, the level of risk decreases but the financial consequences increase. At this point there is substantial investment in the project so unexpected events can cause significant cost issues.

In the Closing stages, although the potential for risks is at its lowest, the financial impact is at its greatest; if, for example, a customer rejects a finished product and changes and rework are required, costs may be significant and can ruin the project.

Tracking Risks with a Risk Register

To track and monitor any risks that could affect projects, effective project managers develop risk registers.

A risk register provides the details about the risks that the project team has identified. These details include a description of the risks, the probability of the risks occurring, their impact(s) on objectives, and a risk score for each risk. The risk register also records the status of each risk and provides an area for any additional comments that may be important.

The risk register also explains how the team will respond to risks if they occur and documents who is responsible for tracking and communicating each risk's current status, as needed. If no one is responsible for handling certain risks, project leaders shouldn't be surprised when those risks interfere with project progress.

Many project practitioners develop risk registers as an Excel spreadsheet while others invest in databases or other software programs that match the size and complexity of the project. No matter what tools are used, the risk register will help ensure that project risks are continuously identified and appropriately managed.

Developing the Risk Register

Risk ID Number Risk Probability Impact Risk Score Response Responsibility Status Comments 1 2 3 4

1. Risk ID Number: Provide an identification number for each risk. This will allow participants to discuss each risk by its number, making conversations easier.

2. Risk: Describe the risk in clear, simple language. Classify the risk as either a positive or negative event.

3. Probability: Record the probability of the event occurring (as "high," "medium," "low," or any combination of these ratings). You will need to work with your team (and possibly other important stakeholders) to define what each rating ("high," "medium-high," "medium," etc.) means.

4. Impact: Record the impact (as "high," "medium," "low," or any combination of these ratings) to the project if the risk occurs. Again, you will need to work with your team (and stakeholders) to define what each rating means.

5. Risk Score: Combine the probability and impact into a risk score. The risk score will give you a simple way to prioritize risks and show which ones need to be carefully monitored.

6. Response: Describe the response you'll implement if the risk occurs. Include as much information as necessary to illustrate your plans.

7. Responsibility: Clearly identify the person responsible for monitoring and addressing the risk should it occur.

8. Status: Record the status of risks as either open (they could still potentially occur) or closed (the risk has been addressed or the chance that the risk will occur has passed).

9. Comments: Record any important information about the risk that doesn't fit into the other columns of the register.

The Risk Register as a Tool

The project manager will need to review and update the project risk register regularly. As changes occur on the project and new information is learned, risks may need to be added— and removed— from the register.

The project team should also refer to the risk register for important information at the conclusion of the project. During the project's Closing stage, reviewing the risk register will help in recording the lessons learned for the project. The register will help remind project participants about the issues that they had to address on the project, helping them and other members of the organization better manage risk on future projects.

The Responsibility Assignment Matrix

After creating the WBS and identifying the project's work elements, it's now time to begin assigning work to individuals. A simple, pragmatic way to track the work assigned is to use a responsibility assignment matrix (RAM). The RAM is a table or grid that connects the human resources on the project to the work on the project. In other words, it connects the people on the project with the "stuff" that needs to be done.

RAMs can be created at high levels (mapping entire units to groups of work packages) or lower levels (mapping an individual's level of responsibility to each work package).

The RAM assigns the responsibility for the completion of work elements to one—and only one—individual. It allocates work in a way such that each individual knows that he or she is responsible for completing that work element.(Several people may be accountable for getting the work done but only one person is held responsible for ensuring that it is done.)

The matrix helps interested parties easily view information in two directions. It makes it easy to see what roles each person will play on a project (by looking at a specific column in the chart) as well as everyone involved in a specific part of the work (by examining the rows of the chart).

A common form of the RAM is the RACI chart. The RACI chart quickly shows who is responsible for an activity, who is accountable for it, who should be consulted about it, and who should be kept informed about it. RACI charts are especially helpful to ensure that roles and expectations are clearly defined when project staff in different units or organizations share work packages.

Ensuring that assigned work is properly communicated to the project team will help practitioners avoid two potentially hazardous risks. The first risk is that multiple individuals will end up working on the same task, thereby duplicating effort and increasing the chances of conflict on the team. The second risk is the opposite of the first—that nobody will be working on a particular task or work element. The RAM prevents these types of problems by ensuring that work assignments are evenly distributed and that all work activities are accounted for.

Geno Ann Mark Jean

Conception R A I C

Finalize A R I C

Test I A R C

Sell Internally C I A R

R = responsible, A = accountable, C = consult, I = inform

The Network Diagram

The baselines established during Planning are critical to help measure progress and monitor changes throughout the project life cycle.

One of the first and most important baselines created is the project schedule. To create an effective project schedule, practitioners will have to:

Identify the activities that will help them meet project objectives Sequence those activities Estimate how long it will take to do those activities Decide which activities they'll have to monitor carefully to ensure that they finish the project on time

To create a schedule that will guide the team in executing project work, participants will use a tool called a network diagram. The network diagram is a simple graphic that shows the logical relationships among project activities. Using a simple graphic like this diagram to illustrate these often complex relationships will allow everyone to quickly see the schedule's complexity in a way that project participants can easily understand.

Completing these steps will ensure that the project schedule accounts for all project work and provides helpful information to project participants.

Identifying Activities

Identifying all of the activities that will have to be completed to meet project objectives allows participants to more accurately estimate the project's schedule (and, subsequently, its cost).

The team can begin to identify these activities by looking at the work packages at the lowest level of the work breakdown structure that was already created. (If these work packages are too big to estimate accurately, they can be divided into smaller work units, then those smaller units can be used in the schedule.) The individuals identifying these activities should ask stakeholders and other team members to suggest activities that they might be unaware of or may have overlooked.

The milestone chart created in the Initiating stage should also be reviewed to ensure that all important project dates are included in the schedule. Reviewing the milestone chart

will remind the team of any dates that have been imposed on the project (by contract or by the organization authorizing the work) and ensure that these dates are planned and accounted for.

Sequencing Activities

A network diagram shows each activity's predecessors (those activities that must be completed before the activity) as well as any successor activities (those activities that will follow the activity) for all of the activities in the project.

To begin, place the first activity in the project on the far left of a large work surface. Place any activities that can be completed at the same time above or below this first activity.

Next, place all subsequent activities to the right of this first activity (or activities) in a sequence that shows progress toward the project goal. Again, place any activities that can be completed concurrently above or below these predecessor activities.

Finally, draw arrows between the activities to show any dependencies or relationships among them.

Estimating Activities

Once the sequencing of project activities is finished, an estimate of how long each activity will take should be developed. The duration estimates for each of these activities will, of course, depend on several factors—the availability of resources, the knowledge and skills of participants, etc.—so it's best to ask key stakeholders and project team members to help decide how complex and time-consuming activities may be. Including these project participants in this estimating process will help in creating more-accurate estimates and increase buy-in to the project.

Teams may also be able to look at records from similar projects that their organization has completed, to accurately estimate the activity durations. And in some industries, they might even be able to access informational databases that describe how long typical activities will take. Whatever method is chosen, be sure that the estimates are realistic and that they are agreed upon by the parties involved.

If there is a feeling that the activity estimates might not be completely accurate or if there are significant risks that may adversely affect the project schedule, the team can add reserves or buffers to account for uncertainty and increase the chance that the project will meet the projected completion date. This additional time can be added to individual activities or work packages, or a more-general buffer reserve for the entire project can be created to use at the team's (or project manager's) discretion.

Developing the Schedule

After the activities have been sequenced and an estimate of how long each will take has been made, the team will be able to calculate the expected start and end dates for each activity and for the project as a whole. They should also start to see the critical path of activities that they'll need to monitor closely to ensure that the project stays on schedule.

The critical path for the project is the path through the network diagram that has no flexibility in the time allotted for path activities—any delay in completing the activities on this path will likely delay subsequent activities and the project's completion date.

To understand how the critical path works, a forward pass and a backward pass through the diagram will have to be made.

The forward pass uses the duration estimates for activities on the path to calculate the early start dates and early finish dates for each activity. The forward pass tracks the activities from the beginning of the project to its end.

The backward pass helps to calculate the late start dates and late finish dates for path activities. The backward pass tracks activities from the end of the project back to its beginning.

Developing the Schedule: The Forward Pass

To complete a forward pass, start at the far left of the diagram and calculate the early start dates (ES) and early finish dates (EF) for each activity in the project. The early start date for an activity is the earliest date that an activity can start, based on the completion of any predecessor activities. For example, if Activity B can't begin until Activity A (which takes eight days to complete) is finished, the early start date for Activity B is day eight. (If an activity has two predecessor activities, the earliest that the activity can start is the latest finish date of all of the predecessors. So if Activity C (which is finished on day five) and Activity D (which is finished on day nine) must be done before Activity E can begin, the early start date for Activity E is day nine because it is the larger of the two finish dates for the preceding activities.)

The early finish date (EF) for an activity is the early start date plus the amount of time that the activity will take. So if the early start date for an activity is day 12 and the activity takes six days to complete, the early finish date is day 18.

Developing the Schedule: The Backward Pass

To calculate the backward pass, start at the end of the project and calculate the late finish dates and late start dates for each project activity. The late finish date (LF) for an activity is the latest that the activity can finish without delaying the project. The late finish date is based on the completion of any successor activities. The late finish date for an activity is equal to the smallest late start date (LS) of any connected succeeding task. So if the successor activities for Activity M are Activity N (which has day 22 as its late start date) and Activity O (which has day 20 as its late start date), the late finish date for Activity M is day 20 because it is the smaller of the two late start dates.

The late start date (LS) is the latest an activity can start without delaying the project. It's equal to the late finish date for the task minus the amount of time it takes to complete the activity.

The flexibility in the project schedule (and therefore its critical path) is determined by comparing the start and finish dates for the project's activities. For example, if an activity's ES is day nine and its LS is day 12, then there are three days of flexibility associated with the activity; the activity can start up to three days late and still not affect the project's expected completion date. If, however, the ES and LS both show the same date, then there is no flexibility associated with the completion of the task and any delay in completing the activity will likely delay the project end date.

Remember that, on the critical path, none of the activities on the path have flexibility in their completion—the ES and LS dates are equal for all of the activities on the path so a delay in any activity on the critical path will likely delay the whole path and cause the project to miss its planned completion date.

It is important to note that a project may have more than one critical path. It's also possible for a project's critical path to change if an activity is delayed so much that it uses up any flexibility associated with the task.

Monitoring the Schedule

As a project is planned and scheduled, participants may find that the network diagram shows that they won't be able to meet a milestone or other imposed project date. In such cases, the schedule will need to be adjusted to ensure that the imposed dates will be met.

One adjustment that can be made is to schedule activities that are done in a sequence to be done in parallel. Another adjustment could be to add additional resources to activities to shorten the amount of time it will take to finish them. Practitioners should be aware, however, that either of these responses may increase the risk associated with the project and cause significant problems. If the team decides to use either of these responses to adapt their schedule, they must be sure to use them sparingly and closely monitor them to ensure that any problems that they might cause can be quickly resolved.

Teams can use the network diagram as a reference to ensure that the project will continue to meet its expected schedule. They can use the diagram to compare actual results to plans, see when corrections are needed, and keep stakeholders informed about changes to the project timeline. As such, they'll need to review the diagram regularly and keep it updated to ensure that activities are completed as expected and the project continues as planned.

The Cost Baseline

The cost baseline is another important document that will need to be created early in the project. The cost baseline is the budget that will be used to measure, monitor, and control the project's overall cost.

To create an effective cost baseline, practitioners will need to estimate the costs for each project activity and then add those costs together to create the project's budget. This budget can then be used as a reference for project costs; as changes occur on the project, the cost baseline (along with the schedule and scope baselines) can be assessed to determine what impact the change may have.

Estimating Costs

To estimate the cost of the project, team members will have to take into account all of the costs that will be incurred to produce the project's deliverables.

They'll need to include labor and services, materials, information technology, facilities, and equipment. They'll need to plan for uncertainties such as inflation or other unforeseen events, and they may want to add a buffer to account for the costs associated with the risks that can't be planned for. They may need to consider the costs incurred while maintaining and supporting the project result after it is finished, if their organization considers these costs to be part of the project. And they'll have to decide if the project's indirect costs—such as overhead or costs that can't be directly ascribed to this particular project—will be included in their project's costs or if those costs will be accounted for at a higher level in the organization.

As the team develops the cost estimates, they will need to review any existing documentation to uncover information that will help them estimate more effectively. For example, they can review the milestone chart and network diagram to see if these documents include a due date that will require higher-than-usual labor or other costs to

meet. They can look at the scope statement and work breakdown structure to ensure that estimates include costs for all of the activities they've planned for the project. And they can consult records from previous projects and lessons learned to expose costs that they may have overlooked.

Finally, they may want to record how confident they are that their estimates are accurate, by describing the confidence level for the estimated cost and the range of possibility for actual cost. For instance, they might estimate the cost for a project phase as $7,000, with a confidence level of 89% that the price will not vary more than $1,000 on each end.

Creating the Cost Baseline

Once cost estimates for the individual activities in the project have been completed, practitioners will need to aggregate those estimates into a cost baseline.

The cost baseline is a graphic form of the budget that will help the team compare actual expenses to planned expenses. Any differences seen between actual and planned expenses should alert team members to potential problems and help them decide whether action will need to be taken to get the project back on track.

The cost baseline stipulates the amount of money that should be spent at every point in time in the project's life cycle. The cost baseline is usually shown as an S-curve, with time on the x-axis and cumulative costs on the y-axis.

The cost baseline shows the summation of all of the costs incurred during the course of the project, so it will always rise over time. Typically, costs are low at the beginning of the project and increase rapidly during execution as work is carried out. Costs then level off as the project nears completion and work slows. The planned project costs are graphed first; as actual results are achieved, they can be added as new lines on the graph for a quick comparison.

As the team uses the S-curve to compare project execution to planned performance, trends will start to appear. These trends will be very helpful in determining if and when action will be need to be taken to prevent the project from going out of control.

In the cost baseline example shown here, the actual expenditure for the project is represented by a line underneath and to the right of the baseline at almost every point except for the end of the project. This suggests that for this project, the expenditures were

below the cost baseline at every point, until the project's end, at which time the actual expenditures appear to have caught up to the planned project expenditures represented in the baseline.

Cost Baselines and Earned Value

The cost baseline is actually an integrated reference; it allows participants to measure actual costs against expected costs but it also allows a comparison of schedule and scope progress as well.

To use the baseline this way, practitioners will need to employ a technique called earned value management (EVM).

EVM allows people to objectively measure performance against progress as a project unfolds.

Performance is measured by comparing the earned value (the work that got done) to the planned value (the work that was expected to get done) and by comparing earned value to the actual cost (how much was spent to get the work done).

The next assignment will cover earned value in greater detail.

Analyzing Cost Performance

The cost baseline helps teams review the project performance, identify trends, and analyze variances on the project.

If a project is off track, practitioners have four options: ignore the variance, take corrective action to remedy the variance, revise the plan to incorporate the variance, or cancel the project.

Regardless of the response chosen, it is the project leader's responsibility (with help from the project team) to identify the causes of variances, assess the magnitude of a variance, and make sure responses to variances are understood, communicated, and carried out.

Term Definition

Planned value (PV)

The cost baseline or S-curve that you created. This is how much you planned to spend to get a specific amount of work done.

Earned value (EV)

The value of work performed. This is how much work you got done for the amount of money you spent.

Actual cost (AC)

The total cost actually incurred in accomplishing work performed. This is how much you've actually spent to get work done.

Earned Value Management

As mentioned in the previous assignment, earned value management (EVM) allows practitioners to objectively measure performance against progress as a project unfolds.

Performance is measured by comparing the earned value (the work that got done) to the planned value (the work that was expected to get done) and by comparing earned value to the actual cost (how much was spent to get the work done).

Planned value (PV), earned value (EV), and actual cost (AC) are used to assess whether work is being performed over time as planned. All three concepts—EV, PV, and AC—are generally recorded in dollar amounts, to make comparisons and calculations consistent.

These concepts can be confusing at first, but common sense will tell you that if you planned for a certain amount of work (planned value) by the third week of a project, and the actual work done (earned value) is closer to the amount that should have been completed by the second week, the project is falling behind schedule. Similarly, if you expected to get a certain amount of work done for a specific cost (earned value) but it cost more than you planned to get that amount done (actual cost), the project is over budget.

A simple way to determine if a project is meeting its schedule is to calculate the schedule variance. The schedule variance is calculated by subtracting the planned value at a specific point in time from the earned value at that same time point. If the result of the calculation is a positive number, the project is running ahead of schedule; if the result is a negative number, the project is running behind the plan.

Similarly, practitioners can determine whether the project is under or over budget by calculating the cost variance. Cost variance is calculated by subtracting the actual cost from the earned value. Again, if the calculation result is a positive number, the project is under budget at that point in time; if the result is a negative number, your project is over budget.

These concepts are illustrated in the example below.

According to the graph above, this project is three and a half months along and is expected to take six months. The planned value line shows the aggregation of expected activity costs at every stage of the project. It is expected to cost $20,000 at the 3.5-month mark, and its budget at completion is expected to be $39,000.

The earned value line indicates that the value of the work performed up until the 3.5-month is valued at $25,000. This means that the project has produced $25,000 worth of the total project work packages planned for and represented by the planned value line.

Earned Value - Planned Value = Schedule Variance $25,000 - $20,000 = $5,000

Because earned value can only be aggregated with respect to the planned value of the work packages, schedule variance can also be calculated by comparing the work packages that have been completed to the work packages that were expected to be completed at that point in time. The project, as of the data date, has completed about 125 work packages, and it was supposed to complete about 100 by this time.

Earned Value - Planned Value = Schedule Variance 125 work packages - 100 work packages = 25 work packages

Schedule variance is most helpful when you calculate it for the critical path because the critical path contains the work packages that must be completed on time in order for the project to be delivered on time. For this exercise, we will stipulate that the data above represents the data for the critical path.

Schedule variance should not be confused with cost variance, even though both variances are quantified in dollars.

The actual cost of the work performed to date is illustrated by the graph. According to the graph, the work performed as of the 3.5-month mark has cost $32,000 instead of its expected earned value of $25,000.

Earned Value - Actual Cost = Cost Variance $25,000 - $32,000 = -$7000

Project practitioners are often asked how close the project is to being done. An easy metric to use to provide this information is the project's percentage of completion. By dividing the earned value up to that point in time by the planned value at the completion of the project you'll be able to calculate what percent of the project is complete.

Change Management

Very few projects—even the simplest and smallest ones—are completed without having a request for change in some form. Circumstances shift, prices fluctuate, and risks develop that could not be predicted. Processes may need to be adjusted because they are not working as planned. And a stakeholder may request a change to any part of a project at any time. Changes will happen—they can't be avoided—so it is very important to set up an effective process to help deal with change and ensure that it doesn't delay or derail the project.

How people manage change will depend on how they view change. The project team and performing organization may view change (as many traditional project management organizations do) as something that needs to be avoided and, if possible, eliminated. People in an Agile organization may embrace change as a way to ensure that project results reflect the latest customer needs. Or people may view change management as a process that needs to be streamlined and optimized as much as possible, as Lean practitioners do. In whatever way they view change, project participants will need to think about how they'll analyze any changes and their impacts on the project as well as how they'll implement or reject change requests.

The Change Request Form

An effective way to track and monitor changes and change requests is to develop a change request form. This form will allow the project team to document requests for project changes and to monitor the results of those requests. It will serve as a record that they can refer to in retrospect to help to develop lessons learned and to understand why a project's final result may differ from initial plans.

Even though the project is currently ahead of schedule ($5000 or by 25 work packages), its actual cost overruns the earned value of the work completed by $7000.

Project Title

Record the project title and date of the request. This will be help in archiving and referencing the document in lessons learned meetings.

Date

Change Request

Describe the requested change in detail. Include information as to why the change is needed as well as any information on which portions of the project (scope, budget, schedule, quality, etc.) the change may affect. Consider adding a unique identification code or number that can be used to quickly reference the change in discussions.

Requesting Party

Record the name of the person (or persons) requesting the change. Consider including contact information for this person and his/her role on the project.

Impact Explain any potential impacts that the change may have on the project. Consider the effect on the project's scope, schedule, budget, quality, risk, processes, and product characteristics.

Status Classify the change request as "open/in process," "approved," "rejected," or "escalated" (to a higher level). If the request is rejected or escalated, state the reasoning behind the decision.

Approval Signature

Have the request signed by the person responsible for accepting or rejecting the request.

Managing and Monitoring Change

Once the change request form has been developed, the project manager and project team will need to decide who will own the change management process and who has the authority to accept or reject the request. The project manager may have some power to make changes (as per the project charter or instructions from senior management) but some changes— especially those that drastically affect project parameters or objectives—may need to be approved by someone with higher authority. Project leaders and executives may even choose to create a change control board of key team members and project participants to analyze and authorize project changes. This change-control group should include people who have a working knowledge of the project and its intended objectives, as well as an understanding of the project's place in furthering organizational goals. They should have the power to get things done and the responsibility to ensure that the changes will be properly implemented. Their approval of a change request will likely depend on factors such as the cost of the change, the effect that the change may have on the project schedule, or specific requirements listed in a contract. If the change will significantly disrupt the project or does not align with strategic goals, they may decide to deny the change request.

The change control process that is developed can be very informal but practitioners should still establish policies in the Planning stage to deal with any mid-project changes, even if those policies are simple guidelines. All change requests should be funneled through some sort of monitoring and management process to ensure that they are analyzed properly and implemented only if they fall within the project parameters. Changes must be coordinated and controlled to prevent them from disrupting project work and compromising the project.

Contract and Vendor Management

As a project is planned, practitioners may find that they'll have to acquire or purchase supplies and resources from outside sources to complete some of the project activities.

There are several steps that they'll need to take to manage this process effectively:

Deciding what they'll need to acquire Selecting the appropriate vendor for the resources they'll need Negotiating and signing a contract to acquire those resources Managing contract and vendor compliance

Because these decisions can have legal and accounting implications, it is very important to consider them carefully and address them appropriately to ensure that the project is successful.

Deciding What Will Need to Be Acquired

To help decide what resources will be needed on the project, take a quick look at the project's scope, schedule, and cost baselines. A quick review of these documents should show what activities need to be performed, when those activities need to be completed, and how much money is needed to complete the needed work. Then decide if there are resources in-house to complete the work or if there is budget available to acquire outside help.

If resources or services from outside sources need to be procured, put some thought into this process to ensure that it goes as quickly and smoothly as possible. Make sure that any directions sent to vendors contain enough information to allow them to correctly bid on the project without limiting their input on the best way to meet project requirements. Consider the time and effort that managing an outside relationship will take and adjust plans as needed. And commit to an ongoing relationship with the vendor to ensure that both parties benefit from project results.

As with all of the other processes used to run projects, tailor this process as necessary to suit project needs and meet organizational requirements.

Selecting Vendors

Project managers will need to think about what criteria they will use to choose the sources they'll procure from. Managers may find that their organization has a list of previous vendors or "prequalified" suppliers to work with, making this effort easier to undertake and manage.

If, however, the organization does not have this type of list, the project manager will have to talk to key stakeholders and project team members to develop some selection criteria. He or she may decide to choose a vendor based on price alone or may consider other factors (like the ones below) before a decision is made:

How well the vendor understands the project needs How well the vendor matches the size and type of business the team would like to work with How well the vendor will be able to meet the technical needs of the project How well the vendor will be able to manage its part of the project How well the vendor has performed on previous contracts with the organization How satisfied the vendor's previous customers were with the work produced Who assumes the risk (and associated costs) for the vendor's portion of the work

Carefully choosing and explaining the project's selection criteria will ensure that the selection process is as open and fair as possible and should curtail assumptions and misunderstanding as to why a specific vendor was chosen.

Selecting and Negotiating the Contract

In many cases project practitioners may need to draw up and sign a contract with outside sources to ensure that work is completed as needed.

Because contracts are formal documents with legal ramifications, it is in the team members' best interest to be well-versed in their creation and use:

They will need to think about how the contracts to be used will be prepared They will need to agree with suppliers and vendors on a contract that meets both parties needs They will need to monitor contract performance throughout its existence They will need to be sure that they close the contract appropriately

Contract Types

Most contracts can be classified into two basic types—fixed-price contracts and cost- reimbursable contracts—with a third option, time and material contracts, that represents a hybrid of the other two. Greater detail on these contracts types, as well as tips for negotiating vendor contracts, will be discussed in future assignments in this course.

Managing Vendors

Once an agreement is entered into with a vendor, the project leader must handle this relationship carefully. At its core, vendor management is about working with a partner- organization to reach a deal that benefits both parties.

To encourage a beneficial relationship, leaders may have to work with vendors to help them understand project operations. Project managers might have to explain project basics, discuss how vendors will affect and be affected by the work, and clarify how they are expected to interact with project practitioners. Vendors should be encouraged to ask questions if any parts of the project are unclear, and they should be invited to specific meetings to help them better understand and interact with teams.

The project manager will also have to monitor vendor work to ensure that it complies with project needs and objectives. Managers will have to consider the vendor's performance on the scope, quality, schedule, and cost issues included in the contract. Any claims or disputes that occur will need to be tracked and a record of all issues should be kept in case legal action is necessary. The team should also document how easy (or difficult) the vendor was to work with and how well they met the requirements set forth in the contract. By tracking and documenting this information, a record (that can be accessed by anyone considering this vendor for future contract work) will be created and valuable input for future contracting decisions will be provided.

Project Scope Management

What is Project Scope Management?

Project scope management focuses on defining and controlling what is and is not included in the project. It encompasses all the processes needed to ensure that the project includes all the work required, but only the work required, to complete the project successfully.

The term scope can refer to product scope or project scope. Product scope defines the features and functions that characterize a product, service, or result. In contrast, project scope identifies the work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.

Preventing Scope Creep

When project practitioners focus on project scope, they need to ensure that all the work gets done to complete the project. However, they also need to ensure that extra work is not added to the project unexpectedly. Change is inevitable in most projects so managing project scope and preventing unnecessary scope expansion can be particularly challenging.

Even when a project seems well defined and well managed, it may encounter scope creep. Scope creep is the growth or change of project requirements. One way to manage scope creep is to validate the scope of the project throughout its life cycle.

Validating scope for a project and minimizing scope changes can be difficult. Scope validation activities are especially important in projects because they help the project team determine whether the project is on track or is expanding beyond its original charter.

Tools for Scope Control

Project practitioners can use various tools to control project scope:

A Formal Change Control System

A change control system is a formal, documented process that describes when and how official project documents may be changed.

Configuration Management

Configuration management ensures that the descriptions of the project's products are correct and complete. Changes to the characteristics of a project must be recorded and reported as a part of configuration management.

Replanning

Replanning the project scope may be required, if the approved changes significantly alter the originally planned project.

Variance Analysis

When conducting variance analysis, project performance measurements are compared with the scope baseline. The project manager is interested in understanding the cause of the variance between the actual project and the baseline. The variance and its cause will help to determine whether corrective action is needed.

The Importance of Effective Scope Management

Taking the time to define a project's scope is an important contributor to project success. Effective project scope planning provides several benefits for any project, such as:

Improving the accuracy of time, cost, and resource estimates Providing a baseline for performance measurement and project control Helping to communicate clear work responsibilities Confirming a common understanding of the project scope across all stakeholder groups

Failure to effectively plan scope management practices for a project can cause countless issues and can result in lost time, money, and effort as project practitioners struggle with project objectives that are moving targets. The waste associated with executing unneeded or unnecessary project activities can slow productivity, frustrating the project team to the point that it can seriously damage team morale.

Setting Project Boundaries With the Scope Statement

To properly define a project's scope, the project team will need to create an effective scope statement. The scope statement establishes the boundaries that the work must be performed within, encompassing all the work, time, and cost needed to complete the project successfully.

Stakeholders and team members alike must understand the scope of a project so they can carry out their roles appropriately. The project scope acts as a crucial baseline measurement —by delineating what needs to be accomplished, the scope statement provides a reference point that the team can use to measure their ability to meet project expectations. All work performed by the team or work change requests submitted by stakeholders is measured against the initial scope of the project to ensure that the project remains on track. The project team will use the scope statement as a guide as they execute project activities, to ensure that the project continues along the path set forth at the beginning of the project.

An effective scope statement will describe the project and product scope in enough detail so practitioners can measure project progress against expectations. These descriptions may be updated and refined as the project continues and more information is gathered or disclosed.

To draft a comprehensive scope statement, project practitioners need to consider the following components:

A description of the product's characteristics or what it is designed to do (which may include product increments or interim deliverables produced during the project) Criteria that must be met before stakeholders will accept the deliverables Specific details about what will not be contained in the project Assumptions made about the project or conditions that exist or are expected to exist during the project Any constraints, rules, regulations, or other factors that may limit work during the project

Scope statements, like other aspects of a project, may be as formal, complex, or extensive as needed, based on the size and complexity of the project. Some projects may be able to use simple, uncomplicated scope statements like the following:

"Corius Corporation will develop a new mobile application for use in tablets and laptops. The app will allow Corius customers to access their accounts from remote locations but will not allow new customers to sign up for Corius' service. The app will be available to the market in six weeks and project costs will not exceed $12,000. Development will be based on existing Corius IP; no outside resources will be used in development."

Other projects will require more-detailed, multi-paged descriptions like the ones listed below:

Scope Statement for The North Carolina Department of the State Treasurer Debt Management Project Scope Statement for the Forests and Rangelands Fire Program Analysis

Collecting Requirements and Defining Scope

A project's scope will ultimately be based on the needs and requirements of its stakeholders. To guarantee that the project will be viewed as a success, the project team will have to gather and prioritize these requirements to ensure that the scope of the project encompasses all of these needs and that the project will meet the most important stakeholders' requirements to their satisfaction.

Collecting requirements may include activities such as:

Conducting interviews, focus groups, or facilitated workshops with select groups of stakeholders Providing questionnaires and surveys that uncover expectations and help refine requirements Executing benchmarking comparisons or developing context diagrams that help in eliciting and understanding requirements Developing prototypes and observing customers interacting with products (or product increments) to uncover unspoken (or even unknown) requirements Analyzing documentation and reviewing lessons learned from previous projects to expose pitfalls or missing requirements from previous work

Interviews, Focus Groups, and Facilitated Workshops

Interviews, focus groups, and facilitated workshops are similar techniques but do have their differences.

While an interview can be a formal or informal question-and-answer session, focus groups provide a more conversational format for culling the opinions of multiple stakeholders. And while interviews may be more useful to uncover sensitive or confidential information that participants are unlikely to share in a group setting, focus groups are usually more interactive than interviews and can bring together prequalified subject experts or stakeholders to brainstorm or discuss their expectations about a project.

Facilitated workshops resemble focus groups in that they are very useful for bringing together a group of cross-functional stakeholders who may have differing expectations for project deliverables. However, facilitated workshops tend to be more interactive and conversational than focus groups, so ample time must be provided for all stakeholders to communicate their expectations and concerns. And because representatives are present across functions, potential problems with the project can be identified and resolved in less time than through individual interviews or smaller focus groups. The group might also benefit from a morale boost as bonds of trust are formed across functional groups.

Refining Requirements

Once requirements are discovered and prioritized, the project management team needs to ensure that they are measurable, testable, traceable, complete, consistent, and that stakeholders will be satisfied with them. If requirements aren't collected in enough detail, it will be hard to set objectives that will ultimately satisfy stakeholders.

The requirements can then be included in project baselines so that they can be used in other processes in the project to measure progress and compliance.

Documenting and Tracking Requirements

Once requirements have been uncovered in adequate detail, they should then be compiled into requirements documentation.

Requirements documentation describes, in clear terms, the way in which project requirements meet the need for the project set out in the project charter. These documents may be very detailed, or they may be a simple summary that refers to other related documents that discuss the requirements in more detail.

One of the most helpful requirements documents that a team can create is a requirements traceability matrix, to ensure that each requirement identified for the project can be traced back to a business objective or need that must be met. The requirements matrix created should contain as much detail as necessary to make it easy to link features in project results back to their origin, to show that project deliverables satisfy the needs of the project.

Project Time Management

One of the key responsibilities for any project leader is implementing the processes needed to complete a project on time.

Project time management is one of the biggest challenges for project leaders and project managers. In fact, many project managers indicate that coordinating work in order to deliver projects on time is one of the primary causes of conflict for their teams.

Why is it Challenging to Deliver Projects On-Time?

As observers assess a project, one of the easiest things to measure is the time that the project takes, so schedule problems tend to be easy to spot. Any minor deviation from the schedule will be easily seen by many, adding stress and pressure for the project team to show visible progress and to keep the project exactly on track. This added stress can lead to mistakes, which only compounds any scheduling problems that already exist. Time is also the variable in a project that has the least amount of flexibility, which can amplify scheduling problems.

Other factors that may contribute to schedule conflicts are individual work styles and cultural differences. For example, if the project team is located in several different countries, the different regional attitudes towards time and work can cause problems for the project schedule.

The Importance of Realistic Schedule Goals

One way that project practitioners can help to keep projects on schedule is to develop realistic schedule goals:

1. First, examine the schedule information in the project charter and the milestone chart from the Initiating stage. These can be good starting points to identify high-level expectations around the schedule.

2. Next, develop a more-detailed schedule. Be sure to involve the people who will do the work to help plan the work.

3. Finally, obtain the approval of the project stakeholders.

Various pressures may lead the project team to use unrealistic schedule estimates. For example, top management may pressure the project manager to set an accelerated project schedule so that a new product can be launched at an important trade show.

Project participants can avoid unrealistic schedules by incorporating buffers or additional resources into the project schedule. For example, a good practice is to schedule resources in such a way that no single resource is utilized more than 75 percent of the time.

In addition, project practitioners should remember to incorporate company holidays, vacation time, and sick time into the schedule—these "off days" can dramatically affect schedules if they are not taken into account during the creation of the schedule.

The Importance of Disciplined Schedule Enforcement

Once the project team has created a schedule with realistic goals and estimates, it is equally important to ensure that the schedule will be met by the team. Disciplined enforcement of milestones is critical. Setting firm dates for key deliverables can help to minimize project changes. It is especially important to avoid poor instructions and bad communication—both are clear sources of confusion and uncertainty and often result in unnecessary obstacles that slow the progress of a project.

When communicating about deadlines and milestones, specificity is critical. For example, a deliverable may be due on April 1. However, what time of day is it due? Does beginning of day mean before 9 AM? Does end of day mean by 5 PM, or is delivery at 11:59 PM acceptable? Also, if a team is geographically dispersed, project participants should clarify the time zone the delivery time is expressed in. It should not be assumed that everyone has the same assumptions about what a delivery date means. By offering specifics related to the schedule, participants will create a shared understanding across the team about what needs to be done and by when.

Team members usually do not like to admit that they are falling behind schedule. As a result, project leaders and project managers must be proactive in seeking out information from team members—especially when there appears to be a problem.

Working With Network Diagrams

To formally construct a network diagram, graphically map each activity in sequence. Show the activity's early start date (ES) and early finish date (EF) on top of the activity box and the late start date (LS) and late finish date (LF) on the bottom of the activity box.

Early dates are calculated using a forward pass calculation Late dates are calculated using a backward pass calculation

These two methods can be used to create a baseline schedule.

Forward Pass

The forward pass calculation answers the question, "What is the earliest that an activity may start or finish?" It can be seen as the best-case scenario.

Begin by setting the project start date, starting with the first activity on day one of the project. Then go through the schedule from the beginning of the job until the end of the job. Consider each activity in its logical sequence.

The early start is the earliest an activity can start, based on the completion of the preceding activities. The early finish is the earliest time an activity can finish, assuming it starts on time and takes no longer than planned.

All prior activities have to be finished before the following activity can start. Therefore the early start date of the following activity is equal to the early start date of the prior activity plus the time it takes to complete the activity. When a following activity is connected to more than one prior activity (i.e., arrows from two prior activities are converging onto one following activity), the early start date of the following activity will be the largest of the finish dates from the prior activities.

When the last activity in the schedule has been reached, with each early start and finish date set, it is possible to answer the question, "What is the earliest that this project can be completed?"

Formulas for the forward pass calculations are as follows:

Early Start (ES) = Previous activity's EF + 1 + Lag (if any)

Early Finish (EF) = (Early Start + Duration of activity) – 1

Backward Pass

The backward pass calculation answers the question, "What is the latest that an activity may start or finish without delaying the project?"

First, set the late finish date of the last activity in the project. Then work your way through the schedule from the end of the project to the start. Address each activity in its logical date sequence. When multiple activities converge into one node in a backward pass, the smallest of the late start dates from the activities becomes the late finish date in the node.

Upon reaching the first activity in the schedule, you will know the latest that each activity should finish. While the late start date is the latest an activity can start without delaying the project, the late finish date is the latest an activity can finish without delaying the project.

Formulas for the backward pass calculations are as follows:

Late Finish (LF) = Successor's LS – 1 – Lag (if any)

Late Start (LS) = (LF – Duration of activity) + 1

After you have built the schedule and identified the critical path and the end date, you will determine if it aligns with the customer's due date. If it exceeds their date (which is often the case) you will have to do some additional planning—running activities in parallel or adding resources to finish activities earlier—to align with their expectations.

On the critical path, LS - ES = LF - EF = zero. (Note: if this does not occur for any of the project paths, the path with the smallest difference should be considered the critical path.)

Schedule Compression

After creating a schedule network diagram, project practitioners sometimes find that the end date specified by the diagram does not align with an imposed time constraint or completion date set for the project. But, after bringing this discrepancy to the attention of key stakeholders or project partners, they may be told that the project must be completed by the imposed due dates—and to further complicate matters, it must be done without compromising or changing the project scope in any way.

To meet these requests, there are two commonly used compression techniques that can be used to shorten the project's duration without affecting its scope. These techniques—fast tracking and crashing—are described below:

Fast tracking

Fast tracking allows project activities that would normally be done in sequence to be run simultaneously instead. By performing these activities in parallel instead of in sequence, the project team can shorten the time needed to complete the project.

Examples of fast tracking include:

using a prototype to begin testing for quality control problems instead of waiting for the final product to be completed ordering the material that a construction crew expects to need before a new building's design is finished

To implement fast tracking correctly, practitioners will need to look at the dependencies among activities and determine which ones can be overlapped; in some cases (where one activity must be completed before a second activity can start), fast tracking is not possible and cannot be employed.

It is important to note that fast tracking a project's schedule may increase the risks associated with the project and could result in rework if the overlapping activities generate outputs that do not integrate or align with each other.

Crashing

Crashing can be used to shorten a project's duration by adding resources to help complete important project activities. Additional personnel, equipment, or other components can be introduced into a project to focus on specific activities and ensure that they are completed sooner than originally planned.

Examples of crashing a project schedule include:

paying for the expedited delivery of supplies or other materials needed for a project increasing overtime for project employees or subcontracting to add resources to the project

These added resources almost always result in increased costs so practitioners will need to consider how crashing can be implemented at the least possible cost increment. Crashing the project may also increase project risk if the additional resources add layers of complexity to the work or do not produce as expected.

These scheduling techniques will be successful only if they are applied to activities on the project's critical path—because the critical path is the determining factor in completing the project on time, applying fast tracking or crashing techniques to non-critical project paths will not help in compressing the schedule or finalizing the project as planned.

Best Practices: Crashing

As mentioned in the previous assignment, adding more resources to activities can dramatically increase a project's cost so it is important for project participants to determine how to shorten the project duration for the least possible cost.

When implementing crashing techniques, it is important for practitioners to think about:

1. How much each activity costs under its normal time 2. The shortest possible activity times (i.e., maximum crashing), and 3. Activity costs under maximum crashing

They should use the following "rule-of-thumb" equations to help them decide which activities to focus their attention on:

Maximum possible time saving = normal time - shortest time Crashing cost = (cost with maximum crashing - normal cost)/maximum time saving

Example: Procedure at a Plastics Injection Molding Plant

Suppose the following parameters exist for the plastics plant:

Activity Activity Description Immediate Predecessor Activity Time A Order for parts arrives None 1

B Contract signed & paid A 2

C Plastic to make parts is ordered B 1

D Steel to make mold is ordered B 1

E Plastic arrives C 7

F Steel arrives D 5

G Develop mold for parts F 10

H Customer approves mold G 1

I Sample mold to ensure part quality E & H 1

J Production of parts I 2

K Delivery of parts J 1

Total: 32

Critical path: A-B-D-F-G-H-I-J-K

Activity Normal Time (days)

Crashed Time

Normal Cost

Crashed Cost

Maximum Time

Savings

Crashing Cost Per

Day

Calculation of Crashing Cost

A 1 1 $0 $0 0 $0 -

B 2 1 $100 $200 1 $100 = (200-100)/1

C 1 1 $0 $0 0 $0 -

D 1 1 $0 $0 0 $0 -

E 7 3 $10,000 $13,000 4 $750 =(13,000-10,000)/4

F 5 2 $2,500 $4,000 3 $500 =(4,000-2,500)/3

G 10 4 $3,500 $5,700 6 $367 =(5,700-3,500)/6

H 1 1 $0 $0 0 $0 -

I 1 1 $900 $900 0 $0 -

J 2 1 $3,000 $5,000 1 $2,000 =(5,000-3,000)/1

K 1 1 $100 $100 0 $0 -

Totals 32 17 $20,100 $28,900 15 $586.67 =(28900-20100)/15

It is important for practitioners to understand that it may be possible to crash partial days of a schedule. So if part production (Activity J) were shortened to 1.5 days, then it might still be possible to limit the crashing cost to $1,000 (0.5 * 2000 = 1000. Here we assume a linear relationship between activity costs and activity times).

Suppose the customer needed the order delivered in 21 days. Which activities should be crashed? They're likely to be the ones with the lowest crashing costs per day. In this situation, that means negotiating, signing, and paying the contract in one day instead of two and placing a rush order on the steel so it arrives in two days instead of five. It probably also means placing rush orders on the plastic and mold development.

However, any time an activity is crashed, it may change the project's critical path so it is important to reassess the schedule before taking any action. Before they decide to crash the schedule, practitioners will have to work through the project network analysis to be sure each step of the project can be completed in time and on budget.

Three-point Estimating

During the course of a project, a project practitioner may be asked to estimate how long a project will take or to determine its expected end date. An effective way to answer questions like these is to use a three-point estimate.

A three-point estimate averages three scenarios to improves the accuracy of estimates when the underlying tasks or components are uncertain.

Three-point estimates are based on the Program Evaluation and Review Technique (PERT). PERT calculates an average of three estimates—an optimistic estimate (based on the best- case scenario), a pessimistic estimate (based on the worst-case scenario), and a most likely estimate. The two most-commonly used formulas in PERT calculations are based on triangular and beta distributions. In a triangular distribution, all three values to be averaged have the same probability—the calculated estimate is just an average of the three points.

mean = (optimistic + most likely + pessimistic) 3

The beta distribution, however, weights the most likely estimate in the formula by multiplying it by four (which then means that the summation of the estimates must be divided by six to attain the average).

mean = (optimistic + (4 x most likely) + pessimistic) 6

The quotient from either of these formulas is called the expected value of the duration estimate.

PERT is considered reliable relative to other estimating techniques; however, all estimations are, by nature, imperfect. The degree of confidence in an estimate is known as a confidence factor, which is expressed as a percentage. The confidence factor of 95% over a normal distribution assumes that about 95% of the time, work will finish within ± two standard deviations of the PERT calculation.

When using PERT, standard deviation (used to find a confidence factor and confidence interval) is represented by (Pessimistic - Optimistic)/6. This factor provides the expected statistical variance in duration.

After finding the statistical variance, the confidence interval (the period of time within which the project practitioner is 95% certain that a project will be completed) can be determined. The confidence interval is calculated by raising the standard deviation to the power of two (for 95% certainty) and separately adding (to get the pessimistic confidence interval factor) or subtracting (to get the optimistic confidence interval factor) this number from the expected value as calculated by PERT.

Using these techniques, project participants should be able to provide an estimate for the amount of time that the activity or project should take, as well as the range of error; an example duration might be between 10 and 15 days with 95% probability of completion within 12 or 13 days (the interval).

Estimating Activity Resources and Durations

Z-Score

Let's step back for a moment and use PERT (without the confidence interval) to answer a different question. Sometimes a stakeholder will push a project practitioner to aim for the completion of a project on a certain date—and that date may be more or less realistic.

In project planning, a Z-Score calculated using PERT can help practitioners determine the question, "Given a desired completion date, what is the probability that this completion date is reachable?"

For general statistical purposes, Z-Score is the number of standard deviations from the mean a particular value is. It can be used in a variety of different real-world applications, one of which is in project planning. For our project management purposes, the value of Z is the number of standard deviations that the desired project due date is from the expected completion time.

So for instance, if a customer wants to complete the project in 30 days rather than 60 days, what is the probability that practitioners can actually make it happen?

A Z-Score can help answer that question.

To determine the Z-Score you would take the proposed project completion time (T), subtract the expected project completion time (TE) from it, and divide it by the project standard deviation (σ):

Z = (T-TE)/σ

Once you determine the Z-Score, you can translate the Z-Score into the probability percentage by locating the Z-Score on a predetermined and pre-calculated Z-Score table such as this one.

Remember that because the expected completion time calculated by PERT is determined to be a 50% probability, the Z-Score will either add to or subtract from that percentage. If the Z- Score is negative, then you would subtract that percentage from the 50% probability of the PERT expected completion time probability. If it is positive then you would add it to the 50% probability completion time.

Below is a step-by-step example that shows the use of PERT in conjunction with the Z-Score.

Example: Using PERT and Z-Score

You have been engaged by a company called iGuide, which provides online travel guidebooks, and they would like you to make a new travel guidebook for Australia. You have estimated the completion times (Most Likely, Optimistic, and Pessimistic) for all of the activities involved on this project and placed them in the table below.

iGuide would like to complete this project in 24 days. What is the probability of successfully completing this project in 24 days?

Activity Most Likely Time(Days) = m Optimistic Time = a

Pessimistic Time = b

A 1 1 1

B 2 1 7

C 1 1 2

D 1 1 2

E 7 3 21

F 5 2 21

G 10 4 21

H 1 1 5

I 1 1 5

J 2 1 5

K 1 1 3

Totals 32 17 93

Step 1: Calculate the expected completion time (TE) using PERT

We know from the PERT section that to calculate expected completion time, we need to use the formula:

TE = (O+4M+P)/6

Using the table above TE would be:

TE = (17+4(32)+93)/6

TE = 39.67 days

Step 2: Begin to calculate the variance of the project by calculating the variance of each task

To calculate the variance of each task, use the equation:

Task Variance = [(P-O)/6]2

(All of the variances for each task have been calculated in the table below Step 3.)

Step 3: Calculate the standard deviation

To calculate the standard deviation, use the equation:

Standard Deviation = √ Task Variance1 + Task Variance2 + Task Variance3… .

The standard deviation can be found at the bottom of the table below.

Note: While the variance for the project is the sum of all the activity variances, the standard deviation for the project is the square root of the variance of the project (not the sum of all activity standard deviations—that would not be statistically correct).

Activity Most Likely Time(Days) = m Optimistic Time = a

Pessimistic Time = b

Expected Time = t

Variance = σ2

A 1 1 1 1 0

B 2 1 7 2.67 1

C 1 1 2 1.17 0.0278

D 1 1 2 1.17 0.0278

E 7 3 21 8.67 9

F 5 2 21 7.17 10.0278

G 10 4 21 10.83 8.0278

H 1 1 5 1.67 0.4444

I 1 1 5 1.67 0.4444

J 2 1 5 2.33 0.4444

K 1 1 3 1.33 0.1111

Totals 32 17 93 39.67 Total of

Variances = 29.5556 STD Dev = 5.44

Step 4: Calculate the Z-Score

Given that iGuide wants to know the probability that the project will be completed within 24 days, we have all the information we need to calculate the Z-Score.

T = 24 days

TE = 39.67

σ (Standard Deviation) = 5.44

To calculate the Z-Score use the equation:

Z = (T-TE)/σ

Z = (24-39.67)/5.44

The Z-Score (z) is the difference between the desired completion time (e.g., 24 days) and the project's expected time (39.67 days) divided by the standard deviation for the project (5.44).

Z = -2.88

Step 5: Calculate the probability of success

Now that you have figured out the Z-Score, you must translate that score (sigma value) into an actual percentage. This translation is done using a Z-Score table. Note that a Z-Score table is not calculated by project practitioners—it is a preexisting table that statisticians have already calculated for use with Z-Scores. The Z-Score contains the same values regardless of the application or industry.

The Z-Score is -2.88, which from a Z-Score table equates to a 0.4980 area under the normal distribution curve. See the Z-Score table below.

How do you read the Z-Score Table? For a Z-Score of -2.88, we would first read down the 0.0 column until we find the 2.8 row, and then we would locate the column that has the 0.08 in it (2.8 + 0.08 = 2.88). At the intersection of the 2.8 row and the .08 column we find 49.80%.

But that is not the end of the calculation! We must add or subtract that value from the mean (50%). Remember the original estimated time of 39.67 days was calculated using PERT, which gives you a 50% probability of success of hitting that date exactly.

If you end up with a positive Z-Score, then you would add this to the 50% probability of success. If you end up with a negative Z-Score then you would subtract it from the 50% probability of success. In our case, the Z-Score was negative (-2.88). So we must subtract 49.80% from 50%, and this gives us .20%.

The probability of success of completing the project in 24 days is .20%. It looks like you have to reset iGuide's expectations of completion time. There is only a fifth of a percent of a chance that the project will complete on the day that they have requested, so their expectations aren't very realistic.

Project Time Management Barriers and How to Handle Them

In a previous assignment, we talked about the challenges of keeping a project's schedule on- track. In this assignment, we will explore some of the barriers that can prevent a project manager from managing a schedule effectively and how those barriers can be avoided.

A project manager first needs to identify the specific problem or problems. Below are some of the potential problems project managers may face.

A Lot of Small Delays

A project with many tasks that are all a little bit late is a dangerous problem for any project manager. Each of the small delays adds up quickly and before the project manager knows it, the project is late. It is important for project managers to keep a holistic view of their projects. They cannot let larger issues distract them from noticing small delays with deliverables.

The Noncooperative Team Member

In some cases, there may be team members who do not agree with what needs to be done on a project. They may refuse to work on the tasks in the order they have been scheduled, and instead work on what they feel is correct. Warning signs may include reluctance to submit status reports and avoiding the project manager. The project manager must meet one-on-one with each problematic team member and emphasize the importance of working as a team. If this intervention is not effective, stronger measures may be necessary.

The Remote Team Member Who Doesn't Communicate

It can be difficult to manage a team when members work in remote locations or telecommute. When remote team members stop communicating with the project manager, this difficulty increases. For team members working at a remote office location, the project manager may need to have another person at the site to confirm that the employees are actually at work. A senior manager at that site may need to intervene and talk to the employees about the communication issues. If the issues cannot be resolved, the team member may need to be removed from the project. To avoid major delays in the schedule, critical tasks should be reassigned to other team members as quickly as possible.

The Client or Vendor Who Doesn't Communicate

Project teams are often dependent on information or deliverables from clients or vendors. When either of these stakeholders goes silent, the project manager may encounter delays in the project schedule. To deal with non-communicative clients, it can be useful to call an emergency meeting with the client representative or project sponsor. In the case of vendors who do not deliver on schedule, it is important to ensure upfront that contractual agreements specify the consequences of late delivery. With vendor delays, the project manager may organize a brainstorming session with the project team and client to identify substitutes for the vendor's deliverable.

Task Uncertainties

Task uncertainty can be generated in different ways. For example, if a team member is scheduled to work on a task, but the task has not yet been defined, there is likely to be confusion and excess time spent on the task. Alternatively, a team member may not know the status of other team members' tasks. This too can be a source of uncertainty. Communication within the team is a logical remedy to this problem.

"Hurry up and wait" and "Wait and hurry up" Situations

There are two "syndromes" that a project manager may see. "Hurry up and wait" is when a stakeholder has an urgent request for information that turns out to have been unnecessary. "Wait and hurry up" is when emergencies arise due to procrastination on the part of the stakeholder. What can a project manager do in these situations? For cases of "hurry up and wait," the project manager can ask specific questions of the requester. For example: Why is the request so urgent? Who specifically has asked for the information? The project manager should clearly communicate how fulfilling the request will impact the project. It is prudent to put the request and project impact in writing and to copy the person identified as the initiator of the request. In the case of "wait and hurry up," the project manager should implement a process for emergency requests.

Dealing with Emergencies

When emergencies arise on a project, the project manager must act quickly. Even if the emergency is the result of procrastination, it must be addressed. Having a process for dealing with emergencies and unexpected, high priority requests is useful. After the emergency has passed, it can be helpful for the project manager to hold a lessons learned meeting to identify ways of avoiding emergency situations in the future.