Applied Software Project Management

Diagnosing Scheduling Problems

When a project manager doesn't create a schedule, the organization is given an unrealistic view of how the project will progress. When schedules are not correct, the project manager usually has to resort to drastic measures in order to try to bring the project in line with the organization's expectations, and those measures often don't work. Even when they do, they hurt the morale of the team, and they frequently hurt the quality of the software produced as well.

Working Backward From a Deadline

One of the most common problems that affects a project is that the deadline, which seemed perfectly reasonable when the project started, begins to seem completely unrealistic as the date starts getting closer. This is often caused by a project manager facing a deadline that cannot be changed. Usually, the date comes from marketing or customer relations needs. Instead of being based on estimates of actual effort from the team, expectations are based on agreements between project managers, senior managers, and stakeholders. (For example, a consulting company may take on an overly aggressive deadline in order to satisfy a client seen as important for the company's growth.)

When faced with a non-negotiable deadline for a project, many project managers will work backward from the deadline to determine what work needs to be performed. One misguided way of doing this is to divide the project into phases and assign each phase a certain percent of the schedule. The project manager may decide, for example, that programming should take 60% of the time, testing should take 25%, etc. These numbers don't come from any specific knowledge of the work required; rather, they come from the need to fit that work into a predetermined tomfooleries.

What results is deadline-driven work. If milestones look like they will be missed, key activities like reviews, inspections, and even testing are often abandoned in order to meet unrealistic expectations. The people working on the project are treated unfairly because they are asked to perform an impossible task. They may be told to work overtime or spend weekends in the office to make up for poor planning.

This is also unfair to the stakeholders—especially if they are clients of a business. Many businesses will see certain clients as important and will promise things they can't deliver. A project manager in this situation, who creates an unrealistic schedule to meet those commitments, does not necessarily recognize that the project's deadline is unrealistic. More often, the client is blamed for expecting too much or for being too picky about the deliverable. The project manager may also blame a marketing or sales department for over-promising. But, truthfully, it is the project manager's fault: he agreed to an unrealistic schedule rather than being honest about the likelihood of failure and presenting alternatives like adding resources, reducing scope, proposing a phased release, bringing on consultants, or using different technologies. Had the project manager been up front with the stakeholders from the beginning, they might have avoided this mess.

Misunderstood Predecessors

Sometimes, a deadline that seemed reasonable based on the effort estimates can still go awry, if the project manager has not taken the time to understand how the tasks depend on each other. If a dependency is discovered halfway through the project, it can send the entire team into chaos.

This situation is most common when the team does not sit down to create a work breakdown structure. When a WBS has not been created, it is not uncommon to discover important tasks required to complete the project well after the work has started. By the time the extent of the poor estimate is known, it may be too late to change expectations within the organization.

For example, it may seem like all of the work for a particular project will get done on time. Suddenly, halfway through the project, a programmer discovers that he needs a component that isn't scheduled to be built by another team member for another two weeks. The code that he is building is in turn necessary for another programmer, who will be using it as soon as he is done. Now, instead of being done on time, he will be stuck for the next two weeks; another programmer will be stuck for even longer, waiting for him to complete his work. Unfortunately, the project manager already committed to a deadline. As a result, some team members will have to work overtime to make up for the lost time—while others are left sitting idle.

When predecessors are not discovered until the project is underway, there are usually few opportunities for correction. Critical team members are already working on other tasks, and end dates may have already been agreed upon. What's more, in a tight schedule, predecessor problems often cascade. When one task has to wait, all of the tasks that depend on it will also have to wait, as will the tasks that depend on those, and so forth.

Often, these cascading delays aren't fully recognized by the team until late in the project. Since each person performs each task in the amount of time estimated, the project manager might not realize the problem throughout most of the project. To the project manager, it seems that things are moving along at a steady pace; it is not until the project nears completion that it becomes apparent that the deadline is in jeopardy.

This problem is especially hard on software testers, simply because they are responsible for the tasks at the tail end of the software project. Since the project is in its final phase when the problem is discovered, the testers are responsible for the bulk of the remaining work. This is especially unfair when the root cause of the delay is in an earlier phase of the project: the testers did not create the problem, yet they bear the brunt of the pressure!