Build versus buy. An age old question that, from my point of view, has had varying conclusions over the years. As a young techy right out of college, I wanted to build everything. The reason more often than not was the challenge I wanted to conquer. And while I delivered what was asked often it did not meet the needs of the customer. Throughout the years since and the various roles I’ve played, I now garner a different perspective on that question and how to answer it.
Below I’ve outlined some essential considerations when evaluating a build vs buy decision.
1. What problem are we trying to solve?
Understanding what problem(s) you’re trying to solve is critical to success. It sounds silly, but often times you’ll see whiz-bang solutions that everyone is amazed by, but nobody knows what problem they actually address. To be effective, step back, take a minute and articulate the problems that need to be solved. If you’re the person doing the solution intervention here, grab a whiteboard and bullet list the items that the solution solves.
Remind everyone involved that the list is not etched in stone. It can be edited as you move through the evaluation process. Lists also help bring out a lot of other items that weren’t considered.
2. Get feedback from the people who will actually use the solution.
Ever solve a problem for someone? Maybe without them even being involved? <sarcasm> I’m sure it’s never happened to you.</sarcasm> It has to me – on both sides of that equation.
Get a whiteboard and gather a group of people LIVING the problem. Ask them to articulate what they are doing today and how it works. Then ask them for their IDEAL state. Whatever they say, write it on the whiteboard
Ask a subset of the group to be an ongoing part of the evaluation process to help with prioritization and questions as they come up.
3. Is the solution to this problem CORE to my business value?
This question really aims to cut out the hopes and dreams and drive to the point. You HAVE to ask if you are solving a business problem that your company makes its money on or if you are solving a supporting function.
Most companies buy systems and staff to support them – Email, CRM, HRIS – because while these are core to supporting their business and value, they are not what the company actually derives value from. Nobody buys your company because they have a kick-ass custom built email system. It’s considered a liability. Why wasn’t the effort put into the product? Don’t be that guy.
4. How do we measure the success?
How are you going to measure the success of your decision? Understand the problems you are solving and derive measurements to prove that this decision made a difference, positive or negative.
A process that was manual and took 3 people 15 hours to complete can now be finished by 1 person in 2 hours – well that’s clear value. Whatever you decide to measure make sure the ABILITY to measure is part of the requirements you put in when evaluating the systems.
5. What are the short AND long term costs?
Most people are “kind of” good when determining the total cost to get a system “live.” I say “kind of” because they usually forget key items, expensive items, which are critical to success.
Often forgotten with a system going live is training. Is training provided on your new system and if so, who organizes/writes/performs that training? Is it a single training session, multiple sessions, one large group or many small groups? I think you get it.
Once live, the system needs maintenance, which means added cost. Business changes, groups and needs grow and evolve. What is the support and development cost for updating this system? Who will add features, fix bugs and adapt changes into the system? Will it be a priority?
This one consideration is where most justifications for building something instead of buying something fall apart. Usually the team building the system is not equipped to be responsive to the business that is using the solution, nor support them long term. Everyone on both sides wants to be successful, therefore, it’s best to consider ALL of the costs during the evaluation process.
Of course there are many considerations to think about when determining whether your organization can build a solution top to bottom instead of working with a vendor. These are just a few. I’d love to hear what your top consideration is when addressing the build vs buy question.
