When to hire an IT consultant, and what to make them leave behind
This is a post about my own service, so treat it accordingly. I have tried to write the version I would want to read before spending money, which means it spends more words on when not to bother than on when to.
Deciding when to hire an it consultant is mostly a question about what your actual constraint is. If the constraint is hours, outside help works. If the constraint is that nobody will fund the fix, it produces a document.
When to hire an it consultant, honestly
Three situations where it genuinely pays.
A fixed external deadline you cannot move. A certification date, a customer contractual commitment, a migration weekend. The risk with one person is not competence, it is that a single individual being unwell that week takes the deadline with them. Buying capacity around a fixed date is buying insurance against a concentration you cannot otherwise reduce.
Independence you structurally cannot provide. An internal audit needs somebody who did not build the thing, which is the clause 9.2 problem and has no in-house answer at this size. Same for a genuine review of an architecture you designed: you will find what you were already worried about and miss what you assumed.
Depth you need once every two years. A platform's specific quirks, a migration pattern, a particular compliance regime. Learning it properly costs you a fortnight and you will have forgotten it by the time it recurs.
Notice what those have in common. Each is a case where the constraint is not your ability or even primarily your time, but something about your position.
When it does not help
More situations, and worth being direct about them.
When nobody will fund the outcome. An assessment produces a ranked list of things to fix. If there is no budget or appetite to fix them, you have paid for a document that says what you already suspected, and you now have it in writing, which is occasionally useful politically and rarely worth the fee.
When you want a certificate without operational change. An auditor will establish that faster than any consultant can paper over it, per what Stage 2 actually tests. Consultants who imply otherwise are selling something that does not exist.
When the real problem is headcount. If the honest answer is that the company needs a second IT person, a consultant is a more expensive way to not hire one, and the underlying position is unchanged when they leave.
When you have not defined the question. "Look at our Azure setup and tell us what you think" produces a broad report and a broad invoice. "Our bill went up 40 percent and we do not know why" produces an answer.
For the everyday queue. Handing over the helpdesk removes the signal you use to know what is breaking, and it is the cheapest part of the job in hours.
The handover test
The test I hold myself to, and the one worth applying to anybody you engage: if you cannot maintain it after they leave, it was built wrong.
That has specific consequences, and they are worth writing into the engagement before it starts.
No automation authenticating as a named person. A script running as the consultant's account stops working when their access is removed, which is usually the week after they leave. Service principals or managed identities, handed over with the permission list and the reason for each, per least privilege.
No credential with an expiry nobody knows. If the work created a client secret or certificate, its expiry date goes in your calendar before the engagement closes. Otherwise it fails at 3am on a Saturday about eighteen months later.
Documentation that stops at the interesting part is not documentation. "Run the pipeline" is not a handover. What it does, what it assumes, what breaks it, and how to tell whether it worked.
Read-only where possible. Assessment work should not require write access. Microsoft's built-in roles reference is worth having open during that conversation, because it lets you offer a specific narrow role rather than negotiating in the abstract. If somebody asks for Contributor to tell you what is in your subscriptions, ask why, because the read-only argument applies to consultants more than to anyone.
Everything in your repository, not theirs. Obvious, and it happens anyway.
What to ask before engaging anybody
Five questions that filter well.
What will I have that I do not have now, in artefacts. A report, a script, a configuration, a decision. Vagueness here predicts vagueness later.
What access do you need, and why that level. A good answer is specific and minimal and comes with a reason. A request for broad access "to be safe" is a signal.
What happens when you leave. Whether they have thought about handover at all.
What will you not do. Anybody who claims a broad remit at a small company is either overselling or about to subcontract.
Can I speak to somebody you have handed over to. Not a testimonial about the work, a conversation about the handover, which is the part that determines whether the money was well spent.
The uncomfortable part
The most useful engagement I could sell somebody is frequently the smallest one: a couple of days establishing what is actually there and what the priorities are, after which they do the work themselves. That converts a large project into a small one and it is the correct advice for a company with a competent person already in post.
The reason more consultants do not lead with it is straightforward. It is a much smaller invoice. Which is a reason to be sceptical of a broad proposal arriving before anyone has looked at your estate, including from me.
If it is useful, that is what this is, and a read-only assessment is generally the cheapest way to find out whether there is anything worth doing. If the compliance half is the problem and you would rather keep it in-house, the book is the version where you do it yourself, which for a lot of companies is the better answer.