Our team spent some time last week reviewing our marketing and messaging. As it often does, the topic of process, and specifically, scope management came up.
We were outlining a few examples of how our teams work with our clients on scope management and how we explain software development when Kristin jumped in to summarize her perspective. I’m paraphrasing here but she expressed it something like this…
“Ok, I get it. We’re having our basement at home finished right now. Just last week I met with several contractors. One said it could take a couple of months but they couldn’t give me an exact end date or price. Another one gave me a very precise end date and cost. They are a larger company, have more employees and will likely cost us more but…”
At this point I cut her off, politely I think…
The house construction metaphor works in a few isolated cases when describing how to build software and a software-based business. However in most cases it is a terrible metaphor. In Kristin’s example, the gap between her two potential vendors is mostly created because of staffing and timing of resourcing.
While there are a few unknowns in the project, each of these contractors has likely built hundreds of basements just like hers. Sure, the price of 2×4’s could increase by $1 or a wall may need to be moved. Maybe a few ugly messes are uncovered when they start the demolition work but in the end it’s a basement and will likely always be a basement. And this is where the metaphor falls apart.
The challenge when scoping software development is monumentally more complicated than this. Today, you think you’re building a spaceship. You’ve written up your specifications for your spaceship. You’ve built a few parts, tested a few things. You have pretty pictures of what the spaceship will look like and even experimented with what customers are willing to pay for rides on your spaceship.
The problem is that two weeks into building your spaceship, we all figure out you don’t need to build a spaceship. What you actually need is a paddleboat. Oh, and there was a moment there when we thought a skateboard was the answer.
How did we figure out you actually needed a paddleboat? Well, we started building, we talked to customers, we iterated, we learned. We learned that we’re primarily crossing a river not going to space. We also learned your customers wanted a lower cost option, etc.
In the early days of building a new software-enabled business, learning has to be one of the top items on your list of goals. Through early stage learning you discover what you actually need and what your customer actually wants. If what your business requires is really a paddleboat, you CANNOT risk spending unnecessary time building a spaceship. At Band of Coders, our teams are very much a part of that early learning process and are often key players in uncovering what it is you truly need to build.
We could, of course, keep our heads down and build your spaceship, but we never want to be in a position where we feel we need to protect preconceived notions at the cost of building what you actually need. Our teams need to surface those learnings quickly. We want to help you learn, and ultimately build the paddleboat rather than deliver on the incorrect plan to build a spaceship!
Coming to these “paddleboat” conclusions and making the necessary adjustments can be messy and often require tough conversations and sometimes pushback. It’s much easier to keep quiet and build that spaceship. While building the wrong product really well can feel good, as a company we take no pride in that.
Scope, requirements, specifications are all required parts of building software but so is learning! Make sure that learning is part of your process and planning. I recommend you go so far as to build it into your compensation models. Discuss how important learning is with your potential development team. Most importantly, make sure you choose a team who is going to help you learn that you should be building a paddleboat NOT a spaceship! No one can afford to be overly protective of yesterday’s best guesses.
By Brydon Gilliss