Build vs. Buy Decisioning in IT Organizations
Many of our clients are constantly challenged by a growing number of technologies to manage and understand in order to support the growing needs of the business. Our clients have experienced this growth quite a bit recently with the amount of technological advancement in both hardware and software creating even more product options for IT. Coupled with the dynamic and rapidly changing business opportunities available, IT Leaders have a lot of opportunities to manage, which includes placing bets on where to build capability versus buy it as a service. In this case, it could be simply described as “EXaaS” or “Expertise as a Service”.
The breadth of technology needs for SMBs is not that different from the breadth of technology needs for the large enterprises. Many in the IT Organization get caught up in trying to be the one-stop shop for all of their firm’s needs. Often the list of technology skills required to run the organization (not to mention grow) gets longer annually while budgets get tighter and tighter. One of the most common struggles is trying to get the skills required for an ever expanding set of technologies from the current IT staff. Sending engineers away for a week to learn additional skills takes away from the capacity to manage and monitor the technical services required by the business. IT Leaders have to constantly juggle the time to train versus the time to fight. But how much time should they allocate for each? And what fighting methods (software and hardware) are we going to commit to mastering, and what fighting methods are we going to allow others to do for us?
Once an IT Leader sets a training ratio, the organization needs to figure out which technologies it will continue to deliver, and which it will source. There are a number of ways to think about this, but here are two methods for identifying which technologies you need to focus on with internal resources. If you plot the skills (or OEM or topics) against their annual frequency, some surprising insights come about. Firstly, that many technologies come up frequently, and there is a significant drop-off quickly. In Marketing and Statistics, this is called “The Long Tail”. The way it occurs in an IT Organization is needing to send an engineer to training to implement the newest version of a software that is only used by IT. An example might be SDS solutions like DataCore, or a Citrix XenApp Farm migration. The critical assumption on this graph is that the less frequently a technology is used or referenced, the less knowledge an engineer will have about the technology. I spoke Spanish (Catalan, actually) while I lived in Madrid, but within 2 years of arriving back in the US I could barely carry a conversation with the guy working in a Mexican restaurant. We all know that if you don’t use something regularly, you lose the capability rather quickly. And investing the resources for an engineer to learn a technology and then use that skill once for your organization is low cost, but low ROI as well. It’s also higher risk because your organization just became the guinea pig for your engineer to practice; not at all a great scenario all around.
The example I use is car maintenance. The activities you have to do very often and are low skill (change oil, refill windshield wiper fluid, refill brake fluids) you can and should do yourself. The activities that happen very infrequently and you may not have the right tools to do (head gasket replacement, control arm replacement, trans-axle replacement) you should find a car mechanic to take care of. It’s the activities in the middle of those extremes (e.g. spark plug replacement, brake pad replacement) that you will need to decide if you want to develop the talent to deliver those services. One of my close friends has restored Mustangs for years, and has personally done just about everything to service all of his various vehicles for the 20 years I have known him. Yet he will not replace brake pads or touch any part of the braking system himself on any car. He simply doesn’t want the responsibility.
Relating this to your IT Organization, you should determine what is needed to run the organization, and then make a framework for choosing which technologies you will invest the time and resources into mastering versus which technologies you will “rent” the skills. When you build your own graph for the IT Organization, it might looks something like this:
On the far left are the areas you want to have skills in-house. On the far-right are the skills and technologies you will want to rent. With a plotting of the needs of the organization like this you will quickly see the obvious. The trickier part will be choosing where that line should exist. In metaphorical terms, you will have to call everything Black or White. There will be obvious colors that are easy to see, but there will be many shades of Grey that you will have to choose a home for. Don’t worry, it may take 2-3 tires to get this correct, but if you make the effort consistently, your abilities will improve.
And the critical last step is to develop the budget for all of these internally developed skills as well as the costs to source them so the CFO has all the data required to understand the costs of running the business as well as growing.
Karl Burns is the Chief Strategy Officer at ManageOps. He can be reached at firstname.lastname@example.org.