This is it. Second to a business’s people, outcomes of the bets companies place on their software strategy have, and will continue to have, the strongest influence on their overall viability and success. Being correct about exactly what that software strategy should be is difficult, even for seasoned leaders. Attitudes that resist change, avoid new expenses, or question new approaches on the basis of previous track records are common barriers. Software strategies must aim to keep the business high-performing and competitive. Often, pursuing the ideal strategy is a strenuous reach even for well-capitalized businesses. Cost and complexity of the strategy must be traded-off against what the business can sustainably support. Leaders should demonstrate humility, and be receptive to expert advice on this topic because history has shown that executives, who put their egos first and place bets on a flawed software strategy, can be responsible for sinking their own ship. You read that correctly — entire companies have flourished or failed after leaders made a bad call selecting Dynamics, Oracle, SAP, or building their own software from scratch.
High Stakes
Software’s presence underlies worker actions, team collaborations, and leadership decisions. Market movements are precipitated by events that first occur computationally. Demand for goods and services manifest as orders transmitted electronically, are fulfilled from inventories whose very existence necessitates representation of its virtual counterpart in computer systems, with delivery occurring on software-dependent logistics networks, and payments being exchanged electronically using virtual cash whose only physical existence is a zero or one on magnetic storage media. Opting for a certain software strategy sets a ceiling on the level of efficiency an organization can achieve, its competitiveness in the marketplace, the amount of friction that is experienced between trading partners, and the level of resources required to sustainably support it. Making the right call is a step towards running a thriving business, get it wrong and your entire company pays the price. Enter the make vs. buy decision. Southwest Airlines, a golden child of B-school curriculums in the late aughts/twenty-teens, posted a net loss of $825 million in the fourth quarter of 2022. Once the airline to beat, demonstrating unmatched efficiency through point-to-point operation of a homogenous 737 fleet, culture exemplified by viral videos featuring freestyling flight attendants, and high levels of customer service, the airline experienced a devastating fall from grace when one part of its software portfolio failed during the 2022 Christmas Holiday travel period. Skysolver, Off the Shelf (OTS) software that positioned flight crews at airports whose departures required them buckled, and eventually broke under the stress of air travel disruptions mostly caused by winter weather. Hundreds of flight cancellations were imposed on frustrated travelers, and burden shifted to other systems to communicate manually scheduled crew assignments and navigate the PR Armageddon event. With a federal investigation forthcoming, I wonder how much overlap there will be in the US DOT’s inquiries and the conversations Southwest had early in its engagement with GE’s Skysolver team—will this software scale as routes are added to new destinations, is it as fit for point-to-point as it is for hub-and-spoke operations, what customizations are required? I was involved in a much smaller make versus buy project almost a decade ago. The project involved a crop receiving station/bulk processing plant in rural North Dakota. These facilities have astounding capabilities when it comes to processing vast quantities of “in dirt” commodities through the early steps in our food supply chain. This particular plant’s geographic location in a densely concentrated growing region caught the interest of a larger competitor, who had recently acquired them. The plant was operated traditionally (a nice way of saying that parts of the business were stuck in the 1990’s, and other parts were stuck in the 1890’s). The acquiring company had strong in-house IT and custom software capabilities, and their Bulk Operations department was keenly interested in modernizing the plant’s operations. I worked with the corporate Operations department, the IT department, and the plant to evaluate various vendors’ solutions to help automate crop receiving operations during the busy harvest season. Ultimately a suitable OTS solution was not found given some of the unique characteristics related to corporate’s existing systems. It was also challenging to find something suitable for the niche commodity the plant dealt with. The team had a narrow window between harvest seasons to deliver a custom soup-to-nuts solution, which they were able to deliver on-time and with great savings compared to the OTS projected costs.
Make versus buy questioning is not cyclical, it is a perpetual & natural state senior decision makers exist in.
Whether a business has made a multi-year commitment to chase ROI for a large investment in commercial software, or decides embark on its own journey to develop something completely custom, make versus buy decisions do not stop getting made. Commodity solutions, like compute, storage and network infrastructure, or implementation of packaged database, middleware, and other supporting technologies will follow. Even the most complex Enterprise Resource Planning systems used by the most unique businesses may be very custom at their core, but it seldom makes sense for the same businesses to craft their own relational database or identity provider solution. Each of these supporting elements has lifecycles of their own and will therefore interact with the others to create impetus for change. An end-of-life operating system, advancement in disaster recovery capabilities of a database, even changes in operation of the business itself can spur the next make versus buy decision. With each make versus buy decision, dependencies need to be evaluated and time is of the essence. Any feelings of being settled are illusional. Like breakthroughs in nuclear fusion, the next make versus buy dilemma is always just over the horizon.
Custom Software Tradeoffs
Consider the list of problems that can be solved by custom software limitless, given the proper application of resources. Alluring. The same cannot be said of closed-source, commercial software that always has feature limitations. Does that mean custom software is always better? Something you’ll always find marketed about packaged commercial software is a list of features. While effective at transferring knowledge of what the product does, and the belief that it can be applied to solve problems, it connotes the veiled implication that anything not on the features list is missing. Limitations are usually unattractive, but many businesses are happy to trade off the possibility of unlimited capabilities for the certainty of predictable costs. This is especially true when a known amount for a perpetual license or subscription can be measured against the cost of not solving a given problem. When the problem and features list have close, unambiguous alignment, decision makers are more confident that project failure is less likely. Custom software is more appropriate when the problem is unique, but marshaling the resources and knowledge to pull off custom software implementation is challenging. The risk of failing to achieve a desired outcome applies to both custom and OTS software implementation projects, but OTS software has the advantage of being able to better-predict the maximum losses suffered from failure. Another consideration for undertaking a custom software project — what technology stack will the team specialize in? This is a crucial decision to make upfront, as it dictates how long the custom software will be supportable (a function of aging technologies that underlie the software), the size and cost of the talent pool that can be tapped to develop and support it, and the degree to which foundational building blocks need to be extended to support the objective the software was built to achieve in the first place. If these all sound like challenging and expensive dilemmas to cope with, trust your instincts. These are problems you want to solve as few times as possible, because monumental changes to something as foundational as a technology stack can be extremely expensive. One final consideration- once custom software has been built and deployed, there is realistically only one team that can readily support everything from ongoing feature requests to recovering from outages. Weigh the importance of keeping key members of the team satisfied and engaged against enforcing the tedium of cross-training and documentation — even if management succeeds in keeping their people happy, people come and go.
OTS software tradeoffs
While not infinitely customizable, OTS software usually offers some customization. The most basic form, configuration, provides technical and non-technical users the ability to make limited changes to the software so that it is a better fit for their business. More powerful customizations might be available, but they will require advanced technical knowledge of the product. In these cases, it is common to engage a specialist (often an expensive third party) for help. Beyond customizing OTS software, some packages offer the ability to integrate with other systems. Technical guidance is usually required to implement integrations, and even then, OTS integration capabilities are not always comprehensive. The best integrations will use standard techniques like API calls. These are familiar to most developers, and if sufficient documentation is provided, API-based integrations can sometimes be implemented without further technical guidance.
Overcoming worse than average biases
We’re going deeper and nontraditional with this part of the analysis. We’re also getting into a subject that’s not usually considered in the context of the make versus buy decision, but it can help us better understand motivations of the audacious few who actually think that “make” is the right decision. Before reaching the point of evaluating make versus buy alternatives, a challenging, unique problem must have presented itself. Some of the forms I’ve seen this take — the possibility for a technology solution where technology was traditionally absent, situations where related but diverse stakeholders demand flexible systems to ensure fitness of the solution for their unique processes, and needing to build a technology bridge between legacy and future systems. Achieving senior management’s buy-in, a mandatory step in order to bring the necessary knowledge and capital to the table, is difficult. Success is common when creative thinkers apply themselves to solve their day-to-day problems with generic OTS software. One department’s sacred spreadsheet has worked fine for years, so why can’t we use the same approach to solve problem X? Success is even relatively common when it comes to making limited configuration changes to OTS software when robust capabilities to do so are included “out of the box”. We only pay vendor Y a few thousand dollars a year, and while their product isn’t perfect, it’s not holding the business back that badly. A predictable, pervasive better than average bias forms around the “buy” approach, because the act of buying something to solve a problem is a common approach. It can be tough to argue against buying something especially if that thing could work, even if it is not the best solution. As an IT leader, the rest of the leadership team is going to look to you to make the call of whether the organization’s needs can be best-met with an OTS or custom solution. If the time, cost, and scope constraints call for a custom solution, because OTS software takes too long to implement, costs too much for a certain use case, or does not fit the unique needs of your organization, then selecting the custom option may be the correct decision. Expect it to be an uphill battle from this point forward.
A worse than average bias emerges because the act of developing and implementing custom software is relatively uncommon.
When an ability is common, people tend to believe they are better than average. Most people who are asked if they are an above average driver will say yes, even though this is mathematically impossible. The opposite version of this bias, where unfounded negativity emerges, applies when abilities are uncommon. Delivering custom software solutions is relatively uncommon, thus many executives will believe their company to be below average when it comes to their ability to succeed at a custom software project, even if making custom software is the most appropriate approach for their situation. If the company has robust in-house development capabilities, then a simple solution could be crafted that takes less time than going through a diligent vendor evaluation and contract negotiation process. The commercial software may be too expensive relative to the problem it is trying to solve. There could also be poor alignment between a software package’s features and the organizations needs. There are many examples of situations when a custom solution is the correct approach, as daunting as the approach may seem to decision makers. Champions of custom software projects face a tough task when it comes to achieving buy-in for their project. Through recognition of this bias, and by shaping the narrative to adequately favor taking a custom software approach, IT leaders can tip the scales in support of taking the full-custom approach in situations when it is warranted.
Finding an expert
Experts from a variety of backgrounds can contribute insights and recommendations to help with the make vs. buy decision. General business strategists can provide models for comparing software strategy alternatives — think management consultants, research groups, and academic types. If you’re considering the “make” approach, you probably also have access to experts with technical backgrounds who can evaluate technical characteristics of both packaged and custom software solutions. Should leaders work with a management consultant or technical expert to make the decision? The answer is yes, talk to both! Perhaps best of all, engage an expert with a background in both business and technical domains. I proudly occupy the consulting niche that represents both the business and IT. If this is a topic you’re interested in discussing further, let’s get in contact and see how R.M can help!
