Things will never go exactly as planned, and the best time to make an accurate estimate on a work schedule is by the project’s end.
I want to share some basic, practical tips and considerations on how to handle schedule slippage. These tips should be particularly useful if you don't currently use a proven methodology or have a mature process in place for your project development. I strongly suggest you consider learning about Agile Methodology and read through the PMBOK's "Planning" and "Monitoring and Controlling" process areas.
- No matter how much time you assign for a task, people will always take as much as you give them to complete it.
If a task can be done within an hour, and you give people 4 hours for it, they’ll take 4 hours. And if something goes wrong, they’ll take 5 or 6. So keep that time flexibility outside of people’s roster when assigning them tasks. Keep that extra time for the overall project plan instead, and give people that flexibility if required; i.e. if a task can fairly be completed within 2 hours you can plan for 3, but give people 2 hours to complete it, and grant them that extra hour only if required.
- Know your critical path.
A critical path is the set of chained tasks in a project plan that take the most time to complete. Any other tasks that are not part of the critical path can be extended if required, as long as they don’t risk to become the new critical path.
The longest time you can take to complete a milestone will be the time of the critical path, and at any given time, a new critical path can come up.
So monitor your critical path, as that will be your priority to keep on track; that’s the one that can make your schedule slip.
Also, knowing your critical path helps you prioritize your tasks: sometimes we closely tackle on completing tasks that have no effect on our schedule and leave behing the ones that do affect us.
Criticality of tasks should be objective, based on the effect it’d have on the project progress rather than subjective, where we give importance based solely on our perceptions.
- Create milestones, and place tight dates for them.
Schedule does not slip at once, it’s the result of a snowball effect in which small delays on early stages cause bigger delays later. We should have control points in which we can stop fairly big "snowballs" in order to avoid them becoming bigger and harder to control.
A milestone is a mid-term goal in the middle of the whole project. Some of them are clearly defined by the project’s lifecycle, i.e. Analysis, Design, Execution and so forth, but we can tailor our milestones according to the nature of the project itself. We should aim to keep close to the deadlines of each milestone rather than shortening the next one by stealing time from it. It is very common that people are very relaxed at the early stages of a project and very stressed at the end. By setting closer deadlines through milestones you set people’s sense of urgency in the right place; it’s better to be fairly busy during the project and maybe work an extra hour or two a week rather than working 12+ hrs a day for 1 month by the end of the project. Snowball effect is exponential.
- 9 women can’t make a baby in 1 month: don’t abuse on extra hours to get things done.
There’s a breaking point in which the amount of defects people inject to a project significantly increases when they work more than 8 hrs a day, meaning having people consistently working that extra time is counterproductive, as they will just inject more defects, hence requiring more time to complete a task and so forth.
No wonder why so many managers ask for exceptions to get final approval for a project. When they burn-out people to get it done project would certainly be very defective.
- Consider splitting tasks that take more than 16 hrs / 2 days to complete.
Tasks that take a whole week or more than 2 days seem more like milestones than actual tasks: they’re good for high-level tracking but not for project progress tracking and task assignment.
If your tasks take more than 16 hrs or 2 days to complete they’re most likely not detailed nor clear enough to execute. For example, let’s say I plan for 5 days, 2 FTE’s (80 hrs) of database design. I may consider modularizing that design as in: 2 days / 32 hours to get the admin module DB design, 2 days / 32 hrs for the products module, 1 day / 16 hrs for the catalogs.
Planning tasks on a more detailed level helps you spot activities that can run in parallel. In the above example, maybe the first two designs can be done in parallel (1 resource to each module), hence taking 3 days instead of 5 to complete the DB design.
Also, by keeping tasks within 16 hrs / 2 days, you get a closer tracking on progress and providing people with constant short-term goals to keep them focused and busy. This also builds momentum into getting things done.
People tend to get distracted during the day and some constantly leave late, not because they have a lot of work, but because they didn’t get organized for it (they have a week to finish it, so where’s the hurry?). When people know they have a goal due by the next day, they will get the most out of their time.
It’s psychology, you help people get disciplined to arrive and leave at their proper hours, hence improving their life quality. Keep the goals short-term.
- Use absolute, measurable values to track progress.
Percentages are way too relative and provide a subjective, unrealistic insight on the project’s progress. They tend to be more of a hunch feeling rather than an actual picture of how the project is going.
Have you ever seen projects reach 95% progress and then take forever to complete? It’s ridiculous and unfortunate.
The best measure of tasks progress is hours (not time/date).
Get used to estimate based on hours, not dates. If a task takes 10 hours, go with 10 hours, not 2 days.
When tracking progress don’t ask what % of progress people have, ask how many hours they have dedicated to it, and how many hours they estimate to complete it. This build actual commitment in completing tangible goals.
Doing this also helps you build very useful metrics that can help you better plan on next project, and be able to forecast the project and spot any schedule slippage risk earlier.
So we’ll have:
– Estimated/planned hours.
– Actual work hours.
– Estimated remaining hours.
Maybe we planned for 16-hr task, and the progress is 14 hrs. Then I won’t ask how many days or just plainly how much more it will take. I will ask: how many hours do you estimate you need to complete it? Again this makes people get into an objective mindset, and sets a tangible goal for them.
Maybe later you can say you estimated 80 hours to complete the design phase, and it actually took 100. That’s a 25% increase vs estimate. You can use that as a reference when estimating a similar project in the future.
Similarly, let’s say you planned for 80 hrs, 2 FTE’s to complete the Design milestone. Progress is now at 70 hours and team estimates 20 more to complete. You know in advance project has slipped by 10 hrs, possibly 1 day, and you can plan to get back in track just that early.
Also, when reporting progress, people would have an objective feeling on where we stand, and that would help better address any risk and get timely support to get back on track.
I hope these tips have been useful. What do you think about these tips? Do you have any to share? Comment! 
