Practical Project Cost Management
blog.twproject.com
Practical Project Cost Management
1–10 of 10 posts
Re: Practical Project Cost Management
#2Re: Practical Project Cost Management
#3Blimey, I don't trust anyone to effectively estimate their time over any period greater than 5 days. And I tell them to add 20%...
Re: Practical Project Cost Management
#4"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%...
Re: Practical Project Cost Management
#5"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%...
Re: Practical Project Cost Management
#6"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%...
Someone else even likes to schedule 2h tasks.... and the planning never stops!
Re: Practical Project Cost Management
#7"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%...
Re: Practical Project Cost Management
#8"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%...
Re: Practical Project Cost Management
#9My 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.
Re: Practical Project Cost Management
#10"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%...
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.