Strategies for Managing IT for Your Organization
Free webinar: Jan 16th, 2-2:30pm (Eastern). Click here to RSVP
(Content lifted from Bob's upcoming book "A CEO's Survival Guide to Information Technology")
Let’s now talk about how you want your IT to be implemented, monitored, and supported for your organization. Each method has plusses and minuses. Each has costs and benefits and risks. And let’s make this abundantly clear. Each of these strategies can work, and each of them can fail spectacularly. Yeah, I know. Helpful, ain’t I? But you need to decide how IT is going to be supported and enhanced for your organization.
First Strategy: Internal IT Staff
Ah, the old standby. This is where you hire employee(s) who have the skill set and experience necessary to manage your IT resources. When work is needed beyond their capacity or skill set, they arrange for a vendor to come in for the project. Otherwise, the day-to-day operational responsibilities is/was on them.
a> Benefits: The primary benefit is one of control. As their employer, you have full control over these human resources. The second benefit is one of focus and understanding. Employees should have a better understanding of the culture, needs, and focuses of your organization than an outsider, but that has to be encouraged (if not required) by you. I’ve seen many organizations where the internal IT staff has no clue what their own company does “for a living.”
b> Risks: For smaller organizations, this situation stifles growth on the part of both IT and the IT employees. If you’re relying on your IT employees to help the organization grow in terms of using Information Technology, how are your IT people growing themselves? And often internal IT personnel are self-taught. That doesn’t mean they’ve learned best practice methodologies, and documentation is often lacking.
c> Why should you do this?: For organizations with extremely unique IT requirements, it’s important that your IT resources are managed by someone with the focus and priority to support you appropriately. Also organizations that are extremely focused on control of their IT resources and reluctant to share responsibilities and access to third parties. This same mentality will make it very difficult to take advantage of many cloud resources and services.
d> Why shouldn’t you do this?: This strategy is usually more expensive than others presented here. It’s also difficult (for smaller organizations) to have an efficient IT strategy with an IT workforce that has a wide spread of skills necessary (i.e., cloud, virtualization, desktop, mobile, security, database). Only bringing in vendors for specific projects means that it’s a buyer-seller relationship, not a partner relationship, so they’re primarily interested in the project only (or worse, setting you up for the next project).
Second Strategy: MSP (Managed Service Provider)
Ah, the latest standby. The term MSP is getting to be as used (and abused) as “cloud,” “<blank> as a service,” and “e<blank>.” To be clear, my company (Simplex-IT) is a Managed Service Provider. So, yeah … I’m part of the problem<g>.
The core belief behind the MSP model is that there is an agreement between your company and the MSP (let’s say Simplex-IT… I mean, a guy can dream, can’t I?). This agreement defines the level of service provided to the customer not based on hours, but results. This agreement can include all levels of service, including Help Desk, Vendor Management, User Management, Performance Management, Security Management, Patch Management, and monitoring of all the devices, applications, and processes we’ve been discussing. For a fixed monthly fee.
Underneath the MSP model lies an array of tools, services, and best practices that allow the MSP to monitor, manage, maintain, and support organizations with a high degree of automated preventative maintenance, minimizing the need for costly unplanned issues and downtime.
a> Benefits: The first benefit is one of cost. Usually, the cost of an MSP agreement is significantly less than the cost of internal IT, if you’re comparing apples to apples. MSP’s have larger technical staff, so there is a greater pool, variety, and depth of technical skills. You (should) have a much more manageable budget for IT expenses. The MSP should engage you and your staff for creating a path to the future in terms of utilizing IT moving forward and keep you informed of new developments in the industry.
b> Risks: Guess what! Not all MSP’s are created equal. MSP’s have their culture, just like your organization. A cultural mismatch between your organization and an MSP can be very damaging and frustrating. This is especially annoying if the agreement with the MSP is a long, multi-year one. Also, some MSP’s don’t share access to their monitoring tools and documentation. Finally, (and this is a big one), the MSP relationship only works if the MSP understands the fundamental requirements of your organization and takes your high-priority issues just as seriously as you do.
c> Why should you do this?: For organizations with “standard” IT requirements, why spend the time to build an IT support structure within your organization when you can simply take advantage of one that’s already built? A good MSP should already have backup strategies, security strategies, policies and procedures, and mobile device management solutions configured with their best practices. They only need to configure to your specific needs, based on what makes your organization unique. And the cost will be less than implementing or maintaining an internal IT department (unless you implement an internal IT department on the cheap).
d> Why shouldn’t you do this?: For organizations with extremely unique IT requirements, it’s important that your IT resources are managed by someone with the focus and priority to support you appropriately. Also so for organizations that are extremely focused on control of their IT resources and reluctant to share responsibilities and access to third parties. This same mentality will make it very difficult to take advantage of many cloud resources and services.
Third Strategy: CoMITs (Co-Managed IT Services)
Ah, the newest entry. Actually, the CoMITs term is one we invented (the acronym, not the co-managed part). The term is relatively new (I first heard it in 2016), but we here at Simplex-IT have been providing this for about six years. As of writing this book, Simplex-IT is providing CoMITs level service to about 25% of our customers. The bottom line is that CoMITs is a hybrid between Internal IT and an MSP agreement.
The MSP model is dependent on the implementation of monitoring and management tools and services. In the CoMITs model, the internal IT resources are given access to these tools to increase their productivity.
A CoMITs agreement also has a great amount of flexibility. If the internal IT resource is primarily good with desktops, the CoMITs agreement can place the management of the servers and infrastructure devices in the hands of the MSP. If the internal IT can handle most issues, but is lacking with database technology and there’s a critical application relying on SQL server, the MSP can take responsibility for managing the performance of that resource.
The core belief behind the CoMITs model is to take the best of both worlds. This agreement defines the same levels of service provided to the customer as with an MSP agreement, but focused to what is needed to shore up the internal IT staff. For a fixed monthly fee.
a> Benefits: The first benefit is one of coverage. You get the benefit of internal knowledge and resource onsite, with the extended resources of the MSP. You still have a much more manageable budget for IT expenses. The MSP should be available for supporting the internal IT with feedback and suggestions, acting as a sounding board.
b> Risks: Not all MSP’s are embracing this approach. And some internal IT departments will see the MSP as “the enemy,” possibly out to take their jobs. The CoMITs relationship only works if it’s a partner relationship with your internal IT, not a vendor relationship.
c> Why should you do this?: If you have a good internal IT department that’s spending too much time on traditional (i.e., workstation, server support) IT stuff and not enough time specific to your organization (opportunities that generate direct value for your organization). Or you’ve grown past the capacity of your internal IT resources but don’t want to replace them (which could lead to a temporary CoMITs relationship, where the goal of the MSP is to make themselves obsolete over a period of time).
d> Why shouldn’t you do this?: This cannot be an adversarial relationship. It also can’t be a way to hide poor or unmotivated internal IT resources. Your internal IT resources need to be all in and buying into the concept. And your MSP should be set up to do this, not “making a special exception” for you and your organization.
Summary: Each model has strengths and weaknesses. Some work better with companies with specific attributes, such as size, growth potential, complexity, need for improvement, etc. But it's important to decide on the model, and stick with it.