what a systems diagnostic actually is

“Systems diagnostic” sounds like something you’d book for a car. In practice it’s simpler than that: a short, fixed-scope look at how work actually moves through your business, ending in a written plan you can act on. This is what happens in those two to three weeks, and what you’re left with afterwards.

the short version

You tell me what feels wrong. I spend time with the people doing the work. I draw out every spreadsheet, tool and hand-off so the whole picture is visible in one place. Then I write down, in order, what’s worth fixing, what to buy rather than build, and what to leave alone. We go through it together. It’s yours.

The fee is fixed and agreed before we start. Nothing in the plan commits you to any further work with me.

why pay for a plan before a build

Because the expensive mistakes happen before anyone writes code. McKinsey and the University of Oxford looked at more than 5,400 IT projects and found that large ones ran 45% over budget on average and delivered 56% less value than predicted. They also found that each extra year of schedule added another 15% to the overrun. Their sample was big corporate projects, not 50-person field companies, and I wouldn’t lift their percentages onto a small business. The pattern is the useful part: the longer and vaguer the build, the worse it tends to go. A diagnostic’s whole job is to make the first build short and specific, or to show you don’t need one.

Ottawa thought the same way for a while. The Canada Digital Adoption Program, which closed to new applicants in 2024, would cover up to 90% of the cost of a digital adoption plan, to a maximum of $15,000, before a business spent money on technology. It also required that plan to be vendor-neutral. I hold this work to the same standard. The plan is written for you, and it shouldn’t read like a pitch for whatever I’d like to build next.

week one: interviews

The first week is mostly listening. I sit with the people who quote, schedule, invoice, chase and file, as well as the owner or manager. The manager’s description of a process and the real process are rarely the same thing, and the gap between them is usually where the time goes.

I’m looking for a few specific things:

• Numbers that get typed in more than once.
• Documents that exist in more than one “current” version.
• Steps that only one person knows how to do.
• Anything that waits on someone remembering to do it.

In a field business, the people I sit with are usually the dispatcher, whoever builds the schedule, someone who does the invoicing, and at least one crew lead. The crew lead matters most. If the schedule the office sends out gets rewritten on a whiteboard at the yard every morning, they’re the one who knows, and knows why.

None of this needs technical knowledge from your side. If someone can describe their Tuesday, that’s enough.

week two: the system map

By the second week I’ve got enough to draw the map. It’s a single picture of every system, spreadsheet and hand-off in the business, with the retyping and the waiting marked on it. Most owners have never seen their business drawn like this, and it’s usually the most useful artefact of the whole exercise. People point at it and say “oh, that’s why that takes so long”.

The map isn’t a diagram of your software. It’s a diagram of where the hours go.

I share an early version with you partway through, because the map is also where the misunderstandings surface. If I’ve drawn a step that doesn’t exist, or missed one that does, it’s cheap to fix now and expensive to fix later.

week three: the plan

The written plan is short on purpose. It opens with what we found: the handful of things that cost the most time or risk, in plain English, with rough numbers against each. Then comes what’s worth building, ranked, each with a sense of cost, effort and what it would remove. Some of these are software. Many aren’t. The last part is what isn’t worth building: the things you might have expected to see, and why I’d leave them alone or buy something off the shelf instead.

We go through it together on a call, so nothing in it needs decoding. After that it’s a document you can hand to your own team, to another supplier, or back to me.

why it often ends with “don’t build that”

A lot of businesses arrive expecting to be told they need custom software. Sometimes that’s true. More often the first fix is organisational: one shared copy of the workbook instead of five, a clear owner for it, an off-the-shelf tool that already does most of the job. Those are cheaper and faster, and they make any later build much smaller.

I’d rather tell you that than sell you something, because the next conversation goes better when the first one was honest.

what it costs you in time

A few hours from the owner across the fortnight, and an hour or two with each person I interview. Most of it works over video and screen-share. If your crews are in a truck or on site all day, I’ll work around their hours, not the other way round.

If any of this sounds like the position you’re in, the free call is the place to start. Thirty minutes, and I’ll tell you plainly whether a diagnostic would be worth it.

sources

• Delivering large-scale IT projects on time, on budget, and on value, McKinsey
• Question Period Note: Canada Digital Adoption Program, Innovation, Science and Economic Development Canada
• CDAP digital adoption plan requirements, Innovation, Science and Economic Development Canada
• Canada Digital Adoption Program, Wikipedia (closure date)