Overcoming schedule slippage
A project schedule, usually in Gantt chart form, shows what work is to be done when. Schedule progress is a project key performance indicator (KPI). It measures how our project is proceeding against its schedule (usually expressed as a percentage). If ours is a time-driven project, then this is an important measure of project success.
Schedule Slippage = (Actual Project Duration – Planned Project Duration / Planned Project Duration) X 100
Plenty of things can derail a project schedule, including underestimated task durations, incorrect dependencies, departing team members and material shortages and delivery delays, but here are some practical techniques that can correct our project if it’s losing ground.
Anyone who has worked on project teams knows that many factors can move a project past its deadline. It’s not uncommon for some of the work to take longer than originally anticipated, particularly for pioneering endeavours about which we have no history of task or project durations. Also, project staff turnover, which is more prevalent on longer duration projects, requires extra time to bring new people up to speed. Regardless of how it happens, at times we’ll find that we’re trending beyond our anticipated finish date. If we discover that happening, our first requirement as project managers is to try to determine the cause for the delay. If we apply remedies to treat effects without knowing the cause, the situation will probably recur. Our second job is to make corrections that will get our project back on track. At the beginning of a project, we usually have several options to solve slippage issues. But toward the end, our choices dwindle. Check out the list below and see which ones we can apply should our project fall behind schedule. Note that this list is not prioritised as some of the ideas may work in one instance, while others could be more effective in another situation.
Outsource the work
If our schedule slippage is due to a lack of resources, we might consider contracting out (outsourcing or off-shoring) some project work. This may add to the cost of our project, but could allow us to catch up, providing suitable contract expertise is available. However, sometimes the procurement process can be time-consuming and further delay the project. Outsourcing successfulness is dependent upon how well we manage the process before and after the outsourcing contract is signed. Some companies award outsourcing contracts to the lowest bidder without understanding what it means to the business and without performing due diligence. When things start to fall apart, like missed delivery dates, quality problems occur or bad customer service, the blame-game starts and everyone runs for cover as our project slips even further behind schedule and costs escalate.
Everyone hates it, but the most obvious solution to schedule slippage is to work overtime, rather than the work-smarter option. If people work more hours, they can usually get more work done in the same amount of calendar time. Overtime may be the best option if we’re close to the end of our project and just need a final push to get everything done on schedule. If it’s still early in our project execution phase, there are probably more effective strategies. This option may also have cost implications if we need to have resources work overtime. Also, there is likely to be some diminishing level of productivity if our people are required to work overtime for a prolonged period. Incidentally, when an employee works more than their normal hours they should be paid for the overtime they do. However, in New Zealand there is no legal requirement to pay overtime above the normal rate of pay after working a certain number of hours in a day or a week. Whether overtime rates will be paid is a matter for negotiation between an employer and an employee. Best practice if the project schedule is based on overtime would be to include agreed overtime rates in the employment contract so both parties are clear about the terms and conditions when the employee works more than their normal hours. Sometimes working longer hours is like dousing a fire with gasoline. It can mean unsafe practices.
Assign more productive resources to critical tasks
We must first understand which tasks are on the critical path since this is the route that determines the duration of our project. After all, if our project is trending over the deadline, by definition it is the critical path that’s late. Interestingly, there have been court cases over this issue, but providing the critical path tasks are on schedule, the project is not officially behind time. Once we understand the critical path, see if suitably multi-skilled resources can be moved from non-critical tasks to help resolve the issue. This may allow us to get the project back on track by delaying or stretching out some work – using float or slack. However, sometimes by delaying work we may change the critical path. Always make sure we check the critical path each time we change the schedule. Some points to keep in mind when we accelerate critical path tasks are:
- Attempt to accelerate earlier tasks rather than those scheduled towards the end of the project. This ensures that we have other tasks to accelerate if our first attempt fails.
- Attempt to accelerate longer duration rather than shorter duration tasks. For example, it’s usually easier to reduce a 10-week task by one week than it is a two-week task by one week.
- Realise that some tasks are cheaper to accelerate than others. Add one person to a task currently assigned two people is likely to cause more cost-effective acceleration than adding one person to a task that has currently been assigned twenty people (not withstanding Brook’s Law).
As mentioned, the first thing to do when we’re trending over our schedule is to determine the cause – essential to effective problem solving. One cause is that we have one or more resources that aren’t as productive as we anticipated. Perhaps certain team members don’t have the right aptitude (skill) and/or attitude (will). Perhaps they aren’t as productive in this particular area as they are in other areas. There may be opportunities to coach, counsel, or replace such resources. Incidentally, the “FIFO” acronym in the diagram below doesn’t mean “First In First Out” as in inventory management. Rather it means “Fit in or go away” if you get my drift. Go talk to their line managers about a more productive replacement or perhaps it’s a matter of temporarily postponing the project team member’s business-as-usual work in order they have more time for their project commitments. If line managers are reluctant to help, we may need to involve our project sponsor who usually has more organisational authority than ourselves.
In some instances, we can simply swap people who are working on different tasks within our project. Other times, we may release a team member and bring in another person. Remember that the tasks on the critical path are key. We may have options to assign a more productive resource to those tasks, while reassigning a less productive resource to noncritical path tasks. If the tasks off the critical path are delayed, we may still be okay in terms of meeting our overall project deadline. We should first reassign resources from those tasks that have the most float, since these tasks can be delayed more than other tasks before causing a delay to the project.
Schedule dependencies represent tasks that must be completed in a certain order. For example, if we are building a house, we cannot start putting up the frame until the foundation is poured and hardened. If we’re trending over our deadline, we might revalidate dependencies, particularly desirable dependencies, but not the mandatory variety, since it’s possible that the schedule is being lengthened by invalid or unessential dependencies between tasks. Invalid dependencies make it appear that tasks must be performed sequentially, when they could be done in parallel. Sometimes scheduling software accidentally adds a dependency. Sometimes the project manager adds the dependency but on later review decides it isn’t needed. It often helps to have the team members review the project network diagram to see if they find invalid or unnecessary dependencies. Check all dependencies to make sure we have all our facts correct before we take more drastic measures to bring the project back on schedule.
Check time-constrained tasks
Time-constrained tasks are those with durations that don’t change based on the number of resources applied. For example, we may assign team members to a five-day class. The class takes five days if one person attends, and it also takes five days if 10 people attend. Check all of these time-constrained tasks to validate the timeframe. Perhaps we’re making assumptions that could be changed with a different approach. For instance, if we allocated three days for a contract to reach a client, perhaps the time could be reduced to one day by using an overnight courier delivery service. I think it was US management guru Warren Buffett who told us “No matter how great the talent or efforts, some things just take time. You can’t produce a baby in one month by getting nine women pregnant.” This expression is now referred to as the “mythical man-month.”
“Crash” or compress critical tasks
Crashing the schedule means applying additional resources to the critical path, which is the sequence of tasks that must be completed on time for the entire project to be completed on time. It’s always possible to just throw more resources at critical path tasks, but crashing also means we try to get the biggest schedule gain for the least amount of incremental cost. For example, if one person was assigned to complete a task in 10 days, we could see whether two people could complete it earlier. If two resources can complete the task in five days, we may not be adding any incremental cost to the project, since we’re applying twice the resources for half the time. In another example, if two people can complete the work in six days, we will have accelerated the schedule at an incremental cost of two workdays (two people for six days versus the original 10-day estimate). In this example, we could further crash the schedule by applying three resources. Perhaps then the task would take four days, or four and a half days. Typically, the more resources we throw on a task, the more the incremental cost will be and the less incremental time-savings we 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 minimise 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 tasks can result in accelerating the schedule.
“Fast track” or overlap critical tasks
Fast track means that we look at tasks that are normally done in sequence and assign them totally or partially in parallel. Back to our home-building example, we can’t construct the frame until the foundation is dry. However, if the house is large enough, we 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 us 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, we wouldn’t start constructing a solution until the design was completed. However, if we were fast tracking, we would start constructing the solution in areas where we 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 finalised, and those final changes may result in us having to redo some of the work already completed or under way.
Stop changing the scope
Many projects begin to trend over their deadline because we are doing more work than we originally committed to. This could be a result of poor scope change (variation) management or it could be that small changes are being worked in under the radar screen – “scope creep” that usually means gradual death to on-time completion. If we’re at risk of missing our deadline, as the project manager we 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.
Scope creep generally takes the form of new requirements being added once our project has started. Typically, these changes are not properly reviewed and we are expected to deliver them with the same resources and in the same time as the original scope. On the other hand, we could end up with a project with lots of approved, considered changes that never end because every time we think we have finished a new requirement arrives in our inbox and we have to make more changes.
When we look at the cause for the project trending over schedule, we may find that some of the internal work processes could be improved. Solicit team member feedback and look for ways that are within our team’s internal control to streamline processes. For instance, perhaps we have a daily status meeting that is not providing value and that can be scaled back to say once per week. Unless an activity in a process adds value it’s a candidate for redundancy. We may also find bottlenecks in getting deliverables approved.
If we discover delays caused by external processes, we might try to negotiate changes to the processes going forward, at least on a temporary basis. For example, we may find that tasks are being delayed because people need to complete business-as-usual work. While such work is important, perhaps this work could be temporarily reassigned or its timing changed to allow critical project tasks to be completed on schedule. A checklist for process streamlining and improvement can be found here.
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. We attempt to de-scope the project. If we think some of the remaining work is not core to the project, we could discuss eliminating it. 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 enhancement project to complete the remaining requirements. To reduce scope requires we prioritise deliverable features and functions and then eliminate those of lesser priority until the schedule of work allows us to get back on track in terms of our deadline. For example, in our house-building project we might forgo that separate laundry on this occasion and combine this facility with our garage. Other trade-offs among project parameters to accelerate the schedule may be possible.
The above are factors to consider if we’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 on-time completion is very important to the client. Some of these techniques don’t require any incremental budget. We should consider these 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 we can’t move the schedule or the budget, there may be options associated with scaling back the scope of work. Usually we can complete less work sooner. Once we know the cause of the problem and our budget flexibility, we can determine the best actions to undertake to get back on track to hit our deadline. However, three points need reiterating:
- Let’s try to negotiate a realistic completion date in the first instance, rather than an optimistic estimate that needlessly puts everyone under pressure and increases the likelihood of quality and OSH issues, and include in this estimate a time contingency to allow for identified risks, which should they occur will impact the project completion date. And continue risk management and re-estimating work-effort and durations throughout project execution. Part of the risk management requires our project sponsor to set schedule slippage tolerances within which we work.
- We need to carefully monitor schedule progress and take early action to rectify any excessive slippage. The mantra is “To solve it easily, detect it early.” There are a variety of ways to monitor progress. The frequency with which we require progress reports could be relaxed if all is going to schedule, but better to over-monitor than under-monitor until we are satisfied all is going well. And we shouldn’t assume that “no news is good news” or that significant schedule pluses and minuses will somehow balance out without our intervention.
- Any proposed scope changes need to be formally advised and assessed in terms of their schedule impact and where necessary the sponsor’s approval sought for additional time or some other remedy if on-time completion remains paramount. “Scope creep” (also called requirement creep and feature creep) refers to uncontrolled changes or continuous growth in our project’s scope. This can occur when the scope of our project is not properly defined, documented, or controlled. Some projects suffer from “scope gallop.”