Techniques to Get a Project Back on Schedule

4.1.1.3T Techniques to Get a Project Back on Schedule

(4.1.1.3T.P1)

People that have worked on project teams know that there is a lot that can go wrong and result in a project trending over its deadline date. For instance, some of the work may be harder than originally anticipated. You may have turnover on the project that results in having to get new people up-to-speed. Sometimes you discover that activities were simply underestimated.

Regardless of how you get there, many times you will find that you are trending beyond your committed deadline date. If you discover that happening, the first obligation of the project manager is to try to determine the cause. If you look for remedies without knowing the cause, you are susceptible to having the situation re-occur over time.

What should you do after you know the cause? Should you notify the client and push the project end-date out further? Not yet. The next obligation of the project manager and project team is to try to make corrections that will get the project back on track again. If you are trending over your deadline at the beginning of a long project, you have many options available to you. If you are toward the end of the project there may be fewer options available. The following techniques can be applied depending on your situation. Note that this list is not in a priority order. Some techniques may work better in certain situations while others can be applied more successfully elsewhere.

Work Overtime (4.1.1.3T.P2)

Everyone hates it, but one logical place to look at is 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 are close to the end of the project and just need a final push to get everything done on schedule. If you are toward the end of the project, you also may be able to issue comp-time (comparable time off) after the project is completed. If you are still early in the project, there are probably other options that are more effective.

There may be cost implications to this option if you need to have contract resources work overtime.

Reallocate Resources onto the Critical Path (4.1.1.3T.P3)

The project manager must first understand the activities that are on the critical path. After all, if the project is trending over deadline, by definition it is the critical path that is late. Once the critical path is understood, you should try to move your most productive resources onto critical path activities. When the project started you may not have known exactly which team members are most productive. However, as the project progresses you should try to move your stronger people onto critical path activities. After all, these are the activities that must be completed on time. If you have some less productive team members they may take longer on their activities but that may be okay if they are working off the critical path. Be careful – if non-critical path activities take longer than expected they may end up changing the critical path. Always make sure you double check the critical path each time you change the schedule.

Swap Resources on the Critical Path (4.1.1.3T.P4)

You saw previously that the first thing you want to do when you are trending over your schedule is to try to determine the cause. One cause you may find is that you have one or more resources that are not as productive as you planned. Perhaps it is because they do not have the right skills. Perhaps it is because they are not as productive in this particular area as they are in other areas. Regardless, there may be opportunities to replace resources. Swapping resources means that you are releasing a team member and bringing in another person from outside the team. (This makes it different than reallocating resources within the project team.) It is likely that when your project started you received the best resources that were available. However, as your project progresses you may realize that other stronger resources are becoming available. These people might be stronger fits for your project.

Double-Check all Schedule Dependencies (4.1.1.3T.P5)

Schedule dependencies represent activities that must be completed in a certain order. For instance, if you are building a house, you cannot start putting up the frame until the foundation is poured and dried. If you are trending over your deadline, these dependencies should be re-validated, since it is possible that the schedule is being lengthened by dependencies between activities that are not valid. 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 if you made a mistake entering the activities. Sometimes the project manager adds the dependency on purpose, but upon later review decides that the dependency does not 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.

The dependencies should all be double-checked to make sure you have your facts correct before you get into more drastic measures to bring the project back on schedule.

Check Time-Constrained Activities (4.1.1.3T.P6)

Time-constrained activities are those that have durations that do not change based on the number of resources applied. For instance, 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 ten people attend. All of these time-constrained activities should be checked to validate the timeframe. Perhaps there are assumptions being made that could be changed with a different approach. For instance, if you allocated three days for a contract to reach a client, perhaps the length could be reduced to one day by paying more for overnight delivery. If you have a two-day wait for concrete to dry, perhaps the time could be shortened by renting fans to blow air on the concrete.

“Crash” the Schedule (4.1.1.3T.P7)

Crashing the schedule means that the end date is so critical that you are willing to throw resources onto the critical path – even if the additional resources are not utilized as efficiently as they could. Of course you want to try to be smart and get the biggest schedule gain for the least amount of incremental costs. However, you are trying to get any gain that you can.

For instance, if one person were assigned to complete an activity in ten days, you could see if two people could complete it earlier. However, perhaps the second resource does not have all the right skills and if you assigned a second person full time, you might only gain two days inn the schedule. Normally it would not make sense to allocate a second person for eight days just to complete the activity two days early. However, if the schedule was so important that you were “crashing” perhaps you would make this tradeoff.

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, in exchange for completing some work ahead of schedule, crashing usually always leads to some additional incremental cost to the project. If cost is not as important as the deadline, “crashing” a set of activities can result in accelerating the schedule.

Fast Tracking (4.1.1.3T.P8)

Fast track means that you look at activities that are normally done in sequence and assign them partially in parallel. For instance, when building a house, the frame cannot be constructed 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 harden there first, 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 way you could fast track would be to start building the walls on the ground while the foundation was drying so that the walls could be erected more quickly when the foundation dries.

Another example involves designing an IT application. Normally you would not 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 always involves risk that could lead to increased cost and some rework later. For instance, in the 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 underway.

A good rule of thumb is that sequential activities can sometimes be fast-tracked by up to 33%. In other words, if you are fast-tracking, you can start the second of two sequential activities when the first activity is 67% complete. There is risk involved; however, this seems to be a level of fast-tracking risk that is normally acceptable.

Implement “Zero Tolerance” Scope Change (4.1.1.3T.P9)

Many projects begin to trend over their deadline because they are doing more work than they originally committed to. This is probably the result of poor scope change management. However, if you are at risk of missing your deadline date, the project manager must work with the client and team members to ensure that absolutely no unplanned work is being requested or worked on – even if it is just one hour – without going through proper scope change management procedures. All energy should go into completing the core work that was agreed to and all additional work must be funded incrementally.

Improve Processes (4.1.1.3T.P10)

When you look for the cause of the project trending over schedule, you may find that some of the internal work processes could be improved. The project manager should 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 can be scaled back to once per week. You may also find that there are bottlenecks with getting deliverables approved.

If you find that there are 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.

This is a good technique for longer projects since you have a chance to optimize your project processes, see the results and optimize some more. However, it may not make sense for smaller projects. It is hard to do much process improvement on a 30 day project. By the time you would want to make any process improvements the project would probably be over.

Regain Commitments (4.1.1.3T.P11)

Sometimes deadlines are missed so often that the team no longer has a commitment to completing their work on time or within budget. This can especially happen if team members consistently miss their deadlines without consequences. Other team members wonder why they need to work hard to meet their deadlines and budget estimates when others are not meeting theirs. When this happens, the project manager should communicate with team members to gain commitments to complete assigned work on schedule. The project manager needs to try to refocus the team to meet the deadlines they are committing to. The project manager should ask each team member for his personal commitment to do what it takes to meet budget and schedule commitments.

Improve Morale (4.1.1.3T.P12)

It may be that morale on your team is poor, but that your team members are still hitting their deadlines. That may be fine for now, but it will probably not continue. Poor morale will ultimately cause you problems with your schedule. When people have poor morale, it impacts your schedule in a number of ways.

People are not committed to their deadlines. Even if they are hitting end dates now, chances are that this will not continue if the team has poor morale.
Quality will suffer. People that have poor morale don’t care as much about the quality of their work and they may start getting sloppy or careless. This may make it seem like they are hitting their deadlines, but there will be more rework later.
They may quit. When morale is bad, people may start to look for new opportunities. This will cause project problems if the turnover occurs.
They spend too much time complaining. When people have poor morale they usually like to commiserate with others. You end up having your team spend time complaining and not spending the time that they need to complete the deliverables.

The team will work harder and perform better if they do not spend time complaining and sulking. The project manager should build shared purpose, increase camaraderie and do some fun things to get people excited and happy again. You can see more information on managing a team with poor morale at 3.3.3T.P6 Attack a Team Morale Problem on Many Fronts.

Check Discretionary Dependencies (4.1.1.3T.P13)

When you map out the relationship between all of the activities you will notice that some of the activities have a firm dependency and others have a soft dependency. That is, in many cases one activity must follow another activity. However, in many cases you will find that certain activities are placed in a certain order for convenience or even arbitrarily. The first case is referred to as a mandatory dependency or “hard logic,” and the second case is a discretionary dependency or “soft logic.” It is important to know the difference.

Discretionary dependencies should be checked to see if you can move a discretionary relationship earlier in the schedule. This will result in starting and finishing the dependent activity earlier, which can help you accelerate the overall schedule. Of course, to have an impact, you must identify activities with discretionary dependencies that are on the critical path or that influence the critical path.

It is also possible that you have some activities that have external dependencies. These dependencies are imposed by people outside of your project or by other projects. These external dependencies should be checked as well since it is possible that they can be changed in a way that will help you proactively manage your project.

Scope Back the Work or Reschedule the Deadline Date (4.1.1.3T.P14)

One final option that is usually available is to look at the work remaining and negotiate with the sponsor to remove some of it from the project. If the remaining work is all vital to the solution, this discussion still might need to take place as a last resort. There may be options to complete the project on-time with less that 100% functionality, and then execute a follow-up project to complete the remaining work.

The other alternative of last resort is to request a slippage of your deadline date and see if you can complete the original work requested if you are given more time.

The key point is that you don’t jump to this alternative as soon as you start to trend past your deadline date. You should first try the other multitude of proactive options available to try to get back on schedule. You should only fall back on reducing scope or asking for more time if all the other tools and techniques fail.