I have to admit right from the start: I am not what anyone would call a neutral observer on this topic. After all, I run a company that builds and sells visual analytics software. I’ve done so for over a decade. It’s in my interest that someone – you, perhaps – be interested in buying that software. I come to these biases honestly and I state them upfront.
Like many senior leaders and executives out there, I’m also trying to do more with less. I want to achieve my business goals with only the most calculated investments. I’m trying to deliver value as quickly as possible and make sustainable choices that will serve my company, and my clients, well over the years to come.
At Verdazo Analytics, we have a unique perspective on the question of build vs. buy, not just because we’re a software vendor but because we might actually have the capabilities to build some of the software products we need to run our business or some of the tools we might embed in our software offering.
So, here are six questions I consider before deciding whether to build software or buy it. I hope they’ll be helpful as you consider whether to do the same.
- What is the time to value? This is the number one thing I consider when I’m evaluating my options. If I’m looking at a CRM or a bug tracking tool or a visualization component to embed in our own software, I always first assess how quickly it will start making an impact. The faster I can get it into the hands of people that can do something productive with it, the better. The opportunity cost that is lost between identifying the need for a solution and the first day it is active is going to outweigh a lot of the other costs and benefits.
- Do we have the expertise to build and maintain the software? This is a critical question. Truth be told – sometimes we look at available software, its UI, its functionality and think ‘we can do that’. But it’s going to take resources, time, and effort to actually build it… and we need to understand those costs. And then we need to ask ourselves – what’s the resource and opportunity cost of deploying that same expertise on an ongoing basis to maintain it? Like your company we have limited development resources and always need to be mindful if they’re focused on what will add the most value, and add it most quickly.
- What risks am I assuming? If we’re considering building software, I’ve got a lot of questions to consider. Do we have the skills and domain expertise to build it? Do we have the resources to adequately maintain what we’ve built? Is the software we build going to be adaptable to our changing business needs in the future? And what’s the likelihood of it being successful? We assess these risks for all the software we use to run our business and for tools we embed in our software products. When possible we seek industry specific software or tools. Industry specific software that has been around for many years has the implicit expertise and insights of hundreds of companies embedded in it. It reduces risk because it has overcome many of the complexities and pitfalls that we would like to avoid.
- Can the software scale to be an enterprise solution? Again, this larger question leads to a number of others. Do I know enough about the software I need that I can build the best out there — or am I going to miss some things that eventually I’ll want down the road? Is it a one-off piece of software for a targeted need or is it an enterprise solution that will scale with my needs as I grow? If I’m trying to find something that I need to scale, building it myself might not be the best way to go. But if I’m just working with my controller and we just need a simple tool to track licenses and things like that, we might just do that in Excel. It might be a one off. We always take scale into consideration.
- Will people actually use it? If I’m trying to scale process changes across the enterprise and looking for the best software to enable that, I need to assess the software from a usability perspective. To really capture software’s optimal benefits, I need adoption. Users have to be able to use it easily – and they have to want to use it to begin with. If a highly technical person builds the software in a way that makes it complicated and intimidating, then the end-user won’t be engaged and the software will fail. I have to ask myself – do I have the usability expertise to mitigate this risk?
- Will I need to customize the software or our organizational processes? I see this a lot in our industry. Someone buys a new piece of software to make what they’re currently doing happen faster or better, but then they ‘hack’ it to adapt to their existing process or way of doing things. This undercuts the benefits. They end up spending more time customizing software to fit their process instead of adjusting the process to fully leverage the benefits the software can provide (which was likely created based on the best practices of many other organizations).
For us, as for a lot of companies, it often comes down to a single sentence.
I can build that.
But can you?
This is a common cognitive bias, “overconfidence”, that we all suffer from: the idea that our desired product can be crafted by us, even though we don’t have enough experience to back up our confidence. It’s a particularly easy trap to fall into for any company with smart people. But we make visual analytics software. We don’t make consumer apps. We don’t make accounting software.
We don’t make most things.
There’s a lesson there, perhaps.
If I’m honest with myself, I know that when I need a new car, I don’t, even for a minute, think about building it myself. I go down to the dealership and get one that’s built by experts who have considered every possible question and tried and failed at more things in the process than I ever could. Building cars is just not my area of expertise.
I don’t fight this realization. I embrace it.
That’s an extreme example so let’s consider a simpler one. I am a very skilled carpenter with decades of experience and could build an excellent child’s play structure. Of course, it will take me half the summer and it might not be as good, or fun, as something pre-built from Costco. It will cost me more money to build it myself, my kids won’t have something to play on for most of the summer, and I won’t be spending time with them while I build it. While I wanted to build something and knew I would enjoy the challenge, I considered the same list of questions above. In the end I bought the structure from Costco… and I’m very happy I did.
And so the final question, the one I’ll leave you with, is why don’t we apply the same kind of rationale we reliably use in our personal lives to business decisions?
We might be better off if we did.
To learn more about how this applies to visual analytics software for Oil and Gas, download our article.