Tag: Operations Visibility

The COO sits at the nexus of functions that have fundamentally different relationships with data: finance thinks in cost centres and P&L lines; engineering thinks in sprint velocity and system reliability; product thinks in features shipped and user metrics; sales thinks in pipeline and conversion rates.

The Definitional Foundation

Cross-functional reporting always breaks down on definitions. “Project cost” means different things to finance (cash out the door) and to operations (including allocated people time). “Delivered” means different things to engineering (feature shipped) and to product (customer-facing impact achieved).

Before designing any cross-functional report, invest time in definitional agreement. Write down what each key metric means, how it’s measured, and who is responsible for it. This glossary is boring to produce and invaluable in practice.

The Cadence Architecture

Different functions need data at different cadences. Engineering needs daily signals on delivery and quality. Finance needs monthly actuals and quarterly forecasts. Leadership needs weekly operational pulse and quarterly strategic reviews.

Design a cadence architecture that provides each function what it needs, at the frequency it needs it, without requiring the entire organisation to synchronise on a single reporting rhythm. The cross-functional synthesis happens at the leadership level, not at every data collection point.

The Shared Dashboard

For cross-functional alignment, a shared dashboard is more powerful than a shared report. A dashboard that all functions can see — showing the same numbers, with the same definitions, updated from the same source systems — creates a common operating picture that a report cannot.

When the operations dashboard shows that Project X is amber on delivery and amber on budget, every function sees the same signal. Debates about whether the numbers are right are minimised because the source is shared. Leadership attention can focus on what to do about the amber rather than which number to trust.

They need to be accurate, concise, strategic, and prepared quickly enough not to consume the entire week preceding the board meeting.

Here is a repeatable process for producing a board-ready operations review in under two hours.

The Template First

The biggest time saving comes from having a fixed template. Every board operations review covers the same five areas in the same order: strategic objective progress, delivery status, capacity and resourcing, financial status, and risks and priorities for the next quarter. Board members understand the template after one or two cycles and can absorb information more efficiently when the structure is consistent.

Build the template once. Reuse it every quarter.

Data Automation Second

The data that feeds the review should be as automated as possible. Delivery status should come from the project management system, not manual survey. Budget vs actuals should come from the finance system. Capacity utilisation should come from the resourcing tool.

If you’re spending thirty minutes per metric gathering data manually, that’s a process design problem, not a reporting problem.

The Two-Hour Process

Hour 1: Pull the automated data for each section of the template. Identify the three to five most significant points in each section — the things that need board awareness, not the full data set. Write one to two sentences per point.

Hour 2: Assemble into the board format. Add context and narrative for the strategic objective section — this is where judgement matters, not just data. Review for consistency — does the capacity status align with the delivery status? Does the risk section connect to the financial section?

Output: a five to eight-page board pack, accurate, concise, and ready for distribution.

What Boards Actually Want

Boards want three things from an operations review: confidence that management has clear visibility of the business, transparency about what’s not working and what’s being done about it, and a clear view of the next quarter’s priorities and risks.

They don’t want every metric. They don’t want detailed project status. They want the story — told with evidence, with honesty, and without spin. The COO’s job is to tell that story with enough data to be credible and enough judgement to be useful.

The problem is that spreadsheets don’t scale. They don’t update in real time. They’re not collaborative in the way modern operations require. They’re fragile — one wrong formula and the whole model breaks. And they require a designated keeper, which means the data is always one person’s departure away from being lost.

The journey from spreadsheets to systems is one of the most important and most difficult transitions a COO makes. Here’s what it looks like.

Stage 1: The Spreadsheet Era

Every operational data point is captured manually. Capacity is tracked in one spreadsheet. Project status in another. Budget in a third. The COO or their team assembles these weekly into a consolidated view, patching together data from multiple sources.

The insight is always one version behind. The process is sustainable until it isn’t.

Stage 2: The Tool Proliferation Era

Frustrated by the manual overhead, teams adopt specialist tools. One for project tracking. Another for financial planning. A third for people data. Each tool solves its narrow problem well. The integration problem — how do these systems talk to each other — remains unsolved.

The COO now has better data per function but worse synthesis across functions. The spreadsheet re-emerges as the integration layer.

Stage 3: The Connected Operations Era

The mature state is a connected operations stack where the key management systems — project management, capacity planning, budget management, strategic planning — share a common data model and surface integrated views.

At this stage, the COO can see project delivery status and team capacity in the same view. Budget and staffing decisions are connected. Strategic theme progress is visible alongside the work delivering it. The synthesis that used to take three hours every Friday happens automatically.

The Journey Is Worth It

The transition from stage 1 to stage 3 takes most organisations two to four years — not because the technology is hard, but because the process design, data governance, and change management are hard. But the operational clarity that emerges from connected systems is genuinely transformative. Decisions are faster, better-informed, and better executed.

The weekly fire-fighting that consumes the COO’s time in stage 1 largely disappears. That’s not a small improvement. It’s a different way of working.

Weekly metrics for a COO need to satisfy two criteria: they need to be available in real or near-real time (not monthly reporting cycles), and they need to be leading indicators — signals that tell you where you’re heading, not just where you’ve been. Here are five that meet both criteria.

1. Delivery Predictability Rate

What percentage of work committed to in the current sprint or planning period is on track to be delivered as planned? Measure it weekly. A rate above 80% indicates a healthy planning and delivery process. A rate consistently below 60% indicates systemic overcommitment or estimation problems.

Track it by team, not just in aggregate — the team-level data tells you where the problem is.

2. Capacity Utilisation by Team

What percentage of each team’s available capacity is currently allocated to planned work? Track it at the team level. The target zone is 70–85%. Below 70% suggests underutilisation — possibly inefficiency, possibly strategic drift. Above 90% consistently suggests overloading — a risk to quality and sustainability.

3. Budget Burn Rate vs Plan

What is the current weekly or monthly spend rate against the plan? Is it tracking above or below the expected trajectory? A burn rate above plan is an early warning of overrun. A burn rate significantly below plan suggests delayed hiring, stalled projects, or scope reduction — each worth investigating.

4. Blocked Issues Count

How many issues, tasks, or projects are currently blocked — waiting on a dependency, a decision, or an external input? Rising blocked issue counts are an early signal of delivery risk. Consistently high blocked counts indicate systemic dependency management problems.

5. Team Health Signal

A simple weekly pulse — teams self-report red/amber/green on a single dimension: “Can your team deliver its commitments this week?” This is deliberately qualitative. It catches what the quantitative metrics miss: interpersonal conflicts, external disruptions, leadership confusion. A simple signal, taken weekly and taken seriously, is far more valuable than a quarterly engagement survey.

The data is there, the charts are accurate, and the CEO opened it twice before returning to asking questions in meetings that the dashboard was designed to answer.

Building a dashboard your CEO actually uses is a design problem as much as a data problem. Here’s how to do it.

Start With the CEO’s Questions, Not Your Data

The first mistake is building a dashboard around the data you have. Start instead with the five to seven questions your CEO asks most frequently in operations reviews. Those are the questions the dashboard should answer.

Common CEO questions in operations contexts:

• Are we on track to hit this quarter’s key commitments?
• Where are we at risk of missing?
• Are we spending within budget?
• Are teams over or under capacity?
• What’s the status of the two or three priority programmes?

If the dashboard doesn’t answer these questions at a glance, it won’t be used.

Ruthlessly Limit the Metrics

A dashboard with thirty metrics gives no signal. Executives can process five to seven numbers in a regular review. Pick those numbers and stick to them.

For an operations dashboard: delivery predictability rate, capacity utilisation by team, budget vs forecast, top three strategic theme progress, and team health indicator. Five numbers. One dashboard. Updated weekly.

Use Red/Amber/Green Consistently

RAG status is simple and powerful when applied consistently. Define what red, amber, and green mean for each metric before you build the dashboard — and apply those definitions mechanically, not judgmentally. A metric where you can manually override the colour to avoid uncomfortable conversations is worse than no metric at all.

Make It Effortless to Access

A dashboard that requires three clicks, a login, and fifteen seconds of loading time will be used occasionally. A dashboard that appears in the CEO’s inbox every Monday morning will be used every week. Friction kills adoption — eliminate as much of it as possible.

Every organisation has multiple systems, multiple data sets, multiple versions of the same number depending on who you ask and when.

COOs have it worse than almost anyone else in the leadership team, because they sit at the intersection of the most systems: project management, finance, HR, capacity planning, strategic planning. Each function has its own data, its own tools, its own definitions. When the COO tries to synthesise across them, the inconsistencies are as numerous as the data points.

Why Single Sources of Truth Are So Hard

The technical problem is real but solvable — data integration is well-understood, even if it’s expensive. The harder problem is definitional. What do we mean by “project cost”? Does it include people time? Contractor fees? Infrastructure? The answer varies by function and by question.

“What’s the capacity of the engineering team?” means something different to the project manager (how many dev-days are available?), the finance team (what’s the fully-loaded cost rate?), and the COO (can we take on this new initiative or not?).

Until the definitions are agreed, no single source of truth can satisfy everyone — because the truth looks different depending on what question you’re asking.

The Practical Approach

The pragmatic answer is not one system to rule them all. It’s a clear hierarchy of systems, with agreed definitions for each context.

For operations decisions, the project management and capacity system is authoritative. For financial decisions, the finance system is authoritative. For people decisions, the HR system is authoritative. The COO’s role is to synthesise across these authoritative sources, not to find one system that replaces them all.

What the COO does need is a dashboard layer that aggregates the key signals from each system — not replacing the underlying systems, but surfacing the operational intelligence that sits across them.