I should really call this post “How to Slip a Schedule without Making Everyone Hate You,” because slipping the schedule is the easy part: you just fail to deliver on time. The hard part is doing so gracefully, and in a way that keeps both the overall goals of the organization and your own professional reputation intact.
First of all, let’s dispense with the fiction that you don’t have schedule. There is always a schedule, even on projects that claim to operate with “no estimates.” If you’re trying to deliver some sort of value to some other group of people, that other group of people have some expectation about when you’ll deliver. That expectation is your schedule. The consequences of failing to meet that expectation are sometimes minor, sometimes major. But in my experience, they always exist.
Next, lets acknowledge that schedules sometimes have to slip, even for the best, most organized projects. In the best case, the schedule is slipping because a risk has come to bear, and there is a contingency plan you can seamlessly switch to following. In the worst case, the schedule is slipping because it was always an overoptimistic fiction. Most cases fall somewhere in between. You made a good faith schedule to the best of your ability and knowledge, and that schedule has turned out to be wrong. This is probably because some risk has come to bear. You may or may not have foreseen this possibility, but you probably don’t have a fully formed contingency plan in place. You and your team have probably been working long hours for at least a few weeks, as the possibility of a schedule slip loomed large and you hoped to avoid it. Everyone’s probably at least a little stressed and tired.
So, what do you do?
First, you take a break. You acknowledge to your team that the schedule is going to slip, and you tell everyone to take a little break to let that become their new reality and to recover their frayed nerves. You want people thinking clearly for the next step, which is to revisit your plans and update them.
It doesn’t matter what form of plans you use- a gantt chart, a project board, an arcane system of notes that only makes sense to you- whatever you use for planning, revisit it. Talk with your team and come up with a new realistic estimate of the time it will take for you to finish the work at hand. Make sure it is realistic, and then add some extra time if you can, as a hedge against further issues. It is far, far better to slip a schedule by a lot once than to have a series of smaller slips. The latter case makes everyone lose faith in your ability to make plans.
Now take another look at your plans. Do you have any other options available? Could you, for instance, drop one of your goals and still keep the original schedule, or at least a schedule closer to the original one? Would adding more people to your team help you finish the work faster? In many cases, the answer to that is an emphatic “NO!” Once a project is already behind schedule, often adding people only makes it fall further behind, because the original team members are now spending their time bringing the new people up to speed instead of doing the work. However, if you’ve recognized the need to take a schedule slip early enough, you may be at a point where adding people can still help. Honestly assess this.
Once you have your new schedule and a few alternatives ready, it is time to talk to the people who were expecting you to finish the project on time. Notify them of the slip. Explain why it has happened, if you can- did a piece of the project turn out to be harder than anticipated? Did a key piece of equipment break? Avoid the temptation to blame someone else for the schedule slip, though. State the facts, but do not assign blame. If someone pushes you for details, tell them you and your team are more focused on getting the project back on track right now, and that you’ll analyze what happened more closely once everything is running smoothly under the new schedule. This should be true, by the way.
Then present them with the options you have identified. Option 1 is to complete the work as originally planned, but with a new timeline. The other options are the ones you identified while you were revisiting your plans. Work with them to agree on a new plan, and then go off to execute it.
Once the dust has settled a bit, get your team together and try to understand why the schedule had to slip. Was the original estimate just a bad one? If so, learn from that and make a better estimate next time. Did a risk come to bear? If so, ask if there was some reasonable contingency planning you should have done. Try to learn as much as you can from this slip, so that you’ll have fewer slips in the future.
Also ask yourself if you recognized the reality that a slip was going to happen as soon as you should have. Did you understand the dependencies in your project well enough to see the slip coming as soon as the triggering event happened? Or were you caught by surprise? If you saw the problem coming, were you honest enough with yourself to acknowledge it, or did you indulge in some over-optimistic thinking about your ability to get things back on track?
Learning when to fight on in hopes of righting a slipping schedule and when to acknowledge the need for a slip, make new plans, and communicate them to all involved is not an easy thing. Getting good at making this sort of call, though, is essential if you’re going to lead a team. It is a key ingredient in having a sustainably high performing team. If you’re too slow to slip, you’ll burn people out. If you’re too fast to slip, you won’t accomplish nearly as much as you could. Luckily, like most project management skills, this is something that you can learn to get better at if you are conscious of the decisions you are making and why, and you commit to learning from the times you make the wrong call.
[…] teach someone how to do what I do when I run a project. I’ve been picking off some aspects- how to slip a schedule, how to write a status report, etc- and I have also identified some things you have to think about […]
Good solid advice. I am wondering what is meant by a “risk coming to bear’? Does this refer to a potential problem that you anticipated coming to fruition? Or something else?
Yes- a potential problem that you (hopefully!) identified and planned for has become a reality, and not it is having an effect on your project.
For example, if you thought there was a chance that a key team member might leave and now they have given notice. Hopefully, you mitigated that risk with some cross-training, but either way, now it has come to bear on your project.
[…] your plans accordingly, and won’t have a big, unpleasant surprise at the end of the project. Most people can handle a schedule slip, if they know in time to change their plans to accommodate it. If you track your project milestones, you can usually see a schedule slip coming early enough to […]