So... my experience with this mindset is that you won't be mad, but you'll just say "that's too long/expensive" and cancel the project entirely. Then the same project will come up again in two months with different wording, again and again, until I give you the estimate you think you can afford. And then the thing will end up taking longer than the original "too expensive" estimate (in part because too many things were rushed in the beginning to try to meet "the date"), but nobody will ever compare the final outcome against the original estimate anyway... because estimates are never meaningful.
The biggest issue I have is developers making business decisions without realizing it or without saying it — saying no to something because it would take too long or be too expensive, without first asking how much time/cost can be consumed
The same occurs with estimating — they’ll give a risky estimate instead of a safe one, because they’ll unilaterally decide the stable one is unacceptable; and not bother mentioning this with their estimate, or knowing what the rest of the timelines look like.
The other half of the problem is that people tend to only want to give one number (and people typically ask for a single number), but what you really want for project planning is the median +- margin of error timelines. The 1x,2x,3x rule is just a hack to work around that unwillingness.
If the date is what's important then start the conversation with "here's the date, can we get this all done by then? If not then what can we get done? If we can't do it all, here's the stuff that I think is important." And make sure to allow some time for people to think about things and give an honest estimate.
If the features are what's important then don't even put a real estimate on it because then that just turns into features + date which never works well. SWAG it by weeks or months and refine as you get further along.
It's basically a law that we always want t do more than we have time for, so it's important for the decision maker to be clear about which parts really matter.
which is good and all, but the reason software projects have such a high failure rate is _because_ these decision makers aren't clear about which part really matter! And not to blame them solely, because it's a hard problem to know.
I like to tell people to give an estimate for when they can provide an estimate.. and estimate for that, if needed :)
Eventually someone knows something
"We can't win with these numbers. Are you trying to lose this business for us?"
"Nope. I'm letting you know what we believe is necessary to finish the work on schedule. We can be more aggressive in some areas and, if so, we'll add items to our risk register."
"You need to hit XYZ target or we're not even going to send a bid."
"Roger."
<Team decides whether it is possible>
The internal cost debate usually ends up with a good budget and the PM/team have an "I told you so" card in their back pocket in case the team can't meet the delegated EBIT. It isn't perfect but this friction (PM sticking up for his team and management pushing for competitive numbers) is better than nothing. I imagine it is similar at most engineering shops.
edit: The fun part is that everybody knows its a game. PM wants as much cushion as possible, management wants great profit at a low price, and the team wants to keep getting work so as to stay employed. Sometimes the costing/pricing stuff goes a little over the top and the infamous "death spiral" gets tossed out by management. Always a hoot.
Let's say the project was first proposed in January 2021. Got estimated as taking a year. Didn't get scheduled, since that was seen as too long, and there was other stuff people wanted done in 2021.
It's pitched again in June 2021. Same story.
Come Feburary 2022, it's pitched again. Now it's estimated as 15 months - there's more to do since more code has been written in the meantime! - and gets started, and ends up taking 19 months (estimates are never perfect!).
You might say "this was stupid, we should've just done it in January 2021" but in the cases I've seen, pushing it off a few times made perfect sense. The payoff wasn't seen as the most valuable thing that could be done, and the effort was high. The effort became higher after it was postponed, but by that point so was the relative value compared to other proposed projects.
On the other hand, if you hadn't come up with that first estimate, maybe the assumption is "ok this will take several months but we'll still be able to do this other stuff in 2021", but instead you work on it throughout 2021 and ship it in March 2022 or so (so ~15 months, still faster than doing it later), but that causes you to not do 80% of those other things you thought you could do.
Postponement or cancellation of a project because it's just too expensive to be worth it right now is a perfectly valid use of an estimate!
Repeat that until the problem gets a singularly misleading wording, or some key person is away, and the project gets a 6 weeks estimation. It will take 19 months anyway, because nothing changed, but for 17 of those you will be late.
(Anyway, I have never seen a problem statement to be well defined enough for this to be the problem.)
At that point we're definitely at a point of "severe company process problems" and the method outlined in the original article probably isn't feasible - I can't really imagine that manager accepting the time required to create a GOOD estimate - but I've definitely seen it work properly at some of my jobs.
As an engineer, it's my job to give an estimate. It's my boss' job to figure out whether that can work within his budget or if the task can be re-scoped. But I have to give him a number he knows is legitimate, and not some half assed BS I pulled out of my ass.
At a recent job, I witnessed an engineering team use some kind of agile "planning poker" game to arrive at estimates. Everyone on the team thought this was a great method. Yet they consistently failed to hit their targets, and it had a very profound impact on the performance of the ENTIRE company, (where various teams had serious backlog-coupling issues).
Because I'm a devops engineer (despite previously having been a development lead at a different company - which was a Fortune 500 by the way) and therefore, not considered a "real programmer" - of course I wasn't taken seriously when I tried to advocate a more data-driven, disciplined approach. But what do I know.
Well, as far as this stuff goes, I kind of have it on easymode because I'm a VP Eng who also does a bunch of product management work. When I'm doing product design, I have the benefit of knowing approximate engineering LoE/order of magnitude, so I can make sure that I design products where the engineering effort fits into the product development cycle.
But it's not unusual for something to be harder than I thought because of some detail that I'm just too far from to realize, and in those cases it's clear to the team that they should be honest with challenges and we'll work around them together, vs. some bullshit because they're afraid I won't like their estimate. The last part is built with trust though and basically never "shooting the messenger" when someone tells me that there's a challenge.
If you have a manager that is unable to deal with this kind of stuff, then your problem is the manager, not the estimates. Estimates are extremely useful, and you’re doing yourself a disfavor if you think that they are never meaningful.
But they don't. Nobody does. They don't just get the timelines wrong, they get the tasks and milestones wrong - which makes sense, because the people asking for the estimates don't actually know what the goals are, usually even after the software is delivered.
The only thing an intelligent software developer can do is play along, learn to read subtle cues as to what they want you to say, say that, and get on with the actually messy business of delivering working software.
And this is the real problem. People who know how to build & design products should be able to explain the goals of what they're asking for. If they don't then either you need to move or you need to get them moved.
One of the first things I tell new engineering managers is that an easy hack to is to always be asking yourself "what am I trying to accomplish?" Whether it's an emotional conversation or writing a document, if you can't answer that question then you probably shouldn't be moving forward with whatever you're about to do. And if you're writing a document, make the very first section "The goal of this document is..." because as you write you can constantly ask yourself "is what I'm writing accomplishing my stated goal?"
Communicating your goal also helps your team - if they know the goal then they don't act as automatons following directions, they can make actual decisions on their own.
If you know the business goal of what you're building then you have a better shot at getting the requirements and tasks correct, which gives you a better shot at giving a good estimate. I've worked with a number of product managers who had no real goal behind what they were asking for. I refuse to have the team start building things until someone can explain why we're doing it and what we're trying to achieve.
I definitely agree that the people asking don't actually know what the goals are. They usually have a very fuzzy picture there.
But I've always found the estimation and planning process to be hugely valuable for revealing the questions that reveal to THEM that they don't know all those requirements yet. And then we have a discussion about them, and we get better specs as a result, and then go on from there... which is way better than when we don't discover those gaps until we are writing the code for it!
It’s probably easier to get a younger dev who’ll go into crunch mode bc they made estimates based on incomplete specs and lack of experience, but who feel the responsibility to deliver. They’re more easily pressured into working more, when the PM should step in and get more resources or do damage control for the mess they created.
