What a fractional CIO actually does in the first thirty days

Most people who call me have already sat through a technology assessment. They know the shape of it: someone inventories the systems, produces a deck, and leaves. The deck is usually accurate. Nothing changes, because an inventory is a description of where you are, not a decision about what to do next.

The first thirty days runs in four steps, in this order, every time. The order is not a preference. Run them out of sequence and you get a roadmap that optimizes the systems you happen to own instead of the business you are actually running.

Week one: understand the business before touching a system

No system inventory yet. The first week goes to three questions: how the company makes money, where it leaks, and what leadership is trying to do over the next four quarters.

That last question does most of the work. A business planning to double its client count has different problems than one protecting margin on the clients it already has, and the same software stack can be right for one and wrong for the other. The inventory comes second, and it comes out differently once this question is answered.

Week two: map the operating reality

Now the systems, but not as a list. What each process is on paper, what it is in practice, and the distance between them.

The distance is the finding. It never appears in a vendor demo and it rarely appears on an org chart, because it is made of the workarounds people invented to keep their week moving: the spreadsheet that sits between two systems, the report someone rebuilds by hand every Monday, the approval that really happens in a text message. Nobody documents these. They are the most valuable thing in the building to find.

This is also where the last twenty percent shows up. Modern software covers roughly eighty percent of any given process out of the box. The remaining twenty is specific to how your business runs, and it is the part no vendor will build for you. That gap is where the manual work lives.

Week three: sequence by impact, not by ease

By week three there is a list. The list is the easy part.

What matters is the order, with effort and business impact attached to every item, including the things worth deliberately not doing. Deferring something is a decision. Writing down why turns it into one you can revisit on purpose, rather than one that quietly comes back every quarter.

Sequencing by ease is the common failure, and it is an understandable one: the easy items are the ones with a clear owner and a short vendor call. They also tend to be the ones that change the least. Impact first is harder to start, and it is the only version that compounds.

Week four: hand it over rather than hold it

Documentation your team can act on, decisions they understand the reasoning behind, and enough internal capability that the engagement could end. This is the step that gets skipped, and skipping it is how a partner quietly becomes a dependency. A partner you cannot leave is a vendor.

None of that is a technology deliverable, which is the point. The systems question sits downstream of the business question, and answering them in that order is most of what separates a roadmap that gets executed from one that gets filed.