We've all seen it happen. A detailed plan is prepared for a project, and everything stays on track for the the first 80% of the schedule. That's when it hits the fan. Heroically, the engineers apply their fixes while going way over budget, and the project is saved from becoming a total disaster. The team obviously needed a better plan, right?
Let me present a radically alternate view. Is it possible that this problem was actually caused by its planning? Remember, a schedule is simply a time budget for a project. Early in the project, we meet this time budget. Therefore, we see no need to intervene, and we can relax because everything is going according to our well-crafted plan.
Things are different, however, later in the process. As slippage starts to appear, we attempt to buy it back by making tradeoffs against other objectives. We may relax requirements, spend extra money, or compromise the project's unit cost target. Of course, the actions we take to regain the lost cycle time are expensive when they occur toward the end of the schedule.
If we take a look at the project as a whole, we would discover that we had many cheaper options to buy cycle time earlier on, but we had no need to do so. Instead, we find ourselves paying dearly to keep on schedule because the options that we have to buy cycle time late in the project are orders of magnitude more expensive than the options we have at the beginning. In essence, we are shopping for cycle time at the single most expensive place to buy it—at the end of the project.
Why do we inevitably buy cycle time at the most expensive opportunity? We do it because we have a plan that tells us that there is no need to buy cycle time back, as long everything is proceeding according to plan. We relax our vigilance and neither seek out nor exploit options to buy cycle time any earlier.
Let me suggest an alternate view of the world. What would happen if we simply gave the team a decision rule? Whenever you can buy a week of time on the critical path for less than $10,000, do it! This would cause the team to cheaply buy cycle time early in the project and put it in the bank as margin for later. It also would push the team to seek out and exploit the most cost-effective opportunities, especially those that appear before you're behind schedule.
In theory, planning focuses our attention on critical deviations from our plan. In practice, it causes us to relax our vigilance whenever we don't see any deviations. Since deviations are least likely to occur at the beginning of the project, we're least likely to be vigilant at this stage. Ironically, this is the portion of the schedule in which it is cheapest to buy cycle time.
Is this an argument to eliminate project plans? Of course not. It's an argument for knowing how to buy time wisely. To do this, we must know where the critical path lies and what time on the critical path is worth. You should never believe you are managing well just because everything is going according to plan. Stay vigilant and buy cycle time whenever you can get it at a good price. Know what cycle time is worth financially. Product development is about making money, not making a plan.