Category: Blog

Your blog category

  • Why Budget Overruns Happen

    Why Budget Overruns Happen

    Budget overruns are nearly universal in project-based organisations. Studies consistently show that more than half of significant projects exceed their initial budget — in some industries and project types, the number is closer to 80–90%. And yet budget overruns are often treated as isolated failures rather than systemic symptoms.

    Root Cause 1: Optimistic Estimation

    The most documented cause of budget overruns is optimistic estimation at the project inception stage. Teams consistently underestimate the time, complexity, and cost of novel work. This is not a character flaw — it’s a cognitive bias (the planning fallacy) that affects everyone.

    The fix is reference-class forecasting: rather than estimating from scratch based on the project plan, look at how similar projects have performed historically. If similar projects consistently take 30% longer than estimated, build that into your baseline.

    Root Cause 2: Scope Creep

    Projects rarely fail because the original scope was mismanaged. They fail because scope expands — often legitimately — during execution. New requirements emerge. Customer feedback changes the product direction. Technical constraints force different solutions.

    Scope changes without budget changes are silent overruns. Every approved scope change should come with an updated budget impact assessment. If the scope change can’t be funded within the existing budget, the question of what gets cut needs to be answered explicitly.

    Root Cause 3: Late Visibility

    By the time a budget overrun is visible in the financial reporting, it’s usually too late to prevent it. The decision that caused the overrun was made weeks or months ago. Late visibility is a measurement design problem — the reporting cadence and metric selection didn’t give leaders enough time to act.

    The fix is earlier indicators: burn rate against plan (not just actuals against budget), commitment tracking, and weekly or biweekly budget signals rather than monthly reporting.

    Root Cause 4: Diffuse Accountability

    When nobody feels personally accountable for a budget, everyone makes spending decisions that seem individually reasonable and collectively catastrophic. “We only went 5% over on contractor spend” sounds fine — until five teams each go 5% over and the project is 25% over budget.

    Clear ownership — a single named person who is accountable for the project budget and whose performance is partly evaluated on budget management — is the single most effective structural change you can make.

  • The COO’s Guide to Project Budget Management

    The COO’s Guide to Project Budget Management

    Here is a practical framework for managing project budgets in a way that gives you early warning on overruns, clear accountability for spend, and reliable data for financial reporting.

    Step 1: Set Budgets at the Right Level of Granularity

    Project-level budgets are necessary but not sufficient. A $500K project budget doesn’t tell you whether the engineering work is on track — it just tells you the total envelope. You need budgets broken down by cost category (people, software, external services, infrastructure) and ideally by team or workstream.

    The right level of granularity is the level at which you can take action. If you can’t do anything with a budget number, it’s too aggregated.

    Step 2: Track Commitments, Not Just Actuals

    Most budget tracking focuses on actuals — what has been spent. This is a lagging indicator. By the time a budget overrun appears in the actuals, the damage is done.

    Track commitments — approved expenditures that haven’t been invoiced yet. A contractor engagement signed but not yet billed is a commitment. Future salary costs for the team are commitments. The gap between your total budget and your total commitments is your true remaining capacity to spend.

    Step 3: Allocate People Costs to Projects

    For most tech companies, people costs are 60–75% of total project budget. But people costs are rarely tracked at the project level — they’re tracked by department in the P&L. This disconnect creates a systematic blind spot: projects appear under-budget because people costs aren’t attributed to them.

    Fix this by running a simple internal transfer pricing model — assign a cost rate to each team (based on fully-loaded salary + overhead) and allocate to projects based on capacity allocation percentages. It doesn’t need to be accounting-perfect; it needs to be directionally accurate.

    Step 4: Establish a Monthly Budget Review Cadence

    Every project should have a monthly budget review: budget vs actuals vs forecast. The forecast — what you expect to spend by the project end date — is the critical number. It’s the one that tells you whether you need to intervene now or whether you’re on track.

    Any project where the forecast exceeds the budget by more than 10% should trigger an exception conversation: what’s driving the variance, and what’s the decision?

    Step 5: Create a Culture of Budget Accountability

    Budget accountability requires that project leads see their budget data regularly and feel ownership over it. A budget managed exclusively by finance, reviewed only by the COO, creates no behavioural change at the project level.

    Give project leads access to their budget dashboards. Include budget status in project reviews. Treat budget management as a core project management competency, not a finance function.

  • How to Run a Quarterly Strategic Review That Actually Drives Change

    How to Run a Quarterly Strategic Review That Actually Drives Change

    Most quarterly reviews are retrospectives disguised as strategy sessions. They spend 80% of the time reviewing what happened and 20% of the time agreeing that the same plan will work better this quarter if everyone just executes a bit harder. Nothing changes. The cycle repeats.

    A quarterly strategic review that drives change looks different. Here’s how to run one.

    Pre-Work (Week Before)

    Send three questions to all participants in advance:

    1. Which of our strategic objectives made meaningful progress this quarter, and what drove it?
    2. Which made insufficient progress, and what was the root cause?
    3. What assumption has changed that should affect our strategy or priorities?

    Require written answers — not slides, not bullet points in Slack. Written pre-work forces synthesis and reveals where there is genuine alignment versus polite agreement.

    The Agenda

    Opening (20 min): Review the strategic objective scorecard — not a deep dive, just the RAG status and headline results for each objective. Everyone should already know the details from the pre-work.

    Deep dives (60 min): Focus on two to three objectives — one that’s going well (to understand what’s replicable) and one or two that are struggling. For each, root-cause the performance rather than accepting surface explanations.

    Strategic assumptions review (30 min): Which assumptions underlying the strategy have changed? Market conditions, competitive landscape, internal capacity, technology availability — what’s different from when the plan was set?

    Priority adjustments (20 min): Based on the above, what — if anything — should change in the next quarter’s priorities? This should result in at least one explicit decision, even if the decision is to stay the course.

    Close (10 min): Assign owners to any actions arising. Every action needs a person and a date — not a team, not “we.”

    What Makes It Drive Change

    The difference between a review that drives change and one that doesn’t is the willingness to surface and act on uncomfortable truths. That requires psychological safety — leaders who won’t penalise honesty about what’s not working — and structural mechanisms that force the conversation, like the written pre-work and the strategic assumptions review.

    COOs who run reviews this way consistently report better strategic adaptation and better team engagement. The format is not complicated. The discipline required to maintain it is.

  • 5 Ways to Know If Your Teams Are Working on the Right Things

    5 Ways to Know If Your Teams Are Working on the Right Things

    Busyness is not the same as progress. Teams can be genuinely stretched, consistently delivering work, and still spending most of their time on things that don’t meaningfully advance the company’s strategic priorities. The question “are we working on the right things?” is one of the hardest for a COO to answer — and one of the most important.

    Here are five diagnostic approaches.

    1. Do a Strategic Theme Audit

    List all the active projects and initiatives in your portfolio. For each one, ask: which strategic theme does this serve? If you can’t answer that question, the project may be valuable — but it’s not connected to strategy. A theme audit will typically reveal that 20–30% of active work is either disconnected from strategic priorities or connected to priorities that have since changed.

    2. Measure the “Urgent vs Important” Split

    Track what percentage of team capacity is consumed by urgent reactive work (support escalations, production bugs, ad hoc requests) versus planned strategic work. If urgent work consistently consumes more than 25–30% of capacity, your teams are in a reactive mode that structurally prevents strategic progress.

    3. Check Your Senior Talent’s Allocation

    Your senior people should be disproportionately allocated to strategic priorities. If your most experienced team members are primarily solving operational fires, you have an inversion — your strategic engines are under-powered.

    4. Ask “What Would We Stop If We Had Less?”

    This counterfactual is a useful prioritisation tool. If the company had 20% less capacity next quarter, what would you stop? Whatever survives that cut is your strategic core. Everything that would get cut first is probably not a strategic priority — and yet it’s consuming capacity now.

    5. Review the Last Three Quarters of Delivery

    Look at what your teams actually delivered over the last three quarters. Map each delivered item to a strategic theme. Where is there delivery concentration? Where are there gaps? If you spent six months shipping features but your strategic priority was “reduce operational complexity,” the delivery-strategy connection has broken down.

  • Strategic Objectives vs Operational Metrics: Finding the Right Balance

    Strategic Objectives vs Operational Metrics: Finding the Right Balance

    Every COO manages two types of numbers. Strategic objectives tell you where you’re going — they’re directional, longer-term, and tied to the company’s competitive ambition. Operational metrics tell you how healthy the machine is right now — throughput, quality, reliability, team utilisation.

    Both matter. The mistake is treating them as the same thing.

    Why Conflating Them Causes Problems

    When operational metrics become strategic objectives, you optimise the wrong things. A company that sets “achieve 99.9% uptime” as a strategic objective hasn’t got a strategy problem — it’s got an operational baseline problem. Uptime is table stakes, not differentiation.

    When strategic objectives are measured with operational metrics, you lose signal. “Increase customer satisfaction” measured by support ticket volume tells you something about operational health but nothing about strategic progress. You need both, tracked separately.

    The Two-Layer Dashboard

    Sophisticated COOs maintain two distinct measurement layers:

    The strategic dashboard tracks OKR progress, strategic theme advancement, and outcome metrics — things like market share, NPS trend, enterprise ARR, product adoption rate. Reviewed quarterly, with monthly check-ins.

    The operational dashboard tracks throughput, quality, reliability, and team health — things like delivery predictability, defect rates, capacity utilisation, team satisfaction. Reviewed weekly.

    The two dashboards occasionally overlap — a customer satisfaction metric might appear in both. That’s fine. What matters is that they serve different decisions: strategic dashboards inform investment and direction; operational dashboards inform intervention and adjustment.

    Telling the Story to the Board

    One practical implication of this distinction: your board reporting should lean heavily on the strategic dashboard. Boards need to understand strategic progress, not operational detail. “We achieved 85% on-time delivery this quarter” is an operational metric. “We reduced enterprise customer churn by 12% against a target of 10%” is a strategic result.

    The COO’s communication skill — translating operational reality into strategic narrative — is what distinguishes good board reporting from confusing data dumps.

  • The COO’s Playbook for Cascading OKRs Across Teams

    The COO’s Playbook for Cascading OKRs Across Teams

    Cascading OKRs — translating company-level objectives into team-level and individual-level goals — is one of the most challenging operational design problems a COO faces. Done well, it creates alignment without rigidity. Done poorly, it creates bureaucracy without accountability.

    The Cascade Architecture

    Think of OKR cascade as a tree, not a chain. Company objectives sit at the root. Team objectives branch from them. Individual objectives branch from team objectives. Each level should be able to answer: “How does my goal contribute to the one above it?”

    The key mistake is trying to make the cascade too tight — insisting that every team’s OKRs map one-for-one to company OKRs. Most teams have legitimate operational objectives that are necessary to support the strategy but don’t map to a single company OKR. Platform reliability, team development, process improvements — these matter, but they don’t always have a clean OKR parent.

    Aim for directional alignment, not structural perfection.

    Setting the Rhythm

    Cascading OKRs requires a sequenced planning process:

    1. Company OKRs set by CEO/leadership: Weeks 1–2 of the quarter before
    2. Team OKRs drafted: Weeks 3–4 (bottom-up, informed by company OKRs)
    3. Alignment review: Week 4–5 (COO reviews team OKRs for gaps and conflicts)
    4. Final sign-off: Week 6 (before the quarter begins)

    This timeline is tighter than most organisations allow, which is why it must be explicitly scheduled, not assumed.

    The COO’s Role in the Cascade

    The COO’s job in an OKR cascade is not to write the team’s OKRs — it’s to ensure the cascade is coherent. That means:

    • Identifying gaps: Which company objectives have no team-level work mapped to them?
    • Identifying conflicts: Are two teams optimising for goals that are in tension?
    • Identifying overload: Have teams committed to more key results than is achievable?

    These three reviews should be the COO’s primary output from the cascade planning process.

    Making It Stick

    The most common failure mode is setting OKRs and then not revisiting them until the end-of-quarter review. Cascaded OKRs require monthly check-ins — not full reviews, but fifteen-minute updates: what’s progressing, what’s stalling, what needs leadership attention?

    Teams that check in monthly on their OKRs deliver significantly better results than those that don’t. The check-in is not overhead — it’s the mechanism by which the cascade stays connected to reality.

  • How to Connect Your Company Strategy to Day-to-Day Work

    How to Connect Your Company Strategy to Day-to-Day Work

    Strategy documents are aspirational. Sprint backlogs are operational. The gap between them — the execution gap — is where most company strategies quietly die.

    Closing that gap requires more than good intentions. It requires structural mechanisms that make the connection between strategic intent and daily work explicit, visible, and maintained over time.

    Step 1: Define Your Strategic Themes

    Start with the company’s strategic objectives for the year. Under each objective, define two to five strategic themes — the major focus areas that need to progress for the objective to be achieved.

    Themes should be specific enough to guide prioritisation but broad enough to encompass multiple initiatives. “Improve enterprise reliability” is a theme. “Fix the database timeout bug” is not. “Increase annual contract value” is a theme. “Train the sales team” is a tactic.

    Step 2: Tag Every Initiative

    Every significant project, initiative, or epic in your portfolio should be tagged to one primary strategic theme. This tagging is simple but powerful — it makes the portfolio-strategy connection explicit.

    When the CEO asks “what are we doing to improve enterprise reliability?”, the answer should come from a filtered view of tagged work, not from a manually assembled slide.

    Step 3: Review at the Theme Level

    In your monthly or quarterly operations reviews, review progress by theme rather than project by project. “How are we progressing against Enterprise Reliability?” surfaces all the relevant initiatives together and gives leadership a coherent view of momentum — or lack of it.

    Step 4: Use Metrics to Track Theme Progress

    Each theme should have one to three metrics that measure whether progress is real. Issue count is a weak metric — it tells you how much work is being done, not whether the theme is advancing. Better metrics are outcome-based: customer satisfaction score, on-time delivery rate, enterprise ARR.

    These metrics should be tracked in real time, not manually aggregated quarterly.

    Step 5: Connect Individual Tasks to the Strategy

    The final step is making the connection visible at the individual task level. When a developer opens a task, they should be able to see which theme it contributes to and why it matters. This isn’t motivational fluff — it’s the information teams need to make good micro-decisions about priority and trade-offs.

  • Why Most OKRs Fail at the Execution Layer (And How to Fix It)

    Why Most OKRs Fail at the Execution Layer (And How to Fix It)

    OKRs were supposed to fix the strategy-execution gap. And for a small number of organisations — typically those that implemented them carefully, with significant leadership investment — they have. For most, they’ve become another layer of overhead: goals that get set in January, reviewed perfunctorily in April, and largely ignored by the time Q3 arrives.

    The problem is almost never the OKR methodology itself. It’s the gap between where OKRs live and where work happens.

    The Layers Problem

    In a typical organisation, OKRs exist at three levels: company, team, and individual. Each level is supposed to cascade from the one above. In practice, each level is often set relatively independently, with loose alignment that looks connected in a slide deck but doesn’t hold up under operational scrutiny.

    The company sets an OKR: “Achieve market leadership in enterprise by Q4.” The product team sets an OKR: “Ship three enterprise features.” The individual engineer’s sprint backlog contains: seventeen bugs, a refactor, and one enterprise feature that’s blocked on design.

    The cascade has broken. But nobody can see it, because OKRs live in one tool and work lives in another.

    Why the Measurement Gap Is Fatal

    OKRs require leading indicators to be useful. You need to know whether you’re making progress toward the key result before the quarter ends — not in the final review. But most organisations measure OKR progress manually, quarterly, in a presentation. By the time you know you’re off track, it’s too late to correct.

    The solution is connecting OKR metrics to real-time operational data. If your key result is “increase on-time delivery rate to 85%,” your tracking should pull from actual delivery data, not from a number someone manually enters into a spreadsheet each month.

    The Ownership Problem

    OKRs also fail when ownership is fuzzy. A key result owned by “the engineering team” is owned by nobody. Effective OKRs have a named owner — a single person who is accountable for the result, even if the work is distributed across multiple teams.

    Without clear ownership, OKRs become shared aspirations rather than accountable commitments — and shared aspirations tend to stay aspired to rather than achieved.

    How to Fix It

    1. Connect OKRs to operational data. Every key result should be measurable from data that already exists in your systems. If you can’t measure it without a monthly survey, you probably haven’t defined it specifically enough.

    2. Assign issues and projects to themes. Every significant piece of work should be traceable to a strategic objective or theme. This creates a visible link between what teams are building and what the company is trying to achieve.

    3. Review at the right cadence. OKR check-ins should be monthly at minimum, weekly for critical key results. Quarterly reviews are post-mortems, not management tools.

    4. Make the connection visible to teams. Developers and designers who understand why their work matters to the company’s strategic priorities are significantly more motivated than those who don’t. The connection between a sprint task and a company objective should be one click, not a paragraph of explanation.

  • From Reactive to Predictive: Building a Capacity Planning Culture

    From Reactive to Predictive: Building a Capacity Planning Culture

    There are two modes of capacity management. In the reactive mode, you learn about overload when something breaks — a deadline slips, a team member burns out, a customer escalates. You scramble, reprioritise, and get back on track. Then the same thing happens next quarter.

    In the predictive mode, you know about overload before it becomes a problem. You see it in the data, you surface it in planning, and you make deliberate decisions about what to take on and what to defer. The emergencies still happen — but they’re rarer, and the organisation is more resilient when they do.

    The distance between these two modes isn’t technology or headcount. It’s culture — specifically, the habits, cadences, and psychological safety required for teams to tell leadership the truth about their capacity.

    Why Reactive Mode Persists

    Organisations stay reactive because being honest about capacity feels unsafe. If a team says “we can’t take that on,” they risk being seen as underperforming or resistant. If a project manager says “this won’t fit in the quarter,” they risk being told to find a way.

    So instead, teams accept commitments they can’t honour. Plans get agreed that everyone privately knows are unrealistic. And then, when things slip, it’s treated as execution failure rather than planning failure.

    The Cultural Shift Required

    Predictive capacity planning requires a cultural contract: leadership will not penalise teams for honest capacity assessments. That sounds obvious, but in practice it means COOs and leadership teams need to visibly reward people for surfacing capacity concerns, not quietly penalise them for not finding a way.

    It also means building the cadences that make transparency normal. A monthly capacity review where overloads are surfaced and addressed is a structural mechanism for honesty. Teams that know leadership will act on the data are much more likely to surface it accurately.

    The Tooling Corollary

    Culture alone isn’t enough. You also need tooling that makes capacity data easy to see and easy to update. If the capacity planning process requires three hours of manual data entry in a spreadsheet, teams will only do it quarterly — which is not frequent enough. If it’s embedded in the project and resource management system, it can be maintained in real time.

    The best capacity planning cultures are ones where the data is always current, always visible, and always connected to the decisions being made.

    Building the Cadence

    Start with a quarterly planning cycle that uses scenarios. Add a monthly check-in where teams update their utilisation and flag emerging overloads. Add a weekly signal — even just a simple red/amber/green flag per team — so early warnings surface before they become crises.

    Over two to three quarters, this cadence builds the habit. Teams start thinking about capacity proactively. Leaders start using capacity data in their decision-making. The language shifts from “we’ll manage” to “here’s what we can commit to and here’s what we can’t.”

    That shift is the difference between reactive and predictive — and it’s worth every ounce of effort it takes to build.

  • 5 Signs Your Team Is Chronically Overloaded (And the Data to Prove It)

    5 Signs Your Team Is Chronically Overloaded (And the Data to Prove It)

    Chronic overload rarely announces itself. It accumulates quietly — in small deadline slips, in the team member who stops asking questions, in the bug that gets logged but never prioritised. By the time it’s visible at the leadership level, it’s usually been embedded in the team’s culture for months.

    Here are five signals — and the data points that surface them.

    1. Deadlines Consistently Slip by 20–30%

    A project that was going to take 8 weeks takes 10–11. Another that was going to take 4 weeks takes 5–6. The slippage percentage is relatively consistent — which is a clue. It’s not project-specific risk. It’s systemic under-resourcing.

    The data: Compare planned vs actual delivery dates across your project portfolio over the last two quarters. If the average slippage is 20–30% and it’s consistent across teams, that’s a capacity signal, not a project management one.

    2. Your Best People Are On the Most Projects

    Senior talent gets pulled towards the hardest problems. That’s natural. But senior talent also gets pulled toward every problem because they’re trusted, available, and hard to say no to. The result is your top performers spread across five to eight projects simultaneously, delivering at fractional quality on all of them.

    The data: Map your top performers against current project allocations. If any individual appears on more than three concurrent initiatives, you have a concentration risk.

    3. “Quick Tasks” Are Taking Weeks

    When a team is at capacity, even small requests take disproportionately long. A two-hour fix takes three days because there’s no slack in the system to absorb even minor work without queuing. This is called queueing delay, and it’s a classic capacity saturation symptom.

    The data: Track cycle time for small or low-complexity issues. If “small” tasks are sitting in backlogs for five or more days before anyone touches them, the team’s queue is saturated.

    4. Quality Issues Are Increasing

    Overloaded teams cut corners — not because they’re careless, but because they’re trying to meet commitments with insufficient time. Code review gets abbreviated. Testing gets compressed. Documentation gets skipped. The downstream effect is bugs in production, customer complaints, and rework cycles that consume the next quarter’s capacity.

    The data: Track defect rates, bug-to-feature ratios, and rework cycles quarter-over-quarter. Rising defect rates alongside rising workload is a near-certain capacity saturation signal.

    5. Attrition Is Climbing

    When people are chronically overloaded, the first exit is internal disengagement — quiet quitting. The second exit is actual departure. High-performing people leave first because they have options and they recognise the structural problem. What gets left behind is a team that’s smaller, less experienced, and even more overloaded.

    The data: Track voluntary attrition by team and correlate it with utilisation rates. Teams with sustained utilisation above 90% almost always show elevated attrition within two to three quarters.

    What to Do

    Naming the problem is step one. Step two is bringing the data to a leadership conversation. Step three is making a structural decision — not a motivational one. Telling overloaded teams to “prioritise better” or “work smarter” is not a solution. Reducing their committed workload is.