This week, we launched something designed to fix that.

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 sit at the top, sub-tasks beneath them, and granular actions beneath those. Every engineer’s active work is 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, real-time 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 directly to our OTRS ticket data and our monitoring alert and acknowledgement stream. 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 bottleneck 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?

Managed IT is not a predictable workload. Incidents happen unexpectedly on Mondays. Vendors upgrade their cloud platforms without advance notice. A client’s strategic 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 have enough real-time visibility over their existing commitments to know what can absorb the impact and what cannot.

It is the same principle that underpins how our Trusted Response Centre operates: not just monitoring the infrastructure 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 rather than reactive.

The MVP Discipline: Protecting Delivery from Over-Refinement

Alongside the project view, we have introduced an explicit split between Minimum Viable Product (MVP) and long-term roadmap for our internal tool development work.

The question this framework forces is simple: does this feature need to be completed before we can deliver tangible value to a client, or is it an enhancement that belongs to a later phase?

MVP gets prioritized immediately. Roadmap items wait. This split is not about limiting operational ambition—it is about protecting the engineering team from the natural tendency to keep refining systems past the point where they are already good enough to be useful.

For an MSP that builds its own proprietary tools, this discipline is as important as the tools themselves. It is easy to spend a month improving something that was already functioning well enough. It is harder—and far more valuable—to ship a fully ready tool and move on. The MVP versus roadmap framework makes that operational boundary explicit and keeps it in full view.