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.
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
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.
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.
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:
- the resource’s experience level or skill set may have been improperly identified
- the resource is not performing to the expected level
- the resource is doing work not planned for
- the resource is not using the proper tools or methods and performance is suffering as a result
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.
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.
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.
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
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
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.
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.
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.
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.
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
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
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.
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
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.
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
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
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.
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.
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.
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.The tips and tricks described in this article implement some of the best practices promoted by the PMI (Project Management Institute). These are taught in most PMP® courses and other PMP® exam preparation training products. If you haven't been certified as a PMP® (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php.