To Build, or Not to Build…?

“To be, or not to be, that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles And by opposing end them. To die—to sleep, No more; and by a sleep to say we end The heartache and the thousand natural shocks That flesh is heir to: 'tis a consummation Devoutly to be wish'd. To die, to sleep….” ~Hamlet I’m not going to paste the entire Hamlet speech here, but you can see that he was going through a very tough decision-making process about a form of death he wanted to pursue. Technology decisions being made in organizations should also be deemed as do-or-die if you want to continue to exist. I know: very drastic. But let’s face it, competition is fierce, startups are popping up ready to grab your market share and the organizations that survive look at expenditures from a strategic viewpoint. From an application development lens, questions include: Should we build, whether in-house or outsource, or should we buy and integrate? See also: How Insurtech Helps Build Trust   The ugly truth: Developers LOVE to build. The maker inside of us wants to create. Integration projects aren’t deemed as fun. I worked with an organization where the IT department predominantly built software solutions. Need a scheduling tool? “I can build this.” Need a workflow solution? “I got this.” Developers would make any excuse known to mankind to devalue other products in the marketplace. Another ugly truth. Build projects are EXPENSIVE and take forever even if you outsource them. Why would you build a scheduling tool? There are thousands of such tools. The same is true with workflow. You may be thinking: Such problems could never happen! Why would someone sign off on the project if such problems were ahead? If you don’t have the right leadership -- your technology reports to a non-technologist or you don’t have the right project oversight -- your organization might very well make this kind of mistake. Technology dollars are precious, so why spend your time, resources and capital on projects that don’t propel your organization forward. Why spend the money building a scheduling tool or workflow solution? Why not take the opportunity to integrate with someone who has already built the solution? Here is the challenge I would offer you if you sit in project prioritization or new initiatives sessions, regardless of your department and role: Has due diligence occurred to look at software solutions that may solve the need? If the answer is no, figure out a way to start the process, or you will be in the do-or-die situation. If the answer is yes, vet various solutions. This can’t be left to IT only. The vetting must be done by a mixture of IT and the business, with equal decision-making power. Vet the various solution providers and find out how you can integrate while building the other pieces. Ask yourself: As an organization, what is your mission? Are you in the business of developing software or using software to serve the mission? Why would a life insurance company want to develop its own workflow tool, its own policy admin systems or its own claims systems? There are vendors whose sole purpose is to make your organization run better. See also: When It’s Better to Build In-House   Use your brightest IT talent in innovation, not in building solutions that exist in the marketplace. Figure out how to transform your organization using best-in-class technology. Integrate with solution providers and startups. Build what others cannot do, and innovate on solutions to beat the competition. “To be, or not to be, that is the question….”