Schedule Analysis, Part 2: Why Should I Do It?

In Part 1 of this series, Schedule Analysis, Part 1: What Is It?, provided a brief introduction to schedule analysis. This article discusses why a schedule analysis should be performed. But first, a point of clarification. Schedule analysis and Schedule Risk Analysis (SRA) are two different things. 

Schedule analysis and Schedule Risk Analysis (SRA) are two different things. Schedule analysis looks at schedule health metrics, counts and amounts, data about the schedule data and draws conclusions about the overall schedule quality. Just like a doctor checks your vital signs to decide about your health. An SRA uses statistics to determine the probability of meeting a specified event completion date. It does not look at the schedule analysis, but the schedule analysis will help determine if the results of the SRA are valid.

In general, a project manager wants situational awareness. They want to know where they are, where they are going, what they still need to do, what could go wrong, and when will I be done? The schedule provides project situational awareness and the questions are best viewed as the five immutable principles of project success courtesy of Glenn Alleman.

The Five Immutable Principles of Project Success:

• What does "done" look like?
• How do we get to done?
• Do we have everything we need for the plan to produce done?
• What could possibly go wrong?
• How are we going to measure progress to our plan other than the passage of time and consumption of money?

What does done look like?

Done is defined by the project scope or Work Breakdown Structure (WBS). Part of the schedule analysis is to determine if all the project scope and only the project scope is in the schedule. Whether project scope is defined by a standardized WBS or not, the scope must be verified manually. Tools can determine that all activities have a WBS assignment, but deciding if it is the correct piece of done is a manual process.

There are a variety of ways to define done within the schedule. The preferred way is to allocate scope to WBS elements. Deliverables and other contractual requirements or specifications can also be assigned to schedule and WBS elements. Defining these elements is best done using an Integrated Master Plan (IMP). The IMP tracks the deliverables and other requirements to ensure that they are completed.

Getting to done is what the schedule does. It defines the process completing the work. The individual activities and order of completion. The activity relationships define the logic. As stated in the last article, the logic should be as simple as necessary to define work completion. Most of the schedule logic should be Finish-to-Start (FS). It is the simplest logic relationship and defines how most work is completed. Other logical relationships can be used, but Start-to-Finish (SF) should be avoided. Automated tools like DCMA Schedule Analyzer forProject, shown below, provide automated analysis of schedule characteristics.

It identifies general, relationship, constraint type, and other counts. Increasing some counts and reducing other counts improves schedule quality.

We have defined what done looks like. We how we will get to done. Now we need to determine if we have all the required resources to get the work done. The schedule must be resource loaded, not cost loaded. A cost loaded schedule has dollars assigned to activities or a WBS level. This may be good for an estimate but is not helpful during execution. A resource loaded schedule identifies the labor, materials, travel, facilities, and equipment required to complete the work at the detail level. The end result may cost the same as a cost loaded schedule, but the resource loaded schedule contains much more information and data. A schedule can be resource loaded at the activity level or some intermediate level. It can contain generic roles and rates or actual names and rates. The level of resource detail and where it is located is not a scheduler’s decision.  It is determined by contract, organizational process, or project manager preference. A resource loaded schedule can be a lot of work to develop and maintain. If the Project manager wants to know what everyone on the project is doing when by looking at the schedule, then the schedule should accommodate that request. The only caveat is to be careful what you ask for, you may get it. The downside of all this information is that it needs to be maintained and that can be a lot of work.

In general, the schedule assessment methodologies want resources assigned at the activity level with the more information the better. If the schedule contains named resources, you can use the scheduling application to determine where resources are over allocated or under allocated. An over allocated resource has too much work assigned. The work either needs to be spread out over time or off loaded to another resource. Under allocation is just as dangerous to a project. Under allocated resources are idle and aren’t included in the project cost. Either find them work on the project, find them work on another project, or furlough them, but don’t let them sit idle on the project.

The automated tool shown below, Steelray Project Analyzer, provides automated analysis of schedule characteristics. It shows that 99.4% of the schedule activities do not have resources. The tool does not know whether the resources are the correct resources. It also doesn’t know whether the resources are over allocated or under allocated. It says that most of the schedule is not resource loaded.

What could possibly go wrong?

At this point, we know what done looks like. We know the plan to get to done. And we know what we need and when we need it to produce done. Now we need to think about what could possibly go wrong. People tend to be optimistic in planning. If we don’t plan for things going wrong, then the best we can do is finish on time.

Risk and uncertainty should be accounted for within the plan. Risks are things that could go wrong that we know about. They are called known unknowns. We know about them but their impact is unknown. Risks have a probability of occurrence and impact if the risk comes true. They are addressed with contingency reserves. Uncertainty addresses unknown unknowns. Things we truly don’t know about. We think we know what will occur, but we really don’t know. Unknown unknowns are addressed with management reserve. While some organizations separate contingency and management reserves, the Federal Government combines them.

The stuff that can go wrong needs to be incorporated into the schedule and the best way to do that is by performing an SRA using a Monte Carlo simulation. In the example below, we ran a simulation on our test schedule using Primavera Risk Analysis.

The results of the SRA show that the schedule as planned has a 9% probability of finishing on time (May 16, 2012). The 50% probability of completion is June 28, 2012, a little over a month later, and the 80% probability date is August 8, 2012, approximately 3 months later. We now have a plan that includes things that could go wrong.

How are we going to measure progress to our plan other than the passage of time and consumption of money?

We have a fully baked plan that includes some wiggle room for things that could go wrong. We have completed schedule construction and now move to execution. How will we measure progress? Measuring the passage of time and the consumption of money is traditional project accounting. I have a spend plan. Time passes and I measure the project against the plan. What if I am not getting done what I planned to get done? Is the project executing more efficiently than planned or less efficiently than planned?

We must collect data on how the schedule is being maintained and updated. Some schedule health metrics can be used to determine execution health. Two are the status date and future/past work. The status date must be entered in the schedule. It is the yard stick against which we measure progress. Status is collected as of the last day of the month after the end of the month. We collect status for things in the past so we don’t introduce errors in the plan. There is no joy in telling someone that the work you claimed as “done” really wasn’t “done.” You end up trying to explain it as the difference between “finished” and “done.”

Collect performance, actual start, actual finish, and an indicator of progress (usually physical percent complete or remaining duration to complete the work). Physical percent complete is how much of the work is physically done. It is different than duration percent complete or percent complete. Duration percent complete measures the passage of time. A 5-day activity starts on Monday and ends on Friday. Today is the end of Wednesday. The task started on Monday as planned. Performance using percent complete or duration percent complete would be 60%. Sixty percent of the time has passed, therefore, it is 60% complete. Physical percent complete asks how much of the work is done. If 60% of the total work is done, great! we’re on plan. What if only 40% of the work is done? We’re behind. Performance can now be measured accurately.

The tools can point out incomplete planned work in the past and hasn’t, or completed work in the future. These are just a few of the health metrics that should be reviewed during project execution.

Summary

We perform schedule analysis to provide confidence in the schedule. Schedule analysis shows where the weaknesses are in the plan. Improving those areas will make it a better plan. A regular schedule analysis keeps us on our toes and tells us how to improve the plan. The plan is a dynamic plan that is changing as the project is changing. The plan provides everyone situational awareness as to where we are and where we are planning to go. It helps define and answer Glenn Alleman’s Five Immutable Principles of Project Success.

In Part 3 of this 3-part series, we will address What Does It Mean to Me? Stay tuned.

Talk to a Pinnacle professional about your needs -  - or give us a call (888) 975-1119