ROM Auctioneering; Accurately estimate complex projects in one hour
david4david4david4.medium.comI always like Avery's "Software Engineer Simulator":
https://apenwarr.ca/log/20171213 (on HN: https://news.ycombinator.com/item?id=15912929)
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?
> 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.
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.
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)
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.
> 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?
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.
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.
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?"
The usual joke: Respond by giving your mangler (and maybe his mangler) two copies of The Mythical Man-Month.
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.
It's worth a read, if just to consider that many of the observations made in the industry during the 70's hold true today. Wikipedia has a summary of the book[1].
You can push it to the extreme and have two persons on each and every coding task. That's pair programming [1], which is said to be less productive, although it is argued you trade productivity for quality and other benefits.
The other often repeated quote is about pregnancy.
Yeah but software is not a baby and software can very well have modules and APIs.
It also does not like to be split cleanly into as many parts as there are people working on it; development work is not an embarrassingly parallel problem.
The longer people work between coordinating with others the more code has to be rewritten.
People do not like rewriting code, so add time for all the bickering.