Everyone is talking about Managed Services. The number of IT organizations working with MSP’s has been rising steadily – fully half of all IT organizations in a survey conducted by Business Solutions magazine are engaged with an MSP. By all accounts, IT spending is only ever expected to increase, and an increasing portion of those budgets are being spent on, or earmarked for engaging with an MSP to handle ‘the plumbing’ of their IT infrastructure. All that said, there’s no shortage of reasons not to use an MSP – let’s review some of the most common ones.
- “They can’t run our environment as well as we can” i.e. “We’re not a vanilla, best practice shop – our environment is complex. There’s no way a 3rd party could come in here and manage everything.”
- Most of us have paid our dues working as part of a small, irreplaceable team. There’s that core function of the infrastructure that’s a “black box, only so-and-so knows how to maintain it.” The environment grew organically, in fits and starts, as the limited resources allowed. It’s is complex and your team keeps it online with sheer grit and determination.
- “Why would I hire somebody to replace my team (or myself)?!”
- Perhaps the most obvious point of all – you’ve spent years building up your environment from the hodge-podge you inherited when you started. Through careful mentoring and training, you now have a solid, talented, and motivated team. Why risk being replaced by some faceless engineers in a remote call center?
- “It’s not in the budget, I’ll never get approval”
- Maybe you’ve got a small department with a tight budget. Or maybe you just spent your budget on a hardware refresh, or a shiny new VDI environment. Whatever the case, MSP’s are for companies with huge budgets and disposable income. Certainly not for small IT shops.
- “We can/are monitoring things with <free/cheap/homegrown app>”
- You’re ahead of the game. You’ve been burned by some outages in the past, and one of your junior guys has been playing around with Cacti and a few other open source tools, not to mention that slick custom monitoring utility your junior dev is working on. There’s plenty of free stuff out there, why pay for it?
If you can empathize with one or more of those sentiments, allow me to share some thoughts you might find interesting. With 17 years of personal experience in IT, 11 in internal IT, and the past 6 working in the Focus Technology Solutions Managed Services department, I’m uniquely positioned to see things from both perspectives.
I’ve yet to work in an environment that didn’t have at least one critical system setup in a non-standard configuration, no longer under support, or inherited by an IT team that knew next to nothing about how to manage it - and subsequently left unpatched, and untouched for years out of fear of breaking it. Not having at least some complexity or deeply nuanced system to deal with would be the exception, not the rule – and this has never slowed us down. You document what you know, what steps to take when something goes sideways, and you work around it.
Working for internal IT, my objective was to elevate my team from simply good – keeping the servers up – to great. In my mind, a great IT department spends its time working with the department managers, identifying ways to improve the core business through the application of technology. To do that, you have to get out of maintenance mode, fighting fires or troubleshooting backups. That’s where we come in. You’re right - of course we don’t know your business as well as you do – we know IT. That’s our singular focus, and we do it well. The point of having a good MSP is to let us manage your day to day IT – backups, patching - the maintenance stuff. Isn’t it time to work on those “someday-maybe” projects you’ve been talking about for years? We work with the incumbent IT department, greasing the skids so you can focus on taking your IT department from good to great.
How much does an outage cost you? Have you ever done the math? In a former life, we had an outage of one of our core business apps, costing us $30k per hour. This wasn’t a pharma giant or stock trading company. Just a small shop with 300 employees. We were down for a day and a half – due to a hardware failure that could have been prevented, or at the very least managed more effectively during scheduled downtime - if only we’d had reliable monitoring in place. Not that we didn’t have monitoring – yours truly had set up couple free monitoring apps – but between limits of the cheap software, and my inexperience with monitoring tools, we simply didn’t catch this failure. In hindsight, that single event would’ve paid for a Managed Services contract several times over. Besides, aren’t you tired of hearing “is the internet/email/database down” from an angry mob when you walk in the door? Why not trade that experience for an email explaining how we prevented your Information Store from dismounting at 3 AM?
We all know that specialization yields improved efficiency and consistency. MSPs specialize in monitoring and maintaining, day in and day out. Do you know what MIB’s to trap for on a Cisco Nexus 7k? Which of the thousands of events your Exchange server is squawking about matter, and which don’t? Is that latency on your SAN something to worry about now, or can you put off the upgrade, and if so, for how long?
There’s no shortage of monitoring apps out there – but you either have to trade depth of insight (and thus increased risk) for simplicity, or dedicate a member of your team to evaluate the tools available, implement them, and then manage them. But hold on – you already said you don’t trust an MSP to know your business well enough to help manage it. What makes you think you can know ours well enough to roll your own monitoring? I mean no disrespect here – just consider this: I’ve observed an average of 11,000 alerts roll through here for any given customer last year (and that’s above and beyond many of our filters for known issues – knowledge built up by a team of engineers dedicated to monitoring datacenters over the course of a decade). Allowing just 5 minutes to respond to each alert, you’re looking at 23 weeks of work. Just to read the alerts. But hey, that’s none of my business.