Category: Blog

Your blog category

  • The Stack Problem: Why COOs Are Drowning in Project Management Tools

    The Stack Problem: Why COOs Are Drowning in Project Management Tools

    There’s a tool for task management. A different one for roadmaps. Another for resource planning. A fourth for budget tracking. A fifth for OKRs. A sixth for meeting notes. A seventh for real-time communication. And so on.

    Each tool was adopted to solve a real problem. Each solved it — and created a new one. The new problem is integration: how do you run an organisation when the information about that organisation is fragmented across a dozen systems that don’t talk to each other?

    The Accumulation Dynamic

    Tool stacks accumulate because different functions in an organisation have different needs, different preferences, and different budgets. Engineering picks one tool. Finance picks another. HR picks a third. Product picks a fourth. Each choice is locally rational. The aggregate is a coordination nightmare.

    The problem is exacerbated by the pace of tool adoption — new tools get adopted faster than old ones get retired. The “try this new thing” energy is strong; the “let’s actually sunset the old thing” energy is weak. The result is a stack that grows but rarely shrinks.

    The COO’s Specific Problem

    The COO’s role requires synthesis across functions. To understand whether the organisation is on track, the COO needs to integrate data from the project management tool, the financial system, the HR platform, and the strategic planning tool. None of these were designed to be integrated. All of them have slightly different data models, different update cadences, and different definitions.

    The result is that the COO spends enormous energy on data reconciliation — gathering, cleaning, and combining data from multiple systems — rather than on analysis and decision-making. The tools are supposed to free up thinking time. Instead, they consume it.

    The Consolidation Case

    The antidote to tool sprawl is consolidation — not eliminating every specialist tool, but identifying where a single connected platform can replace multiple disconnected ones. The most valuable consolidations are at the points where integration is most painful: specifically, where project management, capacity planning, budget management, and strategic planning overlap.

    A platform that handles all four eliminates the most expensive integration points: the reconciliation between who’s working on what, how much capacity that consumes, what it costs, and whether it’s advancing the strategy. This synthesis — which takes hours every week in a fragmented stack — happens automatically in a connected platform.

    The Switching Cost Question

    Consolidation has a switching cost: migration, training, change management, and the political difficulty of asking teams to give up tools they’re attached to. These costs are real. So is the cost of continuing to operate with a fragmented stack.

    The calculation most organisations need to make honestly is not “does a better platform exist?” (it usually does) but “are we paying enough in operational overhead to justify the switching cost?” The answer is often yes — and usually has been for longer than leadership realises.

    The Right Ambition

    The goal is not zero tools. Complex organisations need specialist tools for specific functions. The goal is a minimal stack with maximum integration — where the tools that manage daily work are connected to the tools that manage strategy and resources, so the COO can see the whole picture without being a data engineer.

    That picture — project delivery, team capacity, budget health, and strategic progress in one view — is not a futuristic aspiration. It’s what modern operations platforms are built to deliver. The question is whether your organisation is ready to make the move to get there.

  • How to Build a High-Performance Project Review Cadence

    How to Build a High-Performance Project Review Cadence

    A structured rhythm of reviews at different frequencies, serving different purposes, with clear inputs and outputs for each.

    The difference between a review and a cadence is that a cadence is a designed system: it determines who needs what information at what frequency, and builds the review structure around that need, rather than holding the same review for every audience at the same frequency.

    The Three-Level Cadence

    Weekly: The Team-Level Signal Review

    Purpose: Surface emerging risks before they become crises. Audience: Project teams and direct managers.

    Format: Fifteen minutes maximum. Three questions: what’s on track, what’s at risk, what do we need to unblock? No status updates on things that are fine — this is an exceptions meeting.

    Output: A simple log of risks and owners. Anything requiring leadership decision escalates immediately, not at the next meeting.

    Monthly: The Operations Review

    Purpose: Assess portfolio health, resource allocation, and budget status. Audience: COO, department heads, project owners.

    Format: Sixty to ninety minutes. Five sections: delivery status by theme, capacity status by team, budget vs actuals, risks and dependencies, upcoming quarter commitments.

    Output: Decisions on priority changes, resource reallocations, and budget adjustments. Every decision has an owner and a date.

    Quarterly: The Strategic Review

    Purpose: Assess strategic progress, validate priorities, and reset the plan for the next quarter. Audience: Full leadership team.

    Format: Half-day. Covers objective progress, strategic assumption validation, and scenario review for the next quarter.

    Output: Updated strategic priorities, approved headcount and budget changes, and the committed delivery plan for the next quarter.

    Why This Works

    The three-level cadence works because each level serves a distinct purpose with a distinct audience. Teams aren’t dragged into strategic conversations they can’t influence. Leaders aren’t buried in operational detail that’s already being managed. Information flows up and down the levels efficiently — risks surfaced at the team level reach leadership quickly; strategic decisions reach teams quickly.

    The discipline required is maintaining each level’s focus. Weekly reviews that drift into monthly review territory, or monthly reviews that become quarterly strategy sessions, lose the precision that makes the cadence valuable.

  • 5 Ways a COO Can Drive Team Accountability Without Micromanaging

    5 Ways a COO Can Drive Team Accountability Without Micromanaging

    The difference matters: accountability creates high performance; micromanagement creates anxiety and attrition.

    Here are five practices that drive team accountability without crossing into micromanagement.

    1. Make Commitments Explicit and Public

    Accountability begins with clarity about what was committed. If teams make implicit commitments in a meeting and there’s no written record, accountability is impossible — because there’s always ambiguity about what was actually agreed.

    Make commitments explicit: document them, assign them to named individuals, and make them visible to the team. The visibility itself drives accountability without requiring the COO to follow up on every item.

    2. Inspect the System, Not the Person

    When a deadline is missed, the accountable question is: what in our process, planning, or structure allowed this to happen? Not: who dropped the ball?

    Process-level inspection — looking at whether commitments were realistic, dependencies were managed, and resources were available — drives systemic improvement. Person-level blame drives defensive behaviour and erodes trust.

    3. Establish Clear Review Cadences

    If teams know they’ll review delivery status every two weeks, they prepare for those reviews. The cadence creates a natural accountability rhythm — without requiring the COO to ask “what’s the status?” ad hoc, which feels like surveillance.

    Reviews work when they’re brief, structured, and focused on exception: what’s on track, what’s not, and what does the team need to get back on track?

    4. Use Metrics That Teams Own

    Accountability is highest when teams measure and report their own performance, rather than having metrics imposed externally. A team that tracks its own delivery predictability rate and reports it at the monthly review is more accountable — and more motivated to improve — than a team whose metrics are calculated by someone else.

    Give teams the tools to measure themselves. The measurement is accountability in action.

    5. Distinguish Accountability from Blame

    The cultural shift required for genuine accountability is the separation of accountability from blame. Accountability means: we agreed to X, X didn’t happen, and now we’re analysing why and what to do differently. Blame means: X didn’t happen, and someone is going to feel bad about it.

    Blame cultures produce defensiveness and under-reporting — teams hide problems rather than surfacing them because surfacing problems leads to punishment. Accountability cultures produce transparency and improvement — teams report problems early because early reporting leads to support, not sanction.

  • The Execution Gap: Why Strategy Doesn’t Always Make It to the Team Level

    The Execution Gap: Why Strategy Doesn’t Always Make It to the Team Level

    The journey from one to the other — from strategic intent to daily action — is where most ambitious plans quietly dissolve.

    The execution gap is not a new problem. But the way it manifests in modern organisations has some distinctive characteristics worth understanding.

    The Cascade Illusion

    Many organisations confuse the communication of strategy with the execution of it. They present the company strategy in an all-hands, cascade the OKRs through the management chain, and assume that the work will follow. Often it doesn’t.

    The cascade illusion is that telling people what the strategy is will change what they work on. It doesn’t — because most people’s daily work is driven by immediate priorities: tickets in the queue, requests from stakeholders, the project that’s already in flight. Strategy is the background; the ticket queue is the foreground.

    Closing the execution gap requires structural intervention, not just communication.

    Why Operational Systems Resist Strategic Intent

    Project management systems are optimised for task tracking, not strategy execution. The Kanban board doesn’t know that this sprint’s bug-fixing tasks are not aligned with the company’s strategic priority of shipping the enterprise tier by Q3. The capacity planning spreadsheet doesn’t flag when 80% of the team’s time is spent on BAU work when the quarter’s strategic commitments require 60% on new capability.

    The systems that manage daily work are strategically blind by default. Making them strategy-aware requires deliberate design — tagging work to strategic themes, tracking portfolio allocation by theme, reviewing strategic alignment in operational meetings.

    The Middle Layer Problem

    Large organisations have a middle management layer that translates between strategy and execution. This layer can be a tremendous asset or a significant bottleneck, depending on whether middle managers understand the strategy well enough to translate it correctly.

    In fast-growing organisations, this middle layer often forms faster than the company can train it. New managers are promoted into translation roles before they’ve had time to deeply understand the strategic context. The result is a game of telephone — by the time the strategy reaches the team level, it’s been subtly distorted at each translation point.

    Closing the Gap

    The most effective interventions are structural, not motivational. Connect work items to strategic themes. Make strategic priority visible at the team level. Review portfolio allocation by theme in every operations meeting. Give teams enough context to make good micro-decisions about priority, not just enough instruction to execute predefined tasks.

    The execution gap is narrowest in organisations where every team member can answer, from memory: what is the company trying to achieve this quarter, and how does my work contribute to that?

  • Why Projects Slip: The Real Reasons Behind Missed Deadlines

    Why Projects Slip: The Real Reasons Behind Missed Deadlines

    Every project takes 20–30% longer than planned. Every quarter has at least two or three initiatives that don’t hit their target dates. It’s the norm.

    The norm is wrong. And the reasons behind it are not what most organisations think.

    It’s Not Laziness or Incompetence

    The most common explanation for missed deadlines is execution failure — the team didn’t work hard enough, manage their time well enough, or communicate well enough. This is almost always wrong.

    Teams that consistently miss deadlines are usually working extremely hard. The problem is structural: they’ve been given more to do than is achievable in the available time, with insufficient resources, against requirements that kept changing.

    Root Cause 1: Overcommitment at the Planning Stage

    Most deadline slippage begins at the planning table, not in execution. Teams accept commitments that are optimistic, agree to scope that’s underspecified, and sign off on timelines that assume everything will go perfectly. None of those assumptions survive first contact with reality.

    The fix is not faster execution. It’s more honest planning — which requires leadership to create the psychological safety for teams to say “this won’t fit” without being seen as resistant or underperforming.

    Root Cause 2: Unplanned Work

    Every team absorbs unplanned work throughout the quarter — production bugs, ad hoc requests, support escalations, unexpected dependencies. If the plan was built assuming 100% of capacity for planned work, unplanned work causes slippage. Always.

    The fix is planning for unplanned work — explicitly holding a buffer (typically 15–25% of capacity) for work that will arrive but can’t be predicted.

    Root Cause 3: Dependencies Without Owners

    Projects slip when they’re waiting on something — a decision, a design asset, a data feed, an external vendor. When the dependency doesn’t have a clear owner and a clear resolution date, it sits blocking indefinitely.

    Dependency management is one of the most underinvested areas in project management. Every dependency should have an owner, a deadline, and an escalation path.

    Root Cause 4: Scope That Moves After Commitment

    Scope changes after a commitment has been made are the silent killer of project timelines. The change seems small — “we just want to add this one feature” — but each small change erodes the buffer that was barely sufficient to begin with.

    Scope changes should be treated as budget amendments: formally evaluated, explicitly approved, and accompanied by a timeline impact assessment.

  • Cross-Functional Reporting: How to Get Teams Aligned on the Same Numbers

    Cross-Functional Reporting: How to Get Teams Aligned on the Same Numbers

    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.

  • How to Run a Board-Ready Operations Review in Under 2 Hours

    How to Run a Board-Ready Operations Review in Under 2 Hours

    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.

  • From Spreadsheets to Systems: The COO’s Journey to Operational Clarity

    From Spreadsheets to Systems: The COO’s Journey to Operational Clarity

    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.

  • 5 Metrics Every COO Should Track Weekly

    5 Metrics Every COO Should Track Weekly

    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.

  • How to Build a Weekly Operations Dashboard Your CEO Actually Uses

    How to Build a Weekly Operations Dashboard Your CEO Actually Uses

    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.