The title is vague enough to mean almost anything, which is why so many engagements disappoint. Here is the work, in the order it usually happens.
"Virtual CIO" is one of those terms that survived because it was useful to sell and vague enough to survive contact with any engagement. Ask three providers what it includes and you will get three answers, one of which is a quarterly slide deck.
So rather than define it, here is what the work looks like when it is being done properly, in roughly the order it happens.
The first ninety days are an inventory
Not a technology inventory, though that happens too. An inventory of decisions: who makes them, on what information, and when they were last revisited.
In most businesses of 50 to 300 people the answer is unflattering. The last strategic technology decision was made when something broke or when a contract came up for renewal and somebody noticed the week before. Nobody owns the budget as a whole. There are between four and nine vendors, at least two of which renew automatically. Risk is understood by individuals and written down nowhere.
The deliverable from this phase is not a strategy. It is three things:
- A current-state picture that an intelligent non-technical person can read in fifteen minutes.
- A risk register with owners and dates, not a list of concerns.
- A list of what is about to happen anyway, meaning contracts expiring, hardware ageing out, support ending, compliance deadlines. This list is almost always longer than the client expects and it drives the first year's plan more than any strategic ambition.
Then the quarterly cycle starts, and that is the actual job
Everything after the assessment hangs off a quarterly review. Not because quarters are magic, but because it is long enough for something to have changed and short enough that nothing rots.
A quarterly review that is working has four parts and takes ninety minutes:
- 1.What changed. Incidents, new systems, people in and out, anything the business did that technology now has to carry.
- 2.The register. Each risk: still true, worse, better, closed. Things get closed. If nothing ever closes, it is a worry list and not a register.
- 3.Money. Spend against budget, what is coming, what we decided not to do and whether that still holds.
- 4.Next quarter. Three things, with owners. Not twelve.
The temptation is to make this a reporting meeting where the provider presents dashboards. Resist it. The value is in the decisions made in the room, and dashboards are a way of filling ninety minutes without making any.
Budget season is where the role earns its fee
For most clients the single highest-value thing a vCIO produces is a defensible technology budget, built once a year, with the reasoning attached.
Defensible means every line can be traced to something: a contract, a replacement cycle, a risk the business agreed to reduce, a growth assumption. It means the difference between "IT costs about 180k" and a document that shows what the 180k is, which parts are fixed, which are optional, and what the consequence of cutting each optional one would be.
That document does two jobs. It gets the budget approved, and more importantly it makes next year's conversation a revision rather than a reconstruction.
The questionnaire problem
Increasingly, the trigger for hiring a vCIO is not a strategy ambition at all. It is that a large customer, an insurer or an auditor has sent a long security questionnaire and nobody can answer it.
This is a genuinely good reason, and it is worth being clear about what the work is. Answering the questionnaire once is a week of effort. Being able to answer the next one, and the one after, is a programme: it means the controls described actually exist, somebody owns each of them, and there is evidence. A vCIO who fills in the form for you has solved this quarter's problem. One who uses the form as the forcing function for the control set has solved the category.
What it is not
Two boundary cases worth stating plainly.
A vCIO is not your escalation path. If the mail flow stops, the person to call is whoever runs your service desk. A vCIO who gets pulled into incidents stops doing the planning work you are paying for, and does the incident work worse than the people whose job it is.
A vCIO is not necessarily your implementer. Sometimes the same firm does both, which is efficient and has an obvious conflict in it: the person recommending the project is the person who would be paid to run it. That is manageable if you are awake to it. Ask for the recommendation to include the option of doing it with someone else, and notice whether that option is taken seriously.
How to tell in the first quarter whether it is working
Three signals, none of which require you to understand the technology.
Things close. Items leave the risk register because they were dealt with, and the list is not simply growing.
You are asked to decide things. A good advisor brings you two to four decisions a quarter, framed with a recommendation. If you are never asked to choose anything, you are being reported to, not advised.
Somebody else can answer the questions. By the end of the first year, your operations director should be able to explain the plan, the budget and the top three risks without the vCIO in the room. If all the context still lives with the advisor, you have outsourced the understanding as well as the work, which is the thing you were trying to avoid.
One day a month is enough, if it is the right day
The most common objection is that one to two days a month cannot possibly be enough. It is, for this role, provided the days are spent on the plan rather than absorbed into operations.
That is the single thing to protect in the arrangement. The work is scheduled, it is slow, and it is boring compared with the thing that broke this morning. Which is exactly why it does not happen unless somebody is specifically paid to do it.
