As I have mentioned in previous posts, it’s critical to understand the nature of the work that one is engaged in or significantly dependent on to ensure that everyone (including both C-level executives and developers) have their needs met.
My personal experience with product development is that it is characterized by discovery and learning that occurs throughout the product development cycle. In my experience, and it may be unique to me and the teams I’ve worked with, we knew the least about what needed to be done at the beginning in spite of all the conversations that happened upfront. Enlightenment occurred as the work progressed and then at some point there was that eureka moment where it all came together for a particular item. I’ve even experienced this when working on the second system. This has not been the case, when I’ve been engaged in highly-repetitive work. So if you are domains in which you do highly-repetitive work or you are required to do majority of the learning upfront or where the scope once defined doesn’t change significantly i.e. it is more fixed than not, this post is also probably not for you.
I wondered aloud on Twitter a couple weeks as to why there are so many cost overruns in product development regardless of the sector. I find it hard to believe that all these projects (many which should be executed as products) did not use mature estimation approaches but if I’m wrong, I’d love to be corrected. A thought leader in the software development industry who I respect suggested that “a good/great Agile team can can deploy software at any given time”. The implication being that a good/great Agile team can stop when budget has been met. I totally agree because I have experienced this firsthand, however I also observed that when we stopped, the “finished” product was not exactly what had been conceptualized on paper simply because as we developed, we learned new information and adjusted accordingly. This is not to imply that no features from the original plan were in the finished product but rather that some features were in and others were not but possibly replaced with other features. This isn’t a bad thing.
So for Agile teams (at least), our estimate is not (or is it should not be?) tied to a fixed scope. How could it be except we ignore the nature of our work and insist that we stick to some plan we came up with when we knew the least about what we were doing? In other words, our estimates don’t tell us specifically what we’re going to get with a certain cost. But we know that already, don’t we? Do the people we’re working with understand that? Do they understand the concept of variable scope?
So then, what did the original estimate REALLY tell us? Well it depends on what question we were trying to answer in order to reduce uncertainty. I’m hopeful that no one is contracting work out based solely on cost estimates so let’s assume that we were uncertain as to whether we should proceed and the cost estimate was what we needed to determine if we should proceed or not. The estimate we received made us more certain that we should proceed but now that we have the end result, how valuable was that estimate? I’ll let you the reader decide that. Or maybe we were uncertain as to what the budget should be for an approved initiative and so we needed a cost estimate to determine that. Now that we’ve met budget, how valuable was the estimate? Once again, I’ll let you the reader make that call.
But here’s an idea on budget. What if we have a measures for both ROI and value/gain (and we can know these things going in because we can measure anything, right?) could we not come up with how much we should consider spending i.e. our potential budget? It’s pretty simple algebra (who thought we’d be talking #NoEstimates and high school algebra?) The question now becomes “who should I entrust with my money” because you definitely don’t want to someone to mismanage that.
Just a thought.