Practical Project Cost Management

http://blog.twproject.com/2013/06/03/practical-project-cost-management-with-teamwork/

by robicch • 13 years ago

19 9 13 years ago

blog.twproject.com

korkmitsumi• 13 years ago

Maybe too simplified but effective

lotsofcows• 13 years ago

"20 days subtask"

Blimey, I don't trust anyone to effectively estimate their time over any period greater than 5 days. And I tell them to add 20%...

robicch• 13 years ago

Yeah, actually this is exactly what I think. I believe in agile approach, but for the old generation PMs 20 sounds better :-)

anoressLucy• 13 years ago

Someone else even likes to schedule 2h tasks.... and the planning never stops!

_pmf_• 13 years ago

I've been taught to estimate in logarithmic units, i.e. 1 h, 2 h, 4 h, 8 h (i.e. 1 d), 2 d, 1 week, 2 weeks, 1 month

gadders• 13 years ago

Agreed. I mean at some level of abstraction (EG status reporting to senior management/sponsors), rolling up sub-sub-tasks into one 20 day task would be OK but if I had direct oversight over the developers I'd aim more for 2-3 days.

sfall• 13 years ago

if you think construction then a 20 day subtask could be a trade for a floor

mathattack• 13 years ago

"Blimey, I don't trust anyone to effectively estimate their time over any period greater than 5 days. And I tell them to add 20%..."

I find it more accurate to double the # and bump the metric.

1 hour => 2 days 3 days => 6 weeks

Estimation is one of the hardest parts of the software management.

jacques_chester• 13 years ago

How'd this advertisement wind up on the front page?

My main problems are that the author has failed to distinguish between estimates and plans. They are not the same, or rather, they should be treated differently.

When you consider plans and estimates as identical, two things happen.

First, your estimates start becoming subject to political pressure. After all, the only reason anyone starts a project is to meet some goal or goals. And those goals tend to come with certain constraints. If you work backwards from the goal, you get a plan and then suddenly, if the plan disagrees with the estimate, guess where the pressure goes?

Likewise, if you simply take your estimate and transform it into the plan, you've failed to plan adequately. An estimate is a probablistic statement about some future outcome. By itself it fulfills one and only one of the required features of a plan:

* Job sizing: How big is this job, and how long do you expect it to take?

* Job structure: How are you going to do the work? What will you do first, second and so on?

* Job status: How do you know where you are? Are you going to finish on time and are the costs under control?

* Assessment: How good was your plan? Did you make any obvious errors, what mistakes should you avoid in future, and how can you do a better job next time?

If the estimates were actual estimates, expressed in terms of uncertainty, then the "overflow" statement is a nonsense. In fact all such approaches are a nonsense, as they require hundreds of people to miraculously become expert forecasters in what are often novel tasks. Given how many ways people can fall into the "planning fallacy", that's unfair. Estimation deserves at least a structured process of its own -- whether by parametric model, points poker or PERT 3-point estimation.

Disclaimer: I'm a bit of a wingnut about estimation and I've been working on a tool to make it easier and better.

Practical Project Cost Management

Related Stories