Reinforcing in-house IT: complement, not replacement

Reinforcing in-house IT is usually not about adding expertise the team lacks, but about capacity for what gets left behind in day-to-day work. Five of my clients have their own IT department, which I complement, often as a specialist for Microsoft 365 or for migrations. Here I describe how to recognise the need, how I share the work with the internal team and what has to be clear from the start.

How to tell that your in-house IT needs reinforcing

The clearest sign is when in-house IT mostly reacts to problems instead of developing systems further and tackling risks early. Updates get postponed, documentation falls behind, and security measures and larger projects have been on the list for months. In the environments I know, this rarely comes down to the skills of the people involved. There is simply no time left to move anything else forward alongside day-to-day work.

The occasions for reinforcing in-house IT with outside help are similar: a high workload, or a position that is currently vacant. One client, for example, booked me as an interim solution until they had found a new IT employee. That took several months. Even after the position was filled, the client continued to engage me to support their IT.

I often join for a particular topic as well, above all as a specialist for Microsoft 365 or for a migration. Projects like these come up in an IT department only every few years. Someone who has carried them out many times knows where the pitfalls are, for instance when a file server moves to SharePoint or when Macs are taken over into Intune. The internal team then does not have to build up that knowledge on the side.

Who does what? Tickets, projects and advice

Clients with their own IT department mostly do not use me for handling tickets on an ongoing basis. The reason is simple: in the long run, paying for day-to-day work with external hours would be too expensive for them. In-house IT knows the users and their workstations best anyway. My role lies elsewhere:

There are exceptions. At a communications agency, for a while I also handled tickets and onboardings on site on fixed days, so that the internal team had room for its projects: central management for the Mac fleet and moving the mailboxes to the cloud. That worked well there, as the case study on reinforcing an agency’s in-house IT shows. As a long-term arrangement, today I usually recommend the split above, because it is more economical for the company.

Working together: one ticket system, one set of documentation

I work within the structures the internal team already uses: the same ticket system, the same documentation and regular coordination. A second system just for my tasks would mean that part of the work stays invisible to the team. That is exactly what should not happen. If there is no ticket system yet, I introduce one. If no separate system is to be bought for it, one or more Planner boards in Teams are often enough.

Even more important is where the knowledge ends up. When I carry out a project, in-house IT should be able to run it afterwards. Three things make sure of that: I document what I set up and why. I agree intermediate steps with the team instead of presenting it with a done deal. And where necessary I train colleagues before I step back from a topic. The BSI, Germany’s Federal Office for Information Security, also advises companies to keep enough skills of their own so that they do not become dependent on a provider.

What has to be clear beforehand: responsibilities and access rights

Before I start work, responsibilities and access rights have to be properly settled. For me this is also a matter of responsibility: I want to tell my clients about upcoming effort before it arises. I can only do that if it is clear what I carry out in which system and what stays with the internal team. Otherwise two sides work on the same system, and in the end nobody knows exactly who changed which setting.

In practice, a short list that you go through together with me and your in-house IT helps:

• Which systems am I responsible for, and which explicitly not?
• Which permissions do I need for that, and which not?
• Who approves changes, and how does the internal team find out about them?
• Through which channel do requests reach me, and who estimates the effort in advance?

For permissions, the rule is as much as necessary and as little as possible. For administering Microsoft 365, Microsoft recommends giving administrators exactly the role they need for their task and nothing broader. The BSI calls it a serious security risk to hand out administrative permissions to external providers without control, and advises agreeing in advance which areas and services they may access. Drawing these lines has a further advantage for you: when the working relationship ends, it is clear which access you need to remove.

Fixed days on site or as needed?

As needed. Fixed days on site inevitably create hours in which there is little to do there and I could achieve more elsewhere. For my other clients, fixed days also mean that I am harder to reach for them on those days. So I come when a task requires it, and I often combine on-site visits with other appointments. A lot can be done remotely anyway.

Fixed days make sense when there is regular work that can only be done on site, as with the agency and its onboardings. For the typical role as adviser and implementer in projects, working as needed has proven itself.

Frequently asked questions

Do you also handle tickets for our in-house IT?

Rarely, and usually only for a limited period, for example when the team needs room for a large project. In the long run it would be too expensive for you to have day-to-day work handled externally. Instead I provide advice and take on agreed tasks in projects.

How often are you on site?

As needed, not on fixed days. I come when a task requires it and often combine visits with other appointments. A lot I do remotely, in the same ticket system and the same documentation as your team.

Does the knowledge stay with us when the collaboration ends?

Yes, I set up the collaboration with that in mind from the start. I document what I set up, coordinate with your team as I go and train it where necessary. The access I receive is defined in advance and can be removed specifically at the end.

Sources

• Access rights and dependency with external providers: BSI – IT-Grundschutz module OPS.2.3 Use of outsourcing, edition 2023 (German)
• Least privilege in Microsoft 365: Microsoft Learn – Best practices for Microsoft Entra roles