Managing Projects

This is a follow up to a previous post, To Estimate or Not To Estimate.

I've been doing a lot of reading and learning and experimenting since that post and I now have a much clearer idea of what I'd like to see in a project management application.

I'll start with what kinds of questions I want to be able to answer:

1. Who has too much work, who needs more work? (Developer Workload)
2. How much work have we done, how much work is left (Iteration Status)
3. Is our scope slipping, are we getting things done, are we converging on a completion date? (Iteration Progress)
4. Are certain high level tasks slipping or eating more time than others, or more than expected? (Project Item Progress)
5. What are people working on/what should they be working on?
   

My current thoughts are structured like this:

• Project - top level
• Project Items - high level "tasks", or "features" that make up a project. These are assigned to one or more individuals. Estimates are added at this level in terms of complexity or actual hours.
• Features, Tasks, and Bugs make up Project Items.
• Tasks and Bugs are assigned to developers and estimated in hours (<=16 hours)
• If actual time spent is going to be tracked, enter it at the Project Item level.

There are a couple of important things to note here. First, from an estimation standpoint, it makes no difference how much time the developers have actually spent versus how much time they estimated. All that matters is how much time they think is left. With that information you can create a "burndown" chart. That chart will answer my Iteration Status, Iteration Progress, and Project Item Progress questions (assuming I can filter it appropriately). That information would also make it possible to build a work load chart similar to this one. All of this can be accomplished without worrying about actual time. We can also display a list of all the Project Items a certain developer is assigned to, or a list of all the developers assigned to a given Project Item. No more wondering what people are working on.

Now you have some nice and simple burn down charts. But are they accurate? No. You know your developer's estimates are not correct. You also know that some devs are better estimators than others. So you can't accurately predict a ship date from this data. You can get a rough idea, and you can see that the project is in good shape and is progressing nicely, but you can't determine a date.

If you want to be able to predict an actual ship date, then you need to track time, and you need Evidence Based Scheduling and you need FogBugz. Can EBS account for the fact that working with a third party scan library will take 4 times as long as what a developer usually works on? Kind of, but not really. Can it predict that a ton of redesign and new features may need to be added to the application after the client sees a demo? Kind of, but not really. So even though EBS is way more accurate with the data it has, it's still just giving you a rough estimate because it doesn't know what data may arrive tomorrow.

So the question becomes, how accurate do we need to be with this stuff? Are we satisfied knowing that our work is trending toward completion? Or do we need to know WHEN completion will actually happen?

From my current thoughts above you can tell that, right now at least, I think it's enough for me to know we're trending toward completion. Unfortunately, I'm not the only person in the equation. My boss needs to do two things I don't. First, he needs to guess before we even start a project how long the project will take. I call this a "blind estimate" and it's clearly impossible, but he still needs to do it because the client isn't going to hire you otherwise. Second, he needs to keep the client updated on when we're going to ship, because that is all a client cares about: when we'll ship, and how the budget looks (only some of them care if the app is any good).

Clearly, actual time matters a lot to him. And not just time spent working on tasks, but all "billable time." Time spent in design meetings, time spent with clients, time spent writing documentation, time spent researching tools, etc. Thus any time entry system which is going to be at all useful for integrating with billing has to allow me to enter time on things other than tasks or project items. It should allow me to just enter time and not require it to be "on something."

Furthermore, now that we're entering time, that time can be used to help with future "blind estimates." How long did it take to do x last time? It's likely to take a similar amount of time this time. That's why I think it makes sense to track time at the Project Item level. It's high enough to be "reusable" but low enough to be semi-accurate. Also, since we're estimating at the task level, and tasks are linked to Project Items, we can see how the remaining estimates and actual time spent compare to the original blind estimate and the budget.

I suppose the final question must be, is there a tool that will do all this? Not all of this, at least, not that I'm aware of. I know that a lot of this is very similar to Scrum. But the Scrum tools I've seen don't capture all of it (Scrum for Team System, escrum), especially not the time entry portions. Also, FogBugz comes pretty close, but it lacks the Project Item concept and doesn't have any burn down style reports. So if you were hoping I'd end this by recommending a tool, I'm sorry to disappoint. If I find one, or can make one work like I want, I'll let you know. And if you know of one, please let me know.