101–110 of 133 posts
These comments read like from a different galaxy (for me). Here it is very clear why. Management asks: how long does it take. Engineer replies: will take X man month. Management: thats too long, lets estimate shorter.
I clearly remember estimating something with a manager at a previous job, saying it will take 2 weeks. His response was, that's too long, let's try 2 days and see what happens.
Earlier quoted context omitted.
Exactly. So when a customer asks for an estimate you negotiate for the biggest buffer you can get away with, there is no incentive to make an accurate prediction.
Now I get your point, and agree. Plus, coming out below that estimate will make for a pleasant experience.
> A reasonable model for the “blowup factor” (actual time divided by estimated time) would be something like a log-normal distribution. Interestingly, we did extensive time tracking on a multi-year in-house software project and collected data comparing the estimated completion time of tickets with their actual time. The software department was under a lot of pressure to improve their forecasting, and were somewhat de…
> ...if you want to make a commitment you can take to a customer, you can just extend the lognormal up to... What you're proposing is effectively a fancy "padding factor", it's like on Star Trek when Scotty says they can only go at Warp-8, but really, Warp-11 is possible. Sometimes stakeholders do behave like toddlers and get red in the face and stomp around when a "promise" is broken because "we aren't there yet." (…
The first one tells you effectively nothing. The second one you can build strategy on.
"Every 20 minute job is one broken bolt away from being a 3 day ordeal."
These comments read like from a different galaxy (for me). Here it is very clear why. Management asks: how long does it take. Engineer replies: will take X man month. Management: thats too long, lets estimate shorter.
Engineering Manager: ok, Engineer, we need Vagueness, how long will it take?
Engineer: I can whip up a prototype in about a week but it's only a prototype and will lack any functionality. I'm also busy trying to get the fire put out on the fourth floor and my kids' daycare is closed because of the riots.
Engineering Manager: OK, 3 weeks plus another 3 weeks for QA and bug fixing. Also, have those reviews done and fill out your daily TPS reports. Oh, and can you just slip in those other two projects we talked about informally last week?
Project Manager: OK, I'll promise the client they'll have it by Tuesday. Where do I tell them to download from?
Over the course of my life I've designed and built many products/projects. Not a single one that had deadlines imposed by the customer was late. It might deviate on non critical feature set but the main course has been always served properly.
And? I suspect customers that asked you to, say, build a new inventory tracking tool that interfaces with their existing enterprise infrastructure (SAP, Salesforce, etc) didn't ask you to do it in 2 weeks. So what was asked was probably -reasonable-. If it wasn't, you probably would have dropped the customer/left the company out of frustration. If it was reasonable, for a sufficiently fully featured solution that you…
Estimates are not wrong. We agree upfront what is guaranteed to be delivered by deadline. The rest is optional. I might do it if I am significantly ahead of schedule or should they decide to continue with my services after initial delivery. Sometimes they order initial product but then prefer to maintain it themselves.
> A reasonable model for the “blowup factor” (actual time divided by estimated time) would be something like a log-normal distribution. Interestingly, we did extensive time tracking on a multi-year in-house software project and collected data comparing the estimated completion time of tickets with their actual time. The software department was under a lot of pressure to improve their forecasting, and were somewhat de…
> ...if you want to make a commitment you can take to a customer, you can just extend the lognormal up to... What you're proposing is effectively a fancy "padding factor", it's like on Star Trek when Scotty says they can only go at Warp-8, but really, Warp-11 is possible. Sometimes stakeholders do behave like toddlers and get red in the face and stomp around when a "promise" is broken because "we aren't there yet." (…
And of course it does depend on the nature of the contractual relationship with your client.
However, even if we charitably assume that the developers are accurately estimating the mean, that means that out of 100 projects, 50 of them will be delivered late. It is likely that you'd want to do better than that, and to do so in a principled manner, you're going to need to adjust the estimates that come out of the estimation process.
In my experience from the past decade, it is often the case that, the difficult thing isn't estimating how much time the proposed project takes to build (this is the difficult part for some devs though), but it's how much other stuff comes up. Stuff includes everything not related to your project. E.g. your last project that is now on prod, where bugs were reported and need to be fixed. Another team needs your expert…
A surprisingly large portion of the 'estimates being wrong' is actually down to the fact that people generally estimate that they're going to be working 100% without interruptions or other tasks. Sure, there are times when tasks are harder than expected, but this is a smaller factor than I had originally anticipated.