Projects

The whole is the point.

Most systems don't fail because the parts are broken, but because the connections between them were never built. From engineering components to enterprise planning, the instinct has been the same — find what connects, build what holds.

Walk into ambiguity → leave it a system.

Projects

Personal

Feasibility Driven Planning

Fixed Spine · Flexible Execution · f(Demand, Capacity, Time)

Seven projects, one pattern. Every time I looked — at the planning system, the data platform, the execution schedules, the review model — the same thing was missing. Not the data, not the people. The logic that holds demand, capacity, and time together. This is what I found when I stopped working around it and looked directly at it.

Read the case study →

The pattern none of them named

Feasibility DrivenPlanningf(Demand, Capacity, Time)EngineeringS&OPGlanceEcosystemEngineeringFootprint StrategyGEC StrategyIBP forSurfaceIntegrated ExecutionScheduling FrameworkCapstone — Driving ResultsThrough Cross-FunctionalConnectivityProcessContextData & ToolContextStrategyContextReviewsContextProcessContextOrgContext

Working across seven connected initiatives, a pattern emerged that none of them named individually: most organisations cannot answer the most basic planning question — can we deliver what's committed, with the resources we have, in the time available? Value erodes not in execution, but at the moment of commitment. Developed a planning framework built on one idea: feasibility is a function of demand, capacity, and time — and a plan only holds when all three are aligned intentionally, not assumed.

Demandplanned by phaseProspectTenderedAwarded⁄⁄Capacityplanned by functionFunction AFunction BFunction C⁄⁄Timeplanned by horizonStrategicTacticalOperational

Planning wasn't broken — it was fragmented. Demand: planned by phase. Capacity: planned by function. Time: planned by horizon. Each view is locally valid, but partial without consistent integration. Many plans, many tools — still no one who could confidently say whether a whole project would deliver on time.

Feasibility = f ( Demand , Capacity , Time )TenderPlanningExecutionDemand drives capacity · capacity constrains commitment · both only against timePROJECTS — THE INTEGRATION ANCHOR

Feasibility = f(Demand, Capacity, Time) — the ability to deliver what's committed, when it's committed, with the capacity available. Demand decisions drive capacity decisions; available capacity constrains what can be committed; neither means anything except against time. Projects are where it converges — the natural anchor for horizons, functions, and phases, where feasibility shows up as cost, schedule, and risk.

Demand PlanCapacity PlanSupplyDEMAND →↑ TIMECAPACITY ↗

The Cube Model. Imagine three axes — Demand, Capacity, Time. Each plane is a plan I already recognised from the real world: a Demand Plan, a Capacity Plan, a Supply Plan. Together they form a cube — a supply plan that rationalises feasibility with its dependencies and constraints, reviewed periodically through a review architecture. Fixed where it matters, flexible where it must be; pressure-tested on engineering.

blockfunctional supply planenterprise supply plan

Modular implementation — Lego blocks that snap into place. One building block, built right at its edges and complete in its data, scaled to the enterprise.

SynthesisTranslationSponsorshipTHE SAME JOB

The framework was the easy part. Synthesis — seeing several problems I'd solved separately as one problem in disguise. Translation — retelling a structural insight in the language of the people who fund things. Sponsorship — a sound idea still stalls without an owner who has authority and incentive. Systems design, business translation, and stakeholder alignment are three parts of the same job.

01 / 06
Planning · Systems · Strategy

IBP for Surface

WorkIBP · Planning · Strategy

Surface planning existed but was limited to select functions with no integrated view across projects, products, and commercial activity. KPIs were disconnected from holistic business goals. Proposed a three-anchor IBP model — business, product, function — bringing every function into a single planning cadence with connected KPIs. Approved to proceed to MVP.

Engineering S&OP System

WorkS&OP · Planning · Systems Design

Engineering planning existed across 9 global subsystems but no one could see across all of them. Data collection took weeks. Demand was only 66% visible — which meant missed hiring windows, projects accepted without knowing if capacity existed, and underutilized global delivery centers. Built the framework, guidelines, and Power BI structure that took demand coverage to 95% and gave One Engineering its first shared planning language.

Glance Ecosystem

WorkSystems Design · Digital · Planning

Engineering S&OP generated data across 50+ sources — but no centralised platform existed to make it usable. Planning was fragmented and manual, and data-driven decisions at executive level were impossible. Conceived, built, and evolved Glance from a manual Excel replacement into an integrated planning ecosystem connecting demand, capacity, budget, headcount, and actuals. Shifted leadership from data gathering to decision making.

Integrated Execution Scheduling Framework

WorkPlanning · Execution · Engineering

The gap between strategy and execution is widest at the moment a commitment is made — before anyone has checked if delivery is actually possible. Tender inaccuracy and execution plan changes were the top two drivers of value destruction — accounting for over 45% of VD in both regions studied. Built an integrated scheduling framework from prospect through execution that closes that gap at the earliest stage. Leading implementation across 6 subsystems — 2 complete, target July 2026.

GEC Strategy

WorkStrategy · Operations · Leadership

Global Engineering Centers had no clear purpose, stagnant growth, and significant untapped potential. Without a strategy they were operating as resource pools — available, but not directed. Co-developed the GEC Strategy A3, redefining them from support units into execution centers across four pillars. Two global centers transitioned to execution centers within six months. Capacity only means something in a planning system if you know who has it, where they are, and what they can do. This is what made that visible.

Engineering Footprint Strategy

WorkStrategy · Analysis · Operations

Engineering needed to reduce OPEX while simultaneously ramping capacity to support significant business growth. Those two goals looked like opposites. Built a Power BI what-if analysis drawing on planning data — modelling capacity, cost, and demand by location — to give leadership its first structured view of engineering footprint economics.

Capstone — Driving Results Through Cross-Functional Connectivity

WorkStrategy · Analysis · Leadership

Siloed operations accounted for 35% of the organisation's top-20 value destruction events — 20% of total events. The problem wasn't coordination. It was structural. Diagnosed two systemic root causes using six independent data sources, mapped them to seven strategies, and presented to leadership.

Fittings Standardisation

WorkEngineering · Standardisation · Lean

Engineering a fitting configuration took ~80 hours, each variant largely re-engineered from scratch. Through structured A3 problem-solving, design standardisation, and a configurable interface, I cut it to 8 — a 10× reduction — and built the configurator and stocking logic that made it repeatable. Awarded the TechnipFMC Gold Medal of Recognition.

Artha — Life Operating System

PersonalPersonal · Systems

A personal operating system for life — the same instinct for structure, applied to goals, decisions, and routines. Write-up in progress.

Job-Search Pipeline in Clay

PersonalPersonal · Automation

A personal job-search pipeline built in Clay — sourcing, enriching, and tracking opportunities as a system rather than a spreadsheet. Write-up in progress.