Correcting Schedule Problems

The first project that fell behind schedule was the renovation of the first cave to be used as shelter; the job was continually disrupted by disputes with a previous tenant. Projects have been falling behind schedule ever since, including a high percentage of software projects. I’m going to try to give you some tips which might help to bring your software project back on schedule and keep it there, in this article.

Project managers of software projects should be using the best practices in the industry to manage their projects, including project schedules. The PMI are generally acknowledged to be the leaders in establishing these best practices and their "stamp of approval” is the PMP accreditation. The best practices can be learned in any good PMP course, or other PMP exam preparation product. Attaining the PMP accreditation is good insurance against having to use the tips and tricks described in this article. Investigate the possibility of accreditation if you haven’t already done so. I’ll explain how you can do that at the end of the article.

There are several ways to find out that you’re behind schedule and several different interpretations of what behind schedule means. The project manager’s measurement tool for project performance to schedule is the schedule itself, usually captured in a project management tool such as MS Project. A Schedule Performance Index (SPI) of less than 1.0 indicates a project that is behind schedule. This may or may not indicate that corrective action is necessary; it all depends on the degree and which way the index is trending. Another means of determining your project is behind schedule is missing a key milestone such as a gate/phase exit/business decision point. Yet another indicator is missing the delivery date for a key deliverable. Most project managers would much rather find out the project is behind schedule using the SPI than having it brought to their attention by an irate executive sponsor, or customer.

Tip #1

Always keep your MS Project (or Primavera, or other project tool) file up to date and measure performance to schedule frequently. Keeping the file up to date requires you to mark work complete which has been completed. Note that this does not mean marking it as complete when the programmer says he or she is "95%” complete, or "99%” complete, but when the work is actually completed and you can verify completeness by its presence in the source library, or build. Updating also entails changing the schedule to reflect any changes in the work being done or how it is done. Changes may come to you via an official change request, or you may be informed by a QA tester that they are changing the order in which they will run tests. Make the schedule reflect the work planned, the sequence it is planned in, and the forecast dates by which the work should be complete.

You should use your schedule to measure your project’s SPI at least once a week. SPI is simply the amount of work which has actually been completed divided by the amount of work which was planned to be completed by the measurement date. There are a number of different ways of arriving at these 2 figures, but all of them require an up to date schedule.

How Far Behind Are We?

How far behind you are will determine how drastic the corrective action will be. You will know exactly how far behind you are when you know the SPI. Knowing how much work was planned to date and how much has actually been completed allows you to quantify how far behind you are in terms of hours, days, weeks, or months. Being 50 hours behind schedule on a 12 month, 50,000 hour project won’t cause much panic. Being behind 10,000 hours on the same project should cause panic.

Knowing how your SPI is trending is another good bellwether for corrective action. You will normally establish a threshold which will trigger corrective actions. If your SPI sinks below this threshold you will take some corrective action, and if it doesn’t you won’t. Watching how your SPI is trending may provide you with an opportunity to avoid running behind schedule. Let’s say that 3 weeks ago your project was actually ahead of schedule with an SPI of 1.05. Last week it dipped slightly to 1.02 and this week it went down to .98. You may have set your threshold at .95, but the downward trend of your performance indicates that you can expect to exceed that threshold by next week so why wait to take action?

Why Are We Behind in the First Place?

The first step to take is to determine the root cause of the slippage. Once you know the reason for the slippage, you will have a better idea which one of the many remedies to apply and how to prevent another slippage. By root cause I mean what went wrong that caused the deliverable to be late or the milestone to slip. There are numerous good courses that will train you in conducting a root cause analysis session, but they will all have this in common: the repetition of the question "Why?” until the source of the failure is found.

Determine how many activities are actually behind schedule using your project schedule. MS Project will actually produce a report showing every slipped item in the WBS which is handy for this type of exercise. Once you’ve determined which activities are behind schedule, isolate all the slipped activities that are on the critical path. If the list of slipped activities on the critical path is limited to one or two items, go ahead and determine the root cause of that slippage. If there are many slipped activities on the critical path, your root cause analysis will have a different focus.

Group the slipped activities into meaningful categories, where you are analyzing a significant number of slipped activities. These may be grouped by function (C⁺⁺ programming, database design, QA testing, etc.), they could be grouped by application (User Interface, database, scheduling function, etc.), or by phase. Look for the root cause of the slippage for each item in the group, focusing on a common cause. There may be a cause that is common across every item in the list of slipped activities.

Solutions by Cause

Bad Planning

It will become apparent that there is a problem with the planned schedule for your project as you isolate the slipped activities. For example, let’s say that every C⁺⁺ programming activity on the critical path has slipped (at least all those whose due date has passed). This is a good indication that there is a problem with the duration/effort estimation for C⁺⁺ programming. You can verify this by checking for slipped C⁺⁺ tasks that are not on the critical path.

The solution to a bad planning problem that applies to an entire function or project phase is to re-plan. Apply the learning from your root cause analysis to the re-planning exercise so that you don’t repeat the mistake. There are 2 scenarios that you should plan for with this exercise: a new schedule with extended milestones based on the same resource set you are working with and additional resources and budget to complete the project on the same schedule.

Unidentified activities are another indication of bad planning. Activities that are essential to building the deliverables that were not identified in the planning phase may become apparent as the team attempts to build deliverables. Be sure that the activity is a valid and essential part of the project before approving the work.

Tip #2

Analyze the effort/duration estimates for QA testing activities when you determine that programming activities have been under-estimated. Estimates for programming effort/duration may have influenced the estimates for QA testing (e.g. the QA estimates may be based on the programming estimates). You will want to re-visit those estimates to ensure that the same mistakes don’t propagate to testing.

The new plan must be introduced via your change management process, so author a change request with the two scenarios, offering your executive sponsor the option of delaying implementation of your project, or acquiring the additional resources that would be required for delivering the project to the original schedule. You should be able to forecast what the decision will be based on the way priorities are defined in the project charter (e.g. schedule first, budget next, scope last etc.) but you can’t take the decision for granted. Be certain that all bad estimates have been accounted for in your request; your executive sponsor will not want to approve change requests week after week as you uncover more bad estimations.

The change request may not be the bombshell you might think it would be, if an aggressive schedule was planned initially but don’t spring the change request on your executive sponsor as a complete surprise. They should have been alerted to the possibility of a change request by virtue of their knowledge of the poor performance to schedule. If they were not aware of the poor performance for any reason, educate them before hitting them with the change request. You may even want to prepare them for this possibility by explaining how you intend to manage the project.

Resourcing

Your root cause analysis may determine that your schedule slippages are limited to tasks assigned to one particular resource. There are several possible causes for this:

Performance issues are dealt with at a more detailed level in another series of articles I’ve written entitled "Dealing with Performance Issues”. What follows here is a distillation of the tips and tricks detailed in those articles.

Improperly Identified Skill Set

Replace the resource with someone from the resource pool with the required skill set. Failing this, you will have to either engage an external resource with the required skill set on contract. Return the resource with the miss-identified skill set to the resource pool and correct the HR profile of this resource.

Improperly Identified Experience Level

You should attempt to replace this resource with another from the resource pool with the requisite amount of experience. Failing that, move the resource to a less demanding activity off the critical path. Where the resource was thought to have senior experience and is mentoring a junior resource, place the junior resource with another mentor. Where you have a junior programmer performing activities requiring a "medium” or senior experience, you need to provide the junior resource with the simplest activities. Junior programmers will work best when paired with a senior programmer who has the time to provide proper mentoring. Try assigning the junior resource to administrative tasks where their experience level is not equal to other tasks in the plan.

Poor Performance

The most straightforward remedy for poor performance is to replace the poor performer. Although this is the simplest remedy, it is seldom one that the project manager can exercise. Addressing performance issues is beyond the scope of this article, however I do address performance issues in another set of articles on this site and others titled "Dealing with Performance Issues”.

Performing Work Not in the Plan

This is more common in projects where the resource is not 100% dedicated to the project, but can also happen with dedicated resources. The resource fails to meet their deadlines, or meet them with reduced scope because they have been performing work for another project, or operational work.

Partial resources, who are not devoting the agreed upon hours to your project, call for a more sharply defined division of the resource’s time. Make the agreement specific as to hours or days. For example, rather than a 50% split negotiate a 2.5 day a week split, or a 20 hour per week split. This action alone won’t stop the pilfering but will allow you to monitor the situation more closely and identify problems before they evidence themselves in missed deadlines or dropped scope. Don’t forget to negotiate a return of the time your project has lost due to past pilfering; this is time that your project is owed and it is a valid aid to putting your project back on schedule.

Occasionally you may encounter other project managers or operational managers who will engage members of your team in "skunk” works that is work that is not officially sanctioned or budgeted for. Stop this in its tracks. Approach the offending manager and let them know that the pilfering must stop; inform the pilfered resource that they are not to devote any project time to the "skunk” works, and that means any business hours if they are devoted to your project 100% of the time. This may be difficult to do if you are performing in a matrix environment, so don’t hesitate to escalate the situation to your executive sponsor if you don’t get cooperation.

Incorrect Tools or Methods

Using the wrong tools, no tools, or the right tools incorrectly will lead to poor performance and missed deadlines or reduced work products. The first step is to ensure that your project enjoys the correct tool sets. Development tools (or SDKs) come with many of the web development tools and training in the use of these tools should come with purchase of development licenses. There are many tools that will improve productivity in addition to these including tools that automate unit/function/system testing and tools that automate builds. Tools that automate builds in particular can save the project time that would otherwise be spent on fixing integration bugs.

Ensure that your project has the right set of developer tools and then ensure that all developers, even ones that join the project part way through the build phase, are properly trained in the use of these tools. Developers who avoid using the tools, or who miss-use them, may indicate inadequate training. Training and documentation are frequently overlooked when purchasing software tools. These are critical features of any software tool and should be part of the purchasing decision. Automated test tools in particular can be complex and require adequate training before programmers can become proficient in their use.

Changes

Your root cause analysis determines that your team is bogged down in analysis of an avalanche of change requests and this activity is preventing them from meeting deadlines and completing deliverables as planned. You may believe that having a solid change management plan in place will prevent this from happening to you, but change management plans are meant to deal with the changes you receive, not to restrict the requests you receive.

Your change management plan should define how time is set aside to analyze the requests for change the project receives and also what happens when that buffer is depleted. There are 2 basic approaches to dealing with this situation: either you issue another change request to add resourcing to the plan, or reducing scope so that the additional change requests can be analyzed or you shut down your change request input. These contingencies should be implemented before the project is put behind schedule.

You have 2 issues to deal with when the project is behind schedule, making up the lost time and preventing further erosion from change requests. You can include the lost time in your scope resource increase or scope reduction if you and your executive sponsor choose that remedy. You will have to determine another corrective action if you choose to restrict change requests. Possible corrective actions are: overtime, additional resourcing until the schedule is caught up or a reduction in scope to allow the existing resources to make up the lost time with their standard work schedules.

Tip #3

Excessive change requests may be the root cause of your schedule slippage but you should determine the cause of those change requests. This analysis is not totally within your control, you’ll also need information from the stakeholders authoring the requests. If conflicting stakeholder business objectives are the cause of the "churn”, ensure that your requirements sign off process accounts for each of the stakeholders’ business objectives and then ask your executive project sponsor for help in stemming the flow of change requests. Let them know that the extra work caused by these requests is putting the project at risk and their help is needed to correct the problem. Resistance to a restriction of change requests may be an indication that you need to revisit your business case and either re-affirm stakeholder commitment to the system the project is building, or re-visit the system design.

Iterative Projects

Each iteration in an iterative build approach is a mini-project so falling behind on one iteration does not necessarily mean that all future iterations are badly planned. The down side of the iterative approach is a shorter time to react to scheduling problems, the up side is that you have more opportunities to learn from past mistakes and apply those learnings to future iterations.

Most of the remedies we have described are applicable to iterative projects. The difference is that the threshold (e.g. SP variance) established for implementation of the root cause analysis/corrective action must be set much lower to preserve an iteration.

The discovery that you have underestimated the work required to develop the deliverables planned for iteration 1 will not necessarily mean that iteration 2 work must be re-estimated (the deliverables and work required to build them changes across iterations so under estimated work may only be applicable to the current iteration), however you should investigate that possibility. Plan to perform a "Lessons Learned” session after each iteration, or each major iteration. Quite often "Lessons Learned” will be as good a source of information regarding the root cause for your slippage as a root cause analysis session.

There will be opportunities in future iterations to perform the work differently, perform work in parallel, implement productivity improvement tools, work overtime, or any other strategy that might allow you to do the same amount of work in less time. Allow extra time for training and to accommodate the learning curves required to master the use of productivity tools.

The iterative approach also provides you with opportunities to correct schedule slippages by moving work from the current iteration to a future iteration. Prioritizing the feature set for the system before the build phase will aid in this exercise. Plan to move a higher priority deliverable from the current iteration which is slipping to a future iteration by "bumping” a deliverable of lower priority. Deliverables here are typically features or functions in the business requirements set.

Crash the Schedule

Crashing the schedule is typically done by performing activities originally scheduled to occur sequentially, in parallel. This is a solution that is applicable to schedule slippages whatever their cause, and to almost any development method. Check your plan for activities planned in sequence to determine if scheduling them in parallel would shorten the schedule. Sequential activities that lie on the critical path are obvious candidates for crashing but don’t limit your search to the critical path. You may find that by shortening non-critical path networks you can free up resources to add to the critical path.

Examine the relationships between the sequentially sequenced activities you have identified as candidates for crashing. The criterion for a sequential relationship is a "hard” dependency, which is the successor activity has a physical dependency on the predecessor activity. A classic example of this type of dependency is the dependency of the framing activities for a building on the curing of the concrete in the foundation of the building. This appears to be a hard dependency but only applies to all framing activity if the entire foundation is to be poured in one activity. Pouring different segments of the foundation at different times breaks up this dependency and allows framing to occur before the entire foundation is poured.

Now let’s take an example from the software development world. It is true that you can’t begin development of a software system until the requirements for it have been defined, but do you have to define all the requirements before beginning any design activities? The answer is often "no, you don’t”. Completion of requirements activities are frequently a sticking point in software development projects. Stakeholders are hesitant to sign off on requirements in case they miss an important requirement, or make a mistake with their definition of an identified requirement. One method you can use to break this log-jam is to have your stakeholders sign off on the requirements they are comfortable with so that design can start on those requirements. You need to ensure that requirements that are ready form an appropriate base for your system, but once that has been established you can begin the build phase of your project. Changes can still be made to any of the approved requirements through the change management process.

Redefining Features

The feature set in a software system delivers the functionality that make up the objectives for the project. For most functions there are a variety of features that will deliver the functionality and different features will most likely require different amounts of effort to build. Let’s take the log in security as an example. The software system being built requires a log in function and the log in must be protected by a secure password. One means of ensuring password security on an ongoing basis is to force the user to change their password periodically, to maintain a password history and force the user to select a password never used before. Another means of securing the password is to simply enforce criteria for the password and make the user responsible for their password. The second approach will be much less costly to build (and to maintain).

Examine the features that are the most costly to develop and ask questions. Does this feature deliver a promised function? Is the feature essential to that function? Is there another, cheaper, means of delivering the same functionality? Examine the feature set for any features that aren’t essential to system functionality and change your plans to eliminate those features. Examine the essential features for opportunities to substitute less complex, cheaper features. These changes must be made by way of a change request but showing the decision makers how the change will put the project back on track and still deliver the necessary functionality should sell the change.

Contingency Reserve

Some projects will plan for a contingency reserve to address unforeseen project risks and this may be the time to dip into that reserve. Using the contingency reserve to put the project back on track will require approval from the executive sponsor, steering committee, or other authority in charge of the reserve.

Budget Increase

Increasing the budget is the "brute force” method of bringing the project back on track. The increase in budget may be used to pay for overtime, or additional resources, additional tools, or all of these. Be sure that the new budget for the project is sufficient to deliver all the project objectives and meet the milestones before taking this change request to the approving authority. Your sponsor may be able to accept an increase in the budget at this point but will not be receptive if you go back in 2 weeks time for another increase.

Schedule Increase

The last resort is to increase the project schedule, based on project performance to date. This action should not be taken unless you have verified that none of the preceding remedies will allow you to recover the project and deliver on time. Re-scheduling your project as a corrective action indicates that it was improperly scheduled to begin with. Make certain that all the estimating errors are corrected for upcoming project activities so that the new schedule can be followed.

You may also have to increase the schedule to accommodate activities that were not part of the original plan. Ensure that no other essential activities were missed in the original plan before asking for approval of the change request for the new schedule.

Conclusion

Employ preventive actions wherever possible on your project. Preventive actions will preserve your original schedule (or at least give you that chance) and are often cheaper to implement than corrective actions. Set two triggers for the project: the first trigger will be the trend that calls for a preventive action (i.e. how may reporting periods in a row should the SPI be allowed to decrease without taking action) and the second will be the SPI threshold that calls for a corrective action.

Don’t rush into a preventive or corrective action without first doing a root cause analysis to determine why the project went off the rails. Use the results of the root cause analysis to help you to determine the proper preventive or corrective action, and the extent of the action. Don’t just examine the current iteration, or phase, or function, examine the entire schedule to ensure that the mistake does not get repeated.