Unraveling the 'buy versus build' conundrum

Faced with the choice between buying and building, IT managers must balance a project's uniqueness and its strategic value to the company against the ongoing resources necessary to drive success. For horizontal processes common to most IT operations, it usually makes sense to adopt and adapt software that's already in use elsewhere.


Faced with the choice between buying and building, IT managers must balance a project's uniqueness and its strategic value to the company against the ongoing resources necessary to drive success. For horizontal processes common to most IT operations, it usually makes sense to adopt and adapt software that's already in use elsewhere.

Best Processes
with Greg Lenox

It's a leadership decision

As IT executives, we need to look in the mirror and ask ourselves hard questions, such as: "Is there a clear strategic advantage to building rather than buying? How do I know that what we're building won't be mapping to underlying faulty processes? How long is it really going to take to map and build it? Are we really that unique? And is our need truly unique? What do I give up in speed to market by building versus buying? Are the long-term gains of building going to outweigh the short- and mid-term benefits of buying?"

Honest answers to these questions will lead to the correct course of action. Often, buying the experience of others is a more timely and cost-effective way to hit a high score on a moving target. And, the good news is even if you do wind up building, you will learn a lot by going through the process of doing due diligence on what's out there.

Reinventing wheels is not your business; put strategic imperatives first.

First, rule out the obvious. Building may indeed be the only path, when the problem we are trying to solve is unique and strategic to the business. Take a global overnight package tracking and delivery system, for example. Fred Smith had a unique and outlandish idea about overnight package delivery. However, since this capability didn't exist, he had to invent it. This overnight delivery system would be central to his new company's revenue-producing strategy, value proposition and business model.

What he built became Federal Express.

Great story, but it may not be prudent to invest all your resources and effort into solving every problem in the same way. The question when deciding whether to build or buy should never be clouded by "We have the talented people to build it," or "Because we can."

More bang for your buck

Suppose it costs the same million dollars to build or buy your way to a given level of functionality. If you build, you are also committing to doing your own updates and maintenance. That makes your organization responsible for ongoing creativity and development for the life of the software. The annual resource costs begin to mount for dedicating IT professionals to this task. If you buy, updates, maintenance and (most importantly) the ongoing enhancement (creativity) are included in the price. This frees up your headcount so you can focus them on strategic, revenue-enhancing projects.

Tick, tick, tick…

But the build versus buy conversation isn't just about money. It's also about time. If you can buy and implement an "expert in a box," you may be able to cut your time to deployment by an order of magnitude. With the right systems in place, your company can take advantage of windows of opportunity. Cost savings come faster and lead to a quicker ROI.

Less is more

Finally, building a solution is like trying to hit a moving target from the back of a galloping horse. You'll use up an awful lot of bullets. Why? Because you'll write requirements, go through internal process mapping of the "existing" and negotiations of the "new" processes. When you finally agree, you'll begin to develop a goal of achieving 100% of those requirements. But when you're ready to implement, will 100% still be 100?

It isn't likely.

It is inevitable, however, that some processes will have evolved or changed completely. In my experience, at least 20% of the requirements will change by the time you're ready to implement.

Instead, you may be able to buy and be 80% of the way there in terms of meeting your requirements today. That's why the title of this column is "When 80% is greater than 100%." And I think you'll find that when the dust clears, buying may actually net you more than that.


Greg Lenox, an expert in the processes, methods and practices of IT operations for customer support, help desk, asset management, inventory management, telecommunications management and change management, is president and CEO of Entuition Inc., a maker of operations management solutions in the infrastructure logistics marketplace. At Entuition and in previous positions, he led several major re-engineering projects. His clients included SunTrust Banks, Citibank, Target, GlaxoSmithKline, Baxter Healthcare, Nations Bank, Wachovia Bank, First Union Bank, BB&T, CCNB, CNA Insurance and others.

Dig deeper on Legacy systems migration and integration

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCompliance

SearchHealthIT

SearchCloudComputing

SearchMobileComputing

SearchDataCenter

Close