Most IT assessments are sales documents. That is not a cynical reading — it is the structural incentive. The firm performing the assessment usually sells the remediation, so an assessment that concludes “this is fine, spend your money elsewhere” costs that firm the engagement it was hoping to win. The reports come back long, urgent, and pointed at a purchase.
A useful assessment is the one willing to return a verdict nobody is going to buy anything from. Everything else below is downstream of that.
First: this is not due diligence
The two get conflated and they answer different questions for different readers.
Technology due diligence is performed for someone considering a transaction. Its reader is an outsider, its deadline is the deal, and its output is a risk position — what am I taking on, and what should it cost me.
An IT assessment is performed for the organization that owns the systems. Its reader already knows most of the facts, its deadline is a budget cycle, and its output is a sequence — what should we do, in what order, and what happens if we do nothing. A due diligence that ends in “proceed at this price” has done its job. An assessment that ends in a price has usually skipped a step.
The table of contents of a real one
Not the marketing outline — the sections that have to be there for the conclusion to be worth anything.
- What the business is trying to do in the next eighteen months. First section, not an appendix. An assessment written without it grades the technology against nothing, which is how you get a recommendation to modernize something the business is planning to exit.
- Inventory, and its accuracy. Systems, owners, versions, support status. The gap between the recorded inventory and the discovered one is a finding in its own right and usually the first honest number in the document.
- Support and lifecycle dates. Every platform with a published end-of-support date, laid against the calendar. This is the least glamorous section and the one that most often sets the actual order of work, because these deadlines belong to vendors and do not negotiate.
- Identity and access. Who can reach what, how that is granted, and how it is removed. Offboarding is the test case; if nobody can describe it end to end, that is the finding.
- Backup and the last time it was restored. Not whether backups run — whether a restore has been performed and timed. These are different facts and only one of them is a control.
- Key-person concentration. Which processes have exactly one person who can perform them.
- Spend, mapped to what it does. Licenses held versus licenses used, renewal dates, and the subscriptions nobody can name an owner for.
- The sequence. Ordered, with dependencies, with the reason each item sits where it does.
What is deliberately absent from that list: a maturity score. A single number aggregating unrelated things into a grade is satisfying to receive and almost impossible to act on, and it tends to appear where the sequencing work has not been done.
The four verdicts, including the one that is hard to sell
An assessment should be capable of returning any of these. If a firm's assessments only ever return the third, the assessment is a proposal with extra steps.
- Do nothing yet. The estate is boring, the deadlines are distant, and the constraint on the business is somewhere else entirely — hiring, sales, a product decision. This is a real and reasonably common outcome and it is worth paying to hear, because the alternative is spending a budget cycle on work that changes nothing.
- Do one specific thing, then stop. One dated, unavoidable item — a platform going out of support, a single point of failure with no restore path. Close it and reassess in a year. This is the most common honest answer for a healthy mid-market estate.
- Sequence a program. Several interlocking items where the order genuinely matters, usually because identity or data has to move before anything else can. This is the outcome assessments are written to produce, and it is right some of the time.
- Stop and address something structural first. Occasionally the finding is not technical. There is no owner, or ownership is contested between two functions, and no amount of engineering fixes a decision nobody is empowered to make. Naming this is uncomfortable and it is the highest-value thing an outside reader can do.
The question to ask before you commission one: “What would have to be true for you to tell us to do nothing?” A firm that can answer specifically has a real assessment methodology. A firm that cannot is describing a sales process.
What makes an assessment worthless
Three failure modes, and they are recognizable from the outside.
It recommends everything. A list of thirty findings with no order is not an assessment; it is an inventory of imperfection, and every estate has one. The work being purchased is the ranking, and a document that declines to rank has withheld the only part that was hard.
It is shaped like the assessor's catalogue. If the recommendations map cleanly onto the services the firm sells, that correlation deserves a hard look. Sometimes it is legitimate — a firm that does a thing well will notice where that thing is missing. Often it is the tool defining the problem.
It has no dates in it. “Urgent”, “high priority” and “should be addressed” are not deadlines. Vendor end-of-support dates, contract renewal dates and audit dates are, and an assessment that does not anchor its sequence to them has ordered the work by feel.
How to get a good one
Give the assessor the business context first and in writing — the plan for the next eighteen months, the constraints, what is already decided. An assessment written in an information vacuum will fill the vacuum with generic best practice, which is how the same report ends up delivered to companies that have nothing in common.
Then set the deliverable as a sequence rather than a report. The useful artifact is an ordered list where each item names what it unblocks and what happens if it slips. That is harder to write than a hundred pages, which is rather the point.
And ask who reads it after. An assessment that is not revisited when a date moves has a shelf life of one budget cycle, and most of them quietly do.
Where this work sits
An assessment is judgement bought by the engagement. There is nothing to license and nothing to resell — the platforms stay in your name, the recommendations are yours to accept or ignore, and the value is entirely in whether the person writing it is willing to tell you to spend nothing.
That is the same footing as the rest of the fractional CIO work: senior technical judgement, applied to a decision that is expensive to get wrong, without adding a permanent seat to the org chart to get it.
Related reading: Technology due diligence: what actually moves the number — the same estate read by an outsider with a transaction in mind. And legacy modernization without a rewrite, for when the sequence turns out to start with a system nobody wants to touch. And interim CIO or fractional CIO? — who reads the assessment afterwards, and why that choice decides whether anything happens to it.