24 October 2008

Project Management Tools

Project management tools don't get work done.

My company like so many companies I've worked for is trying to get the tools the team needs to get their work done. My friend John Moren has said many times that the most common problem he's run into in his career is the lack of tools. Specifically the lack of a company to invest in tools to automate important tasks for him.

The other side of this coin is that simply rolling out a tool for people to use doesn't get them to use it. Some say we need to train them, some say we need to motivate them, some say we need to provide process for using the tools. They are all right of course. Unfortunately they are also completely wrong.

Training, motivating, and providing written process will not actually result in anyone doing anything. They are only fascilitations. They are important fascilitations. The truely impactful management technique that will make things get done is "putting the rubber to the road."

Getting something actually done. So the true measure of a Project management tool is the ability for it to serve three purposes:

1. Organize the work into bite size measurable chunks that when completed can be checked off.
2. Provide a common repository for work artifacts so that the measurable bite size chunks of work can be seen, reviewed, and utilized.
3. Provide a way to compile, agregate, or deploy the work products that have been created.

Unfortunately none of the worlds Project management tools do all three. Most do the first item ok. A few expensive ones do the second item. But because of the lack of integration to systems like AGILE, software build systems, or other development and deployment systems there is a serious lack of true project tracking to the end deliverable. 

This means that progress reporting cannot be automated against the actual work. Instead people have to report on their progress.  Whenever you have a system where people are reporting instead of the work speaking for itself you are going to have inaccurate reports. 

The common sources of inaccuracy are: 
1. Miscalculations
2. Missunderstanding
3. False reports

The problem is that often by the time you determine that inaccuracy in the reporting you are in trouble. 

Oh i can go on and on. 

But I'll just summerize:

Project management tools don't get work done.

1 comment:

  1. This has come up recently where I work. GarageGames has a strong data metric philosophy. I was working out with my manager some value we could use to evaluate code quality.

    Our system doesn't have a good way to judge coverage since each unit test is compiled just using the necessary source and there is no wholistic source measure.

    The idea was thought of was to get a listing of all the files in the system and run them through Gimpel lint. And use that to quantify inspection/quality work that is left to be done.

    This was in regards to a quality refactor.