The day before yesterday, I was sitting in a meeting, examining the project schedule which our project manager had just handed out. “Not another @^#%& Gantt chart!” I thought to myself. I know this sort of planning is essential for the people outside the project who need to know when it will is likely to be done and what progress is being made, but as an individual developer contributing to the project, I’m generally only interested in two things: the very highest-level view of the scope of the project and our progress, and the details of my tasks.

The first of these is, of course, the same thing that outside observers want from the project management process. The latter is something that’s only of interest to me, and which nobody else cares a bit about, except perhaps when the project falls behind. But because we use Microsoft Project for our scheduling, I have to see the giant task list, 85% of which doesn’t even remotely apply to me. After staring at the monstrous chart for a few minutes, I went into reverie, considering what this process should look like. Here are a few of my scattered thoughts:

• When a project is started, all the projected tasks will be enumerated in a web application. (Part of the problem with Project is that, at least as it’s generally used, everything has to go through the project manager, who is The Keeper of the File. Using a web app distributes the maintenance of the project plan.) A project manager creates high-level tasks. The developers would then create sub-tasks with increasing granularity until the work units are small enough to be estimated accurately. (My experience is that any task that one expects to take more than a few hours probably should be broken into sub-tasks.) When this process is complete, the total for each developer is multiplied by his personal “fudge factor” as computed by the system and fed into the project estimate total.
• Each developer will have an individual and continually revised “fudge factor” computed, based on his initial work estimates and the actual time it takes him to complete the jobs. This will be well-buried, as it’s only used to increase the accuracy of work estimates, not to point out deficiency in her estimates.
• Each project should have a “dashboard” which shows the original estimated date of completion, the current estimated date of completion, the number of tasks completed, the percent of tasks completed, etc. There should be a single, big pretty progress bar/timeline with color coding to indicate scheduled progress, schedule slips, etc. This is the view that most everyone from outside the team doing the work will want to see. The highest-level tasks will be marked on the timeline.
• A developer will have a personal “work entry” page which lists all the tasks assigned to her. If a task has prerequisites, it will only appear here once the prerequisites have been completed. By accessing this page at the start of a work day, the developer will be able to easily see what parts of the project she can work on. At the end of the day, she’ll simply enter the number of hours she worked on a given subtask, and click a checkbox if the subtask has been completed. (The checkbox, rather than a “percent complete” setting, also reinforces the idea that subtasks should take no more than a few hours.) This allows progress to be tracked easily, and helps to keep the developer’s “fudge factor” accurate by comparing the original estimate to the actual time spent on the project. This page should also include a small version of the dashboard progress graph, thereby consolidating all the information that the developer needs on a daily basis into a single page.

That’s what I’ve got so far. I know some of my developer friends have thought about some of this stuff before too, so please feel free to chip into the discussion, or alternately to swipe any of these ideas you like for your killer project management application.