3 ms·
ROM Auctioneering; Accurately estimate complex projects in one hour
- jrockway 6y agoI always like Avery's "Software Engineer Simulator": https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213 (on HN: https://news.ycombinator.com/item?id=15912929 https://news.ycombinator.com/item?id=15912929)
- cortesoft 6y agoIn 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?
- iamasuperuser 6y agoDetermining 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)
- jacques_chester 6y 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 6y agoThank 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.
- al2o3cr 6y agoWe 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 6y agoThe usual joke: Respond by giving your mangler (and maybe his mangler) two copies of The Mythical Man-Month.
- ofrzeta 6y agoI 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.
- rzzzt 6y agoThe other often repeated quote is about pregnancy.
- daly 6y agoIn 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 6y 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 6y agoManagement 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 6y agoYou 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.