Deciding to build enterprise software for your organization? You may want to rethink that....
Recently, I was talking to another ECM systems integrator and he was lamenting over the customer-who-got away. His sales rep was hovering to close the deal on a custom application of ECM, case management. Then the prospect (who is a CIO) “went dark.” After a few days, he finally got ahold of them and got the bad news. The prospect decided to go ahead and build the desired system himself.
This prospect was faced with the buy versus build dilemma and decided to build. For a CIO (or any leader for that matter) this is a difficult question to answer and it is easy to make the wrong decision. And unlike choosing between avocado toast or an omelet for brunch, this is an expensive choice with potentially years worth of repercussions.
There are many ways to analyze this choice. I think it should be viewed through four different lenses:
What is the problem you are trying to solve? Is the problem directly related to your core function? If not, buying is almost always the best option. Also, don’t go through the trouble of building software that is highly specialized or is undoubtedly complicated. Email is highly complicated and specialized so you wouldn’t waste time building an email client. For that matter, ECM ticks the complicated and specialized boxes also!
How do the costs of buy versus build compare? If the software is enterprise-class and complex it will require a large in-house development team to develop, test, and support it. However, licensing fees can be a black box if you don’t understand how they are calculated. Obviously, when you build, you have no license fees. Nonetheless, you need to pay the developer’s salary, and whatever infrastructure, development tools, and hardware are needed. Sometimes, this IS a simpler solution, but it is truly difficult to estimate accurately when building this type of software isn’t your expertise. Also, factor in the cost of maintaining the software over time (also difficult to estimate.)
What are the risks and outcomes of buy and build? The main risk when it comes to building is whether or not you can deliver usable software. At some point, we’ve all be a part of a failed software project, delivering late－or not at all, while watching large amounts of money circle the drain. Building software when you lack expertise in its primary function can lead to problems. Buying has it’s risks to, but in my opinion, they are much lower. Primarily, if you buy, you don’t fully control the application. So, if there are bugs, you need to hope your partner is responsive about fixes.
And…….implementation? Enterprise-level installs are rarely one-and-done if you build you’ll need to implement the product and integrate it with your other systems in addition to QA, hotfixes, and user and feature management. Yet, if you buy, you’ll need a team member who “owns” the system and acts as a point-of-contact with your reseller. Also, if buying, be mindful of who you pick to work with. Vendor partners can be incompetent or they can be your best source of expertise and support. Be sure you carefully check references.
No matter which you choose (and obviously, I am firmly in the buy camp) in the end, how you implement the software (hopefully with an excellent partner) will decide the success of the project. If you’d like to further debate the buy versus build question please contact me here.
Comments