Buy Vs. Build

I frequently speak with risk officers from financial institutions across the country about their operational risk management approaches and potential solutions to minimize risk within their organization. In the past, many of these individuals would manage third party due diligence, business continuity planning, alert notifications and incident reporting through a host of spreadsheets and reports via their own custom solution.

Featured Sponsors:

 

 
As the influx of rules and regulations has increased and the fervor at which auditors are scrutinizing potential risk within the institution, the complexity of managing these processes internally has become daunting. This has forced many risk officers to consider weather to buy or to continue to build on their own operational risk solution.

Risk officers need to consider a host of items before making a long-term decision about building or buying. These include: Do you have the resources, technology background, and expertise needed? What is the time to market when you build vs. buy? Have you evaluated the on-going cost to maintain the solution? How will you keep up with industry trends and innovation? Are best practices incorporated into the solution from a diverse group of experts? Is there greater risk if you build it yourself?

Featured Sponsors:

 
These, and a number of additional considerations, should be reviewed before moving forward. In an article entitled “The Buy Vs. Build Decision: Choose Wrong And Put Your Job At Risk,” Dan Simerlink, a Business Value Consultant for Teradata, discusses additional points to consider.

“When evaluating software solutions, businesses need to determine if they should build or customize their own software, or buy from a vendor. Making the correct choice will deliver a strong ROI, enable competitive advantage and earn accolades for the decision maker. However, the wrong selection can be costly for the business—and for the career of the person spearheading the project.

Buy versus build decisions used to be straightforward, partly due to limited options. Organizations would assess their needs and the IT staff’s workload and make a decision based on a total cost of ownership (TCO) analysis. These days businesses need more accurate methods to keep pace with a labyrinth of ever-expanding choices.

Featured Sponsors:

 
Project Risks And Career Perils

When organizations build or customize a solution, they should expect a 10% to 15% error rate, according to an article on ComputerWeekly.com. The article also notes that in the U.S. alone, an estimated $75 billion a year is spent on rework and failed or abandoned systems. For example, poorly tested software caused transaction process problems for millions of online customer accounts and resulted in widespread email phishing attacks that cost one large multinational bank more than £50 million.

On the other hand, purchasing a solution reduces the likelihood of time and cost overruns and the possibility that the project will fail because:

>>Conversations between vendors and their customers identify the pros and cons of the solution

>>Many of the errors and bugs have already been worked out

>>Vendor specialization in deployments eliminates a long learning curve

Although the cost of failure is usually not considered in the buy versus build analysis, thousands of hours can be sacrificed on a project that will never launch. Even if the project does see the light of day, time and cost overruns can impact people’s careers.

In terms of career stability, the riskiest decision is for the company to build its own software. This exposes the decision maker to much more scrutiny than a “buy” scenario. When a company buys software, the vendor shoulders part of the risk and assigns additional resources if the implementation timeline slips (assuming a reputable vendor with a track record of success is chosen).

Narrow the Choices

The abundance of customizable software solutions now available has erased the hard dividing line between buy and build decisions. As technology matures and business models evolve, default modes for a funding model for buy versus build decision making need to be re-evaluated.

Increased competition, shorter time-to-value cycles, and the rapid pace of innovation are forcing organizations to look at the speed and agility of their software deployments. In fact, these factors can be parlayed into a competitive advantage, which means the project must be carefully planned so that advantage is not devoured or sacrificed to failure.

The decision-making process should entail estimating the TCO for the software. A good starting point is to create a list of criteria for each potential option that weighs factors such as time to value, solution functionality, the technical expertise required, and funding. The value proposition for the buy, build or customize options can help narrow the choices.

Considering the time to value, which is erroneously omitted from many financial business cases, helps make a more informed project decision. Including all costs, along with ROI and time-to-value evaluations, enables decision makers to reach the most informed conclusion.

Critical Decisions 

The proliferation of software vendors and solutions has greatly complicated the selection process. To make the best choices, organizations need to quantify options and approaches to determine the total costs and benefits. The right choice will deliver substantial value to the business and could launch a career. At the other end of the spectrum, the wrong choice can cost a lot of time and money—and put your job at risk.”

In a blog published by Rex Chekal of TableXI, he looked at the buy vs. build decision from this perspective. “Our software build vs. buy checklist: When we’re looking to make a buy or build software decision, we don’t rely on a complex matrix or framework. Instead, we ask four straightforward questions:

>>What are the must-have features for this software? Then we determine if an existing product can deliver enough of those features to get the job done. If yes, we move on.

>>What’s the timetable? The feature set will determine what’s going to be faster–off-the-shelf or custom. A super-tight timetable may make the decision for us.

>>What’s the build vs. buy cost analysis? Once we know the features we need and the time we have to build them, we can start scoping out what it will cost to buy vs. build.

>>What’s the ROI potential? This is the biggest question we need to answer: Will this product make enough money to justify its costs? Sometimes this answer will push us toward custom or off-the-shelf. Sometimes it will force us to return to step one and rethink our features until we have something we know will turn a profit.”

As you can see, there are many factors that need to be considered before making the decision to buy vs. build. One thing is clear though: the old way of throwing together a few spreadsheets for due diligence, business continuity planning, alert notifications and incident reporting and thinking it will meet auditors expectations for operational risk management is no longer true. The time to make the right decision about buying vs. building is now, before the auditors come knocking.

About The Author

Marc Riccio
Marc Riccio, President of Specialized Data Systems, Inc., has over thirty years of experience providing software solutions to the financial industry. Marc is known for his forward thinking and vision of introducing new and innovative technologies including “rules-based” Loan Origination software, COLD/Document Image Systems, Internet Security Services on Demand, Cloud Computing and now Operational Risk Management software. Prior to founding Specialized Data Systems in 1989, Marc worked for several technology companies as a Systems Analyst, Account Manager and Sales Manager. Among his significant previous positions, Marc served as Senior Marketing Representative for FiServ-Connecticut and worked in the Retail Banking and Systems group for Bank of America.