What we built: a real-time project management dashboard for managed IT operations

Inside our operational platform, we have deployed a Project Management Dashboard that maps every active workstream in the business as a tree. Projects at the top. Sub-tasks beneath them. Actions beneath those. Every engineer’s active work, visible in one place, updated in real time.

It sits under a new menu section called Agenda. It is not a ticket queue. It is not a timesheet. It is a structured view of what is actually being worked on across the business — the kind of view that, until now, only existed in the collective memory of the team.

The dashboard connects to our OTRS ticket data and our monitoring alert and acknowledgement stream. The idea is that over time, it gives us a clear signal about where resource attention is concentrated, where capacity is being consumed, and where we may need to redirect effort before a problem becomes visible to a client.

Why operational visibility matters for managed IT capacity planning

People on managed IT teams are genuinely busy. The challenge is that “busy” is not a useful input for capacity planning. Busy doing what? Busy in a way that can flex if something urgent comes in, or busy in a way that cannot? Is the busyness concentrated on a single large project, or spread across fifteen smaller ones that each require context-switching every few hours?

Without a structured view, those questions get answered at weekly meetings, which means the information is a week old by the time it is acted on. With a dashboard that reflects real-time project state, the question can be asked and answered at any point in the week.

That matters more than it might seem. Managed IT is not a predictable workload. Incidents happen on Mondays. Vendors upgrade their platforms without notice. A client’s business decision creates three new projects overnight. The teams that handle this well are not the ones who predicted the unpredictability — they are the ones who had enough visibility over their existing commitments to know what could absorb the impact and what could not.

It is the same principle that underpins how our Trusted Response Centre operates: not just monitoring the environment, but understanding the full context of what the team is carrying at any given moment, so that when something urgent arrives, the response is calibrated — not reactive.

The MVP discipline: protecting delivery from the pull of over-refinement

Alongside the project view, we have also introduced a split between MVP and roadmap for our internal product development work.

The question it forces is simple: does this need to be done before we can deliver value to a client, or is it an enhancement that belongs to a later phase? MVP gets prioritised. Roadmap waits. The split is not about limiting ambition — it is about protecting the team from the natural tendency to keep refining things past the point where they are good enough to be useful.

For an MSP that builds its own tools, this discipline is as important as the tools themselves. It is easy to spend a month improving something that was already working well enough. It is harder to ship something that is genuinely ready and move on. The MVP vs roadmap framework makes that distinction explicit and keeps it in view.

The underlying idea: one operational picture, built to reflect reality

What we are building toward is a single operational picture that connects projects, tickets, and alerts into a coherent view of where the business is focused and where it needs attention. That is not a novel concept in enterprise software. But most MSPs do not build it — they buy whatever project management tool comes bundled with their PSA platform and adapt their operations to fit the tool’s assumptions.

We are doing it the other way around: building the view to fit how we actually work, and connecting it to the data sources that reflect what is actually happening. It is slower to build and harder to explain, but the result is a dashboard that shows the real picture — not the one that looks tidy in a status report.

The difference between an MSP that reacts and one that responds is not speed — it is the depth of operational picture available in the moment something unexpected arrives.

If you want to understand what that kind of operational transparency looks like in a managed service relationship, explore how the Trusted Response Centre works — or speak with our team directly.