Getting Beyond the “Buy vs. Build” Cliché
Making a major technology change for your business can be daunting. Invariably, the question of “should we buy or build?” comes up... Then a long, time-consuming and often meandering evaluation process ensues. At long last, choices are made (build, buy, or likely a hybrid), and the work to implement kicks off. This can take several months or even years to complete, and it’s not uncommon for these big initiatives to falter. Reasons include:
- They often take longer than planned.
- The value isn’t made clear to key stakeholders.
- You don’t get what you thought you would.
- Your out-of-the-box software actually needs a LOT of work.
- Your custom-built software turns out to be a lot harder to design and implement than originally estimated.
- You have new insights before the software is even rolled out that you’re not able to incorporate.
There is a lot of guidance out there on how to make these kinds of decisions. We’re not going to cover that ground again here. What we will do is share some common antipatterns from our hands-on experiences that dig deeper into the wrong turns businesses take along their Buy vs. Build journeys. Want to avoid a facepalm moment later on? These are some not-so-obvious mistakes you should look out for.
IT Skips Involving The Business (or Vice-Versa)
In some organizations, software is viewed as the sole responsibility of the IT group; IT builds and buys the software, and the business is forced to use it. In other organizations, executives or individual business units make software decisions without any input from technology experts. Both of these approaches have significant risks which are often the subject of articles, blogs and online discussion. Hopefully, your organization is able to ensure that your business and IT stakeholders are collaborating to define business needs and both have a front row seat throughout. It shouldn’t be a waterfall process of defining comprehensive requirements that are then handed over to IT to build and/or buy. Better decisions are made when business and IT work closely to create a strategy and navigate the options and trade-offs together, throughout the whole process.
You Think "New" Must Mean Getting Rid of the Old
Your systems of record (think ERP system) are often the bedrock of your business. But customer expectations, market trends and competitive forces are driving you to engage with your customers, partners and employees in new ways. Information now needs to be personalized, real-time, mobile and proactive, and this often means that you need to pull, aggregate, visualize and share data.
When modernizing, don’t underestimate the work needed to define and create the connective tissue between the old and the new. On the other hand, don’t jump to the conclusion that a “rip and replace” approach will be faster, easier, or more cost-effective. Consider replacing or modernizing your existing COTS (Commercial Off-The-Shelf), open source, or custom software on a layer-by-layer or component-by-component basis. Sometimes, you may just need to update the presentation/UI layer for usability or to support new devices. Maybe you can accomplish your goals by refactoring the application’s business layer to expose new services or an API. Or you may just need to migrate your data layer off of a technology that is no longer supported or is not sufficiently fault-tolerant. Naturally this “layer by layer” approach is more applicable with custom or open source software, but it’s not always impossible with commercial applications.
You Don’t Look Under the Covers
Businesses—and the software that supports their needs—evolve. They buy other businesses, comply with changing regulations and adapt to meet the needs of their customers and partners. Your software and how you use (or misuse) it has invariably morphed over time to support new concepts and processes. But this isn’t always immediately obvious until you look under the hood.
The uniqueness of your business and the technology that supports it is a key consideration when evaluating COTS software as a supplement or replacement for what you’ve already got. But different isn’t always better. Make sure you look into the vendor’s data model and explore how well it aligns with yours. Map the flow of information through some key processes to highlight gaps. If there is work needed to address gaps, identify whether their data model CAN change and, if not, what it will take for yours to. Don’t assume their way is the right way, but also don’t assume that your way is best just because it's unique. Focus on maintaining the unique value you provide in the market, and attempt to accommodate more standardized ways of doing things in places where your uniqueness isn’t contributing to that value.
You Don’t Consider Usability and User Experience
There are several key areas that you should look at here.
- Consistency: People increasingly expect to be able to do everything everywhere. If a partner can use the web, their watch, their mobile device and their Amazon Echo to interact with you, there should be consistent elements in their experiences. Define what these elements are, and make sure that they are a central consideration in your planning, design and implementation.
- Context and channel: Sometimes new applications are added to provide capabilities like mobile or analytics. Consider what is most needed in different modes, and don’t assume that all capabilities are needed everywhere. For example, when I’m on my phone, I probably won’t be filling out a mortgage application, but I would like to see things like alerts, issues and upcoming events.
- The “swivel chair” effect: If you’re adding another tool to your employees’ toolbelt, you may be requiring them to swivel between applications to assemble a complete view. It may be better to expand the capabilities of existing software or create a new dashboard or front end to several systems that pulls them all together.
You Forget About the 4th Dimension
Time, and not just the time to build or buy, is often a tertiary or neglected consideration. Ignoring what may change about your business, market, customers and staff, 1-3 years in the future, may mean you’re forced to do more frequent, reactive and possibly desperate iterations of the “Build vs. Buy vs. Hybrid” dance in the near future. Maybe that’s OK—you can’t anticipate all these future changes, and maybe you just need something reasonable right now. Maybe that’s not OK—you have very specific or complex needs and can’t afford to invest so much only to wind up throwing it away or dumping more and more investment into a "money pit" system over time.
Sometimes packaged software isn't exactly what you need, but it may do enough to buy you some time. This approach is also useful when the needs you’re addressing are not well-defined. By using a packaged app first, you can get real-world feedback about what’s most important. Can the app really deliver the value you believed it could and engage a broader set of users in the process, or not? Now that you’ve learned more about your requirements and priorities, where is this app missing the mark? Ideally deciding to buy, at first, means buying yourself time, reducing risk, learning as you go, while hopefully not getting locked into a long-term commitment. With custom software solutions, define a Minimal Viable Product (MVP). Try to keep it minimal, but at least identify definite and likely future functional and nonfunctional requirements so you don’t unnecessarily box yourself in with a solution that will cost much more in the long run to refine and support. In any case, evaluate your system needs beyond just the immediate, and if you decide not to solve for future possibilities, costs, and demands, at least do so with open eyes.
You Don't See Things from the Enterprise Perspective
The software in question (regardless of whether you are building or buying it, some combination, or even just integrating it into another solution) almost never exists wholly in a vacuum. Software can end up looking like the organization (or communication) structure of the firm that bought (or especially built) it—see Conway's Law. This can be good or bad, depending in part on how well your organization and communication structures meet the needs and goals of your enterprise. It can be particularly bad when the software aligns with only part of the organization, and other parts are left out completely. If those other parts of the organization are impacted by the software, or could contribute value to it or with it, it’s important that they’re involved.
It’s all too common, especially on smaller software decisions and projects, to not take the time to look at things from the larger enterprise perspective. Dive deeply to identify stakeholders outside of the primary business units / teams and get their input when doing impact analysis, design, and evaluation criteria. Otherwise, you may wind up creating or reinforcing walls and silos.
Considering Building or Modernizing Your Software?
We have 20 years of experience creating technology solutions that give our clients a competitive edge. What are the possibilities for your business?
