After Hours

10 ways to get a slipping project back on track

Plenty of things can derail a project plan: underestimated tasks, departing staff, misallocated resources. Here are some practical techniques that can correct the direction of a project that's losing ground.

Plenty of things can derail a project plan: underestimated tasks, departing staff, misallocated resources. Here are some practical techniques that can correct the direction of a project that's losing ground.


Anyone who's worked on project teams knows that a variety of factors can move a project past its deadline. It's not uncommon for some of the work to be harder than originally anticipated or to have turnover on the project that requires you to bring new people up to speed. Sometimes you discover that activities were simply underestimated.Regardless of how it happens, many times you'll find that you're trending beyond your committed deadline date. If you discover that happening, your first obligation as the project manager is to try to determine the cause. If you look for remedies without knowing the cause, the situation will probably recur. Your second task is to try to make corrections that will get the project back on track.At the beginning of a long project, you have many options to solve your problem. But toward the end, your choices dwindle. Look at this list of techniques and see which ones can be applied to your situation. Note that this list is not prioritized. Some of the techniques may work in one instance, while others could be applied better in another situation.This information is based on the articles "Correct your off-schedule project with these techniques," and "Apply these techniques to get your project back on schedule," by Tom Mochal. It's also available as a PDF download.

#1: Work overtime

Everyone hates it, but one logical place to start is with overtime. If people work more hours, they can get more work done in the same amount of calendar time. Overtime may be the best option if you're close to the end of the project and just need a final push to get everything done on schedule. If you're toward the end of the project, you also may be able to issue comp time after the project is completed. If you're still early in the project, there are probably more effective strategies. This option may also have cost implications if you need to have contract resources work overtime.

#2: Reallocate resources

The project manager must first understand what activities are considered most vital to the project's success, or on the "critical path." After all, if the project is trending over deadline, by definition it is the critical path that's late. Once you understand the critical path, see if resources can be moved from other activities to help resolve the issue. This will allow you to get the project back on track by delaying or stretching out some work. Be careful, though: Delaying some work may end up changing the critical path. Always make sure you double-check the critical path each time you change the schedule.

#3: Double-check all dependencies

Schedule dependencies represent activities that must be completed in a certain order. For example, if you're building a house, you cannot start putting up the frame until the foundation is poured and dried. If you're trending over your deadline, you should revalidate dependencies, since it's possible that the schedule is being lengthened by invalid dependencies between activities. Invalid dependencies may make it appear that activities must be performed sequentially, when they can really be done in parallel.

Sometimes the scheduling software accidentally adds a dependency. Sometimes the project manager adds the dependency but on later review decides it doesn't really exist. It might make sense to have the team members review the schedule to see if they find dependencies that the project manager thinks are valid, but that they know to be invalid. Check all dependencies to make sure you have all your facts correct before you move into more drastic measures to bring the project back on schedule.

#4: Check time-constrained activities

Time-constrained activities are those with durations that don't change based on the number of resources applied. For example, you may be allocating team members to a five-day class. The class takes five days if one person attends, and it takes five days if 10 people attend. Check all of these time-constrained activities to validate the timeframe. Perhaps you're making assumptions that could be changed with a different approach. For instance, if you allocated three days for a contract to reach a client, perhaps the time could be reduced to one day by paying more for overnight delivery.

#5: Swap resources

I mentioned that the first thing to do when you're trending over your schedule is to determine the cause. One cause you may find is that you have one or more resources that aren't as productive as you planned. Perhaps certain team members don't have the right skills. Perhaps they aren't as productive in this particular area as they are in other areas. Regardless, there may be opportunities to replace resources. In some instances, you can simply swap people who are working on different activities within your project. Other times, you may release a team member and bring in another person.

Remember that the activities on the critical path are key. You may have options to assign a more productive resource to those activities, while reassigning a less productive resource to noncritical path activities. If the activities off the critical path are delayed, you may still be okay in terms of meeting your overall project deadline.

#6: Crash the schedule

Crashing the schedule means applying additional resources to the critical path, the sequence of activities that must be completed on schedule for the entire project to be completed on schedule. It's always possible to just throw more resources on the critical path, but crashing also means you try to get the biggest schedule gain for the least amount of incremental costs.

For example, if one person were assigned to complete an activity in 10 days, you could see whether two people could complete it earlier. If two resources can complete the activity in five days, you may not be adding any incremental cost to the project, since you're applying twice the resources for half the time.

In another example, if two people can complete the work in six days, you will have accelerated the schedule at an incremental cost of two workdays (two people for six days vs. the original 10-day estimate). In this example, you could further crash the schedule by applying three resources. Perhaps then the activity would take four days, or four and a half days. Typically, the more resources you throw on an activity, the more the incremental cost will be and the less incremental timesavings you will receive.

The additional resources may come from within the project team or they may be loaned temporarily from outside the team. One of the goals of crashing the schedule is to minimize the incremental cost. However, crashing -- in exchange for completing some work ahead of schedule -- usually leads to some incremental cost increase to the project. If cost is not as important as the deadline, crashing a set of activities can result in accelerating the schedule.

#7: Fast track it

Fast track means that you look at activities that are normally done in sequence and assign them totally or partially in parallel. Back to our home-building example, you can't construct the frame until the foundation is dry. However, if the house is large enough, you may have options to fast track by starting to erect the frame on the side of the home where the foundation was poured first. The foundation will start to harden there and might allow you to erect the frame on that side, while the foundation on the far side of the home is still drying.

Another example involves designing an IT application. Normally, you wouldn't start constructing a solution until the design was completed. However, if you were fast tracking, you would start constructing the solution in areas where you felt the design was pretty solid without waiting for the entire design to be completed. Fast tracking usually involves risk that could lead to increased cost and some rework later. For instance, in our example of designing and constructing an application, it's possible that the design might change before it is finalized, and those final changes may result in having to redo some of the work already under way.

#8: Prevent all scope change

Many projects begin to trend over their deadline because they are doing more work than they originally committed to. This could be a result of poor scope change management or it could be that small changes are being worked in under the radar screen. If you're at risk of missing your deadline date, as the project manager you must work with the client and team members to ensure that absolutely no unplanned work is being requested or worked on, even if it's just one hour. All energy should go into accelerating the agreed-to core work.

#9: Improve processes

When you look at the cause for the project trending over schedule, you may find that some of the internal work processes could be improved. Solicit team member feedback and look for ways that are within your team's internal control to streamline processes. For instance, perhaps you have a daily status meeting that is not providing value and that can be scaled back to once per week. You may also find bottlenecks in getting deliverables approved.

If you discover delays caused by external processes, try to negotiate changes to the processes going forward, at least on a temporary basis. For example, you may find that activities are being delayed because people need to work on their yearly performance reviews. While these are important, perhaps the timing of completing the reviews can be changed to allow critical project activities to be completed on schedule.

#10: Scale back the scope of work

One option that is usually available is to look at the work remaining and negotiate with the client to remove some of it from the project. If you think some of the remaining work is not core to the project, you could discuss eliminating it quickly. If the remaining work is all core to the solution, this discussion still might need to take place as a last resort. It may be an option to complete this project on time with less than 100 percent functionality and then execute a follow-up project to complete the remaining requirements.

Determining priorities

I've pointed out 10 areas to examine if you're behind schedule. Obviously, one solution is just to deliver the work at a later date. In some cases, that may be perfectly acceptable. However, the assumption here is that the scheduled completion date is important to the client. Some of these techniques don't require any incremental budget. You should look at them first, if possible.

Other techniques to accelerate the schedule will result in increased cost to the project. If the deadline date is more important than costs, these techniques should be applied next.

If the deadline date is extremely important and you can't move the schedule or the budget, there may be options associated with scaling back the scope of work. Usually you can complete less work faster. Once you know the cause of the problem and your budget flexibility, you can determine the best actions to undertake to get you back on track to hit your deadline.

12 comments
apm7
apm7

A good article, but it does not address a key question: where do you start? 1. If the work you accelerate is not on the critical path, it makes no difference how much you accelerate it. 2. If the work you accelerate, despite being on the critical path with a duration of 30 days, only has drag of two days, then two days is the most you can accelerate the project on that activity, even if you add triple shifts and armies of resources sufficient to reduce the duration to one hour. You'd be much better off accelerating an activity that has a duration of just 10 days, but drag of 9 days. 3. If you haven't bothered even to develop a critical path schedule, then you're screwed no matter what and will probably do what most people who don't understand CPM do: just throw money at the project and see if anything sticks.

kevin
kevin

Remember the side effects of the options you have given mean quality will undoubtedly be compromised..but hey we will have delivered the solution and moved on so who cares!! Cancel the project and have a retrospective at the end and adopt agile methods so you don't get into this mess again.

b.lutgerink
b.lutgerink

A project being on or off track is also depending on the schedule. Is it a one-point estimate (statistically impossible) then you can be 100% certain that you are in problems even before the project starts. I think it is the PM responsibility to start there first. And then break down the project into smaller pieces. If either one of those smaller (easier to overlook) pieces tend to overrun the schedule it is also easier to correct that, in either one of the described ways, although I am quite reluctant about "crashing the schedule". That, in my experience has never worked well.

uFunctional
uFunctional

#13. Replan, and replace a bad date with one the team is confident about. Depending upon the business reason for the original date, this may actually be preferable to the unintended consequences of a lot of the other corrective actions you suggest. If you're going to slip, take it all in one gulp. The weekly schedule slip of yet another week is a morale killer. #2 and #5 (adding and/or swapping people) goes against the old Fred Brooks admonition, "adding people to a late project only makes it later." The new people have to learn, and while they're learning, the slow everybody else down. McConnell (Software Estimation: Demystifying the Black Art) and many, many other works warn against the perils of schedule compression, by whatever means.

The Igneous Group
The Igneous Group

Not super helpful. These are the obvious "low hanging fruit" to project managers.

wparke
wparke

Mr. Mochal: Why it OT listed as #1 when every class I've ever taken in project management says use OT as a last resort?

Marty R. Milette
Marty R. Milette

From each project -- become 'smarter' by doing a post-mortem and benchmarking. Use that knowledge to do a better job estimating the next project. Develop project templates for the same types of projects you do regularly. For example, a Microsoft Exchange consultancy should have a pretty accurate idea of the steps and timeframes for each new contract. It is amazing how few firms do this and end up repeating the same gaffes.

SObaldrick
SObaldrick

Cut the quality. Reduce testing time. Isn't that how the big boys get their software out on time? Les.

wizard57m-cnet
wizard57m-cnet

Leave the dead to rest in peace Wizard57M TR Moderator

The 'G-Man.'
The 'G-Man.'

Not super good. Just the normal "fallen & spoiled fruit" to forum users. Added nothing. What about the beginner, this article may be handy for them to know.

Donald Wood
Donald Wood

Despite what may be taught, OT is the first thing that Upper Management thinks of, in my experience. Besides, he did explain that this was not the best idea and that it's primary use should be toward the END of a project when you have limited options to resolve issues. At the beginning, or early into a project, he suggested that this was not the best method and other options should be considered. It may be a simple matter of "reading the bullets" and not the subsequent text. As someone else pointed out...this is just a LIST, not a Top 10.

The 'G-Man.'
The 'G-Man.'

10 ways to get a slipping project back on track - not the 'TOP 10' ways. The description of #1 is just a place to start and even says as much. Perhaps other classes are needed?