A team that I have been working with for some time has one project (we’ll call it Project X) that has had a problem getting traction over the last three months. What do I mean by “getting traction”? Specifically, on an ongoing basis the team plans the amount of work required to meet delivery commitments but consistently completes significantly less work than it plans.
In the above graph, the yellow lines represent the amount of work planned for each weekly task cycle on Project X. The green bars represent the amount of work that was actually completed for each task cycle. The white space between the top of the green bar and the yellow line indicates how much planned work is not getting completed each task cycle. I know that for the last four task cycles Project X needed to complete eighteen effort days of work to remain on target (and not chew through slack). Therefore, based on this chart, I know that Project X is not getting traction.
This particular team is more than twenty people and is working on several projects simultaneously. Some team members are dedicated to Project X and some split their time between Project X and other projects. Since I know that we are having a problem getting traction on Project X, I should really find out how we’re doing on the other projects that we are currently working on. To do this, I run a different report that gives me the average planned versus completed totals for the last six task cycles, broken out by project.
Based on the above graph I can see that, in general, the team is completing the amount of work it plans. The traction problem that I am observing on Project X is happening on two other projects: B and G. But these are non-critical projects, so I’m not concerned to see us completing less than we plan there. Project J is the only other critical project we are working on, and that project is delivering rather well.
Now no one is blaming the team members on Project X for this traction problem. There are good reasons that they are having this problem–which I am not going to get into here–and we have kept the business and upper management well informed on these reasons the entire time. We do, however, need to try to correct this problem. So we reduced our effort on other non-critical projects, asked upper management for assistance with the external dependencies that are slowing us down, and authorized a bit of paid overtime for the team members on this project. We did these things during Task Cycles 10 through 12, when it was clear that significant steps needed to be taken to keep the project on track.
On Thursday, when we closed Task Cycle 12 and started Task Cycle 13, the key question on my mind was whether the actions we took to help this project were sufficient. If not, we might need to discuss a reduction in functionality or moving the delivery date. On Thursday morning each team member reported status for the tasks planned for Task Cycle 12 and queued up the tasks for Task Cycle 13. At the point, we could add a couple new data points to our graph for Project X.
Well, we’re not out of the woods yet, but Project X seems to have found sure footing for the first time. And we’ve planned more than 25 effort days work for segment 13, which means we could begin to make up some of the ground we lost. We will continue to warn the business and upper management that we are still dealing with the issues that have slowed this project up to now. But, based on this new data, we can show progress toward overcoming those issues. And we know what metrics to watch for at the beginning of Task Cycles 14, 15, 16 an onward in order to determine whether this project has really overcome its problem getting traction.