Why Buy When You Can Build? A.K.A. Why Save When You Can Spend?

A while back we were looking for a car. After some research and test drives my wife and I decided to get a Subaru. It was a great great car and when we came home and told me 2 pre-teen kids we had decided on it but it would cost quite a bit and they had to be careful and take care of it; my 10 year old looked deeply in my eyes and asked in the wisest voice he could muster, “But Dad, why don’t we just build it???"

It made complete sense in his head. Around that time, we had been watching some reruns of “Home Improvement” with Tim “The Tool Man” Taylor building his own hot-rod with his kids. So yes, it made sense to him and yes, to answer his question, we could, theoretically, build a car. The bigger question of course was – SHOULD we?

Its one of the most common questions asked in IT departments considering new systems. The dreaded Build or Buy. I'll be the first to admit, having an IT developer background, my base position, my first primal instinct when confronted with a problem that can be solved with software was to immediately build that software solution in house. After all, by building it myself, I thought I would meet my 5 magic objectives:

1. I have complete and utter control over what I am building. Yeah!
2. I can make it completely tailored to my needs – no generic processes, no extra fat.
3. I can do it cheaper than buying something off the shelf and then having to customize it to meet my needs. Saved money = good!
4. I have a great Dev team that has all the technical skills I need, so why not give this to them and get them cracking.
5. And maybe most importantly - I understand me. I am unique and all the business processes I have are very geared to the way I do my business. Also, who understands me better than me and therefore, by logical extension, who can build me a better solution for me than me?

Pretty solid arguments there, don’t you think???

Well yes, those are pretty solid arguments.

 Now if only they were true!!!

And before you get out those pitchforks and force my to…well…maybe quit waxing philosophical, let me explain what I mean. There are ways in which you can leverage commercial software and still maintain control of your implementation. There are ways to benefit from the innovation and R&D that industry-leading tools have today and still customize their workflows to meet your unique needs. There are ways to save money by buying versus building. Yes, what I am saying is that there are ways to eat the cake and have it too!!

So let’s look at each of the 5 magic objectives I outlined earlier in more detail and see if we can make things easier:

1. Control. This is a pretty important point and something that people deeply care about. However, great SaaS tools available today allow you the control you need AND give you innovation for free, based on what they are seeing with other customers. If they are speaking to even a thousand customers, that’s best practices being collected across a thousand customers and being presented to you to use. Add to that the fact that you can change pretty much anything you need to; have sandboxes where you can test and train to your hearts content and have the ability to take your time and select when to turn on new features and manage training and change – well, that pretty much allows you to be the master of your own ship (while the ship keeps getting upgraded based on feedback from your and a thousand other ships)!! Pretty awesome.
2. Completely tailored. Another important consideration. Yes, your processes are unique, but with workflow engines that you can modify to pretty much anything you want – you ARE able to customize these tools to what you want. You also get to see the best practice process flows the tools provide OOB and if that makes sense, you can just use that and save yourself even more time. Sometimes our existing processes are built around limitations we had in the past, getting a new tool is a great time to question if those processes are the most effective they can be and adjust accordingly. I have lost count of customers who when I probe deeply about why a process exists, simply do not know and are doing it just because they have been doing it forever.
3. Cheaper. Maybe yes, when all you think about is the simple upfront project labour cost. Definitely no, when you think of TCO and most importantly ROI. Even if buying something costs twice the amount of building it, but gets you 5 times the return and saves you 3 times on ongoing support and innovation costs, is that worth it? You get to decide, but rarely have I seem home grown enterprise systems give better ROIs (especially when you start scaling and going into multiple business units and using the tools across your company) than the agile cloud based tools available to you today. Run a TCO/ROI model, look at ALL the costs – manpower, infrastructure, loaded costs, time to value and ALL the benefits – doing more of what your business does, doing it faster and doing it smarter and you may be surprised at what you find.
4. I HAVE a great development team. Of course you do. But that’s no reason to start a project in areas outside your core business expertise like ITSM/customer service/HR/Security etc. You are not a development company – and even if you are you likely don’t have domain expertise in areas outside your core competency. Use your team to work on YOUR products and leverage the experts in those other areas, who have put together tools based on best practices learned from hundreds and thousands of customers. You are never going to be able to match the product innovation and learning they bring to the table. Just because you have an army, does not mean you go to the wrong war, use that army for building your own products, in your own domain of expertise and in winning over more customers with your awesomeness there.
5. I understand me. Sure you do! And you should use that understanding to customize the best of breed off the shelf software that you buy to meet your needs. Not to build another tool that people will start growing out of by the time you release it and start the painful cycle all over again. Use implementation partners who have done this a hundred times before and can get industry best practices to you. You also know your own product the best, keep focus on building that and supporting that.

I recognize that there are a lot of nuances that a short post like this cannot cover. I’m not telling you what to do (even though I am :) – BUY, don’t build software outside your core business products) but what I AM saying is look at it from a more TCO/ROI focused mindset rather than a simple project costs approach. You do have the ability to maintain control, tailor stuff to your needs and have a great TCO/ROI. Isn’t that, in the end, what ITs promise to the business is?

PS. Also, needless to say, I bought the car :)

Image courtesy: Home Improvement Wikia