28. Time Removes Cards from Your Hand

Time is a poor project manager.

It’s the decisions a manager makes early in the life cycle that have the most impact on a project. For example, a manager’s staffing decisions usually need to be made early—not at the outset, but early. With eight months to go on a ten-month project, adding another developer and a tester may well increase the chances of a full-function, on-time delivery. On the other hand, adding that developer and tester with two months to go may not help your odds at all. Indeed, it could lower them a bit. Somewhere between month 2 and month 8 of the project, Time removed the value of adding additional people.

Time can also make shortsighted decisions about what will be in the next release. This situation may be familiar: The next release of the system has already been announced to customers for full functionality by the end of November. The team is not very confident that it can build, test, and integrate everything for release by that date. The manager isn’t too sure either, and he lets everyone know about the team’s concerns. The word comes back,“Come on. It’s only May. Give it your best shot. That’s all we ask.”

As the months go by, the picture gets no cheerier, yet nothing has changed in the release plan. Somewhere in mid-October, a Corporate Rocket Scientist announces, “They’re not going to have everything done for November.” The team gives a sarcastic cheer at this “news.” Then the Rocket Scientist proceeds: “No need to panic; we’re all adult men and women here. Let’s convene first thing tomorrow morning in the Donner Party Conference Room to see what we can do to save face by delivering something for the promised November date.”

The next morning, the Rocket Scientist starts the meeting by writing on the white board, “November 30—Core Release.” He turns to the assembled, and asks,“What shall be in the Core?”

At this point, you are trying not to burst into laughter, because this is clearly a roomful of adults pretending to have a situation in control when Time has taken all degrees of freedom away from the project.

The answer to “What shall be in the Core?” is simple: “Whatever we’ve got now, dude—it’s October already!” Somehow, you now have the equation, “Finished = Core.” Anything already done is Core; it’s vital to the release. We can prove this to you.

The following is a dialogue you will never hear in any Save-the-Release-Date meeting:

Manager: “What shall be in the Core Release?”

Developer: “Well, Matilda has finished this little froufrou component that changes the color of the background based on a randomization routine. It’s coded. It’s tested. It’s ready to go.”

Manager: “No, that’s not Core.”

By the fact that it is done, it must be included in the release. You have to laugh here, or you’ll cry. Time has managed this project into a complete bind. By waiting until it was clear to everyone that full functionality was not going to happen for November, Time has steered the project badly in two ways:

First, the project will deliver less than it could have. If the human manager and the team had decided back in May to scrap the Full-Functionality-for-November plan, they could have prioritized the feature set, building and completing features, working down the priority list as time permitted. They would have delivered more features 100 percent done, and some not even started. Time’s strategy, on the other hand, produced a lot of features that were close to done. But “Close to Done ≠ Done.” What a waste.

Second, Time delivered a misshapen core. Instead of the most valuable features making the cut for the November release, Matilda’s distinctly noncritical code and other bits like it get delivered.

All good project managers know when they need to play their cards so that Time cannot trump them.