8 months ago
48 ARTICLE AD
Should we buy, or should we build? As the leader of an internal software development team at an academic medical center, this is one of the most common questions that we face. It is also one of the most difficult to answer, because of the long-term implications of our decision.
I’ll talk here a little about how we approach buy vs. build decisions, then discuss some of the key factors for successfully building and supporting internally developed software solutions.
The decision to buy or build
The single biggest factor in this decision is the availability, suitability and cost of commercially offered products. Our decision is the most straightforward when there is a commercially available product that meets our specific needs and is available at a price that we consider reasonable, especially when compared to the full life cycle costs to internally develop an alternative.
It’s even better when the product has been developed by one of our core software partners, for example our existing EHR or ERP vendors. In this situation we benefit from working with a trusted partner, and the solution will likely integrate smoothly into our existing workflows.
But often our decision is not so straightforward. The more unique our needs are, the more likely that a commercial solution will not meet those needs.
For example, for the patient care aspects of our work there tend to be more commercial products available to us compared to the offerings that might serve our school of medicine. For situations where there is no commercially available product, the decision comes down to “build or don’t build,” in which we decide to proceed or not based on assessing the ROI of the effort.
In situations where commercially available products do exist, we will often issue an RFP and assess the vendor products, their features, and their cost as compared to an internally developed option.
Building internally – now what?
We’ve assessed our options and have decided that the best approach is to build and maintain a custom application. Clearly, we have a lot of work to do to develop a custom application, primarily the classic work of requirements, design, build and test. But what is often not appreciated is the amount of nontechnical work needed to build and support a custom application throughout its life cycle.
When you purchase a vendor product, you are purchasing more than just software. Commercial vendors continually update their products, which involves making decisions about which new features to introduce to improve the product. While customers may not agree with those decisions, that is work that does not need to be done internally. When a solution is developed internally, someone needs to perform the product management function of deciding what to build next from what becomes an increasingly lengthy list of “wish list” items from the internal user community.
These are three of the areas that we focus on to ensure success:
Product management partnership between operations and the software development team. When we build a custom application, it is typically because our organization has unique needs that cannot be met by commercial products. So, in order to be successful we need to have an operational or clinical leader who can convey the business needs and set priorities for our work. When we’ve lacked such a partner, our software development efforts have been less successful because it is hard for a software team to understand the nuts and bolts of what it needs operationally. On the development team side, our software product owners can contribute to this process, but there is no substitute for an engaged, creative operational partner.
Having a team in place for the full life cycle of the product. After the initial delivery of a custom-developed solution, we need to commit the technical staff to enhance the product, fix bugs and provide technical support to end users. But just as important is the long-term commitment from our operational partner to continue to steer the product in the right direction. Without that commitment our internal products can flounder and lose uptake, because the product is not evolving to meet the changing needs of users. Our product management team ideally would include participants from our day-to-day users and our analytics and training communities.
Planning for technology refresh. Some of the applications that we build have a short life cycle of several years, to address a short-term need (for example, in response to the COVID-10 pandemic) or to fill a gap until a suitable commercial product becomes available. At the other extreme we’ve developed a number of applications that have been in production for over 20 years. For these long-lived applications we need to set expectations and allocate resources periodically to refactor and modernize our applications, so they will continue to function properly.
When commercial software solutions are unavailable or not a good fit, custom software can help organizations meet their unique needs. Increase your chances of long-term success by putting in place the right team and partnerships from the start.
Glenn Fala is the Associate CIO of Software Development at Penn Medicine.
