Can you estimate without knowing the solution?
Recently, on Twitter, a post came across my feed. I responded to it. Which generated a response. Which I really couldn’t figure out how to respond to in 140 characters or less.
The thread is on the right…
And, below is my (slightly longer than 140 character) response:
First of all, let me be clear that I’m talking about work in the obvious or complicated domains. I’m not talking about something in the chaotic or complex domain. If this doesn’t make sense to you, have a look at this video: https://www.youtube.com/watch?v=N7oz366X0-8
And why is this important? Well, because in the obvious or complicated domains, it’s something we’ve done before. Maybe not you, specifically. But someone has.
Building a 747 is a solved problem. We know how to do it. Well, not me. I don’t have a clue. But there are experts I could go an ask, and since they’ve done it, they can help me. There might be different ways to build it, do things in a different order (again, I have no idea), whatever – not the point. My point is that if someone were to ask me to build a 747, I could provide them with an estimate to do that, without knowing exactly how I was going to do it, by talking to the experts who have done it before, and solved that particular problem.
Let me get out of 747’s, and into a domain where I have a little more experience…
A few years ago, I was asked to provide a quote to a potential customer on the cost to build a web application, with specific functionality and usability requirements. And to be clear, I had never build this specific web application before. But, I had been part of teams that had built other web applications, with similar functionality. So I could apply expert judgement, and validate some of the assumptions I made with others on the team who had also built similar solutions for other clients. And we did. We ended up with an estimate for time and cost, and we wrote the SOW with enough latitude that we could adjust the specifics of the scope along the way. Not for our benefit, although it did work out well for us. But really for the benefit of our potential customer.
You see, we’d built similar applications in the past. We had an idea that what the customer was asking for wouldn’t actually be what they wanted once we got started. And we were right. It was on day three of the project when the customer changed their mind on something, and wanted an additional section to be added. No problem. We weren’t contractually obligated to deliver on any specific item. What we were on the hook for was to deliver a web app to help them solve a business problem.
And when the customer asked for changes, on day three, we were able to have a meaningful conversation of what that might mean to the overall project, and allowed us to look at ways of providing a better solution to solve their problem, and meet their needs. We spent a lot of time over the course of the project, working directly with the customer to build something that would work for them. We re-architected aspects, change the information architecture, created an enhanced UI, and made their initial UX designs far superior & easier to navigate and use. None of this was scoped explicitly at the outset. But we still provided the potential client an estimate.
Our estimate, which fed into the budget and allowed us to earn their business was a key in this process. It provided a budget for the customer to decide if they wanted to start the project at that time, or hold off until a later date. We didn’t need a specific solution. We just needed to be 80% confident that we could deliver something that would solve their problem, in the time they wanted it, for a price they could afford. And yes, we told them that our estimate was likely off a bit, but that we were willing to assume the risk through a fixed price contract. Remember, we’d done very similar work before. We were clearly in the complicated domain for our team.
There was a huge industry convention coming up for them, and they wanted to feature their new web app at that convention, if they could.
So, estimating a solution depends on how you define the word solution. Going back to the initial tweet, that “behind an estimate there is the assumption that any piece of functionality has only one possible implementation”, is flawed if you mean defining how, specifically, we’re going to solve the problem.
Providing an estimate, in this context, as to what problem we’re going to solve, actually frees the team to come up with any solution they can imagine, while providing a constraint that something needs to be done by a certain date. And, that it’s all based in actual historical data, so it’s not just a wild-ass guess. An estimate doesn’t need to be based in a single solution, and thinking it does constrains the learning and ongoing conversations that can and should occur during the development. I’d suggest that if this isn’t the case, you might be doing it wrong.
I’m a huge proponent of #NoEstimates. I believe there are lots of better ways to make decisions, and make shared, informed choices about how we spend our money. I also believe that not everyone is on that same page. And that, in certain contexts – like this one – an estimate can be a good thing. Without that estimate, our potential customer would never have become our actual customer. No one wins in that scenario. By providing a simple estimate in this case, we were able to earn the business, and deliver an exceptional product about 20% under budget and 22% ahead of time. Oh, and as a fixed-price contract, that went directly to our bottom line. Happy customer. Happy business. Happy team.
When we’re in the complex or chaotic domains, I think you’ll have a tough time convincing me of the value of most estimates. But when it’s a solved problem – something we know how to do – an estimate can not only be quite accurate, it can be quite helpful. We need to be aware that sometimes, when we think we’re in the obvious or complicated domains, we’re not actually in the complex or chaotic domains. It’s often tough to tell. And, I’m not content with the status-quo, so I’m always going to be looking for ways to challenge anyone who says “well that’s how we do it here”. In this case, I’m pretty happy with the choices we made, the estimate we provided, and the result we delivered.
We need to be careful with absolutes. There can be a time and place for anything and everything. We should continue to question everything in order to continue our quest to find better ways of working together, making decisions, and solving problems.