This is part 2 of a series of posts on software project management. The series starts with Managing Software Projects Part 1: Tools. Start there to get the whole story.

Jeff Atwood has noted, “On our project we’re always 90% done.” That phenomenon arises from not having a checklist of remaining work (or from having items on your list that are too big to really track).

Create Small Tasks

Smaller tasks allow for better estimates and being 100% done on 9 of 10 tasks is more accurate than being 90% done on one task. Consider developing a new app. Early in the project, you might have an item like:

And that’s fine for an initial plan, but it’s too big and too vague to implement. So, thinking about it more, you might get to:

I’d argue that the 30-hour and 20-hour items need to be broken down more but look what else has happened: by itemizing parts you added 10 hours to the estimate for the UI. You understand it better and you have a more accurate picture of the scope. If you did this immediately after project approval, you’d know early that you had estimated low.

Do High-Risk Tasks ASAP

The risk of delivering all the intended features or meeting your planned schedule is highest at project inception. If you are doing something novel — developing a new algorithm, working with a new widget set — you don’t yet know if it’ll take a day, a week, or a month. That risk can be reflected in assigning a low confidence to the estimate for the novel task.

You might also consider that a task that has not yet been broken down into bite-sized subtasks is risky because you don’t know what you’ll discover as you refine the task. Or you may know that one member of your team is always optimistic. Whatever the source of risk, you want to drive it out of your project as quickly as possible by scheduling high-risk tasks as early as possible. Once they are done, you have a much higher confidence in the remaining, lower-risk plan.

Confidence Levels

While “high” may be attractive for being intuitive, it’s hard to manipulate. How can we sort the low-confidence tasks before high-confidence ones? What is the overall confidence in the estimate for the UI task? Since we’re storing our project tasks in a database and manipulating them with code, we can assign numeric values behind the scenes.

It is no accident that there are an even number of choices. When given an odd number of choices, people tend to pick the middle value. By not having a middle choice, users are nudged to think a little harder about how confident they are in their estimate.

For completeness, my system has two more values, one on each end.

• A task may have no confidence selected and we use 0 to indicate “very low.”
• A task may be complete, in which case we use 5 to indicate we have perfect confidence that the actual hours worked is how long it took.

Using Confidence Levels

By taking the average of the confidence values weighted by the number of hours in each task, we can answer the question from above: how much confidence do we have in that 90-hour estimate?

((30*2) + (10*3) + (15*4) + (15*3) + (20*1)) / 90 = 2.39

Looking up 2.39 in the table of values, we can say we have Medium-High confidence in that estimate.

Next Time

In my next post, I’ll talk about scheduling tasks based on your business rules.