The longer a project takes, the more it will cost. More importantly, such delays typically bring increased levels of rework. As this rework must be absorbed by the team, they will become less efficient in delivering value to their customers. As they become less efficient, their products will thus become less affordable for their customers, and the number of customers may decrease. Unfortunately, with fewer customers, there may be fewer resources available to support the remaining customers. And with fewer resources, it may also take longer to deliver value to those customers. And you can see where this is going, right?

The only way out of this dilemna is to shorten the time and resources it takes to accomplish a benchmarked amount of work. A focus on the rate that such work can be performed is often the most important strategy for an organization to increase value to its customers, and differentiate it from competition. Streamlining your throughput can generally only be achieved by anticipating your customer's needs during planning, becoming more agile in performing the activities which you perform to design and develop your products, adopting an intense focus on disciplined execution, and proactively eliminating the constraints which cause delays and waste to occur.

In this context, our planning processes should produce information which enables this time compression to be accelerated and appropriately focused, and which enhances our ability to quickly and appropriately respond to emerging situations as they arise. Both of these scenarios require plans that are an accurate representation of the activities which the members of the team plan to do and are actually doing. Unfortunately, the availability of planning information at this level of detail can be about as rare as snow in Phoenix.

In my experience, projects typically represent their planning information in several different views, for different stakeholders. There's usually a top-level view that is used by senior leadership to set targets, align organizational commitments, and summarize progress.This view typically summarizes the overall activities and required resources through a Work Breakdown Structure, description of critical events, and resource budget. When multiple organizations must coordinate their activities, this first view may also highlight responsibilities for deliverables among the performing organizations. In such situations, there will typically also be a second schedule view which highlights the integration and interactions among the responsible organizations. Each of these interactions becomes, in effect, a contract among these collaborating parties which describes the things they are expecting from and committing to do for each other. In an even more detailed view, each team responsible for deliverables develops progressively more detailed plans which extend down to the level at which the work is actually assigned. Finally, a means of reconciling schedule and risk information is necessary.

Unfortunately, the priorities, sequencing, and dependencies that determine individual performance and throughput may not be anticipated in advance, and may not be readily apparent from any of these views as the project is executed. In practice, each of these views is essentially an abstract model of what someone believes or hopes will happen over time in the project. Since each view can have its own belief system and representation, they need to be reconciled with each other over time, since these models are often not developed or verified concurrently, and may not be based upon the same information, perspectives, or assumptions. The effort to perform this reconciliation can drain a substantial amount of energy and time from the team, even in the best situations. Even when this schedule integration is accomplished, there are always gaps between what is desired, what can be negotiated, and what can actually be accomplished by individual team members. As the project unfolds, things rarely go as well as projected; communications breakdowns occur, risks become issues, and estimates are often revealed as overly optimistic hopes for the future.

As these cracks in even the best laid plans develop, there are really only two scenarios worth considering. Under the first scenario, the original plan anticipated these difficulties, and made provisions for them by establishing time and resource reserves. If you are lucky enough to be in this situation, and if you have kept your high-fidelity planning models up to date, you should be able to contain the impact of such problems to a subset of the downstream activities which remain; in essence, your map of the project is still relevant to the terrain you have found yourself in, with some minor adjustments enroute.

Under the second scenario, the original plan is obviously no longer relevant to observations during execution. In this situation, a difficult choice presents itself. Should you develop a new plan that is an accurate rendition of progress to date, or should you instead stick with the old plan, and attempt to add pressure or resources in the hope that delays can be recovered. In my experience, nearly always, those looking at the top-level planning summaries want to choose the option of sticking with the original plan. This is because they still likely relying on a model of the world in which they believe success can still occur. They need to be able to assess velocity (the speed of the project team), but top level plans are not very useful in communicating that information.

In effect, people who chose to avoid replanning are doing the equivalent of driving by looking at the rear view window. Yet what the situation requires is for them to evaluate how long it will take to reach their destination from where they actually are. If this assessment is not robust, they can easily miss opportunities available to change direction, or re-purpose resources to improve your overall throughput over the remaining period of project performance. Once it has been determined that replanning is essential, selecting  the best replan option going forward means evaluating options that are most likely to pull dates to the left which deliver the most valuable content to customers in the short term, while minimizing the accumulation of significant technical debt in the long term. The faster the project can recognize the need for this replanning, and accurately identify and select the best of these opportunities, the better off the project will be in the long term.