If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

I have been watching an interview with Joel Spolsky this morning and one section really caught my attention which was a new feature within FogBugz. In the next major release 6.0 Joel stated that they will be giving development managers the ability to create probability curves to represent the % chance of completing your project on time within given times scales.

So for example a project that is meant to take 20 days has a 10% chance of taking 20 days, 25% chance of taking up to 30 days and a 65% chance of taking over 40 days.

What really interested me was how this could work alongside a few things I implemented years ago for a previous company when I wanted to try and automate the process of time estimates. What any IT project manager knows is that every individual has a ratio of how much you need to alter their estimates against what you put in the schedule.

This can range from them being ultra conservative and giving themselves massive amounts of buffer time; or the ultra optimists who think everything can be done in a day. There is actually nothing wrong with either of these approaches; as long as your keeping track of previous estimates against actual time taken. This can then give you a future ratio to work with when building your schedule.

But working with even a small team (e.g. 5 people) over 6 months means quite a surprising amount of project information and manually estimating peoples under/over estimates by hand is an impossibility. Something like Microsoft Project is totally unsuitable to this task but did have some of the building blocks I needed. So I decided to delve into the murky depths of VB and try and kick project until I got it to do what I wanted.

The end result was a system that tracked all previous tasks per resource (people in our case) by looking at the original estimate and the actual time taken and then performing some mathematical jiggery pokery to take account of trends and time distribution it then came up with a current ratio to apply to the resources original time estimate.

This sounds complicated but to the project user all you had to deal with was an extra field to track the actual time taken. You then in your Gantt chart were shown the bar which represented the original estimate plus a different coloured bar tacked onto the end that then showed the predicted time scale. This still worked all within usual project constraints of linking tasks, predecessors and the like.

Anyway back to my original point of how this links into what Joel had mentioned about probability curves. What I suspect they will be doing is looking at the previous task instances as I did and then produce the probability curve based upon that data.

Will they also be building the probability data based upon all previous history information or will they bias the probability based upon newer data higher than on older.

What will make or break this is in the end is how they build that graph when dealing with multiple resources and how they interact. Because the end product must be something that is easy to understand and easy to explain to those above who not always understand the numbers.

Only time will tell.. or someone else reads this and does it differently.

Related links

Joel Spolsky PodCast (Scoble show) - PODCAST

Joel Spolsky Blog - BLOG

FogBugz Project Management - FOGBUGZ