6th Edition PMBOK® Guide–Process 6.6 Control Schedule: Tools and Techniques


In controlling the schedule, you monitor the progress being made on the project and compare it to what’s in the plan using data analysis techniques.   You use some of the same tools used to create the schedule, i.e., the critical path method, resource optimization, leads and lags, as well as schedule compression, in order to identify risks to the schedule and to come up with ways to mitigate them with preventive action if necessary.   This post will cover these tools and techniques.

6.6.2  Control Schedule:  Tools and Techniques

6.6.2.1  Data Analysis Techniques

  • Earned value analysis–this is a technique which takes a measure of the triple constraints of scope, time and cost, and in the case of either the schedule variance or schedule performance index, can give you an idea if you are ahead, behind, or on schedule
  • Iteration burndown chart–in agile methodology, this charts the remaining work to be completed in the iteration backlog (see Figure 6-24 on p. 226 of the PMBOK Guide for an example), and a trend line is calculated to forecast completion based on the remaining work.   This replaces earned value analysis as a form of variance and trend analysis used in agile environments.
  • Performance reviews–these are not HR reviews of the personnel on the team, but rather reviews of the performance of the project as compared to the schedule baseline.
  • Trend analysis–reviews project performance over time to determine whether it is improving or deteriorating.   Even if the project is not behind schedule now, it may be at some point in the future if a negative trend continues.   In this case, a preventive action might be recommended.
  • Variance analysis–this is not just the detection of a variance between the actual work done and the work scheduled to be done, but if there is a variance, the source of that variance is investigated.   This will suggest a possible corrective action to bring the project back on schedule.
  • What-if scenario analysis–there may be positive opportunities listed in the risk register which, if pursued, may bring the actual performance of the project back to the schedule model.

6.6.2.2 Critical Path Method

  • If activities are showing a delay compared to the schedule, it is important to identify whether they are on the critical path.   If they are, then there is a risk that the schedule deadline may be delayed, and it is very important that these activities on the critical path be brought back into line with the schedule model.

6.6.2.3 Project Management Information System (PMIS)

The software used to create the schedule is a tool which can also be used to alter the schedule if necessary.

6.6.2.4  Resource Optimization

Resource leveling and resource smoothing are techniques which adjust the duration of activities to fit the constraints of the workplace (8-hour workdays for example) and of the individuals themselves (some may only be able to work for a few hours per day).   If activities have to be adjusted as a corrective or preventive action, it may be necessary to take into consideration the resource optimization techniques.

6.6.2.5 Leads and lags

If there are two activities that occur one after the other, and there is a need to shorten their duration, it may be possible to move the start date of the successor activity back, in other words, to create a certain lead time so that the start date of the successor activity happens while the predecessor activity is still going on.   This is actually a schedule compression technique (see next paragraph), and can be used as a corrective or preventive action to bring the work back on schedule.

6.6.1.6  Schedule compression

If there is a delay in some of the activities related to a particular work package, one of the corrective actions required may be shorten the duration of the remaining activities, and schedule compression may be a way of accomplishing this, either by crashing (adding resources to the activities) or fast-tracking (taking the successor activity and advancing the start date so that it is done partially in parallel with the predecessor activity).

With these techniques, the outputs of the process will be information that can be turned into reports to the stakeholders.   If variances are detected, an analysis of them during this process may result in possible change requests to bring the work of the project back on schedule..   These outputs of this process will be discussed in the next post.

 

6th Edition PMBOK® Guide–Process 6.6 Control Schedule: Inputs


We are at the final process for the schedule management knowledge area, namely the Control Schedule process.   The word “Control” tells you we have gone from the planning process group to the monitoring and controlling process group.    Whenever you see “Control” in a process, you should realize it really includes both monitoring (seeing if there is a variance from the plan) and controlling (doing something about that variance if one is detected).

As a monitoring and controlling process, the inputs are coming from the planning process group for the schedule knowledge area and the executing process group, namely, the general process of 4.3 Direct and Manage Project Work.    The outputs are going to go to

  • the general monitoring and controlling process 4.5 Monitor and Control Project Work
  • to the process 4.6 Perform Integrated Change Control if there are any change requests, and
  • any updates to the project management plan and/or project documents.

Let’s go through these inputs.

6.6.1 Control Schedule:  Inputs

6.6.1.1  Project Management Plan

The project management plan consists of a) 9 knowledge area plans, b) 3 subsidiary plans for requirements, change and configuration management, and c) project baselines for the major constraints of scope, schedule, and cost.   The elements that are inputs to this process include:

  • Schedule management plan–this plan, which is the output of the process 6.1 Plan Schedule Management, contains guidelines on how to do all of the other processes, including this one of 6.6 Control Schedule.   Such guidelines include:
    • Project schedule model maintenance–the process used to update the status and record process of the project in the schedule model
    • Rules of performance measurement–how will earned value measurement be used to monitor the schedule
    • Control thresholds–variance thresholds for monitoring schedule performance, so that some action will be needed to be taken if the performance (based on the rules of performance measurement specified in the previous paragraph) varies beyond a certain threshold
    • Reporting formats–in what format, with what frequency, and to whom will reports about the progress on the schedule be made?
  • Schedule baseline–created in the process 6.5 Develop Schedule, the current version of the schedule model is referred to as the schedule baseline and it is the plan against which the actual results will be compared to see if there is a variance.
  • Performance measurement baseline–using Earned Value Analysis, you can calculate a measure of how well the project is doing, either a Schedule Performance Index (SPI) or the Schedule Variance (SV).
  • Scope baseline–This is actually three documents in one:
    • the project scope statement (which breaks down the scope from the requirements to the level of deliverables which fulfill those requirements),
    • the WBS (or Work Breakdown Structure, which further breaks down the scope from the level of deliverables to that of work packages, whose completion you will be monitoring as a part of this process, and
    • the WBS dictionary, which contains information about the work packages such as the duration estimates, also used in monitoring as a part of this process.

6.6.1.2  Project Documents

The project documents used as inputs to this process are (these are arranged by knowledge area)

Integration Knowledge Area

  • Lessons learned register–created as an output of 4.4 Manage Project Knowledge, this is updated in many processes so any lessons learned early on in the project can benefit you later on; in this case, to improve schedule control.

Schedule Knowledge Area

  • Schedule data–particularly the inputs to the schedule model such as the scheduled activities and their attributes, which may end up being updated as a result of this process.   These are processed by the Project Management Information System tool (such as Microsoft Project) to create the project schedule.
  • Project schedule–the output of the schedule model, particularly the most recent version referred to as the schedule baseline.
  • Project calendars–these are the calendars that show the working shifts when resources are available to work on the project.   These are the general calendars that affect the company as a whole, for more specific calendars for each resource, see the “resource calendar” document below.

Resources Knowledge Area

  • This is an output of 9.2 Estimate Activity Resources and shows the availability of physical and human resources to be used on the project.

6.6.1.3  Work Performance Data

An output of process 4.3 Direct and Manage Project Work, this shows for the reporting period in question

  • which activities have started
  • the progress of activities (their actual duration so far, remaining duration, and percent complete)
  • which activities have completed

This data will be compared to the schedule baseline to see if there is a variance, and the output of this comparison will become work performance information which is useful to the project team.

6.6.1.4  Organizational Process Assets

  • Schedule control-related policies, procedures, and guidelines (usually contained in the Schedule Management Plan)
  • Schedule control tools that the company has developed (a software program like Microsoft Project created by another company is considered to be an Environmental Enterprise Factor).
  • Monitoring and reporting methods to be used (also usually contained in the Schedule Management Plan).

With these inputs, we are ready to do the process!   The tools and techniques of this process are contained in the next post.

 

 

 

 

6th Edition PMBOK® Guide–Process 6.5 Develop Schedule: Outputs (2)


In my last post, I discussed some terminology PMI uses to discuss the schedule, including the schedule model, the project schedule, the schedule baseline, etc., in order to clarify what these similar-sounding terms mean.

With that preliminary discussion out of the way, let me now list the outputs for this final planning process of the schedule management knowledge area.

6.5.3  Develop Schedule:  Outputs

6.5.3.1  Schedule Baseline

The approval version of a schedule model is known as the schedule baseline.   The schedule model basically just means what we normally think of as the schedule–the word “model” is added to emphasize the fact that it can change as the inputs to the schedule change.   During the monitoring and controlling process, the actual schedule is compared to the schedule baseline in order to determine whether there is any variance, i.e., whether you are ahead of or behind schedule.   If there are change requests made that alter the schedule, the new version becomes the new schedule baseline.

6.5.3.2  Project Schedule

The project schedule, the output of the schedule model that you create with a scheduling software tool such as Microsoft Project, presents activities that are linked and have durations, and attributes such as the resources that will do those activities.   Special key dates known as milestones are also a part of the schedule, as these are the ones that stakeholders are particularly concerned about.   The linkages between the activities are shown in a project schedule network diagram.

The schedule model can be presented in tabular form (like in an Excel spreadsheet), but it can also be represented graphically by a bar chart known sometimes as a Gantt chart.  See examples of such a Gantt chart on p. 219 of the PMBOK Guide.

6.5.3.3  Project Data

These are the inputs to the schedule model; they are important because if they change, the schedule model may chart.   These include such information as:

  • Schedule activities
  • Activity attributes (additional information on the activities such as their predecessor and successor activities
  •  Resource requirements for activities

6.5.3.4  Project calendars

These show the portion of working days that are available for scheduled activities on a given project.

6.5.3.5 Change Requests

If there are any change requests for the schedule proposed as a result of this planning process, these are sent to the process 4.3 Integrated Change Control for approval or rejection.

6.5.5.6 Project Management Plan Updates

  • Schedule Management Plan–this plan may be updated to reflect changes in the way the schedule was developed.

6.5.5.7 Project Document Updates

These documents are listed by knowledge area

Integration knowledge area

  • Assumption log–may be updated with assumptions revealed as a result of developing the schedule
  • Lessons learned register–may be updated with techniques that were efficient and effective in developing the schedule

Schedule knowledge area

  • Duration estimates–resource-leveling analysis may require updates in the durations of activities

Resource knowledge area

  • Resource requirements–resource-leveling analysis may require updates in the estimates for the types and quantities of resources required

Risk knowledge area

  • Risk register–opportunities or threats revealed through the analysis of scheduling assumptions may require updates to the risk register

These are the outputs for this final planning process.   As mentioned above, any changes you have to do to the schedule uncovered during the execution of the project will require you to do the next process, 6.6 Control Schedule, which is covered in the next post.

6th Edition PMBOK® Guide–Process 6.5 Develop Schedule: Outputs (1)


The output of the Develop Schedule should be obvious from the title of the process, in other words, the schedule, but PMI has something called the schedule baseline, the project schedule, and schedule data as outputs.

Before I discuss the other outputs of this process, I wanted to clarify some terminology PMI uses.   What is the “schedule model” and what is the relationship between it, the schedule data, and the project schedule?

Remember, you will be using the Project Management Information System or PMIS as a tool of this process, an example of which is Microsoft Project.   It is a computer program, and the project data is the input to the program.    This includes the schedule activities and activity attributes, the outputs of process 6.2 Define Activities and 6.3 Schedule Activities.   It contains information on assumptions that affect best-case and worst-case scenarios, which can affect the “optimistic” and “pessimistic” estimates for any given “most likely estimate”.

Once you use the software on the schedule data, using the schedule network analysis technique of the process, you get the schedule model , the output of the PMIS.   It is called the “model” because it is not written in stone:   it is based on the assumptions that you put into it, and if the assumptions change or new ones become uncovered in the planning process, then the schedule model may change as well.   The current version of the schedule model is called the “schedule baseline.”

With this discussion of PMI terminology out of the way, let’s talk in the next post about the outputs of this process.

6th Edition PMBOK® Guide–Process 6.5 Develop Schedule: Tools and Techniques (3)


In this series of posts, I am discussing the tools and techniques used in the process of developing the schedule.   The overall technique is called schedule network analysis, and it begins with the critical path method, which I discussed in the last post.   It got its own post because it not only is important in its own right, but the questions on the PMP exam  asking you to calculate the critical path of a given network are some of the most time-consuming on the exam, and I wanted to give some guidance on how to answer them.

Here I discuss some of the other techniques used in the process.

6.5.2.3  Resource Optimization

There are two techniques, resource leveling and resource smoothing.   These sound similar, so let’s understand the difference.

  • Resource leveling is when certain critical resources for an activity are only available for a certain quantity per day.   If you have an activity that is scheduled for Monday, and it requires people to work overtime, your boss may prefer that you take some of the work and shift it to the next day so that people are only working 8 hours a day at maximum on the project.    Resource leveling might also occur if one of the resources is splitting his or her time between more than one project.   Say Resource A is working on two projects at once, yours and some one project manager’s project; then his or her maximum amount of time that he or she can spend on your project is now only 4 hours a day at maximum.    If that resource is critical for your project (i.e., can’t be replaced with someone else), and that person is scheduled to work on your project on Monday for 8 hours, then you might have to shift 4 hours of that work to the next day.   You can see how resource leveling might add extra days to the project work to accommodate work rules in terms of maximum amount of hours allowed per day.
  • Resource smoothing–once resource leveling is done, a further shift in resources can be done through resource smoothing.   Let’s say that Resource A is working on an activity for 8 hours during the week.   If the activity has to get done on Friday, there’s no reason why all 8 hours of the work has to get done on Monday.   The work can be spread out to 4 hours on Monday and Tuesday, so that Resource A can have time to work on other projects and/or operational work.    This kind of delay within the free float of four days (since it doesn’t have to completed until Friday) to accommodate the work preferences of resources is what resource smoothing accomplishes.

6.5.2.4  Data Analysis

These are analyses of scenarios that represent the effects on the schedule of various project risks.

  • What-if scenario analysis–by asking the question “how would the schedule be affected if scenario X happens”, you can help create a response plan to address the impact of such a situation if it were to occur.
  • Simulation–this is the “what-if scenario analysis” on steroids, as it models the combined effects of individual project risks.   The most common simulation technique is Monte Carlo analysis which calculates the possible effects on the schedule if certain project risks were to occur.   The result is a probability distribution that says for example, that there is a 90% probability of achieving a project deadline of a certain date.

6.5.2.5 Leads and Lags

Lags are delays after a predecessor activity before a successor activity can take place.   Leads are advances in the successor activity so that it can start taking place even before the predecessor activity has completely finished.

6.5.2.6  Schedule Compression

If you complete your schedule network analysis, and it shows a completion date for the project which is unacceptable, you may have to attempt to shorten the project completion by one of the following two schedule compression techniques.   Each of them has a potential negative affect on one of the other constraints in the project, so you need to be careful when using them.

  • Crashing–adding more resources to get the job done more quickly.   This of course has a negative impact on the constraint of cost.   A typical crashing technique is approving overtime work, or paying to bring in additional resources.
  • Fast tracking–taking two activities which are done in series one after the other and moving up one of them so that it is done in parallel with the other at least during part of its duration.   This has a potential negative impact in terms of risk to quality because it may cause confusion and require some of the work to be redone.

6.5.2.7  Project Management Information System (PMIS)

The software you use for scheduling is a tool rather than a technique.  Microsoft Project is an example of this.

6.5.2.8 Agile Release Planning

In an agile methodology, the project is broken down into releases (from 3 to 6 months out typically), and then each release has a set of iterations that are planned to take place every 2 or 4 weeks.   Each iteration will have a plan to schedule feature development, where the features are prioritized by user stories (the agile equivalent of deliverables), and the user stories are broken down into tasks (the agile equivalent of activities).   See p. 216 in the PMBOK Guide for Figure 6-20 which demonstrates this process graphically.

The next post covers the outputs of the Develop Schedule process.

 

6th Edition PMBOK® Guide–Process 6.5 Develop Schedule: Tools and Techniques (2)


The last post discussed the overall technique of schedule network analysis, which actually consists of a group of techniques.   The first one of these is the critical path method, which is the subject of this post.   If you are taking the PMP exam, you will get a question that will ask you to figure out the critical path for a series of activities.   This is the shortest possible duration of the project, which is figured out by showing which of the paths created by the network diagram is actually the longest or critical one.

The critical path method does the following:

  1. It starts out with the following information given in the question.
  • activities (usually listed with letters of the alphabet A, B, , C, etc.)
  • information on predecessors and successors for each activity, and the
  • duration of each activity

The procedure of using a forward and backward pass to calculate the early start, early finish, late start, and late finish of the activities is the standard way to find out which activities are on the critical path.   The difference between either the late start and the early start, or the late finish and the early finish, give the float of each activity.  If the float is 0, then this means that the activity cannot be delayed without delaying the successor activity.   If the float is some positive number, say 3, this would mean that the activity can be delayed 3 time units (days, weeks, or whatever your network diagram is using as units of time) before the successor activity is delayed.

To determine how long a project will take, you need to find out the critical path, that is, the sequence of activities in the network diagram that is the longest. Other paths along the network will yield sequences of activities that are shorter than the critical path, and they are shorter by an amount equal to the float. This means that activities that have float could be delayed by a certain amount without affecting the schedule. Activities along the critical path have a float of zero. This means that any delay along the critical path will affect the schedule.

Here’s an outline of the critical path methodology.

a. You create a network diagram of all the activities.

b. You label each activity with the duration derived from process 6.4 Estimate Activity Durations.

c. You do a forward pass to determine the early start and early finish date of all activities, from the start of the project to the end of the project.

d. Once at the end of the project, you do a backward pass to determine the late start and late finish date of all activities, from the end of the project to the start of the project.

e. For each activity, you use the results of c and d to calculate the float of each activity.

f. All activities that have 0 float are on the critical
path for that project.

Let’s take a look at the methodlogy in general.

Step 1. For each activity, create a matrix which will contain the duration, the early start, the early finish, the late start, late finish, and float for a particular activity.

Activity Number
Duration
Early Start (ES) Early Finish (EF)
Late Start (LS) Late Finish (LF)
Float

Here are the meanings of the numbers in the boxes:

Activity Number: you can label them A through Z, or 1 through N, just as long as each activity has a unique identifier.

Duration: this is the number that you should get as an output of the 6.4 Estimate Activity Durations process.

Early Start (ES): The Early Start is the number you begin the analysis with to do the forward pass. It is defined as 0 for the first activity in the project. The Early Start for subsequent activities is calculated in one of two different ways, which will be demonstrated below.

Early Finish (EF): This is the next number you go to in the forward pass analysis. It is taken by adding the number in the ES box plus the number in the Duration box.

Late Finish (LF): The Late Finish is the number you begin the analysis with to do the backward pass. It is defined to be equal to the number in the Early Finish box for the last activity in the project. The Late Finish for preceding activities is calculated in one of two different ways, which will be demonstrated below.

Late Start (LS): This is the next number you go to in the backward pass analysis. It is taken by subtracting the number in the Duration box from the number in the LF box.

Float: Once ES, ES, LF, and LS are determined, the float is calculated by either LS – ES or LF – EF. Just remember that a piece of wood will float to the top of the water, so the float is calculated by taking the bottom number and then going upward and subtracting the number that’s on the top of it.

Step 2.

For activity A, the first activity in the project, ES = 0.

A
0

Step 3.

Then EF for activity A is simply ES + duration. Let’s say activity A takes 5 days. Then EF = 0 + 5 = 5.

A
5
0 5

Step 4.

The forward pass for activity A is complete. Let’s go on to activity B.

Since activity B has only one predecessor, activity B, the ES for activity B is simply equal to the EF of activity A, which was 5.

B
3
5

Then the EF for activity B is taken by adding the ES of to the duration of activity B or 3, giving EF = 5 + 3 = 8.

There’s one more situation that we have to discuss and that is if an activity has more than one predecessor.

Let’s assume the durations for each activity are as follows:

Activity Duration
A 5
B 3
C 6

Assume Activity A and Activity B are both done concurrently at the start of the project, and both need to be done in order for Activity C to start. Well, before we do the formal forward pass analysis, what does logic tell us. Activity A takes 5 days; Activity B takes 3 days. Both activity A and B have to be done before Activity C can take place. In this case the start date of the project is considered to be 0. Can Activity C take place on day 3, when activity B is done? No, because Activity A isn’t completed yet, and you need BOTH A and B to be done. The earliest possible start date for Activity C will be day 5, because only on that date will both A and B be done.

So this illustrates the other way of calculating ES for an activity B. If there are multiple predecessors, then the ES is equal to the LARGEST of the ES of the predecessor activities.

Step 5.

Now, let’s assume we are at the end of the project at activity Z.

Z
5
95 100

EL = ES + duration gives us EL = 95 + 5 + 100. So the project will take 100 days according to our forward pass calculation.

Now, we have the backward pass.

We start this out by stating as a principle that the late finish or LF date for the last activity in the project is equal to the EF date.

Z
5
95 100
100

Then, of course, the late start date or LS = LF – duration = 100 – 5 = 95.

Z
5
95 100
95 100

Step 6.

Now we go in the reverse direction towards the beginning of the network diagram, this time filling out the bottom LS and LF boxes for each activity.

If the activity has one successor, then the LF for the predecessor activity equals the LS for the successor of activity. But if there are more than one predecessor activity, then here’s what you do. For the forward pass, you take the highest EF of all predecessors.

For the backward pass, you take the lowest LS of all successors. Let’s see how this works.

Let’s assume the forward pass is done on A, B, and C. We do the backward analysis and we get to the following point. What is the LF of activity A?

A B C
5 3 4
0 5 5 8 5 9
6 9 5 9

Well, activity B and activity C are both successors of A. In this case, activity B has an LS of 6 and activity C has an LS of 5. The earliest LS is therefore 5, and so LS of activity A is 5.

A B C
5 3 4
0 5 5 8 5 9
0 5 6 9 5 9

Step 7.

What is the float? Take LF – EF (or LS – ES) for each of the activities.

A B C
5 3 4
0 5 5 8 5 9
0 5 6 9 5 9
0 1 0

So the float of B is 1, and the float of A and C are 0. Therefore A and C are on the critical path, and activity B is on a non-critical path.   If you needed to compress the schedule, you would do it with activities A and C that are on the critical path.  If you shortened B by one day, however, it would not shorten the overall schedule at all, but would just reduce the float from 1 to 0.

3.  Exam questions

Oh, PMI just loves giving questions on the critical path, and they can be time consuming.  When taking a test with 200 questions, every minute counts, so how can you answer questions on the critical path without having to go through this long and time-consuming process?   HINT:  Most critical path questions can be answered without the forward and backward pass methodology.   How?  Read the next post to find out!

NOTE:   I am going to have to edit this post because the diagrams showing the forward and backward pass did not come out as I had created them and they may be confusing.  If you are reading this note, be patient as I correct the post!

 

 

6th Edition PMBOK® Guide–Process 6.5 Develop Schedule: Tools and Techniques (1)


This is the process where the schedule is finally developed.   In earlier planning processes for schedule management you have

  • listed all the activities you need to complete the project (process 6.2)
  • put the activities in a logical sequence, including the possibility of doing several activities at the same time (process 6.3)
  • estimated the duration of each of the activities (process 6.4)

With these previous processes completed, you can now put the schedule together.

6.5.2 Develop Schedule:  Tools and Techniques

6.5.2.1 Schedule Network Analysis

This is actually a group of techniques, many of which are described in their own section below.

  • the critical path method or CPM (6.5.2.2), which estimates the minimum project duration
  • resource optimization techniques (6.5.2.3) , which adjusts the activity durations to accommodate the resource schedule (i.e. when people are available to work on the project
  • modeling techniques (6.5.2.4), which analyzes risks and their effect on the schedule, resulting in a range of completion dates
  • the use of schedule reserves or buffers to reduce the probability of a schedule slip (sometimes referred to as a critical chain method–not listed in the 6th Edition PMBOK® Guide but referred to in the 5th Edition)
  • the addition of leads and lags between activities (6.5.2.5) as necessary, which adjusts the time of successor activities
  • schedule compression techniques (6.5.2.6), used to accelerate the schedule if necessary to meet required deadlines

I will be doing a summary explanation of these techniques in the sections below.   For examples of these techniques, I will be referring to diagrams in the 6th Edition PMBOK® Guide itself or previous posts I have done for the 5th Edition PMBOK® Guide.   Don’t worry, although these were done for a previous edition of the Guide, the techniques themselves have not changed and the tool (the Project Management Information System such as Microsoft Project) hasn’t changed either.    The one additional tool and technique that is included in the 6th Edition is agile release planning, obviously used only in a case where you are using agile methodology on a project (see section 6.5.2.8).

Since the tools and techniques of this process cover an enormous amount of material, I am splitting them up in several posts.   The next post will cover the critical path method and resource optimization techniques.

 

 

6th Edition PMBOK® Guide–Process 6.5 Develop Schedule: Inputs


This is it:   the final planning process for the schedule management knowledge area.   The first planning process, 6.1 Plan Schedule Management, has as its goal the creation of the overall Schedule Management Plan, which includes all of the guidelines on how to do all the other schedule management processes, including this one.

The other planning processes before this, namely

  • 6.2 Define Activities
  • 6.3 Sequence Activities
  • 6.4 Estimate Activity Durations

take the inputs of one process, use the tools and techniques of that process, and create outputs, which in turn are used as inputs into the next process, etc.   That is why the list of inputs for this final planning process is so long.

One word before we start:   you will hear the phrase “schedule model” used by PMI in connection with this process.   Although the title of the process is “develop schedule”, PMI likes to use the word “schedule model” to remind project managers and the people who interact with them that a schedule is not written in stone.   When you think of the word model, think of the model-building kits you used to play with when you were younger.  They consisted of building blocks and connectors that you could use to make structures out of those building blocks.   For a schedule model,  it is based on the building blocks of activities, but these are connected together with assumptions, facts that are assumed to be true provisionally in order to determine how these building blocks called activities are put together.  If the assumptions end up changing later on, or new ones get discovered during the planning process, then the connections between the activities may end up changing.    Even the size of the activities in terms of duration estimates may change based on a change in assumptions.   So at any given point, the schedule is a model that may change and so that is why you will see the phrase “schedule model” in the PMBOK® Guide.

Okay with that preliminary set of remarks out of the way, let’s list the inputs to this process.

6.5.1 Develop Schedule:  Inputs

6.5.1.1  Project Management Plan

This is the overall project management plan that is put together in the process appropriate namely 4.2 Develop Project Management Plan.   It has several types of components, including a) knowledge area management plans (like the schedule management plan listed below), b) subsidiary management plans like ones for requirements, change, and configuration, c) project baselines for the major constraints of scope, schedule, and cost (see scope baseline listed below), d) project documents (which are outputs of many processes from different knowledge areas–see long list of project documents below), and e) information on the specific life cycle approach (will the project be broken up into phases?) and the development approach (traditional/waterfall, incremental/iterative, agile/adaptive, or a hybrid of these).

The specific components of the Project Management Plan that are inputs to this process are:

  • Schedule Management Plan–created as an output of the appropriately namely process 6.1 Plan Schedule Management, it contains guidelines on how to do all of the other processes of schedule management, including this process 6.5 Develop Schedule.   Some specific information that may be helpful for this process is:
    • the scheduling method used (schedule network analysis, critical path method, resource optimization–all covered in next posts on “tools and techniques” )
    • tool used to create the schedule (e.g., Microsoft Project)
    • how the schedule is to be calculated (specifically what data analysis techniques are to be used–covered in next posts on “tools and techniques”)
    • release and iteration length–if you are using an adaptive of agile life cycle, you need to specify the time-boxed periods for releases (phases of the project), and iterations of a release:  usually this is a 2 or 4-week cycle, but it needs to be specified and it needs to be consistent.
  • Scope baseline–remember this is actually three documents in one, consisting of
    • the project scope statement (the scope is broken down from the original requirements given in the initiation phase to the level of project deliverables, the tangible or intangible items that will fulfill these requirements)
    • the Work Breakdown Structure or WBS (the scope is further broken down from the level of project deliverables to the more manageable work packages needed to complete them
    • the WBS dictionary (contains information on other constraints that are related to each work package, such as who is assigned to do it, and what the duration estimate and cost estimate are to complete it)

6.5.1.2  Project Documents

The PMBOK® Guide, in true laundry-list fashion, lists the documents in alphabetical order, but I will organize them for you based on what knowledge area and process these documents come from.

Integration Knowledge Area

Output of 4.1 Create Project Charter

  • Assumption log–although this is created as an output of develop project charter for any basic assumptions behind the project that are known by the project sponsor, this log is then updated during the schedule planning processes to include any new assumptions that are uncovered during those processes that may affect the schedule (either by affecting the sequence of activities or their duration estimates)

Output of 4.4 Manage Project Knowledge

  • Lessons learned–this will be updated in this process to include any lessons learned with regard to developing the schedule model early on in the project to improve its validity in later phases of the project.

Schedule Knowledge Area

Outputs of Process 6.2 Define Activities

  • Activity list and activity attributes–the activity list is an output of process 6.2 Define Activities, and the associated list of activity attributes for these activities are updated by
    • adding information on the sequence of activities as an output of 6.3 Sequence Activities, and by
    • adding information on the duration estimates as an output of 6.4 Estimate Activity Durations.
  • Milestone List–this takes the general milestones that may be listed during the initiation phase in the project charter, and adds to them during the Define Activities process to include more specific milestones.

Outputs of Process 6..3 Sequence Activities

  • Project Schedule Network Diagrams–this contains the logical relationships of predecessor and successor activities in the form of a diagram that looks like a flowchart, with the the logical relationships between activities represented by lines and arrows which connect the activities represented by rectangular boxes called nodes.

Outputs of Process 6.4 Estimate Activity Durations

  • Basis of estimates–this document includes
    • Documentation of any known constraints that may influence the estimates
    • Indications of the range of possible estimates, stated in terms such as plus or minus a certain percentage, or in terms of a confidence level of the estimates (i.e., the percentage probability that the actual duration will not exceed the estimate)
    • List of individual project risks influencing the estimates
  • Duration of estimates–these are the assessments of the likely number of time periods needed to complete the activities in the activities list.   I say “likely number”, because the estimates may be refined so that they are not single-point estimates, but ranges of possible results.  These ranges may be expressed in terms such as 1 week plus or minus 2 days, for example, or in terms of a confidence interval, that is, an 85% probability of taking only one week.

Resources Knowledge Area

Output of 9.2 Estimate Activity Resources

  • Resource requirements–identifies the types and quantities of resources required for each activity used in creating the schedule model.
  • Resource calendars–contains information the availability of the resources during the project

Output of 9.3 Acquire Resources

  • Project team assignments–specifies which resource is assigned to each activity used in creating the schedule model.

Risk Knowledge Area

Output of 11.2 Identify Risks

  • Risk Register–although this is created as an output of 11.2 Identify Risks, it is updated in later risk management planning processes to include details about those identified risks.   It is used to see if there are any identified risks which may affect schedule model, and is important for creating schedule reserves (buffers used to account for both anticipated and unanticipated delays in the project).

6.5.1.3  Agreements

If you have vendors on your project who are doing some of the project work or creating components that will go into the product of the project, agreements need to be specified so that they supply those components or work in a timely manner so that it can be used on the project and not cause any delays in the overall project work.

6.5.1.4 Enterprise Environmental Factors

The factors that can influence this process are:

  • Government or industry standards for schedule modeling
  • Communication channels within the organization

6.5.1.5 Organizational Process Assets

The factors that can influence this process are:

  • Scheduling methodology, including policies governing schedule model development (usually included in the Scope Management Plan)
  • Project calendar(s)–these are calendars from other projects, which may affect resources who are working on more than one project

With this long list of inputs from many processes, let’s discuss the overall tool and technique of schedule network analysis in the next post.

 

 

 

6th Edition PMBOK® Guide–Process 6.4 Estimate Activity Durations: Outputs


This post will cover the outputs of the process 6.4 Estimate Activity Durations.

6.4.3 Estimate Activity Durations:  Outputs

6.4.3.1 Duration Estimates

These are the assessments of the likely number of time periods needed to complete the activities in the activities list.   I say “likely number”, because the estimates may be refined so that they are not single-point estimates, but ranges of possible results.   These ranges may be expressed in terms such as 1 week plus or minus 2 days, for example, or in terms of a confidence interval, that is, an 85% probability of taking only one week.

6.4.3.2  Basis of Estimates

When going to single-point estimates to the more refined three-point estimates, you make assumptions to take the most likely estimates and come up with the pessimistic and optimistic versions of those estimates.   These assumptions may come from the assumption log given as an input to this process, or they may be developed during the process itself.    In addition to the assumptions made to form the estimates (which are listed in the assumption log–see “Project Documents Updates” section below), additional supporting details for the duration estimates may include the following:

  • Documentation of any known constraints that may influence the estimates
  • Indications of the range of possible estimates, stated in terms such as plus or minus a certain percentage, or in terms of a confidence level of the estimates (i.e., the percentage probability that the actual duration will not exceed the estimate)
  • List of individual project risks influencing the estimates

6.4.3.3 Project Documents Updates

  • Activity attributes–this gives details regarding the activities in the activities list.  Based on the results of this process, the activity duration estimates are added to the list of activity attributes for each activity.
  • Assumption log–any assumptions developed during the course of this estimate process are added to the assumption log
  • Lessons learned register–any techniques that were shown to be efficient and effective in developing the activity duration estimates are added to the lessons learned register.

All of these outputs are added to the growing list of inputs to the next process, the final planning process for schedule management, process 6.5 Develop Schedule.   This process will be discussed in the next post.

 

 

 

 

6th Edition PMBOK® Guide–Process 6.4 Estimate Activity Durations: Tools and Techniques (2)


In the last part of this two-part post, I went over the tools and techniques for this process 6.4 Estimate Activity Durations which I call generic, because they are used for any complex planning process, and not just the ones for schedule management.   These are

  • Expert judgment
  • Decision Making
  • Meetings

In this post, I will cover the tools and techniques that are used specifically for this particular process 6.4 Estimating Activity Durations, namely:

  • Analogous estimating
  • Parametric estimating
  • Three-point estimating
  • Bottom-up estimating
  • Data analysis (alternatives analysis, reserve analysis)

Let’s discuss these tools and techniques (the numbering is based on the categories in the PMBOK guide, so there will be a little skipping of  numbers–this is intentional and it means that the missing categories are the ones covered in the last post on the “generic” tools and techniques for this process).

6.4.2  Estimate Activity Durations:   Tools and Techniques

6.4.2.2  Analogous Estimating

6.4.2.3  Parametric Estimating

I am going to discuss these two techniques together because they are both examples of top-down estimating techniques, that is, estimates based on the total cost of previous, similar projects.   They both require historical information on similar projects in order to work.

Let’s illustrate these techniques with an example.   Suppose I work for a construction company, and we bid for a project to build a new home in an already existing subdivision.   How do we estimate the amount of time it will take to complete the home?  Well, one quick way is to see how long it took our company, or perhaps another company or comparable size, to complete a similar home in the subdivision.    If it took then 90 days to build it, we can use the analogous estimating technique to calculate that 90 days is a good rough estimate for our project as well.

However, say there are no homes that are comparable to the one we are doing in size.   Maybe there are small and medium-sized homes, but not one that is as large as the one we want to build.   In that case, a more nuanced estimating technique called parametric estimating can be used.    If you have data on how long it took to build homes of various sizes in the same subdivision, and you have how large these houses were in terms of square feet of floor space, then you can calculate a parameter or unit measurement which estimates how long it takes per square foot of floor space.

If the average home in our subdivision has 2,700 square feet of floor space, and we assume it takes 90 days to build it, then it takes 1 day per 2,700/90 = 30 square feet of floor space to complete an average home.    If our project is to build a house that is larger, say, 3,000 square feet, we can make a rough estimate that it will take 3,000 square feet x (1 day/30 square feet) = 100 days to complete the home.

This is a rough estimate, and it is based on assumptions such as

  • the other homes being built are comparable in terms of floor plan
  • the building materials being used are similar
  • the experience level of the companies that did the other houses is comparable to that of our company

So the advantage of these techniques is that they are quick, but the disadvantage is that they are rough estimates are therefore not as accurate as a bottom-up estimating technique (see paragraph 6.4.2.5 below).

6.6.2.5  Bottom-Up Estimating

This is when you estimate the duration of each activity on the activity list, and then aggregate the estimates for the differing level of components in the Work Breakdown Structure or WBS.   First you sum up the durations of each activity for each work package, then you sum up the subtotals for each work package, rolling up the levels of the WBS until you get the total estimate for the entire project.

The advantage of this technique is that it is accurate, but the disadvantage is that it is time-consuming.    It is the exact inverse of the advantages and disadvantages of top-down estimating techniques (discussed above in paragraphs 6.6.2.2 Analogous Estimating and 6.6.2.3 Parametric Estimating).

6.6.2.4  Three-Point Estimating

I am putting this below the bottom-up estimating technique because that is where you start, with a single-point duration estimate for each activity that is made in the bottom-up estimating technique listed above.

You further refine this one-point estimate with the three-point estimates listed below:

  • Most likely (M)–this is based on the duration of the activity, usually the one found in the bottom-up estimating technique, based on the assumptions that will most likely occur such as:
    • the resources likely to be assigned to the activity
    • the productivity of these resources when performing the activity
    • the realistic expectations for the availability of these resources for the activity
    • the dependencies of the resources on the other participants in the project team, etc.
  • Optimistic (O) –this is based on the best-case scenario for the activity
  • Pessimistic (P)–this is based on the worst-case scenario for the activity

The expected duration can be calculated with one of the following formulas:

  1.  Triangular distribution

E = (O + M + P)/ 3

in other words, the simple average of the three-point estimates.    This is done when there is not a lot of historical data regarding the activity.

If there is historical data regarding the activity, and you have more confidence in the “most likely” estimate, you can statistically give it more weight by using what is called a “beta estimate” (I remember this by thinking of it as a “betta” estimate than the triangular one).

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

In this case, you divide by 6 inside of by three because in essence you have copied the “most likely” estimate of M 4 times, and so you have a total of six terms to take the average of rather than just three terms that you have with a normal average.

Let’s see how this works with an example.

Okay, let’s say you move to a new house, and your boss asks you how long it will take you to get to work from your new place.   On a typical work day, you see the estimate of the time you leave your house to the time you get to your work place to be 30 minutes.   Not bad!    However, that is the “most likely” estimate, if traffic is normal and you only have to deal with “rush-hour” traffic.

What would be the “optimistic” and “pessimistic” estimates for getting to work.   In the optimistic or “best-case scenario”, there would be very little traffic.   This can happen if you are coming to work on a holiday or maybe even on a Saturday, when there is no “rush-hour” traffic to deal with.   Let’s say it only takes 20 minutes to get to work in that case.

How about the pessimistic or “worst-case scenario”?   That might be if there is a traffic accident which causes traffic congestion that is worse than the normal “rush-hour” traffic.   In that case, say it takes 60 minutes to get to work.

What is the three-point estimate of how long it will take to work?    If you are new to your new route to work, and don’t have a lot of historical data to compare it with, then you might want to go with a regular triangular estimate:

E = (O + M + P)/3 = (20 + 30 + 60)/3 = 40 minutes.

If you tell your boss it an estimate of 40 minutes, then since it most likely will take you 30 minutes, you will always make it to work on time if you leave 40 minutes before you are scheduled to work UNLESS you face the pessimistic scenario of an accident on the freeway or highway you are taking to work.

Let’s say you get some more confidence in your route to work, and you have never seen an accident yet on the road to work, so you can now use the beta or weighted average to calculate your time to work.   Now

E = (O + 4M + P)/3 = (20 + 4 X 30 + 60)/6 = 33.3 minutes.

If you give your boss an estimate of 33.3 minutes, then you now can tell yourself to leave 3.3 extra minutes rather than 10 and still be reasonably confident that you can make it to work on time.

That’s how three-point estimating works.   It takes the single-point estimates found in bottom-up estimating and creates an estimate that is robust, that is, will work under most scenarios but perhaps the most pessimistic.

6.4.3.6  Data Analysis

The techniques used to analyze the duration estimates of activities are:

  • Alternatives analysis–this is an analysis of the assumptions behind the various options you have for doing an activity.   These assumptions come into play a lot when doing the three-point estimates described above.
  • Reserve analysis–this has to do with determining contingency and management reserves needed for the project.   Contingency reserves are those that can be used by a project manager, and management reserves are those that need approval of management (such as a project sponsor).

Let’s take the example we talked about before.   It takes 30 minutes according to your GPS for you to get to work.   The three-point estimate shows that, in order to account for the possibility of some unforeseen circumstance that might cause you to take more time, a better estimate is 33.3 minutes.   This extra 3.3 minutes could be considered a contingency reserve which would allow you enough extra time if there was some sort of slowdown on the highway that caused you to take more time than you normally would (i.e., 30 minutes).   This is a reserve that you control yourself and it helps you get to work on time in most cases.

However, if there was some sort of traffic emergency on the road, you might have to call in to your boss and tell him or her that you might not make it by the time work starts.   The boss will usually say “okay” given the nature of the emergency, and this is like a management reserve which allows you to take the extra time you would need provided that is is an emergency.    “Hey, boss, sorry I forgot to set the alarm clock” would not be considered sufficient circumstances to allow you a “management reserve” of extra time in this case.

There will be more on these estimating techniques when we turn to the next knowledge area of schedule management.

With this discussion of tools and techniques for schedule management being concluded, let’s now turn in our next post to the outputs of this process.