MGM_PRO1

Module_Three_Project_Planning.pdf

Home >Business & Finance homework help >Management homework help >MGM_PRO1

Module Three: Project Planning

One of the key deliverables of project planning is the project management plan, which shows how the project team will complete project work and achieve the results for which the project was designed. Comprehensive project planning keeps the project on schedule and on budget, ensures the project's quality remains high, helps the project team manage resources (including human resources), and mitigates project risk.

Learning Outcomes

After completing this module, you should be able to:

1. Recognize how planning helps the project team achieve project goals 2. Develop a comprehensive project management plan to guide project work 3. Create a work breakdown structure to show the work involved in the project 4. Provide accurate time and cost estimates for project work 5. Develop a cost baseline for the project 6. Describe the tools that will be used to monitor project quality 7. Assign responsibility for project work to project participants 8. Create a risk register to identify, analyze, and prepare for risks 9. Explain how the project team will manage contracts and vendors on the project

3-1 Module Three Pre-test

Module Three Pre-test

Click "Next" to access the Module Three Pre-test

3-2 Planning the Project

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 common project problems such as the following:

These are common but detrimental issues 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 while mitigating risks.

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.

Because there is an almost infinite number of combinations to take into account and choreograph, it is possible that two projects done by the same people in the same organization will be vastly different

in the way they are handled. As such, it is vitally important for all project participants to list, itemize, and archive their methodology and approach to assist others who may be involved in similar projects in the future.

The comments, notes, and entries passed on to succeeding project leaders and team members may help them avoid repeating mistakes from the past and attain results quickly, skillfully, and efficiently.

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 plan, they are more likely to buy-into it to a greater degree.

Tailoring the Plan

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, plans 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.

Factors, Constraints, and Considerations

A tailored project management approach can be created by specialists within an organization or procured from outside the company (from vendors, associations, or governmental agencies). If a tailored approach is generated in-house, a project manager will need to work with his or her project sponsor, project team, and organizational management (or some combination thereof) to determine which combination of processes, phases, inputs, tools, techniques, and outputs will help them achieve their goals. They will need to balance all competing constraints, including:

the project's environment, the culture of the organization, the needs of stakeholders, levels of governance, and internal and/or external customer designations

to guarantee that all perspectives and points of view have been allowed for and all angles have been considered. They may need to alter governance tactics and procedures to harmonize with the specialized approach. And they will likely need to spend additional time communicating with colleagues and stakeholders to explain why certain processes and assignments were altered or eliminated from projects.

Agile Planning

More traditional approaches to project management that 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 methodology 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. Spending too much time and effort tracking minute details can risk shifting the focus away from delivering results. If not enough attention is paid to detail and project planning is insufficient, there may not be enough information available to complete work well.

3-3 The Project Management Plan

The Project Management Plan

The project management plan is a comprehensive, integrated document that can be revised throughout a project as more about the project is known. Most of the plan's components are the outputs of other project management processes, but a thorough plan may include components that will be generated as the plan itself is created.

At a minimum, the project management plan should include these tools:

the scope statement the work breakdown structure the risk register the responsibility assignment matrix the network diagram the cost baseline contracting and vendor management plans

However, the plan may contain some or all of the additional components in the graphic below.

Click on each item in the graphic below for more information.

Note: For the sake of simplicity, this module will focus on particular key components of the project management plan. However, information on these topics may also be found in other areas of the course.

Tailoring the Plan

Like other essential parts of a project, the project management plan will be subject to progressive elaboration and continuous improvement, to allow the plan to become more detailed and accurate as the project advances. And, like other components, the plan can be as simple or complex as necessary, depending on the wants and needs of the project and its stakeholders.

Finally, at some point during the project, the project management plan should be "locked down" as much as is feasible, so that any and all suggested changes will have to be sent through a formal change control process. This will ensure that modifications will only be implemented in a coordinated and integrated manner that benefits the project as a whole.

3-4 Exercise: The Project Management Plan This assignment does not contain any printable content.

3-5 Planning a Project with Agile Techniques

Planning a Project with Agile Techniques

A traditional project management mantra is to "plan the work and work the plan." This expression is based on the idea that a project is predictable if a team spends enough time understanding the nature of the work. However, experience has shown that many projects are not easily predicted.

To avoid the problems associated with this assumption, Agile-influenced teams employ a philosophy of exploration and adaptation as they run their projects. The nature of an Agile project is uncovered as the project progresses, and the team modifies its work to accommodate any variation. This approach leads to less emphasis on planning and monitoring, and more emphasis on adapting to change.

The Project Manager's Toolbox

Teams can use a number of tools and techniques to help them plan, monitor, and adapt their activities. These mechanisms provide guidelines that help teams structure projects, demonstrate progress, and reflect on interactions, to ensure that their work continues to meet expectations and deliver value.

Click on each of the headings below for more information.

Timeboxing

Timeboxing sets a fixed time constraint or deadline date for an iteration or project. In each timebox, the team completes as much work as it can realistically accomplish within the prescribed period of time but, because the work cannot exceed the time allotted, the team is limited in the amount of scope it can attempt. And because the timebox sets a cadence for the delivery of a working product on a regular basis, it provides a schedule that organizations can use for planning and monitoring project progress.

Care must be taken when planning the timeboxes for a project; the timebox must be short enough to constrain project scope, yet large enough to ensure that the team has enough time to complete value-added activities. Timeboxes must also allow the team to deliver working product increments at a cadence they can continue indefinitely—if the time allotted is too short, team members will quickly exhaust themselves trying to complete the work, requiring recovery time that will ultimately slow down projects.

Velocity

Velocity (also known as throughput or productivity) describes how "quickly" a team is completing its work. It illustrates how much work a team can complete at a sustainable pace within a given

Establishes how the scope will be defined, developed, monitored, controlled, and validated [PMI® definition]

Establishes how the requirements will be analyzed, documented, and managed [PMI® definition]

Establishes the criteria and the activities for developing, monitoring, and controlling the schedule [PMI® definition]

Establishes how the costs will be planned, structured, and controlled [PMI® definition]

Establishes how an organization's quality policies, methodologies, and standards will be implemented in the project [PMI® definition]

Provides guidance on how project resources should be categorized, allocated, managed, and released [PMI® definition]

Establishes how, when, and by whom information about the project will be administered and disseminated [PMI® definition]

Establishes how the risk management activities will be structured and performed [PMI® definition]

Establishes how the project team will acquire goods and services from outside the performing organization [PMI® definition]

Establishes how stakeholders will be engaged in project decisions and execution, according to their needs, interests, and impact [PMI® definition]

The approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, which is used as a basis for comparison [PMI® definition]

The approved version of the schedule model that is used as a basis for comparison to the actual results [PMI® definition]

The approved version of the time- phased project budget that is used as a basis for comparison to the actual results [PMI® definition]

Describes how the change requests throughout the project will be formally authorized and incorporated [PMI® definition]

Describes how the information about the items of the project (and which items) will be recorded and updated so that the product, service, or result of the project remains consistent and/or operative [PMI® definition]

An integrated scope-schedule-cost plan for project work against which project execution is compared to measure and manage performance [PMI® definition]

Describes the series of phases that a project passes through from its initiation to its closure [PMI® definition]

Describes the product, service, or result development approach, such as predictive, iterative, Agile, or a hybrid model [PMI® definition]

Identifies the points in the project when the project manager and relevant stakeholders will review the project progress to determine if performance is as expected, or if preventive or corrective actions are necessary [PMI® definition]

time period. A team's velocity should be one that is challenging but achievable.

During its first iteration, the team must take an educated guess of the number of story points it can complete in the allotted timebox. After completing the iteration, the team can reflect back to see whether the number of story points attempted was appropriate for the time period. Based on this feedback, the team can adjust the number of story points it selects for the next iteration. Likewise, at the end of subsequent iterations, team members can decide again whether the number of story points selected was appropriate.

After a few iterations, an Agile team should have a feel for its velocity. A team's velocity may change over time, but any change must be demonstrated and proven, not assumed. Velocity can then be used to estimate how long it will take to complete the product backlog.

Kanban Boards and Work-in-Progress Limits

A Kanban board is a story board that lists the user stories in each phase of a project and shows how much work is involved in the different parts of the project life cycle at any given time. Because it shows how many activities are in each phase of a project, the Kanban board quickly reveals any bottlenecks that result from having too much work in any single phase; teams can then apply additional resources to move the work through the bottleneck.

To minimize the probability of work creating a bottleneck in a portion of the life cycle, teams may set work-in-progress (WIP) limits. WIP limits prescribe a maximum number of user stories that can be in each phase at one time—when this maximum is reached, no more user stories are moved into the phase. Additional effort is then focused on completing the work in the blocked phase so that new user stories can be moved in, and work can continue as planned.

Burn Charts

Burn charts show a team's progress in its completion of project work. Typically, time is listed on the horizontal axis (usually as iteration increments), and the amount of work is listed on the vertical axis. (Work can be represented in a number of ways such as total user stories, story points, or total estimated effort hours.)

At the end of each iteration, there will be less work remaining than when the iteration started. Plotting this information on a burndown chart will show a steady decline in the amount of remaining work as each iteration progresses, and a trend line will emerge that will show when the project backlog will be completed. Conversely, a burn-up chart will plot the work completed rather than the work remaining; as more work is finished in each iteration, the trend line will increase.

If the trend in either burn chart shows a deviation from expected progress or schedule completion dates, an Agile team can adapt its work to bring performance back in line with expectations.

Burndown Chart

Burn-up Chart

A special form of burn chart (known as the feature burn chart or product backlog burn chart) shows patterns or trends in project work over time. The feature burn chart shows the number of features completed, the number of features remaining, and the total number of features, together in one image that provides for easy comparisons.

Backlog Management/Refinement

An iteration review session may result in a number of suggestions that need to be added to the existing product backlog before upcoming work can begin, but doing so may affect the order and priorities of the current list. To ensure that the team will continue to work on the most important items, the backlog will need to be adjusted and refined to guarantee that project outputs continue to meet the most pressing needs and wants of users and customers.

This adjustment process (also known as backlog refinement) will ensure that:

All backlog items (including previously existing items) are continuously reprioritized to meet current needs All items have been assigned appropriate and up-to-date estimates Any new suggestions or stories have been added to the backlog Any old or irrelevant items have been removed from the backlog Items have been categorized or classified (as "near-term"/"long-term," "technical debt/customer wants/organizational needs," etc.), as necessary

A properly refined backlog helps to streamline subsequent planning meetings because all backlog items will have been prepared to an appropriate level, making their selection for upcoming iterations or releases quicker, simpler, easier, and more understandable.

The person most responsible for the refinement of the backlog is the product owner, but he or she should only do so after soliciting input from the members of the Agile team. Product backlogs must be reviewed and refined before each upcoming iteration, but this activity should not be postponed until the last minute—product owners should remain vigilant in their management of the backlog to guarantee that they are not scrambling to prepare for an imminent planning meeting, or that surprises do not occur as work is currently being performed.

3-6 The Work Breakdown Structure

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 the 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. The chart 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 practitioners can make reliable estimates 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

In general, the steps for creating an efficient WBS are as follows:

Click on each of the numbered boxes below for more information.

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.)

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.)

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.

The slideshow below shows the specific steps needed to create a WBS that will support a project and help identify important project parameters:

Click on the next and previous buttons to progress through the slideshow.

Slide 1

A work breakdown structure helps project participants identify all of the work involved in a project and organize it into segments or categories.

Slide 2

The WBS break a project down from more general areas (at the top of the structure) to more specific items (at the bottom of the structure).

Slide 3

The project name is listed at the top of the WBS.

Slide 4

The structure is then decomposed into successive layers...

Slide 5

to break the project down into finer...

Slide 6

and finer granularity...

Slide 7

until it reaches a point where reliable cost and scheduling estimates can be made.

As a project evolves, practitioners will learn things that they didn't know at the start of the project; they'll need to use this new information 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.

3-7 Scheduling

Scheduling

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:

Click on each of the numbered boxes below for more information.

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.

The Gantt Chart

Perhaps the simplest scheduling tool, available in many software programs such as Microsoft Project, is the Gantt chart (also called a logical bar chart). A Gantt chart is a sequential bar chart that shows the start and finish dates of activities, as well as with their durations, the dependencies among the activities, and the resources associated with them.

Gantt charts allow project managers to see how the duration of a project changes depending on changes in the resources or activity durations. The Gantt chart also helps to see what gaps or lags there might be in the schedule and the times when each team member appears "open" to possibly assist in another activity.

A simple example of a Gantt chart is illustrated below.

An Example

Thierry and Janice are coworkers on an architecture project and have been assigned to a subset of activities as described in the table below:

Janice and Thierry would prefer not to work on weekends, but they will work on Saturday if necessary.

What would a Gantt chart for this subset of activities look like?

Note: If you have Gantt chart software, you can use it to follow along with this example. If you don't, you can plot your own Gantt chart on paper or in Excel. There are some free software options available, but we have found them to be buggy.

To set this project up using software, you will need to do the following steps:

1. Enter the activities and their durations. 2. Set the begin date of Activity 1. 3. Enter the names of the human resources, and assign them to their respective activities. 4. Ensure that the human resources are scheduled to be off on weekends. 5. Set the dependencies of the activities.

Click to see an image of the project that illustrates the data provided in the table above.

Based on the information in this schedule, it looks as if the project will finish at the end of the day on March 26.

But what if the client decides she wants the project completed as early as possible? Your best option in this situation would be to ask Thierry and Janice to work on Saturdays until the project is finished. So let's change the chart to see what the earliest finish date would be for this part of the project if you make this change.

After you make the changes to allow Thierry and Janice to work Saturdays, what does your new schedule look like, and what would the new estimated completion date of the project be?

Click to see an image of the project that illustrates the data provided in the table above.

If you've plotted everything correctly, you'll notice that you can complete this part of the project on the 22nd.

3-8 The Network Diagram

The Network Diagram

It's important to create a schedule that will guide the team in executing project work. Although many practitioners use a Gantt chart, others create a network diagram to help them see the dependencies within their schedule.

The network diagram is a simple graphic that shows the logical relationships among project activities. Using a simplified graphic 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.

Example of a Network Diagram

Building the Diagram

To create an effective network diagram, project participants will follow the seven-step process described below. Completing these steps will ensure that the network diagram will account for all project work and provide helpful information to project participants.

Click on each of the headings below for more information.

1. Identifying Activities

Identifying all of the activities that will have to be completed to meet project objectives allows participants to estimate the project's schedule more accurately (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

Activity Duration Dependency Projected Start Date Projected Finish Date Human Resource

Activity 1 4 days none Monday, March 5 Thursday, March 8 Janice

Activity 2 5 days Depends on the completion of Activity 1; Activity 1 must finish before Activity 2 can start Friday, March 9 Thursday, March 15 Thierry

Activity 3 7 days Depends on the completion of Activity 2; Activity 2 must finish before Activity 3 can start Friday, March 16 Monday, March 26 Janice

Activity 4 4 days Depends on the completion of Activity 2; Activity 2 must finish before Activity 4 can start Friday, March 16 Wednesday, March 21 Thierry

javascript:opengraphic('Gantt_Zhivago_Before_r.png')

javascript:opengraphic('Gantt_Zhivago_After_r.png')

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.

2. 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.

3. 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, it is important to 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.

4. 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.

5. 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.

6. 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.

7. Finding the Critical Path

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.

3-9 Identifying the Critical Path

Identifying the Critical Path

To help you better understand how a network diagram works, let's spend some time calculating a critical path.

Remember that a critical path is determined by comparing a project's early dates (from a Forward Pass Calculation) to the project's late dates (from a Backward Pass Calculation).

The Forward Pass

The Forward Pass Calculation answers the question, "What is the earliest that an activity (or path) may start or finish?" and is usually seen as the best-case scenario. The forward pass works through the project sequence from the beginning of the job until the end of the job, considering each activity in its logical sequence.

Keep in mind that:

The early start date must take the completion of all of its preceding activities into account. The early finish date assumes that the activity will start on time and take no longer than planned. When an activity is connected to more than one prior activity (i.e., arrows from two-or-more 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. Early start dates and early finish dates are shown on top of an activity box.

The formulas for the Forward Pass Calculation are as follows:

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

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

A Sample Forward Pass

The Backward Pass

The Backward Pass Calculation answers the question, "What is the latest that an activity (or path) may start or finish without delaying the project?" The backward pass works through the project sequence from the end of the project to the beginning, again addressing each activity in its logical date sequence.

For the backward pass, keep in mind that:

The late finish date must take the completion of all successor activities into account. 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. Late start dates and late finish dates are shown on the bottom of an activity box.

The formulas for a Backward Pass Calculation are as follows:

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

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

A Sample Backward Pass

Critical Path Determination

On the project's critical path, all of the early start dates for activities will be the same as the late start dates, and all of the early finish dates will be the same as the late finish dates for the same activities.

LS– ES = 0 and LF– ES = 0

After identifying the critical path and the project's end date, it should be easy to see if the project's expected end date aligns with a customer's due date. If the end date exceeds the customer's request (which is often the case), additional planning (such as fast tracking or crashing) will be required to align expectations.

Exercise

Gateway Construction is constructing a highway bridge. The bridge must be completed before severe cold weather sets in. Six paths for construction have been identified: ABFKNO, ABGLNO, ACGLNO, ACHLNO, ADHLNO, and AEIMNO.

Based on the following table, which is the project critical path?

Activity Estimated Completion Time (Days)

A-B 5

A-C 5

A-D 5

A-E 6

B-F 4

B-G 6

C-G 4

C-H 5

D-H 2

E-I 8

F-K 3

G-L 4

H-L 2

I-M 3

K-N 1

L-N 1

M-N 1

N-O 1

Click on the check mark below for the correct answer.

The critical path is AEIMNO, which takes 19 days.

ABFKNO = 5 days + 4 days + 3 days + 1 day + 1 day = 14 days ABGLNO = 5 days + 6 days + 4 days + 1 day + 1 day = 17 days ACGLNO = 5 days + 4 days + 4 days + 1 day + 1 day = 15 days ACHLNO = 5 days + 5 days + 2 days + 1 day + 1 day = 14 days ADHLNO = 5 days + 2 days + 2 days + 1 day + 1 day = 11 days AEIMNO = 6 days + 8 days + 3 days + 1 day + 1 day = 19 days

Gateway is considering accepting a 2-day delay from a subcontractor in completing Activity L-N. Will accepting this delay the project?

Click on the check mark below for the correct answer.

No, accepting a 2-day delay in Activity L-N will still allow the project to finish on time. Paths ABFKNO, ACGLNO, ACHLNO, and ADHLNO will all be delayed 2 days, but will still finish faster than the critical path AEIMNO, which takes 19 days. Activity ABGLNO will also be delayed 2 days and will therefore finish in 19 days, which also makes it a critical path for the project. However, that will still allow the project to finish on time.

3-10 Estimating Techniques

Estimating Techniques

There are several specialized tools and techniques that project managers can use to help them prepare estimates (especially duration estimates). Three of the most common techniques—analogous estimating, parametric estimating, and three-point estimating—are summarized below:

Alternative Methods to Estimate Activity Duration

Analogous estimating

Analogous estimating uses parameters (such as size, weight, budget, complexity, or duration) from a previous, similar activity as the basis for estimating the same parameter for a future activity. For example, if a team just finished designing a website and is starting to develop a new site of similar size and complexity, team members could assume that the new project will take about the same amount of time as the previous project.

Analogous estimating is a good technique to use when a project is very similar to one already completed, and the team members have the necessary expertise to complete it. In general, time estimates stemming from this synthesis are averages.

Parametric estimating

Parametric estimating uses a statistical relationship between historical data and other variables (e.g., square footage in construction, lines of code in software development) to calculate an estimate for activity parameters. For example, to estimate a duration parameter, participants would multiply the planned quantity of work to be performed by the historical labor hours per unit. So if a productivity rate is five installations per labor hour, and the quantity of work is 1,000 installations, the labor hours required would equal 1,000/5, or 200 labor hours.

Parametric estimating is a good technique to use when a project has aspects that are similar to other projects, and organizational process assets exist to capture past experience and convert it into statistical data.

Three- point

estimating

Three-point estimating averages three cost or duration estimates that represent the optimistic, most likely, and pessimistic scenarios. This technique is applied to improve the accuracy of the estimates of cost or duration when the underlying decomposed tasks or their cost components are uncertain. A common application of three-point estimating is the PERT technique, which will be described in a subsequent assignment in this course.

Review Checkpoint

To test your understanding of the content presented in this assignment, please click on the Questions icon below. Click your selected response to see feedback displayed below it. If you have trouble answering, you are always free to return to this or any assignment to re-read the material.

1. A(n) ________ estimate averages three duration estimates representing the optimistic, most likely, and pessimistic scenarios.

a. parametric

Incorrect. Try again.

b. analogous

Incorrect. Try again.

c. three-point

Correct. A three-point estimate averages optimistic, pessimistic, and most likely values to determine activity durations.

d. none of the above

Incorrect. Try again.

2. ________ is a good estimating technique to use when a project has aspects that are similar to other projects, and organizational assets exist to capture past experience and convert it into statistical data.

a. Parametric estimating

Correct. Analogous estimates are similar to parametric estimates, but parametric estimates use statistical data to estimate whereas analogous estimates rely more on the past experience of the team.

b. Analogous estimating

Incorrect. Try again.

c. Three-point estimating

Incorrect. Try again.

d. All of the above

Incorrect. Try again.

3-11 The Program Evaluation and Review Technique

The Program Evaluation and Review Technique

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—to determine activity durations. The two most-commonly used formulas in PERT calculations are based on triangular and beta distributions.

Click on each of the headings below for more information.

Triangular Distributions

The triangular distribution averages all three values so they would have the same probability—the calculated estimate is just an average of the three points.

Beta Distributions

The beta distribution 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).

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

Video Commentary: Three-Point Estimating

Distributions Used in Three-Point Estimating

Rich Maltzman

Distributions Used in Three-Point Estimating

Rich Maltzman

Let's talk for a minute about estimation, and let's talk about the difference between a triangular estimate (three-point estimate) and a beta three point estimate. Sometimes the beta estimate is called a PERT estimate. Let's start with that one.

In that estimate, we use three different--as in the triangular--points to come up with an expected value. We use an optimistic, a most likely, and a pessimistic. In the case of the beta distribution, we actually multiply the most likely by 4, and then we divide the entire numerator, which is going to be the optimistic with a vote of 1 or a weight of 1, pessimistic with a weight of 1, and most likely with a weight of 4, so a total of 6. We divide by 6. So, we've given 4 weighting points to the most likely, and we do this when we have more faith in this most likely estimate. If indeed we think this is most likely and we have data to back that up, we have experience, we want to trust that number more, so we give it, literally, a weight of 4.

I often make the analogy to an electoral college, where one, in the US anyway, might Delaware, one vote for Delaware, one vote for Montana, four votes for California--a much more populous state. So we give more points--more electoral votes--to California or most likely in this case, to to have it take more of an effect of the overall average, because now we're going to divide 4 times that most likely number, it's going to be 4/6 of the overall number.

In the case of a triangular distribution, we give them all equal weight. So here, Delaware, Montana, and California have the same votes--one vote each--and we divide by three. And we use this distribution when we really have these three points to work with, we have an outside pessimistic, we have an outside optimistic number, we have a most likely number; we just take the three numbers, add them all up, and divide by three and get a simple average.

Both of them are approaches to taking information that you have--translating it into an estimate. It's just a matter of whether you trust your most likely number more. In that case, you would use the beta distribution. That's it.

Rich Maltzman, PMP®, is a speaker, consultant, senior lecturer, and professional advancement leader with extensive project management and business development experience. Rich has authored and co-authored several highly regarded books and articles and continues to develop curricula and programs for national and local colleges.

PERT and Statistical Confidence

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 the following equation:

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 manager is 95% certain that a project will be completed) can be determined. The confidence interval is calculated by multiplying the standard deviation by two (because the project manager assumes that work will finish within ± two standard deviations) 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, the project manager 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).

Review Checkpoint

1. You are using a triangular distribution to calculate a three-point estimate. The optimistic estimate is 2 days. The most likely estimate is 4.5 days. The pessimistic estimate is 10 days. What is the expected value for the duration estimate?

a. 5 days

Incorrect. Try again.

b. 5.5 days

Correct. Using a triangular distribution, the expected value would be (2 + 4.5 + 10)/3 or 5.5 days.

c. 2.75 days

Incorrect. Try again.

d. 4.5 days

Incorrect. Try again.

2. In a beta distribution for a three-point estimate, which estimate is multiplied by four to give it additional weight in the calculation?

a. the optimistic estimate

Incorrect. Try again.

b. the most likely estimate

Correct. In a beta distribution, the most likely estimate is multiplied by four to give it additional weight in the calculation.

c. the pessimistic estimate

Incorrect. Try again.

d. none of the above

Incorrect. Try again.

3-12 Exercise: Estimating Using PERT Calculations

Exercise: Estimating Using PERT Calculations

An instructional designer has to design a screenshot for a webpage. As the project manager, you ask the designer to give you an estimate of how long this will take to complete. Her estimates range from 3 to 10 days, with 5 being the most likely estimate. How can you accurately estimate the duration of this activity?

What we know:

3 days—optimistic estimate

5 days—most likely estimate

10 days—pessimistic estimate

Type your answer in the blank provided and click the Submit button to see if your answer is correct.

Calculate the expected value for this activity (likely duration time for this activity using a weighted beta-distribution formula):

mean = submit

Increase your confidence in this calculation by applying standard deviation, rounding to one decimal point.

standard deviation = submit

Now calculate the confidence factor for this activity ( Note: Complete both equations before clicking the Submit button):

submit

3-13 Estimating With Agile Techniques

Estimating With Agile Techniques

Some projects can't be planned out completely ahead of time and require more adaptive planning processes, so practitioners have developed several tools and techniques to assist in their estimation efforts in those circumstances. These tools allow teams to create forecasts of uncertain events while still following the basic Agile principles of collaboration and adaptation.

The Project Manager's Toolbox

Click on each of the headings below for more information.

Ideal Time vs. Real Time

A familiar technique to estimate work duration is to calculate effort hours—the amount of time it will take the team to complete the user stories of the project. Unfortunately, these estimates tend to be optimistic because they are based on ideal conditions; the estimates assume that team members will be able to work exclusively on the project with no interruptions. But few tasks are completed without interruptions—phone calls, meetings, emails, and unexpected events quickly derail project work and make these calculations obsolete.

To create more accurate estimates, teams must differentiate ideal time from real time. Ideal time assumes that work will be completed without interruption—the person doing the work will be completely focused on the tasks at hand. Real time assumes that interruptions will occur and takes this "lost time" into account.

Using real time rather than ideal time allows project participants to develop practical estimates that suggest realistic completion dates. For example, an ideal time forecast for a task may estimate that it will take 16 hours of uninterrupted work to complete; however, the real time estimate for the same task—assuming an average number of everyday interruptions—might be 24 hours. By taking a practical view of the work that could be completed each day, real-time forecasts enable teams to make practical estimates and better predict work.

Relative Sizing/Story Points/T-Shirt Sizing

Developing estimates based on effort hours can be very subjective—an experienced team member may be able to complete work much faster than an inexperienced worker performing the same task. As a result, some teams use relative measures to compare and estimate work. These relative story points provide a simpler model that allows Agile teams to estimate based on the perceived effort and complexity of work packages in relation to one another. If one work package is perceived to be twice as complex as another package, it is assigned twice as many story points.

Each project team establishes its own story point scale. There is nothing magical about the exact number of story points assigned; one team may assign five points for a work package and 10 points for a package that is twice as complex, while another team may assign 25 and 50 story points for those same two work packages. The key is that the story points represent the relative size of the user stories in relation to each other.

While numerical story points may help some teams develop work estimates, other teams may choose an even simpler model to estimate effort and complexity. This model, known as t-shirt sizing, assigns relative amounts to work based on the common "sizes"—small (S), medium (M), large (L), and extra-large (XL)—used in the clothing industry. In such cases, work designated as "small" would be less complex (or require less effort) than work listed as "medium," and it would be much less complex than work with an "extra-large" designation. T-shirt sizing can be especially helpful to those practitioners who are new to Agile estimating, but may cause problems because it may be difficult to say how much of a discrepancy exists between the different "sizes" (i.e., a small work package requires less work effort than a medium package, but exactly how much less could result in misunderstandings among team members).

Affinity Estimating

Affinity estimating relies on the knowledge and experience of team members to rank-order the user stories in a project. In this technique, the team lays out the user stories of the product backlog in relative size order—usually from smaller to larger as the stories move left to right. Team members then silently re-order the stories, with each member making independent decisions as to where each story belongs. If disagreement occurs, the team discusses the discrepancy to gain a common understanding, and then again silently returns to the ordering process. Once the stories are ordered, they will get progressively larger as the process moves to the right and the team can quickly estimate the number of story points in each iteration.

Wideband Delphi

Wideband Delphi is a technique that uses the combined experience and knowledge of the members of the team, but asks the team to make estimates independently. To expand their understanding of key issues, the team discusses the user stories and any common assumptions, but estimates for each story are made independently by each team member. The estimates are collected, and the project manager determines if there is a consensus for each user story. If the estimates vary widely, the team will re-open the discussion to try to reach a common understanding. The team members then re-estimate the work until a consensus is reached.

Planning Poker

Planning Poker is a specific version of Wideband Delphi that uses cards that have been printed with numbers (or ranges) on the back side of the cards. After the team discusses each user story, each team member chooses a card that represents their estimate. (Often, the labeled cards follow a Fibonacci sequence—or some variation of this sequence—to force a larger separation between ranked items.) Team members then turn over their cards to reveal their estimates. Discrepancies are discussed and additional rounds are played until a consensus is reached.

3-14 Sprint Planning

Sprint Planning

One of the most commonly used Agile estimating tools—sprint planning—can help an adaptive-approach team plan and schedule its work.

In sprint planning, Agile team members meet with the product owner and scrum master to plan the work of an iteration and ensure that the activities they choose will fit within the timebox set for the iteration/sprint. They select items for the sprint backlog and develop a sprint goal that will guide their actions as they work their way through the sprint.

Sprint planning is timeboxed to ensure that Agile teams do not overplan or overprepare for sprints. (Most organizations limit these planning sessions to one eight-hour period, although sessions may be shorter if the team is planning sprints that are shorter than one month in length). The limitations imposed on planning sessions prevents practitioners from dictating and prescribing solutions or instructions before a sprint is even launched.

Sprint Planning Activities

Sprint planning encompasses several activities that allow the Agile team to plan for project success; these activities are discussed below.

Click on each of the headings below for more information.

The Sprint Goal

Effective sprint planning results in the creation of a compelling sprint goal—one that delineates what the team will achieve in the sprint and explains why they are doing it. The goal, in effect, outlines the sprint deliverables and shapes the sprint into concrete objectives and targets.

The Sprint Backlog

Once a sprint goal has been developed, the team then generates a sprint backlog by selecting high-priority items from the product backlog to focus their attention on. They may ask the product owner for additional details about the items, to ensure that they fully understand the need and purpose for each. (They may also contact other practitioners or stakeholders to clarify items or provide additional information before selections are made.) Team members then discuss their selections in detail to determine how they will tackle the tasks and activities needed to meet their objectives.

Estimating

To generate a practical and functional sprint backlog, Agile team members will have to estimate the amount of work that they can take on in the sprint timebox. They may use several Agile tools (i.e., story points, Planning Poker, t-shirt sizing, and Wideband Delphi) as they prepare their estimates but will have to do so as accurately as possible to ensure success.

The discussions centered on the estimates may be as important as the estimates themselves; the conversations entered into may uncover hidden pitfalls or unexpected risks that would otherwise have gone unnoticed. Open discussions may also foster a sense of inclusion and synergy as the team explores creative options and collaborates on perfecting their estimates.

Definition of Done

During sprint planning, the team should agree on what it means for a product or product increment to be done. Team members often assume that all stakeholders are defining this term in the same way, but these definitions may deviate significantly. For example, one person involved in a project may believe that "done" means that the product is ready for implementation at the end of the sprint; another person on the same project may think that "done" indicates that the product is ready to be shipped to customers. By failing to define done in common terms, the individuals have misunderstood the status of the product, which may cause confusion and result in unfulfilled requirements and unhappy customers.

Teams do not have to spend time doing extensive research to find a standard "textbook" definition for the term; they simply need to agree on a comprehensive definition that all team members and project stakeholders are willing to accept. They may even create different definitions of "done" at different levels (i.e., they may define "done" at the sprint level differently from the way they would define it at release or project level). Regardless of the choices the team decides to make, they need to ensure that, at the end of the process, all parties agree. Although coming to agreement may require some work (and may seem trivial to some practitioners), this decision is crucial to ensure that work is not missed and expected quality is not overlooked.

3-15 Exercise: Sprint Planning

Exercise: Sprint Planning

You are part of a team that is beginning its sprint planning for the next phase of a project. After reviewing the product backlog and requirements with the team and the product owner, you have calculated the story points and discussed the priority levels of each item. The prioritized product backlog is listed below:

Requirement Story Points Priority A 14 High B 13 High C 10 High/Medium D 8 Medium

You then collectively decide that, based on the team's velocity, the sprint could include a maximum of 25 story points.

Which combination of requirements should the team select to best meet the customer needs?

Click on the check mark below for the correct answer.

The best combination would be to include requirements B, C, and H. Adding the story points for these requirements results in a total of 25 points. While there may be other combinations that would give you 25 points (or combinations that total 25 points and have more requirements in the combination), combination BCH includes the highest priority items (1 high priority item, 1 high-medium priority item, and 1 very low priority item) and still fits within the 25-point maximum.

What would happen if a new high priority requirement (requirement I) worth 11 points was added to the product backlog? Which combination would then be the best one for the team to accomplish?

Click on the check mark below for the correct answer.

With the inclusion of this new high priority item, the best combinations to complete could be either combination AI or combination BI. The story point total for combination AI would be 25 points. For combination BI, the total would be 24 points. Both combinations would include two high priority requirements. Because both combinations would fit within the 25-point maximum and both would include the same number of high priority items, the team would have to have a discussion to decide which combination to choose; further discussion may uncover a compelling reason to choose one combination over the other.

3-16 Contingency and Management Reserves

Contingency and Management Reserves

When practitioners are planning and estimating projects, they will need to establish reserves to deal with the risks associated with project work. A reserve is the amount of time (and/or cost) allocated to a project to account for risk.

Contingency reserves (also called contingency allowances) are established to deal with "known unknown risks" and accepted known risks. They may be in the form of additional time, money, or resources, and cover risk events that are not accounted for in project duration and cost estimations. Contingency reserves should include enough money and/or time to implement contingency plans (to deal with known risks), as well as a buffer for dealing with unidentified risks.

Management reserves are meant to cover unplanned/unpredictable changes in project scope, time, and cost (sometimes called "unknown unknowns"). Management reserves are often included in the total project budget but are generally not included in project cost baselines.

Types of Contingency Reserves

Contingency reserves can be broken down into schedule reserves (which establish time in the schedule to deal with risks) and budget reserves (which cover money). Typically contingency reserves are determined at the outset of a project, but they may be adjusted or modified during the project life cycle.

While there is not a standard formula for calculating the size of contingency reserves, the project team should take a variety of factors into account, including:

E 6 Medium/Low F 5 Low G 4 Low H 2 Very Low

Contingency Reserve Best Practices

Some best practices related to contingency reserves relate to how they are used and how they are communicated to the team. A rule of thumb is that reserves should only be used for problem-solving. A project manager may be tempted, for example, to use schedule reserve to handle scope creep or other risks. This behavior will inevitably lead to greater project risk overall.

The way that reserves are communicated among the team will differ from project to project. In some cases, the reserves are known to all. In other instances, they are only discussed among the project leaders. In general, open communication is preferred. However, knowledge of reserves can lead to scope creep and Parkinson's law ("work will expand to fill the time available for it"). One technique that can be used to prevent this phenomenon is to reward teams for any unused reserve at the conclusion of the project. The reward should be proportional to the amount of reserve that remains—the larger the untouched reserve, the larger the reward for the group.

3-17 The Cost Baseline

The Cost Baseline

Another important baseline needed early in the project is the cost baseline. The cost baseline is the budget used to measure, monitor, and control the project's overall cost.

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

Click on each of the headings below for more information.

Estimating Costs

To estimate the cost of the project, project planners must first take into account all of the costs that will be incurred to produce the project's deliverables.

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

While developing cost estimates, it is important to review any existing documentation to uncover information that will facilitate more effective estimation. For example, the milestone chart and network diagram should be reviewed to see if they include a due date that will require higher-than-usual labor or other costs to meet. The scope statement and work breakdown structure should be looked at to ensure these estimates include costs for all of the activities that are planned for within the project. And records from previous projects and lessons learned should be consulted to expose costs that may have been overlooked.

Finally, it may be helpful to record the project team's confidence that estimates are accurate by describing the confidence level for the estimated cost and the range of possibility for actual cost. For instance, the team 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

After completing the cost estimates for the individual activities in the project, the next step is to aggregate those estimates into a cost baseline.

The cost baseline is a graphic form of the budget, which helps compare actual expenses to planned expenses. Any differences between actual and planned expenses should alert the project team to potential problems and help the team decide whether or not to take action 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 lines on the graph for a quick comparison.

When using 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 the project team will need to take action 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.

Analyzing Cost Performance

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

If a project is off track, there are 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 chosen response, it is the project manager'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.

Video Commentary: Managing the Cost Baseline

What Is a Cost Baseline, How Do You Manage It, and How Is It Connected to Other Parts of the Project?

Rich Maltzman

So the first thing to note is that the cost baseline and the budget are not the same thing. The cost baseline is going to include contingency monies, for example. The budget is something that is static, where the cost baseline could be changed - with change control - could be changed. Also the cost baseline is a time-phased plan for spending your money.

That could mean, for example, that if your project is a January-to-December project and you have most of the work taking place in July, August, and September, that you might have $40,000 a month spent in those months, with only $5,000 a month spent in January through May. So it's a time-phased budget, meaning that money is spent at different rates as you move through the project. Whereas the budget is just some number, like $300,000.

So you'll see a lot of connections here. There's a lot of integration in this concept. The fact that you're going to be spending money at different times in the project connects us to schedule management. The fact that we have contingency is a reaction to risk.

So there's a lot of integration here. If you're familiar with earned value and especially the graphics that come up in earned value (the S curve - the famous S curve which indicates the planned value spend over the life of the project), that's your cost baseline if you then add the contingency fund to that.

3-18 Managing Cost and Schedule with Agile

Managing Cost and Schedule with Agile

As change-driven approaches and adaptive techniques become more popular in project management, it can be difficult for some executives to transition to these new ways of working, especially those who are accustomed to detailed reporting and tight controls.

Projects run with Agile processes include a degree of uncertainty; there are no detailed project plans or lists that specify what will be created, when it will be available, and how much it will cost to produce. As a result, executives who have spent their careers in a traditional project environment may struggle to adapt their management style to this less-documented approach.

To help senior managers better understand Agile practices and deal with the organizational transformation, project managers should be prepared to do the following:

Click on each of the headings below for more information.

Create a Budget

For some projects, budgeting is easy; the budget is predefined, and the release will include as many features as can be created within the budgeted total amount. The product released typically will satisfy many (if not all) of the most important customer requirements because each iteration is designed to include as many of the highest priority items from the product backlog as possible.

For those projects that release products only after a certain number of features have been completed, budgeting can be problematic. Management may be reluctant to commit resources to projects that, by their very nature, are open-ended—the requirements are incompletely defined and the release date unknown. To overcome this reluctance, it may be helpful to have the team develop a high-level view of the project first to set the project boundaries. Then, the project manager can suggest that senior management use these boundaries to decide how to fund the project. This will still allow the team room to adapt its work to best achieve the project's objectives but will assure management that the project will not exceed the preset boundaries.

As an alternative, the project manager can suggest to management that they set up initial funding for the project, then review project progress after a certain number of iterations to decide if funding should be continued. In this way, management can terminate funding for any projects that are not meeting expectations at any point and free up funding for projects that better meet the organization's objectives.

Track the Budget

It is actually easier to track budgets in Agile-based projects than in traditional Waterfall projects. Daily updates to the burndown chart (or burn-up chart) show how many tasks are completed each day; by tracking how much of the budget was expended to complete each task, management can compile an accurate picture (rather than an estimate) of the value that was produced for the costs incurred. (This can also help determine how much it will cost to complete each story point, which can then be used to forecast expenditures for future stories and iterations.)

Create a Schedule

Some projects set a release date and then work to satisfy as many requirements as possible within the allotted time (similarly to using a predefined budget as a constraint, as described previously).

However, if the schedule is not set as a constraint, senior management should decide whether it will use cost or scope as the boundary for the project, then have the team schedule a preliminary planning meeting to discuss how many iterations they believe it will take to create the product. Although this discussion will result in only a rough estimate, the estimate can be refined as the project continues.

Alternately, because an adaptive cycle produces potentially shippable products at the end of each iteration, management can decide when the product will have enough minimally marketable features to be of value to the customer. They can use this point as the low end of a range and set the date when all of the features will be completed as the range's high end. The range can then be refined and updated as the project progresses.

Track the Schedule

Much like tracking budgets in adaptive projects, tracking schedules can also be easier than tracking with traditional project-scheduling methods. Iteration reviews, team velocity, burn charts, and timeboxes make it easier to track real progress against the remaining schedule and to forecast future results.

For organizations to be successful in adopting adaptive techniques, senior executives must adjust their management style to align with the work of their teams. For many managers, this transformation can prove difficult. They have to leave old management ideas behind and adapt to new methods and practices. Those that are able to adapt create options and opportunities for organizational success.

3-19 Quality Planning

Quality Planning

No project can be successful unless its deliverables conform to specifications; a project's quality is the degree to which the project will meet those specifications.

A recurring theme in successful projects is that quality is planned into the project from the start—it is not "tacked on" to the project end or handed off to another group as "their responsibility." Quality should be everyone's responsibility, so quality tools and techniques should be employed to ensure that this important concept remains foremost in everyone's thoughts.

There are several tools that allow a project team to sort data and visualize the extent to which their project results will conform to defined project objectives. These tools provide information in a simple, yet easy-to-understand manner that helps teams address problems and uncover the factors that contribute to those problems.

The Project Manager's Toolbox

Click on each of the headings below for more information.

Affinity diagrams

An affinity diagram helps a team make sense of a large amount of data by grouping ideas into categories that can then be analyzed or evaluated. By sorting data into groups or categories, common themes or patterns emerge that can be used to break through bottlenecks or allow the team to clarify its thinking about quality issues or problems.

By collecting ideas into groups, affinity diagrams allow practitioners to uncover hidden relationships (like "common causes of defects") that may not have been noticed before. The sorting process helps to filter and sift through ideas, tying concepts together and creating consensus about issues before additional work is begun. The collaborative way that affinity diagrams are developed helps to ensure that all viewpoints are considered and prevents dominant personalities from taking over the process.

A Sample Affinity Diagram Showing Common Complaints from Restaurant Customers

Affinity diagrams are useful for gathering and organizing ideas so they can be acted on or further developed. These diagrams allow teams to analyze a lot of verbal or qualitative information so it can be used as an input to subsequent work. Affinity diagrams show common threads among ideas and allow patterns to emerge, preventing teams from the paralysis that may ensue from trying to work with such large amounts of data. And although these diagrams may take some time to develop, the time spent here organizing information will be balanced by the amount of time saved later trying to make sense of unsorted data.

Cause-and-effect diagrams

Cause-and-effect diagrams (which may also be called Ishikawa diagrams, fishbone diagrams (because they look like fish skeletons), or why-why diagrams) help project teams determine why a problem is occurring. Boxes representing contributing causes to the main problem feed into the main problem's line. Causes are arranged according to their level of importance or detail, resulting in an image that shows the hierarchy of events that are leading to the problem. Once all of the contributing causes are mapped, project team members will be able to answer the question of "why" or "how" something happened. They may also have a better understanding of the root cause.

To create a cause-and-effect diagram, the creator must first identify the correct problem to be studied. Afterward, "nodes" or "branches" can be filled out, moving from the problem through each line of causality back to the root cause, as shown in the image below.

A Sample Cause-and-effect Diagram

If some areas are relatively empty, they might be able to be attached to other places. By contrast, overcrowded clusters might need to be broken out into separate lines of causality. Once completed, team members can pinpoint which root causes warrant investigation, or they may agree on how they need to be immediately addressed.

Checksheets

A checksheet is a structured form or table that practitioners use to count how many times an event or problem happened or to record when or where something happened.

Checksheets are easily adapted to any need and can be as simple or as complex as necessary. Some teams create simplistic tables to track data in clear-cut categories, while others create more complex matrices or draw pictures of a part or process and keep count of the defects or occurrences directly on the image they created.

A Sample Check Sheet

Control charts

A control chart is a graphic display of the data for a repeated process over time in relation to established control limits. It has a centerline that is drawn using the ideal values of process data, and that centerline assists in detecting a trend of plotted values toward either control limit.

Generally, the specification limits—the tolerance within which variation will be acceptable for project delivery—are determined by a contract or other official agreement. In contrast, control limits are usually determined by statistical calculations that reflect the natural capability of the process.

Control limit lines (that represent the upper and lower control limits) represent the values that a project measurement can have without necessitating corrective action. Common practice suggests that, for repetitive processes, control limits are often set at ±3 standard deviations from the ideal value. (Three standard deviations will contain most of the population—99.7%—in a bell curve.) If a data point falls out of the control area (or if the control chart shows some other deviation), the project is usually considered to be out of control, and the management team will have to decide how to change processes to bring the project back under control.

The example below shows how a project management team might use a control chart to manage the variation of items that should fall within a fixed limit. In this example, casino dice are required to have a tolerance of no more than .0005 inches. The chart shows that as each of the dice is measured, the variance gets progressively larger (which may suggest that a mold needs to be replaced because of repeated use). Once the measurements exceed the control limit, the project management team will need to take action. If the dice exceed the specification limit, the customer will not accept delivery because they cannot legally be used.

Note: During the planning process, the project management team will want to determine what the upper control limit will be. If statistical sampling is used—for instance, if only three dice from each lot are to be measured—the sample size will need to be set during the Planning stage as well.

Flowcharts

A flowchart is a graphical format that shows the relationships and interfaces between project activities.

Flowcharts can be either high-level (with little to no detail) or very detailed. To create a flowchart, practitioners define the process boundaries by picking the beginning and end points, then clearly define the relationships and steps within, including decision points after any steps that, if completed incorrectly, could create delay in the project.

The image below is a portion of a flowchart, showing ovals as start and end points, standard rectangles for operational steps, diamonds for decision points, and arrows to show sequence. Other symbols that could be used include a rhombus indicating material entering or leaving the system, and a circle with a letter inside or a baseball "home plate" symbol indicating that the flow continues elsewhere at a matching letter or symbol.

Activities that identify potential issues with quality (i.e., reviews or inspections) can be placed in flowcharts at important points in the project's schedule. In this way, the project's documentation will make it very clear that the role of these quality activities is to ensure that issues are resolved before the project's work progresses.

Histograms

A histogram is a bar chart that illustrates how occurrences can be sorted by the variables, causes, or attributes of that occurrence. In quality management, each of the bars can represent a contributing cause of variance in process or product quality. After looking at a histogram, project management teams should be able to answer 1) how often a variance state occurred and 2) how often it was attributed to each of the several identified causes.

Please click on each of the items in the legend to the left to read its definition.

Upper Specification Limit

The upper specification limit shows the maximum positive variation from the goal allowable before the project will be rejected by the customer. It is usually based on stipulated limits imposed by the contract.

Upper Control Limit

The upper control limit shows the maximum positive variation from the goal allowable before the project manager should take action. It is usually set by the project manager or the organization.

Goal

The goal or mean line shows the planned or ideal value. Ideally, all data points would be on this line.

Actual

The actual line shows the actual numerical value of the characteristic being measured

Lower Control Limit

The lower control limit shows the maximum negative variation from the goal value allowable before the project manager should take action. It is usually set by the project manager or the organization.

Lower Specification Limit

The lower specification limit shows the maximum negative variation from the goal allowable before the project will be rejected by the customer. It is usually based on stipulated limits imposed by the contract.

A Pareto chart is a specific type of histogram that sorts the variables or attributes from "most frequently occurring" to "least frequently occurring." Pareto's Law (also known as the 80/20 principle) suggests that 80% of the problems with a product or process can be attributed to 20% of the causes. After looking at a Pareto chart, project team members should have a good understanding of the primary cause(s) of a problem (i.e., the "vital few") and be able to focus their efforts and resources on solving those causes.

Matrix diagrams

A matrix diagram shows how strong the relationships between items or sets of items are. Items from one group are compared to items in another group; the comparisons are then compiled in a table for analysis and easy reference. The results from these comparisons help to expose gaps that should be addressed and focus the team's attention on high priority areas that should be tackled immediately.

The cells of a matrix diagram can be populated using a variety of designations or "markers" such as letters, numbers, symbols, or colors to show how strongly items are related. Some common markers are included in the table below:

Relationship Numbers Letters Symbols Colors

Strong 9 H (High)

Medium 3 M (Medium)

Weak 1 L (Low)

The choice of which markers to use is up to the team developing the matrix diagram, but care should be taken to ensure that anyone looking at the matrix will understand the information it contains. To prevent confusion, it is often helpful to include a legend with the diagram to explain what each marker means, to help interested parties read the chart with a minimum of problems.

It is also important to leave a significant gap between the marker for strong relationships and the marker for medium relationships, to dramatically separate these items from each other as they are ranked. If this gap is not large enough, it may be difficult to spot the differences in the data, especially if numbers are used and the columns or rows are averaged or totaled. (This explains why there is such a large numerical gap between the "9" assigned for strong relationships and the "3" assigned for medium relationships; if a "5" was used instead of a "9," the totals or averages calculated for each row or column may not be separated enough to be noticed.)

L-shaped Diagram Comparing Satisfaction Levels

Mind maps

Mind-mapping is a highly visual and efficient way of organizing ideas. It links concepts or ideas in a series of appended branches, to systematically yet creatively explore options and quality alternatives.

A Sample Mind Map

Scatter diagrams

Scatter diagrams plot data points as dots on an XY axis to show possible correlations between two variables. The dependent variable is usually the variable that project practitioners hope to find the cause for; by plotting the independent variable against the dependent variable, they can determine if a correlation exists. (If the dependent variable goes up or down as the independent variable goes up or down, the team has discovered a correlation between the variables.)

As shown below, there are several correlative relationships that can emerge in scatter diagrams.

Slide 1

Strong Positive Correlation

The value of Y clearly increases as the value of X increases.

Slide 2

Weak Positive Correlation

The value of Y subtly increases as the value of X increases.

Slide 3

Strong Negative Correlation

The value of Y clearly decreases as the value of X increases.

Slide 4

Weak Negative Correlation

The value of Y subtly decreases as the value of X increases.

Slide 5

Complex Correlation

The value of Y clearly seems to be related to the value of X, but the relationship is not easily determined.

Slide 6

No Correlation

There is no correlation between the two variables.

After reviewing a scatter diagram, practitioners should be able to identify when two variables are correlated. It is important to note, however, that correlation does not always imply causation; there may be a root cause on which the two observed variables are dependent. In such an event, both observed variables might actually be caused by the other, hidden variable.

3-20 Exercise: Quality Management Tools

Exercise: Quality Management Tools

3-21 Managing Human Resources

Managing Human Resources

One of the tasks that project leaders should perform as they plan their projects is to develop their human resource management plan to help in directing and coordinating the many people who will be involved in project work. In creating an effective plan, project leaders will need to work to identify and document the roles, responsibilities, required skills, and reporting relationships for the project, to ensure that necessary resources will be ready to participate when needed and to prevent misunderstandings that will block the project from meeting its intended goals.

Creating the Human Resource Management Plan

A project's human resource management plan describes the ways in which project practitioners can utilize organizational resources and policies to improve the chances for overall success. It explains how roles and responsibilities, reporting relationships, and staff management will be addressed and structured throughout a project.

To produce the human resource management plan, project leaders often consult with subject matter experts and human resource specialists to ensure that an appropriate plan is in place given the requirements of the project, the organization, and any applicable government and union contracts that may apply. As they structure their plan, project participants will also need to consider the organizational, political, environmental, and interpersonal human resource factors that could impact the project's success; these often overlooked factors could be the difference between well-integrated, effective resource management and a tangled knot of individuals who cannot fulfill their obligations.

Constraints and Limited Human Resources

Effective resource management is concerned not only with identifying which human resources will be necessary to complete project activities, but also pinpointing when and how long those resources will be required. Human resources—like most other resources—are limited, and may have to be shared between projects. It is important for practitioners to ensure that appropriate personnel are involved when and where they are needed, but not tied up unnecessarily if their services are not immediately required.

Resource Constraints and Resource Calendars

Project practitioners may be constrained by several factors that will limit the use of project human resources. Important resources may only be available to assist in short, specific windows of time. Contracts, collective bargaining agreements, or other formal agreements may impose restraints on the use of specific resources or resource types. And, in some cases, individuals may be "pre-assigned" to work on a project due to contractual obligations or other promises made in a project charter.

To help understand and coordinate the requirements and timing of a project's human resources, practitioners should consider using a resource calendar to document when each resource will be needed.

Resource calendars show how much time each resource will be needed on a project and aggregate this information for quick and easy understanding by interested parties. They may list required resources by name (e.g., Karla, Ray), type (e.g., software developer, tester), or department or function (e.g., product development, quality assurance), but should be very specific about the time frame and quantity of resources needed. In some cases, practitioners may include maximum allowances or other project limits in their calendars to help in coordinating and scheduling resources appropriately.

If a resource calendar shows that available resources and project constraints are in conflict, project participants may need to apply resource leveling or resource smoothing techniques to realign resources and needs. Resource leveling adjusts the start and finish dates in the schedule to align with resource availability. Resource smoothing spreads project activities out among several resources so that work can be completed without exceeding predefined limits or a specific resource's capability or workload.

Video Commentary: Resource Optimization Techniques

Resource Optimization Techniques

Richard Maltzman

Resource Optimization Techniques

Richard Maltzman

What's the difference between resource leveling and resource smoothing--two terms that sound very similar?

They are both used to account for over-demand for resources on a project. Resource leveling ends up changing the timeline of the project, possibly affecting the critical path. I like to think of resource leveling as pushing down on the bar chart and that's going to squish out the end date a little bit because the start date is fixed and the end date is going to move out.

Resource smoothing, on the other hand, is used only on activities that have some built in float or slack. In other words, those are off the critical path and therefore will not change the critical path-- unless you push too hard on them and they become part of the critical path (again, a science unto itself).

Resource Histograms

To evaluate whether personnel requirements align with resource availability, practitioners may choose to create a resource histogram like the one below.

A resource histogram is a bar chart that illustrates how many hours a person, group, or project team will be needed in order to complete the project work. These charts often include a horizontal line that indicates the maximum availability of a resource; if a resource's bar exceeds this line, the project team will need to come up with solutions to explain how they will resolve this impediment—by changing the requirements, adding resources to the project, or adjusting the work to be spread among several resources.

As can be seen in the chart below, histograms can illustrate the different types of resources needed. The activity-specific chart on the left shows the number of hours that Julie, John, and Sam will be needed to write code for a program. The functional chart on the right shows the total hours that organizational units or functions will be available to the project team.

The activity-specific calendar is for the activity "Writing code for program." The legend shows that Julie, John, and Sam will be the coders, and the monthly maximum for each of their hours combined is 62. January has Julie coding for 12 hours, John coding for 10 hours, and Sam coding for eight hours. February shows Julie coding for 12 hours, John coding for 20 hours, and Sam coding for five hours. The numbers for March, April, and May are given as well, but in no case does the sum total more than 62 hours.

The functional resource calendar on the right is for the entire project; it shows when and how long the IT, engineering, and marketing departments will be working on this project. The chart reveals that a problem currently exists that will need to be resolved—specifically, that the required resources substantially overrun the maximum monthly allowances of 40 hours for all departments.

In this situation, the project team can apply one or both of two primary strategies: 1) acquiring additional resources or 2) rearranging the schedule so that the resources available fulfill the new requirements. When human resources are constrained (as in the right-most chart in the example above), and work is not able to be rescheduled (if, for instance, the project is working under a tight deadline and the work is on the project's critical path), the project management team will need to document how additional staff will be acquired to complete the work on schedule.

Review Checkpoint

1. Bjorn has just realized that he doesn't have enough programmers to finish his team's assigned tasks on time, so he decides to adjust the schedule's start and finish dates to align with his available resources. What is this called?

a. resource scheduling

Incorrect. Try again.

b. resource smoothing

Incorrect. Try again.

c. resource leveling

Correct. In resource leveling, the start and finish dates in the schedule are adjusted to align with resource availability.

d. resource spanning

Incorrect. Try again.

2. What does a horizontal bar across the middle of a resource histogram signify?

a. the maximum availability of a resource

Correct. A horizontal bar running across a resource histogram shows the maximum amount that a specific resource can be made available to work on project activities.

b. the minimum availability of a resource

Incorrect. Try again.

c. the total number of hours a project activity will take

Incorrect. Try again.

d. the total number of people that will be needed on the project

Incorrect. Try again.

3-22 Exercise: Resource Constraints and Limited Availability

Exercise: Resource Constraints and Limited Availability

3-23 The Responsibility Assignment Matrix

The Responsibility Assignment Matrix

As part of project resource management, project practitioners will need to begin assigning work to individuals. A simple, pragmatic way to track the work assigned is to use a responsibility assignment matrix (RAM). A 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).

The RACI 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.

3-24 The Procurement Management Plan

The Procurement Management Plan

In some instances, a project team may find that it needs to purchase goods and services from outside its project environment to meet its objectives. In such cases, it may be helpful to have team members develop specific procurement management plans to help them plan for, execute, and monitor their procurement activities.

The procurement management plan will explain how procurement management outputs—like the procurement statements of work, make-or-buy decisions, procurement documents, source selection criteria, change requests, etc.—will be instituted. An effective procurement management plan will address several important concerns, as described in the graphic below.

The procurement management plan should be developed early in the planning process to help define procurement roles and responsibilities as quickly as possible. It should explain whether bids will be solicited at an international level or only at a national or local ones. It should also closely align with the project's scheduling and funding limit reconciliation policies to prevent possible disruptions or inconveniences in project progress. Finally, it must be developed in accordance with the project's other baselines to ensure a seamless integration of procurement activities into project operations.

3-25 Contract and Vendor Management

Contract and Vendor Management

There are several steps that project practitioners will need to take to manage their procurement 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.

Click on each of the headings below for more information.

Deciding What to Acquire

To help decide what resources will be needed on the project, project participants will need to 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 will be necessary to complete the needed work. They should then decide if there are resources in-house to complete the work or if there is budget available to acquire outside help.

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

If resources or services from outside sources need to be procured, the project team should put some thought into this process to ensure that it goes as quickly and smoothly as possible. The team should 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. They'll need to consider the time and effort that managing an outside relationship will take and adjust plans as needed. And they'll need to 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, the process should be tailored 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 misunderstandings as to why a specific vendor was chosen.

Selecting and Negotiating the Contract

In many cases, project managers 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 monitor contract performance throughout its existence. They will need to be sure that they close the contract appropriately.

They will also need to agree with suppliers and vendors on a contract type (i.e., a fixed-price contract, a cost-reimbursable contract, or a hybrid of these two forms) that will meet both parties' needs and satisfaction.

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.

3-26 The Risk Register

The Risk Register

To run a project effectively, project managers will 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 recognize and manage it properly. 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 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 managers 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 which tools are used, the risk register can help ensure that project risks are continuously identified and appropriately managed.

Developing the Risk Register

Click on each of the highlighted boxes below for more information.

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.

Module Feedback

[feedback|module]

Risk ID Number

1. Provide an identification

number for each risk. This will

allow participants to discuss each

risk by its number, making conversations

easier.

Risk

2. Describe the risk in clear,

simple language. Classify the risk

as either a positive or

negative event.

Probability

3. Record the probability of the event occurring

(as "high," "medium," "low,"

or any combination of these ratings).

Then, work with the project team

(and possibly other important stakeholders) to

explain what each rating ("high,"

"medium-high," "medium," etc.)

means.

Impact

4. Record the impact (as

"high," "medium,"

"low," or any combination of

these ratings) to the project if the

risk occurs. Again, work with

the team (and stakeholders) to define what each

rating means.

Risk Score

5. Combine the probability and impact into a

risk score. The risk score offers a simple way to prioritize risks

and show which ones need to be

carefully monitored.

Response

6. Describe the response that

will be implemented if the risk occurs. Include as much information as necessary to

illustrate these plans.

Responsibility

7. Clearly identify the person responsible for monitoring and

addressing the risk, should it occur.

Status

8. Record the status of risks as either open (i.e., they could still

potentially occur) or closed (i.e., the risk has been addressed

or the chance that the risk will

occur has passed).

Comments

9. Record any important

information about the risk that

doesn't fit into the other columns of

the register.

1 2 3 4

Module Three: Project Planning

Module Three: Project Planning
Learning Outcomes

3-1 Module Three Pre-test

Module Three Pre-test

3-2 Planning the Project

Planning the Project

Creating an Appropriate Plan
Tailoring the Plan

Factors, Constraints, and Considerations

Agile Planning

3-3 The Project Management Plan

The Project Management Plan

Tailoring the Plan

3-4 Exercise: The Project Management Plan

This assignment does not contain any printable content.

3-5 Planning a Project with Agile Techniques

Planning a Project with Agile Techniques

The Project Manager's Toolbox
Burndown Chart
Burn-up Chart

3-6 The Work Breakdown Structure

The Work Breakdown Structure

Work Packages
The Parts of a WBS
Developing the WBS

Slide 1
Slide 2
Slide 3
Slide 4
Slide 5
Slide 6
Slide 7

3-7 Scheduling

Scheduling

The Gantt Chart
An Example

3-8 The Network Diagram

The Network Diagram

Example of a Network Diagram
Building the Diagram

3-9 Identifying the Critical Path

Identifying the Critical Path

The Forward Pass

A Sample Forward Pass

The Backward Pass

A Sample Backward Pass

Critical Path Determination

Exercise

3-10 Estimating Techniques

Estimating Techniques
Review Checkpoint

3-11 The Program Evaluation and Review Technique

The Program Evaluation and Review Technique
Video Commentary: Three-Point Estimating

PERT and Statistical Confidence

Review Checkpoint

3-12 Exercise: Estimating Using PERT Calculations

Exercise: Estimating Using PERT Calculations

3-13 Estimating With Agile Techniques

Estimating With Agile Techniques

The Project Manager's Toolbox

3-14 Sprint Planning

Sprint Planning

Sprint Planning Activities

3-15 Exercise: Sprint Planning

Exercise: Sprint Planning

3-16 Contingency and Management Reserves

Contingency and Management Reserves

Types of Contingency Reserves
Contingency Reserve Best Practices

3-17 The Cost Baseline

The Cost Baseline

Analyzing Cost Performance

Video Commentary: Managing the Cost Baseline

3-18 Managing Cost and Schedule with Agile

Managing Cost and Schedule with Agile

3-19 Quality Planning

Quality Planning

The Project Manager's Toolbox

A Sample Affinity Diagram Showing Common Complaints from Restaurant Customers
A Sample Cause-and-effect Diagram
Activity: Cause-and-effect diagram
A Sample Check Sheet

Control Chart: Deviation of Casino Dice Dimensions from Mold Dimensions

Flow Chart

L-shaped Diagram Comparing Satisfaction Levels

A Sample Mind Map
Slide 1
Slide 2
Slide 3
Slide 4
Slide 5
Slide 6
Example: Scatter diagram

3-20 Exercise: Quality Management Tools

Exercise: Quality Management Tools

3-21 Managing Human Resources

Managing Human Resources

Creating the Human Resource Management Plan
Constraints and Limited Human Resources

Resource Constraints and Resource Calendars

Video Commentary: Resource Optimization Techniques

Resource Histograms

Review Checkpoint

3-22 Exercise: Resource Constraints and Limited Availability

Exercise: Resource Constraints and Limited Availability

3-23 The Responsibility Assignment Matrix

The Responsibility Assignment Matrix

The RACI Chart

3-24 The Procurement Management Plan

The Procurement Management Plan

3-25 Contract and Vendor Management

Contract and Vendor Management

3-26 The Risk Register

The Risk Register

Risks and the Project Life Cycle
Tracking Risks with a Risk Register
Developing the Risk Register
The Risk Register as a Tool

Module Feedback

Module Feedback