How many systems are out there for tracking the status of a project and the tasks within that project? Whose responsibility is it to gather and compile these status reports? Is it the manager, project manager, some software? Is "get the status" the wrong things to consider?
The Manager Tools podcast on Assign Work AND Reporting gives me a new view of this question. First off, while acknowledging that task status is a valid concern, the Manager Tools guys suggest that the need to “get status” is the wrong view. Instead, reporting of the task status is the responsibility of the task owner: she is the best person to know when a task is done (including handing off any relevant documentation, code, materials). And she is the best person to know that the task is going to be done early or late. And if there are problems, the owner most likely knows who might be able to help.
The Manager Tools guys touch briefly on why this reporting of status has gotten away from the task owners. In the world of primarily physical work, the status was obvious: the thing you were working on was sitting there for everyone to see. But in knowledge work, much of the status is not obvious until the task is done. And even then, people may not know the work is done until they ask for it. It makes sense for the person doing the work to report this status.
But why don't they report status? The manager tools guys suggest that it's due to the way managers and business talks about tasks. The tasks are "do X," and there is no longer the assumption that status is part of "X." Without that assumed need, people naturally do not report the status. Manager Tools argues that is it not obvious when work is done. More importantly, it is easy to hide "not done" and "going to be late" if the standard behavior is not reporting the status. So Manager Tools recommend changing task descriptions to "do X and report on status," where the status is something in the form of a report or proof that the task is complete (or the current state of the task).
So why is this so interesting? One of the elements of the work I've been doing with Critical Chain Project Management has to do with task management. Rather than holding people to specific dates, we ask them to to work as quickly as possible (single-task focus) to get tasks done when they start. And while the task is in progress, report the status on a daily basis in the form of how much time is remaining on the task. If there are problems / delays, that should be reported as quickly as possible, so the issue can be resolved and the task completed. The goal is not to complete individual tasks "on time" but to complete the overall project as quickly as possible. This dovetails nicely with the discussion from Manager Tools: the task owner should be responsible for communicating the status.
Another thing they touch on is the idea of status tracking software. If it is built and set up with the mindset that it is there to "get the status" of tasks, the organization is going to find great resistance to the software. This sets up the software as the enemy, and it's even worse if management don't bother using the status information to make decisions. (Ever hear the argument that people can't get work done because they are spending so much time updating the status? It's a smokescreen.) Instead, if software is to be used, it has to be part of a logical response to how task owners can report status / troubles / successes in a standard way that helps them do their job AND helps the organization do something with the information.
[Photo: "Every year is getting shorter, never seem to find the time" by John Harvey]