ROM Auctioneering; Accurately estimate complex projects in one hour

ROM Auctioneering; Accurately estimate complex projects in one hour(david4david4david4.medium.com)

37 points by iamasuperuser 5 years ago | 18 comments

jrockway 5 years ago |

I always like Avery's "Software Engineer Simulator":

https://apenwarr.ca/log/20171213 (on HN: https://news.ycombinator.com/item?id=15912929)

cortesoft 5 years ago |

In my experience, the hardest part of estimating how long a project will take is estimating how much time things OUTSIDE of the project itself will take. How much time will be spent maintaining other projects? How much time will be spent helping other teams on things they need? How much time will be spent on random other things?

jacques_chester 5 years ago | |

> In my experience, the hardest part of estimating how long a project will take is estimating how much time things OUTSIDE of the project itself will take.

Of interest, the author mentions Work Breakdown Structures. A WBS is meant to obey the "100% rule": it must contain all the work (ie, sums to no less than 100%) that goes into a project and it include only the work that goes into a project (ie, sums to no more than 100%). So if something shows up that wasn't foreseen, you add it immediately and adjust the fractions.

So far, this is not helping the competing-work problem. That's where old-school project management adds control accounts. Each item in a WBS has an account where individuals "spend" their hours, dollars and so forth. If you have competing work, then the dollars and hours get spent on a control account belonging to some other WBS.

Finally, this typically gets rolled up into an "Earned Value" plot. You can show much time and money was intended to have been spent at a given point in time and how much has actually been spent. If you notice that the rate of spend is below intended, you go looking for where the leakage is. Since you can perform Earned Value analysis on any part of the graph of control accounts, you can quickly identify what's going on.

And that's when two project managers begin to yell at each other.

This kind of apparatus comes with a lot of overhead. But I think it's underutilised, even informally.

iamasuperuser 5 years ago | | |

Thank you for the feedback. You clearly understand Project Management. I’m an advocate for Earned Value. It offers deep insights into a project during the Execution and Control phase. This ROM Auctioneering method is meant for the Initiation phase and allows the facilitator to create an accurate Rough Order of Estimation as possible, within an hour rather than the days or weeks that I typically saw it taking. One failing of this approach is that it doesn’t account for Critical Path identification or analysis. However, I suppose it could be the groundwork for analysis in that area and for Risk Identification too.

iamasuperuser 5 years ago | |

Determining the Critical Path, the sequence of events that must happen from Start to Finish, is the next critical step. This conversation pours cold water on the Mythical Man month. (If the manager 'gets it)

daly 5 years ago |

In 50 years of programming I've never, ever seen a project that met estimates.

I did see a 5 month, 5 person, fixed cost contract take 18 months, 10 persons, and sank the company.

Never, ever, try to estimate software projects.

sombremesa 5 years ago | |

> Never, ever, try to estimate software projects.

So...just go around telling people you need an indefinite amount of time to do anything at all?

daly 5 years ago | | |

Management has always taken my estimates, put them in a drawer, and then blamed me when the estimate was wrong.

Of course, they ignore the fact that the requirements changed during the project every single time.

That said, every project I've ever worked on was "new ground" and had never been done before. Musk can estimate how long it will take to make the next Tesla but might have a bit of trouble estimating the opening of the first Mars colony.

There was a posting about estimating that talked about walking in California. It was perfect. Can't find it again though.

Mesmoria 5 years ago | |

You and I have had quite different experiences. After 30 years I have [seen] most projects meet budgets. Time frames have varied more but that's usually driven by client scope creep.

We estimate all the time.

al2o3cr 5 years ago |

We did a process like this at a job once; it came back with an "estimate" of 240 developer-weeks, so the next question from management was "so we can have the feature in six months if we put ten people on it?"

kabdib 5 years ago | |

The usual joke: Respond by giving your mangler (and maybe his mangler) two copies of The Mythical Man-Month.

ofrzeta 5 years ago | | |

I haven't read it but from what is commonly quoted it is about "Adding manpower to a late software project makes it later."

So the assumption of bringing n people to work on a projects increasing the productivity n-fold doesn't seem totally absurd when they are working on the project from the beginning. It might not be exactly n but (n-m) due to increased management, communication etc. So we might discuss how big is m? Still there should be some increase in productivity because that's essentially how huge projects work.