Schedule Control

Question

Here's the scenario: You are building a schedule for a project that has a planned duration about three months. You are not concerned about project costs so you will not be doing EV. You are developing the schedule ensuring that your work packages are linked to represent your planned sequencing and all of your packages are fixed duration. Once complete, you baseline the schedule and you have a good representation of your current critical path.

During execution, maybe you are 30% complete from a time perspective, you update the schedule with progress (assume you have a valid and credible way of capturing work complete). The project finish date is starting to show an unfavorable finish variance, adding about 1.5 weeks to the three month project. You estimate work remaining and, due to some changes in the way you do the work and other interventions, you estimate that you can shave off the finish variance and actually come in sooner than planned with a favorable variance of four days.

1. Do you alter the durations of the remaining work packages based on your latest revised estimate, allowing the schedule to calculate a finish that shows the favorable finish variance?

2. If so, do you process the change in duration through your change control or do you consider duration something outside of what is baselined?

3. Or, do you keep your original baselined duration the same and show in another way your latest revised estimate and the resulting finish date? If so, how?

Answer 1

TL; DR

At various points, your project is potentially 1.5 weeks late or 4 days early. Your methodology values calculated variances, but (as far as I know) doesn't mandate continuous re-planning. It would therefore be more efficient to value communication over re-scheduling.

Communication: The Underlying Question?

In your question, you state that at some point in your project you think you're 4 days ahead of schedule. Awesome!

Then you ask some detailed sub-questions, currently tagged with schedule-risk, but really about how to communicate your project's status to a wide audience that you've defined as:

Multiple audiences: stakeholders of the project, project sponsor, senior management, public, the project team itself as it is managing the project and its health....

To my way of thinking, all your questions boil down to How do I communicate that we're slightly ahead of schedule?

Favor Communication Over Re-Scheduling

1. Do you alter the durations of the remaining work packages based on your latest revised estimate, allowing the schedule to calculate a finish that shows the favorable finish variance?

In other words, should you recalculate your schedule with accelerated dates, removing slack from the process? That seems like a bad idea. Slack is important, regardless of one's chosen methodology.

2. If so, do you process the change in duration through your change control or do you consider duration something outside of what is baselined?

Change control is usually a process for adjusting scope, not recalculating schedules. While there is some inherent overlap in that scope can impact scheduling, I don't think submitting positive scheduling changes to a steering committee for approval makes sense.

In this particular case, I think what you'd want to do is provide a communique saying that the project has is slightly ahead of schedule (yay!) but that at only 30% completion this slack may be required to mitigate other schedule risks down the road. This has the dual benefit of keeping stakeholders informed while protecting necessary slack from reduction by management fiat.

3. Or, do you keep your original baselined duration the same and show in another way your latest revised estimate and the resulting finish date? If so, how?

Again, communication is the key. Your original baseline is used to calculate deviations that need to be controlled. Slack probably doesn't need to be tightly controlled, so unless your project goals have changed dramatically there really isn't much justification for a new baseline. A new baseline also implies the need to review your project controls; is that worth it for this use case?

Instead, your routine status communications should highlight the process efficiencies that have provided this slack. You might also want to identify project risks or milestones where the slack can be allocated to mitigate slippage in the future, but that may not be a level of detail appropriate to every project communication plan.

Answer 2

Manage it through change control

due to some changes in the way you do the work and other interventions, you estimate that you can shave off the finish variance and actually come in sooner than planned with a favorable variance of four days.

Sounds like a miracle! I recommend a cautious approach. I would hate to communicate an early completion now and go back with bad news later.

I will put this change through change control to understand the risks, limitations and dependencies. If everything checks out, then communicate the good news to everyone else.

Answer 3

Do you alter the durations of the remaining work packages based on your latest revised estimate, allowing the schedule to calculate a finish that shows the favorable finish variance?

My default is to re-baseline the project schedule at pre-defined control points after reviewing upcoming work with the team. This involves review of upcoming work, identification of new risks/issues, identification of work missing from the original plan, re-evaluation of the planned schedule, etc etc

The frequency of these plan/schedule revision exercises depends on the complexity and criticality of the project, as well as your workflow. It is best to have this kind of exercise at a logical management phase of your project rather than at fixed timepoints (e.g. planning to do this after development ends but before testing starts instead of 2 months after project start).

2.If so, do you process the change in duration through your change control or do you consider duration something outside of what is baselined?

3.Or, do you keep your original baselined duration the same and show in another way your latest revised estimate and the resulting finish date? If so, how?

Once I've gone through the exercise of getting team feedback on upcoming work and have enough information to update the plan and schedule I process the changes through change control. This is a more extensive change than what you are asking about, but I think good documentation of agreed-upon changes is necessary from a best-practices standpoint. If your project is simple/non-critical to the business the extent of the documentation could be pared down, but I would still have something. Ideally there are pre-defined thresholds in terms of changes to schedule/scope/budget that make it clear who approves what changes.

If I'm in a situation where the project is ahead/behind schedule I report this based on the project's governance structure (e.g. at update meetings or through status reports or however). This reporting usually includes a root cause assessment for schedule slippage and a recovery plan (if there is one).

Answer 4

This is, in my opinion, a risk management problem.

The project finish date is starting to show an unfavorable finish variance, adding about 1.5 weeks to the three month project. You estimate work remaining and, due to some changes in the way you do the work and other interventions, you estimate that you can shave off the finish variance and actually come in sooner than planned with a favorable variance of four days.

Status quo you have a risk of a 1.5 week late finish. This must be communicated quickly to the relevant stakeholders. (I'm inferring that since you're not managing cost and don't seem to care about quality, that schedule is the primary interest of the sponsor/stakeholders. If this is true, then I belive you have an obligation to quickly inform them of anything that could threaten the planned complete date.)

The good news is that you have already analyzed the problem, and you have a proposed risk response. The proposed risk response presents an opportunity to finish 0.8 weeks early. I would want to brief the stakeholders on that too.

I would want to attach probabilities to the two outcomes, and then write up the proposed changes in a format that would feed into your change control process. You want to clearly express what impact these changes will have on other facets of the project, and how they might affect any KPI that the stakeholders have identified.