In my last two posts I talked about the impossibility of creating good (i.e., accurate) estimates for software.
There’s a well-known concept in project management called “The Iron Triangle.” This is the idea that delivering a project is always a tradeoff between schedule, scope, and budget (or resources).
If you take the Iron Triangle to heart – quality, scope, time, choose two – then there’s no way to deliver high-quality software features on any accurate estimated-beforehand timeline.
That’s what the Iron Triangle means.
So something has to slip – either time, or quality, or scope.
What usually happens is that two things slip initially – scope and quality. When the organization realizes that quality is sucking and that scope is not good enough, then time slips.
Unfortunately, because of the previous rush to get something incomplete and not very good out, you’re way behind the 8-ball by this time.
You end up releasing something that’s not very good, doesn’t meet the desired scope, and is late anyway.
The nature of software is that it’s unpredictable. The nature of estimates is that they are always too low. If you combine those two things then there’s no way to get the scope you expect out at the time you predict.
I have heard many people tell me that they could get software products out on time with good quality, but I think those people did something slightly different. There are three possibilities:
The reality is that even though you can’t, by definition, give an accurate estimate for anything interesting, it is possible to finish interesting things, and release them. You can beat the Iron Triangle – kind of.
The main problem is that you can’t really say when they will be finished. And so as a product person, because you are expected to be able to provide a roadmap, you need alternative ways to talk about it versus simply saying “We’re releasing feature A at this time, and feature B at this later time.”
I encourage people who think they can release a software product with a set scope and a set level of quality by a set time to try a) to convince me that they did it, and b) to teach me how to do it, because I’d like to know. I’ve never seen it happen in my experience, either with my own products or with the products of other teams and companies. I’ve only heard about it, from friends of friends. It sounds like an urban legend to me.
Your host and author, Nils Davis, is a long-time product manager, consultant, trainer, and coach. He is the author of The Secret Product Manager Handbook, many blog posts, a series of video trainings on product management, and the occasional grilled pizza.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.