Several years ago, I worked in sales management for an Internet service provider. In this position, I was heavily reliant on an unreliable sales force automation system to support my regional teams. A previous ill-conceived project that was meant to improve the system had failed. My sales team suffered the consequences, so senior management tossed the business-side burden of replacing or rebuilding it on my shoulders.
We chose to build rather than buy for the usual reasons—faster delivery time and reduced costs. Rebuilding the system would be quicker and less disruptive because the changes we needed to make were mostly in the area of adaptors and database structure. The changes to the user interface would be minimal, so we could avoid a major retraining program. We could do it quickly and cheaply, and best of all, we could start immediately.
On the flipside, the “buy” option seemed slow and painful. The off-the-shelf alternative was huge and complex, and the in-house implementation team would not be available to address the sales team’s customization requirements for at least four months. The business needed to grow quickly and needed to be flexible, so we were confident in our decision to rebuild the existing system.
Build vs. buy
For more on the build vs. buy debate, read "Consider these points when making the build vs. buy decision."
The quick fix that never ends
Using an outsourced development team, we proceeded with the rebuild, which quickly morphed in to a “quick fix” approach. We built the quick-fix solution, and then another, and then another. We renamed the system and relaunched it. We seemed to be stuck in an endless loop of quick fixes. Of course, the users were still dissatisfied, and the list of problems continued to increase. And each problem we addressed seemed to involve dismantling and rebuilding something from the last release.
Something had to give—and it did. During the third of these quick-fix projects, we hit a budgetary limit and exhausted the board’s patience. The outsourced development team dug in their heels over pricing and intellectual property rights, forcing the lawyers to get involved. Development work screeched to a halt for six months.
Maybe buying wasn’t so bad
It was time for a rethink. In my business analyst and database designer roles, I always seemed to be inventing wheels while suppressing a growing realization that somebody must have been here before me, building these same wheels and doing a much better job than I was doing. I looked again at the market and found that the market leader was offering a package that addressed all the problems we had been wrestling with, as well as a whole bundle of issues that hadn’t even crossed our radar.
Despite our trepidation about asking the board and senior management to sign off on another expensive project, we pitched them the idea. They saw the buy option as a ray of hope and approved it enthusiastically.
Lesson No. 1: Customer need, not developer skill set, should drive the fix
During the course of this project, I learned a few important lessons. Lesson No. 1: People tend to define problems in terms of the solutions they know. When I took over as business driver for the development project, I found myself dealing with a team that had an established skill set. And during the quick-fix cycles, they always seemed to be addressing problems within that skill set. When I put together the business case to buy the package, I took the opposite approach, addressing the problems of the customer—in this case, my sales team.
I learned that before you engage somebody to solve a problem, it pays to know what their tools of trade are and what they’re capable of doing with them. While they’re working, it’s smart to make sure they’re addressing the problems that really matter to the person signing the checks, not just the problems they can easily solve.
Lesson No. 2: People think their problems are unique
Inexperienced people tend to think their problems are unique, and they are usually half right.
Every parent of teenagers knows that teens can give a thousand reasons why the world works in dumb, pointless, and wasteful ways and that all the problems could be solved if only the teens were in charge. And parents—having been around the block a few more times than their kids—know that somebody else already has solved (or tried to solve) most of the problems. A similar logic can be applied to the build vs. buy dilemma.
Now, I’m not saying that off-the-shelf packages are usually better than homegrown solutions, but it is useful to find out how other people have solved problems similar to yours. At worst, looking at an off-the-shelf package gives you one more option, and at best, it might give you a snapshot of industry best practice at the time the package was designed.
If you have a short-term, non-mission-critical project that is well within the skill set of your in-house development team, they have reviewed the market and can demonstrate why their solution is better than everything available, and they really want to do it because they’re interested in the subject and are keen enough to follow through to see it delivered and support it for as long as required, I would happily recommend that you give the job to the in-house team every time.
If you have a large, long-term, mission-critical project that is outside the skill set or capacity of your in-house team, where the market has chosen a clear leader, and that leader seems likely to survive for the long term, I would go with the market leader’s packaged offering every time. That holds true even if the package appears to be expensive. Let the software salesman make the business case, or talk a hard deal and get them to discount their licenses and maintenance. Unless you’re planning to become their major competitor, the market leader’s product will be cheaper in the long run.
Do you agree?
What’s your take on the build vs. buy dilemma? Drop us an e-mail or post a comment below.