The situation
A CTO at a technology services firm had the problem every CTO has and few will say out loud: he could not see his own portfolio.
The data existed — in SharePoint lists, in project trackers, in status updates written by team leads in prose. What didn't exist was a single surface where he could answer what is at risk this month without asking eight people and waiting two days. By the time the answer arrived it described a portfolio that had already moved.
The failure mode of most executive dashboards is that they solve this by flattening everything into green, amber and red — which feels like clarity and is actually a loss of information, because the amber is doing an enormous amount of unearned work.
What was built
A dashboard with three views, because a CXO is three different readers depending on the day:
- Card — the glance. What's the shape of things right now.
- Cockpit — the working view. Where attention should go this week.
- Execution — the portfolio. Every project, every deadline, filterable by team.
The Execution view carries KPI tiles across the portfolio's state, a deadline radar colouring overdue and at-risk work, and a clickable team filter so a conversation with one lead doesn't require reading everyone else's projects.
Alongside it: a one-pager, an eight-agent map showing which parts of the CTO's operating rhythm could be automated and in what order, and a test kit so the thing could be handed over rather than demonstrated.
Which statuses are inferred
Where this system can be wrong
The Execution view opens with a status-trust banner. It says, in plain language, that blocked and paused are explicit — someone set them — while at-risk is inferred, derived from the free text in Issues and Risks fields. And it says: confirm with the owning team before you take this into a portfolio review.
This was the most contested design decision in the build, and we'd defend it in any boardroom.
The inference is genuinely useful. Reading a hundred-plus risk narratives and surfacing the ones that read as trouble is exactly what this technology is good at, and no human portfolio manager does it weekly. But an inferred status rendered in the same red as an explicit one is a lie of typography. It tells a CTO that a machine's reading of a paragraph carries the same weight as a team lead's deliberate declaration. The first time that difference surfaces — in front of a board, on a project that was actually fine — the dashboard is finished, and so is trust in everything else on it.
Naming the seam turns the one real weakness of the approach into a visible, honest feature. It is also what lets the inference stay in the product rather than being stripped out after the first false positive.
What happened
The most useful thing about this engagement is a thing we didn't do.
The client took the demo and extended it himself, connecting it to his live SharePoint project list. It went from sample data to a running portfolio of 119 projects. He did that without us in the room.
That is the outcome we'd put ahead of any metric. A dashboard a consultant maintains is a dependency. A dashboard the client can extend is an asset — and the fact that he could extend it says more about how it was built than any adoption statistic.
So the arc reads: demo → client-extended → live portfolio. Three stages, and the middle one is the one that matters.
What came back into the product afterwards: SharePoint moved from a theoretical connector to a proven one, with his implementation as the reference. The portfolio module was formalised with a project schema so a refresh regenerates the Execution view rather than rebuilding it. The status-trust rule was written into the skill documentation so every future build inherits it instead of rediscovering it.
What made it repeatable
The engagement ships as a package, not a session: a portable skill, a data schema, a handoff prompt, a connector-options document marking which integrations are proven versus theoretical, a test kit, and a one-pager.
The distinction between proven and theoretical connectors is small and it's arguably the most honest artefact in the set. A prospect reading it knows exactly which claims have a running system underneath them.
The engagement shape
- A working demo on your shape of data — days, not weeks. Real enough to argue with.
- You extend it. Deliberately. If you can't, it was built wrong — better to find out at demo stage.
- Harden and formalise — schema, refresh path, documented rules.
- Handoff — package, prompt, test kit.
The measure of success is that the fourth step makes us optional.
What's still open
Named, not hidden. A case study that admits open items is worth more than one that doesn't.
- Inferred status is only as good as the prose it reads. Teams that write thorough risk narratives get good inference; teams that write “on track” get nothing. The banner makes this visible rather than solving it — solving it means changing how teams write status, which is a management problem wearing a software costume.
- The eight-agent map is a roadmap, not a delivery. It sets out what could be automated and in what sequence. The dashboard covers part of it; the rest is sequenced work, not shipped work.
- Deadline radar timing is relative to the data's refresh. Overdue and at-risk recompute against live data — correct behaviour, but a stale export shows stale urgency.
Next case study
WatchWise →