Solving Schedule Problems

Solving Schedule Problems

At some point in the project, somebody will be late completing an activity. How do you recover, and how do you ensure that whatever caused the slippage will not recur in other activities?

Slippages come in two varieties: those you expected and those you did not. They require two types of action: corrective, to reduce the impact of the slippage, and preventive, to avoid similar kinds of slippages in the future.

Expected and Unexpected Slippages

An expected slippage is one you knew about before the activity was due to end. An unexpected slippage occurs when you discover on or after the activity's due date that it is late.

The purpose of tracking progress is to find out in advance about potential slippages. Therefore, an unexpected slippage is a project management problem beyond its impact on the schedule. You will want to know why you were not told of the slippage until it happened. Unless some unusual circumstances arose during the last few days of the activity, you must recognize that you were misled.

The sooner you know of a potential slippage, the sooner you can act. You must make it clear to your people how important it is that they give you as much notice of problems as possible. They must understand that failure to report a problem is a worse offense than being late. Unexpected slippages, unless mitigated by sudden events, are not acceptable, and if they are repeated or blatant, you will have to remove the offender from the team.

Corrective Actions

Corrective actions reduce the slippage's impact, which will range from minimal if the slippage is absorbed by slack time to severe if the activity is on the critical path.

Corrective actions apply to activities in the future as well as to the problem activity while it is in progress. The range of corrective actions includes any combination of the following:

1. Add resources. It is a cliché that you cannot recover from a schedule problem by "throwing more people at it." If the activity requires a high degree of knowledge about the application, the development environment, the project standards, or project components, the cliché is true. However, there are many activities that you can partition and assign parts of to newcomers with little disruption. If you have designed the project to keep activities independent so that new people can be readily added, you will now be able to capitalize on your forethought.

2. Request overtime. Overtime presents a dilemma. If the company pays for overtime, people are generally willing to work it, but the project budget balloons. Conversely, if the company does not pay for overtime, the budget is protected, but it is harder to get concurrence from the team.

People's willingness to put in overtime also depends upon the culture of the company. If management expects overtime, treats it as commonplace, and regards it as one route to promotion, people will be willing to comply. But if overtime is the exception or the company regards it as a refuge for those who are unable to meet assigned targets, they won't.

As part of your planning, you must consider the environment for overtime should it become necessary. An ideal overtime policy is one in which:

The company does not pay overtime to senior or management staff. They are expected to produce the results to which they commit.

The company does not pay overtime to anyone for an activity that that person estimated. Those who made the commitments are expected to keep them. (This assumes, of course, that the scope of the activity has not changed from when the estimate was done or that the overtime is not necessitated by work from other activities.)

The company will pay for overtime work only when the project manager has authorized it, and only for those activities specified. One word of caution: Be sure that whenever you authorize overtime, the company will pay it. Otherwise, nobody will be prepared to put in overtime.

If your company's overtime policies are lenient, be prepared for budget overruns. If they are stringent, recognize that you may have difficulty getting overtime work from your staff.

The best way to get willing cooperation for extra work, regardless of overtime pay policies, is to build a team. When your people are committed to the project's success, they will do whatever is necessary to ensure it. If they are not committed, they will do the minimum necessary to keep their jobs.

3. Get creative. Are there shortcuts you could take? Might a different approach cut the work? Is it possible to reduce the effort by being creative? For example, you might reduce the time for integration by forming small integration teams to work on two or three components as they are developed rather than integrating everything at the end. You may be able to cut development time by assigning a database specialist to code all database accesses, leaving others free to focus on business logic.

Getting creative does not mean thrashing about in a panic. Creativity is applying your intelligence and that of your team to come up with new, time-saving approaches to the work.

4. Reduce the scope or extend the schedule. If you have a project that will take longer than the time you have available, there are no more resources to add, your people are already working overtime, and there is no other way you can think of to trim the work, you have just two options: Reduce the scope or extend the schedule. Sometimes you can reduce the short-term scope, delivering limited functionality by the deadline and the rest later.

The approach you choose, whether to reduce the scope or extend the schedule or apply some combination of the two, will depend on the client's prioritieswhich you identified when you defined the project, rememberand on whether the deadline or the functionality is stricter. However, when all other options have been exhausted, these are all that remain.

Preventive Actions

Preventive actions are those designed to prevent a similar slippage from occurring in other activities. They require you to know what happened here. Was there a one-time event that caused the slippage? Was the estimate too low? Did the estimator not understand the extent of the work? Was there a change of scope? Did a team member not perform as well as you expected? In particular, you must determine whether this slippage was an accident or a symptom of a deeper problem.

You cannot plan for accidental slippages; that is why you have a contingency. Hence, other than reviewing the project plan and the risks, there are no specific preventive actions to take.

Symptomatic slippages, however, are a threat to your project. They have one of just two possible causes: Your estimates were wrong, or your people did not perform.

If your estimates were wrong, you miscalculated the amount of work needed. Now that you have a better understanding of the project, you can review the other activities to identify those that have also been underestimated. Revise the estimates to reflect what you now know.

If your people did not perform, it is either because they are underqualified or because they simply did not meet your expectations. If they are underqualified, you may need to replace them, shuffle work assignments to put them on easier or less critical activities, or get them some training. You can send them to a course, or arrange for on-the-job coaching by other team members, other company staff, or outside consultants.

A special type of underqualification occurs in projects that involve new technologies or unusual development environments. You may find that your team, including the most senior technical people, become overwhelmed and frustrated by a continual succession of problems. Do not hesitate to call for help, externally if necessary, from people who understand the tools you are trying to use. It is more cost-effective to pay for a few days of consulting time than to drag the entire team down for several weeks searching for elusive solutions.

If some people did not meet expectations, it is time for discipline. Meet with each personin privateto find out if there are any problems and to restate your expectations. Ultimately, if you have a consistently poor performer, you will have no choice but to remove him or her from the project. If you cannot get a replacement, redo the plan with the lower level of resources.

Your preventive action will probably lead to a revised plan, and the revisions will probably not shorten the project duration. You now have the unenviable task of informing management and the client that the project completion date is jeopardized. (See "Bearing Bad News" in Chapter 6.) You will either receive approval for the extended schedule or be asked to bring the completion date back to where it was. In the latter case, you are once again dealing with an externally imposed date, and your job is as described in Chapter 4 in "Aligning the Schedule."

What If?

The Schedule Slips Because Assigned Team Members Are Inexperienced.

If the estimates assumed a reasonable level of experience on the part of the project team members and they do not have the needed background, you will not be able to meet the schedule and the project will slip.

Actions

Revise the estimates based on inexperienced people. Include a block of time for training and some time and costs for on-the-job consulting, from an external source if necessary.

Identify specific people from other projects who have the kind of experience you need. If there are external consultants capable of providing the skills, revise the project budget to include them.

Present management with the option of either accepting the extended schedule and budget or providing you with the skill levels you need from other projects.

You Devise a corrective Strategy That is Not Consistent With The Project Methodology.

If the methodology cannot be violated and management applies it consistently, your ideas will not be acceptable and your scope for making alternative plans will be limited.

Actions

Identify any risks that would arise because of your departure from the methodology and develop plans for mitigating them.

Prepare two plans, one with the methodology and one with your new strategy. Present the plans to management along with your assessment of the risks resulting from a departure from the methodology and ask them to decide which approach they want you to follow.

Determine whether the methodology can be "retrofitted" to the project. That is, it may be acceptable to develop some of the deliverables required by the methodology after the project is over. Do not forget to estimate the extra effort and costs.