Slipping task management.

They say someone who is successful is someone who has screwed up a lot and learnt from it. So I'm hoping this project will help me to do that. There was a project manager at my work who was ruthless (in a good way) at tracking tasks that were slipping. Those who worked with her found it annoying in some sense, but everyone acknowledged she also provided perspective and butt protection. At some point, people stepped back and reassessed where they were with the task and re-planned. This is good for the developer, the project and the project manager.

So say you have a task that is slipping by a developer. You need to analyze the task and determine what kind of slippage it is. Is it slipping because its not clear what work it is. Maybe you need to break up the task into more manageable bits.

If it is dangerously slipping you might need to not deliver the entire thing. Understand what is the real dependency or feature that has to be delivered. Can you get away with perhaps releasing the interfaces even if there isn't an implementation. Can you deliver where the configuration is via a configuration file even if there isn't a GUI component requirement. It is a case of being creative and understanding your requirements.

If a person has missed a deadline several times, then you need to keep that in mind when dealing with them again. They could be bad at estimation, or their loading needs to be really low. Note you may have an opportunity for improvement with a person if their productivity is really low*.

When even that fails, you need to start micro-managing. This is where you break the task down with them, ask them daily how they are going with the task, and tracking very carefully. Its funny how quickly a task that is carefully scrutinized ends up being delivered.

Going back to my earlier point on idiosyncrasies of each team, it is really important to understand the motivations of each team member. I've heard people say 'everyone is out to do a good job and spend the right amount of time on it', and this is not always true. As a general rule, it is true, but you need to understand both extremes in the project too. There is the person who will work 12 hour days, rip through tasks, burn out and quit. You also have the 9-5 institutionalized person is waiting for their LSL to kick in and say things will be done 'when its done'. Whilst you can help, often those folk need to sort out their priorities in life outside of the project. You need to realize both are a risk to the project and the tasks and allocate accordingly.

*The funky thing about matrix organizations is that the closest person to the employee in question can't suggest those improvements. They need to tell the coach instead. Unnecessary layer of communication there.