"Our Take" - Buy versus Build

(Past Editions by: Date, Title, Topic)

 
About "Our Take" 
"Our Take" is a collection of daily vignettes covering a wide range of CRM topics. It's an attempt to add our own spin to the world of CRM. We will use the column to share our perspectives, opinions, epiphanies, web nuggets, or quite frankly anything that moves us. Get ready to expect the unexpected. And, don't be shy about sharing your thoughts.
 
 
12/8/05 - Buy Versus Build
OK, Gartner believes we will see a rejuvenation of "build your own" CRM applications in 2006. I tend to agree. The response from our readers so far has been evenly split with half of you agreeing and half disagreeing.
 
Actually, I don't know if the readers disagree with the prediction or the strategy. What I can say is that we have a vocal group that believes a "build your own" strategy is full of pitfalls. One reader quoted statistics from the Standish Group that discovered internal projects tend to cost about double initial projects and take more than twice as long as expected to deploy.
 
Many of you wrote to warn about what happens after deployment. Internal developers move on to the next project leaving you orphaned for support and upgrades. I'll share thoughts tomorrow so there is still more time to share your opinions and experiences.
 
Gary Lemke, Publisher
(Share your thoughts)
 
12/13/05 - More on "Buy Versus Build"
As promised, today I will share more on what readers are saying about building versus buying CRM solutions. The feedback has been split almost evenly between proponents of the build strategy and proponents of the buy strategy.
 
There is more information than I have space for in this column, so click here to read more.
 
Of course, please let me know what you think!
 
Gary Lemke, Publisher
(Share your thoughts)
 
1/17/08 - Build versus Buy
It has been a while since we last talked about the build versus buy question as it relates to CRM technology. In fact, it was December 2005 that Gartner said we would see a rejuvenation of "build your own" CRM applications.
 
A new study from CRMIndustry suggests that 53% of respondents currently use an in-house CRM solution. The report goes on to say the top three factors that motivated choosing an in-house solution are cost (48%), flexibility (41%) and speed to implementation (41%).
 
I'm a big believer in build your own for specific situations but not for the reasons reported in the study. I think it is a good choice for those desiring a technology advantage not readily available to competitors, more seamlessly integrated CRM capabilities, and control over the evolution of the technology. Do you agree?
 
Gary Lemke, Publisher
(Share your thoughts)
 
1/31/08 - Buy Versus Build
Earlier this month, I summarized the results of a study on the buy versus build question as it relates to CRM technology. Many of you weighed in with comments and opinions that were quite interesting.
 
Looking back into the CRMAdvocate archives, I found a compilation of reader feedback on this particular question. Although the comments were written more than a year ago, most still apply today.
 
Take a moment and read what your fellow readers have to say on both sides of the "buy versus build" question. How do these strategies apply to your decision making?
 
Gary Lemke, Publisher
(Share your thoughts)
 
2/6/08 - Can You Afford to Buy?
Conventional wisdom suggests buying off the shelf software is more economical than writing your own code. I wholeheartedly agree with the statement under one specific condition - your company needs the majority of the functionality provided by the packaged software. Typically, you pay the same price for a particular software product regardless if you use 10 or 100 of the features. Consider, this reader's thoughts:
 
"We had a 'buy if we can, build if we can't' attitude for several years, until we saw the real total cost of ownership (TCO). You pay for the product, add in a small fortune to install the product, include ever spiraling yearly licensing fees, support that reaches mediocre on it's best days, and forced upgrades with their associated costs, and you start to see the build side become much more attactive. When you build it yourself, you do not have a vendor to call if there is a problem, but you do have the source and people in-house, available now instead of in a few weeks, when the vendor's short support staff finally gets back to you."
 
The level of frustration is obvious. It is difficult to determine the buy versus build decision for this particular situation or any situation. Have you ever thought about determine the percentage of features used versus not used? If you are using less than half the feature set, are you paying more than double?
 
Gary Lemke, Publisher
(Share your thoughts)
 
2/7/08 - Build And Forget?
We continue with the "buy versus build" discussion today by sharing more reader comments. Consider this real life story:
 
"People go down the build it yourself route and find themselves in difficult straights a few years later when the programmers who built it left the company and no one knows how to fix it or maintain it. No matter if the IT department has the source code, the reality is that the people who wrote the applications know what they did in the code and why, and someone coming later may have no real clue. So the users find themselves in a situation with a largely unsupported system, little or no upgrade options, and frustrations that are different but just as real as those who bought off the shelf."
 
Has this happened with your home grown code? Have you found yourself "left out" from a vendor that goes out of business or is acquired? Is the risk the same regardless if you build or buy?
 
Gary Lemke, Publisher
(Share your thoughts)
 
2/8/08 - Build But Don't Forget
Everyone has a story about building CRM solutions. And, everyone has a story about buying a CRM solution. OK, "everyone" is an exaggeration but it appears both building and buying have challenges. Sometimes organizations "grow their own" so they have control of their own destiny. Others like to buy so they can focus on their core competencies. Regardless of the strategy, both have one thing in common - you have to rely on the availability of someone. Consider this story:
 
"We have been known to pay the employee, who resigned, significant dollars to continue to support the application, until we could design, implement, train, and replace an old "home grown" application. Our solution has been to standardize on specific platforms/programs throughout our organization with a mix of vendor and in-house IS support depending upon the application."
 
Many like to have internal support for their in-house solutions. However, what happens when the employee experts no longer show up for work? Has the expertise and support walked out the door leaving you without options? Is that worse than dealing with technical support from the vendor?
 
Gary Lemke, Publisher
(Share your thoughts)
 
2/11/08 - I Wish I Had Bought
Allow me to share one more real life story about the "build versus buy" question. This individual has been on both sides of the argument as both the owner of a software development company and as a company with in-house code. Here's the story:
 
"Right now I am stuck with an in-house custom built contact database that has no means of support, no programmers available, and little opportunity to improve. For the dollars wasted on development on this product a few years ago, I could have purchased a COTS (Consumer Off the Shelf) CRM systems, paid for the complete implementation, and had enough money left over for numerous 3rd-party add ons needed for growth and change."
 
When the decision was made to build in house, the expectation was something different. It was determined that there was more bang for the buck in coding than buying. The point is this - when making such a decision, it is important to make sure the expectations are set closer to worse case than best case. Mr. Murphy would probably agree.
 
Gary Lemke, Publisher
(Share your thoughts)
 
2/12/08 - My Turnover is Bigger than Your Turnover
The build versus buy question is something most organizations that have the luxury of in house expertise will eventually ask. One issue that has surfaced has been employee turnover - when the employee leaves, the expertise leaves. But technical support people leave vendors too. Consider this reader's perspective:
 
"Based on our experience, the vendor's support turnover far exceeds most company's (and consultant's) turnover, so many companies are much better off depending on our own personnel, processes and documentation. From our experience, the vendor's first response is 'its a customization, we don't support that', followed by weeks of poor customer service and little to no response, until you get 'its a known bug that MIGHT be fixed in the next few releases'. That is, if you can understand the person from the company to which your vendor has outsourced their support! If your business already has appropriate standards and processes in place, the loss of people experienced with your system will be unpleasant, but not painful."
 
Consider these questions: How does employee turnover in your company compare with employee turnover at your vendor's company? Do you get better response from your vendor or from in house technical support?
 
Gary Lemke, Publisher
(Share your thoughts)
 
2/13/08 - Is Build an Option?
Not every organization even considers building their CRM solutions. The primary characteristic of this type of company is size. The smaller the organization, the smaller the IT staff. The smaller the staff, the less likely an in-house solution will be considered.
 
So smaller organizations can take a "pass" on the build option? Probably, but not necessarily. While in-house expertise may not exist, companies of any size can always consider using contractors to get the exact solution set they desire. I will be the first to admit, this option is not for most organizations, large or small.
 
But the right functional requirements matched with a third party contractor that brings specific CRM expertise to the table can be a real "build over buy" win. And that goes for double for larger organizations. Do you agree?
 
Gary Lemke, Publisher
(Share your thoughts)
 
2/14/08 - It's All About Support Stupid
As I read through the array of reader responses to the "buy versus build" question, one theme seems to be bubbling to the top more than others. And that issue is technical support. It seems many people are extremely frustrated with the poor technical support they receive from their CRM vendors.
 
Consider this thought: "Based on our experience, the vendor's first response might be 'its a customization, we don't support that', followed by weeks of poor customer service and little to no response, until you get 'its a known bug that MIGHT be fixed in the next few releases'. That is, if you can understand the person from the company to which your vendor has outsourced their support!"
 
I see this as an extremely important issue and an area for differentiate among CRM vendors. Let's face it, the most common and necessary functions of a CRM system are available from just about every vendor. Hey vendors, do you agree?
 
Gary Lemke, Publisher
(Share your thoughts)
 
2/15/08 - Vendors Are Smarter
One well reasoned reader response regarding the "build versus buy" discussion didn't pull any punches. You need to read this one because it will almost certainly spark a reaction. But that reaction could be polar in agreement or disagreement.
 
"It almost never makes economic sense to build your own. The vendor spreads R&D costs over hundreds or even thousands of customers. The vendor has an entire staff to support you. If one person leaves, there are still others there to pass on the institutional knowledge. The vendor is smarter than you in designing the system. The vendor has feedback from hundreds of users over years or decades. As your needs increase (and they will) the off the shelf system probably already has features to support you. Your in-house system will not."
 
It is hard to argue with those points. Taken at face value, why would you ever build? Check back next week and I'll tell.
 
Gary Lemke, Publisher
(Share your thoughts)