What to Do When Your Project Slips
When I Googled “project falls behind” in search of tips for this story, I found lots (and lots) of links about specific projects that had fallen behind. If your project has ever slipped, you are most certainly not alone.
For many projects, it may be that the estimate was overly ambitious. This is despite (or perhaps because of) cognitive scientist Douglas Hofstadter's aptly-named creation Hofstadter’s Law, which states “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” In other words, if you know a project will run late and you build that knowledge into your planning, it will overrun your new estimated finish time, too. This is known as the planning fallacy, and we’re all susceptible to it when we make estimates.
Making life difficult for project managers, the schedule for a major project is usually visible to executives and project stakeholders, and they’ll all have opinions about why the project slipped and what to do about it. Sometimes, of course, these parties have valid points. To avoid falling victim to this external scrutiny, it’s important to be clear about the project’s critical path and to manage to that path.
Once the project falls behind, for whatever reason, it’s important not to panic. Instead, assess the situation and ask: What resources will we need to bring the project back on schedule (if indeed, a return to the original schedule is even feasible)? And, what will the new completion date be if everything proceeds from this point forward? If you’re lucky, the client will agree to a reprioritizing of time, cost, and quality factors.
It may be wise to provide customers and stakeholders ongoing access to status reports about which aspects of the project are complete, due, or running behind, so that a slip isn’t a complete shock. In any case, be sure you always know where your project stands, both time-wise and budget-wise.
Of course, communication is key when a project slips. It’s usually best to deliver the bad news all at one time. Provide the worst case scenario and emphasize that it is just that—the worst case scenario. When they—management, customers, stakeholders, whomever—finish ranting and raving, you may be able to have a rational conversation about what’s next. Difficult as this is, it’s usually better than delivering the bad news a dribble at a time, leading them to assume that any time you’re about to say anything, it’s more bad news.
Whatever you do, don’t forget that adding manpower to a late software project makes it later—advice courtesy of the renowned Frederick Brooks, from his book The Mythical Man-Month: Essays on Software Engineering.
