jump to navigation

How Do You Plan to Catch Up? June 12, 2012

Posted by Tim Rodgers in Management & leadership, Project management.
Tags: , , , , , ,

When a project falls behind schedule — as it almost inevitably does — there’s a tendency for project managers and their teams to enter a state of denial and convince themselves that they can catch up by “working harder.” Maybe they remembered an earlier stretch when they weren’t working especially hard, maybe thinking there were still many weeks or months of budgeted time. Perhaps they encountered a barrier that couldn’t be easily overcome right away, and decided to “work around it” and come back to it later. Senior managers who are responsible for providing oversight to the project teams may accept this “working harder” plan, either because they’re sympathetic or don’t want to be bothered with the details.

How often does that actually succeed? Senior management shouldn’t accept an explanation that the project team will simply “work harder.” They should require the project team to explain how they will work differently. Doing things the same way is not going to help the team catch up; there needs to be a change in the scope of the project or how the work is done, for example adding resources, re-assigning tasks, or re-arranging tasks on the Gannt chart.

When I managed software testing we would track the number of defects found and fixed each week over the course of the project. The goal was always to have zero open defects by the time of the scheduled software release date. From historical data we had a rough idea of how many defects one developer could fix each week, so at any point in the project we could extrapolate an end date based on the number of open defects. If the extrapolated date was later than the scheduled date, we knew we were behind schedule and had find a way to catch up. In a case like this “working harder” means somehow increasing the rate at which the work (defect fixing) gets done, because continuing at the current rate was not going to reach the goal.

We used a variety of strategies, depending on the software project. Most often we would reduce the scope of the remaining work by de-rating defects and removing them from the fix queue, essentially accepting a lower level of quality. Sometimes we would add resources (developers) to fix defects, but anyone who has read “The Mythical Man-Month” from Fred Brooks knows that adding resources to a late software project just makes it later. We would finesse that problem by changing priorities and re-assigning tasks within the existing team instead of adding people (it didn’t always work).

Regardless, project managers shouldn’t be allowed to wave their hands and offer vague plans when projects fall behind. The catch-up plan must explain how things will be done differently, and it must be explicitly reviewed and approved by senior management to ensure a successful project completed without further surprises.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: