In my post, I list steps that I have found effective for creating and using project plans. And I agree that scheduling a project, or project tasks, to death, or using the schedule as a weapon, is counterproductive.

I think that even the Monte Carlo approach is overkill–you don’t know how something is going to happen until it happens, especially when people are performing service work. I would rather see PMs put their efforts into managing people with professionalism and grace, and managing risks with their best soft skills, than learning how to run probability analyses to estimate completion dates within a certain margin of error. I know there are mangers who love to see these numbers–so crunch them if you have to–but I think the effort decreases your final ROI.

Oh yuck. Now I know why you’re so angry.

Poor fella!

Rob: I’m not lucky enough to get project that simple. Although I didn’t spell it out, my points were about major projects with a whole range of unknowns. If you’re able to break a project down into small, discrete steps you’re usually able to give accurate estimates. One step at a time.

Likewise, as a software engineer it’s beyond my field of expertise to say how long until there’s a cure for AIDS, but asking a virologist might give you a better idea, certainly some reasonable chance of estimating the likelihood of having a cure by such-and-such a date.

Thankfully, most projects I’m involved with only require my team and I to apply skills and techniques we either already have or that are similar to things we already know how to do, and getting a risk profile for things like, for example, “time taken to learn Python” or “delays introduced by the database team screwing up the upgrade” would be a lot easier than the examples you give.

I will agree totally that the “unknown unknowns” (thanks, Don) will be the ones that kill you. That’s why you have to keep searching for new risks – risk discovery doesn’t just happen at the start of the project (although even then would be an improvement for my current team), it’s an ongoing process, and your risk profile may need to be changed as you go along.

The most important thing to realise, though, is that N-day is NOT (or, at least, very unlikely to be) the day the project will be complete. Unfortunately most project managers work on the basis that all will go well and there’ll be no extra work, so the customer is told “N-day is the day we ship.”, only to be told later that the project is slipping like crazy.

Brad Bellomo: I’m not sure why you think running a Monte Carlo simulation 500 times would take such a long time (i.e. as long as the project), given you’ve already got the tool to do it and you just need to enter the data. Unless, of course, you mean the time taken to collect and enter that data in the first place, but that’s just a re-statement of the original problem (identifying and profiling risks) which is not dependent on the simulation method (or, even, whether you simulate or not).

Mr Angry: In a Monte Carlo simulation you basically run the project many times in simulation, but with events occuring (or not) each time through based on their assigned probability (see http://en.wikipedia.org/wiki/Monte_carlo_method)

Would you really never be happy making 100% assertions? How about “I can change the background colour of my blog to light green by the end of next year”. That’s 100% do-able, surely? So what about by the end of next month? Next week? Today? In the next 30 seconds? At some point you can give a reasonable “guestimate” that the chance you’ll have something completed falls to just under that 100% – that’s the other end of your risk profile curve (the one that starts with 0.000 000 001 chance at N-day)

[Great blog, BTW]

I see how important scheduling is. Funny thing is that we don’t really know when something comes. Life is mystery.

Crashcodes: you’ve highlighted some of the very things that would stop me from ever being 100% sure of delivery

Brad: I’m not familiar with Monte Carlo so i don’t know how much hassle it is.

I don’t like the second part. By the time you are done running Monte Carlo, you could have been done with the project.