My Approach to Managing Projects

1. Product Breakdown Structures (PBS) Enabled Artefacts [THE WHAT]

A project brief almost always exists in some form—but not all artefacts are structured to support PBS tracking. That’s exactly why this step matters. It’s about tailoring those artefacts to enable objective progress tracking against the project or programme goals. 

To keep the focus on end users and delivery teams, I work with stakeholders to translate the purpose—the why—into a set of collaboratively created construction artefacts. These delivery-focused outputs are developed through workshops and structured engagement, and I design them specifically to support objective progress tracking. Each comes with clearly defined Minimum Viable Product (MVP) criteria.

In essence: welcome to the foundations laid by the Product Breakdown Structure (PBS). This underpins the arithmetic I use to quantify delivery progress—and in turn, it generates the metrics that feed into weekly, monthly, and phase-end reporting. PBS becomes a cornerstone of reality-driven project governance. The Work Breakdown Structure (WBS) also plays a crucial role—especially in defining how those artefacts will be delivered.

In projects where the delivery team isn’t explicitly working to a PBS, I often construct a logical PBS of my own to support progress checks. This helps ground WBS percentages in something concrete. For example, if the WBS shows 75% complete on a four-week task to produce a requirements spec, I’d expect to see a near-final draft that’s been through at least one review. If what’s actually available doesn’t match that level of completeness, I’ll explore the disconnect with the team—and, if warranted, record a delivery risk against the WBS.


2. Work Breakdown Structures (WBS) Enabled Activities [THE HOW]

Whereas the PBS defines what needs to be delivered, the WBS defines how it's going to get done. This step is essential for translating the artefacts into actionable, trackable chunks of work—especially in programmes with mixed delivery methods and overlapping teams.

To ensure the WBS stays grounded in reality rather than presentation theatre, I work closely with delivery teams and workstream leads to break activities down to a usable level of granularity. Not a monster Gantt for decoration, but a framework that reflects the actual sequence of work needed to produce each artefact, complete with clear ownership and logical dependencies.

The result? A Work Breakdown Structure that aligns tightly with PBS artefacts—so every task supports a defined output, and every progress update can be mapped back to something meaningful. This alignment keeps governance honest: no ambiguous “80% done” updates, just visible, structured progress.

In short: the WBS puts the scaffolding around delivery. It turns the purpose-built artefacts of the PBS into executable plans and provides the mechanics that make earned value tracking and milestone forecasting worth more than guesswork.

Where appropriate, I refer back to the PBS to get a clearer sense of actual progress. If there’s a mismatch between WBS-reported progress and what’s materially delivered in the PBS, I’ll flag it—gently—as a potential risk or issue for further review."


3. RAID Management (Risks, Assumptions, Issues, Dependencies)


Not every RAID item needs to make it past the workstream. CxO stakeholders don’t need play-by-plays on technical spikes or backlog stories that stretch across sprints—unless they impact the critical path.

To manage this, I keep a staging RAID log—essentially a holding area—so we can triage and discuss internally before deciding where each entry belongs. Some stay within the team; others are escalated to the project or programme level if needed.

Used properly, the RAID log isn’t just a formality—or a place to park awkward problems. It becomes your project’s early warning system. A mirror that doesn’t flatter, but helps you stay honest.

3.1 🎯 Quality (The What – PBS)


If the Product Breakdown Structure defines what we’re delivering, the RAID log helps track whether those deliverables are actually fit for purpose.

It’s not just, “Did we build it?”—it’s, “Did we build the right thing, to the right spec, with the right sign-off?”

  • Risks flag when quality might slip—think scope creep, lack of SME input, or shifting requirements mid-sprint.

  • Issues show where quality already has slipped—missed acceptance criteria, artefacts not matching the spec, or rejections at demo.

  • Dependencies remind us what quality relies on—like having an approved data model before the build begins.

Done well, this keeps the PBS outputs solid—not just rushed out the door to tick a box.

3.2 🛠️ Progress (The How – WBS)


If the Work Breakdown Structure is the roadmap, the RAID log highlights the bumps, roadworks, and dodgy detours that could throw you off course.

  • Risks signal what might derail delivery—resourcing gaps, compressed timelines, or over-reliance on manual effort.

  • Issues show where things are already off track—missed handoffs, slipped milestones, or under-reported effort.

  • Assumptions (the stealthy troublemakers) expose where the WBS rests on shaky ground—phantom dependencies, unassigned activities, or just wishful thinking.

This is how you keep progress honest. No vague “80% complete” claims—just visibility tied to real work.

3.3 🧭 Bottom Line


A RAID log that’s working for you—not just collecting dust—helps answer two big questions:

  • Are we building the right things? (PBS – quality)

  • Are we doing it in a way that holds up under pressure? (WBS – progress)

The RAID is not admin for admin’s sake—it’s governance that supports delivery, not fights it.

 


4. Earned Value Analysis (EVA)

The primary reason for using PBS-enabled artefacts is to support objective progress measurement through Earned Value Analysis (EVA). I track Planned Value, Earned Value, and Actual Cost, and apply metrics like the Cost Performance Index (CPI) and Schedule Performance Index (SPI) to assess delivery health.

When I detect cost or schedule variances, I treat them as signals to investigate root causes, reforecast if needed, and engage stakeholders—typically via the RAID process—to identify and implement corrective actions.


5. Agile Delivery Framework

I tailor my Agile approach to fit the programme context—whether that involves Scrum, Kanban, or a hybrid model like ScrumBan. Sprint planning is run as a collaborative, team-level process, supported by estimation techniques such as Planning Poker and three-point estimates to improve forecast accuracy.

I facilitate key Agile ceremonies, e.g., daily stand-ups, sprint reviews, retrospectives, and backlog refinement.

To ensure progress remains visible and on track, I monitor team velocity and use tools like burn-down charts and cumulative flow diagrams. Actual spend is tracked against sprint capacity, incorporating contractual artefacts e.g., timesheets, contract rates, and tooling costs.


6. Quality Assurance and Continuous Improvement

Quality is embedded from the outset—for example, by defining what “done” means and consistently reviewing deliverables against that benchmark. The use of PBS-enabled artefacts, ensures that change control is managed in a structured way without compromising Agile adaptability.

I conduct retrospectives at the end of each sprint and phase to capture lessons learned and drive continuous improvement. PBS also serves as a framework for tracking measurable progress and maintaining alignment with delivery goals.


7. Murphy’s MVP (the version most projects deliver)

This isn’t some horror story—it’s just the usual outcome once reality has had its say. The shiny blueprint goes in, but what comes out is something that works… just not quite as advertised. There’ll be some duplicated effort, manual nudges to get things moving, and a heroic spreadsheet or two doing things no spreadsheet was ever meant to do.

It’s functional enough to ship, and it’ll tick the MVP box. But let’s be honest—quality takes a knock, and the tech debt doesn’t just creep in, it walks through the front door with its boots on.

By the time you hit turnaround, what you’ve built is often a negotiated truce between the ideal and the chaos you inherited. The trick isn’t perfection—it’s knowing when to stop digging and start steering.



Summary: 
Delivering Clarity, Control & Continuous Value

I lead projects with a structured yet flexible approach—defining clear outcomes, embedding quality from the start, and adapting Agile practices to fit the context. I use RAID management, Earned Value Analysis, and Product Breakdown Structures to keep delivery on track, transparent, and aligned with business goals. Whether starting fresh or joining mid-flight, I bring calm control, collaborative energy, and a sharp eye for measurable progress.

Programme Delivery Insight

I use Bill of Materials (BoM) as a useful thought blueprint for any programme I am involved with; Kanban. The real value comes from autonomous assembly in the agile layer. Without assembly, it's just organised ambition.

There’s no need to concern the programme board when issues are resolvable and actively managed in the practitioner Scrum layer—i.e., no impact on critical path or key milestones at this stage. A BoM is like a blueprint for effort: each project is a component, each task a screw or bolt. If one’s missing or misaligned, the end product may wobble—or fail to assemble at all.

Methods at a Glance

  • Programme: Sets the why, when, and who — defines goals, allocates resources, and monitors milestones.
  • Kanban: Manages how work flows across teams — good for visibility, continuous delivery, and limiting overload.
  • Scrum: Manages how work is delivered in chunks — good for uncertainty, iteration, and regular feedback.

Governance Definitions I use (at a Glance)

Aspect Programme Kanban Scrum
Method A structured management framework for coordinating multiple projects A visual workflow method focused on managing work in continuous flow An Agile delivery method based on sprints and defined ceremonies
Approach Top-down, milestone-driven, often stage-gated or using Waterfall Pull-based, evolutionary, lean approach with focus on efficiency Iterative and incremental, emphasizing team collaboration
Operations Focuses on governance, integration, dependencies, risk, resource alignment Operates via boards, WIP limits, flow metrics, and team autonomy Operates in time-boxed sprints with ceremonies like stand-ups, reviews, retros

Orchestrate to avoid the Chaos

Aspect Waterfall - Low Granularity Kanban - Medium Granularity Scrum - High Granularity Combined Use Case
Approach Sequential, phase-driven Continuous flow Iterative, time-boxed sprints High-level waterfall with Kanban/Scrum at team level
Planning Heavy upfront planning Minimal, rolling planning Sprint planning (typically 1–4 weeks) Waterfall for governance milestones; ScrumBan for delivery flexibility
Delivery Big bang, at the end Continuous, as tasks complete Incremental, sprint-based Regular drops (Scrum) within phase gates (Waterfall)
Change Management Difficult after sign-off Very adaptive Adaptive between sprints Waterfall sets scope; Scrum/Kanban manage change locally
Roles Traditional PM, BA, QA Flexible — team-managed Scrum Master, Product Owner, Dev Team Traditional PMO + Agile delivery teams
Artifacts Gantt charts, BRDs, Test Plans Kanban boards, WIP limits Product Backlog, Sprint Backlog, Burndown charts Use Jira/DevOps to integrate epics (Waterfall) with user stories (Scrum/Kanban)
Tools MS Project, Excel Jira Kanban, Trello, Azure Boards Jira Scrum, Azure DevOps, VersionOne Integrated tools (e.g., Jira with waterfall roadmap plugins)
Best For Construction, compliance-heavy IT projects Support, BAU ops, content delivery Software/dev teams, iterative data modeling ERP programs, data lakes, cloud migrations
Team Autonomy Low High Medium-high Teams self-organize under waterfall structure
Customer Involvement Low after requirements High, continuous High, per sprint High during delivery; minimal during planning and governance
Metrics Focus Milestone deadlines, budget adherence Flow efficiency, cycle time Velocity, team capacity Milestones (Waterfall) + Agile metrics (ScrumBan) for delivery tracking

NLP Techniques for Programme and Project Managers

Project management isn’t just about Gantt charts and RAID logs—it’s also about people. Neuro-Linguistic Programming (NLP) offers practical tools to help PMs navigate the emotional terrain of stakeholders, teams, and high-stakes delivery.

🧠 Key NLP Techniques

  • Mirroring & Matching: One of my favourite techniques. Subtly align with stakeholders’ language, tone, and posture builds rapport and reduces resistance.
  • Reframing: Help others view problems from a constructive angle (e.g., "Never say No; the answer is always varying degrees of YES (sure requirements may need altered, and when good rapport has been established agreement can be achieved").
  • Anchoring: I try to be dispationate and objective. I work on a consistent emotional state (e.g., calm before, especially difficult, steering meetings) by associating with tone, setting, or phrasing.
  • Meta-model Questioning: I use conceptual models and precise questions to uncover misunderstandings, assumptions, distortions, and generalisations in discussions.
  • Visual/Kinesthetic/Auditory Cues: I endeavour to tailor communications for how people will best receive information.

🐑 Herding the Sheep: The Human Side

Typically I find I need to manage 'hard' timelines with 'soft' tension, personalities, and focus. NLP helps you notice when the flock is scattering emotionally and guiding me to gently nudge them back on course—without barking like a sheepdog.

Pro Tip: Typically, stakeholders may raise irrational or opaque issues, I typically ask: "What would need to be done for the situation to make sense?" This typically reveals the hidden drivers. It is important to minimise confrontation by embracing the stakeholder(s) worldview and their right to have an opinion.

“Projects fail mostly from human misalignment.” – adapted from an anonymous source; I reckon they were a PM

Governing using combination of approaches makes sense

Programmes 'are defined by' Projects 'are made manageable by' Kanban 'are realised in individual' Scrum sprints

Aspect Programme Project Kanban Scrum
Definition A coordinated set of related projects aligned to strategic goals A temporary initiative to deliver a specific product or outcome A workflow method for visualising and managing continuous tasks An Agile framework for iterative product delivery
Focus Strategy, value, governance, benefits realisation Scope, time, cost, quality Flow efficiency, task visibility Iteration, team velocity, feedback
Structure Milestones, workstreams, benefit tracking Tasks, deliverables, dependencies Visual boards, WIP limits Sprint backlog, ceremonies, retrospectives
Timeframe Long-term, multi-phase Defined start and end Continuous flow Time-boxed sprints
Delivery Style Waterfall or hybrid Waterfall or Agile Agile/Lean Agile (Scrum)
Team Autonomy Low to medium Medium High High
Primary Tools MS Project, Planview, Jira Align MS Project, Smartsheet, Monday.com Jira Kanban, Trello, Azure Boards Jira Scrum, Azure DevOps, VersionOne
Best Use Case ERP rollout, digital transformation System migration, product launch IT Ops, BAU, content production Software dev, BI dashboards
Key Artifacts Programme plan, business case, benefits map Gantt chart, RAID log, risk register Kanban board, cumulative flow diagram Burndown chart, sprint goals, product backlog
Interaction Oversees and coordinates multiple projects May use Kanban/Scrum for task execution Used within projects or programmes Used within projects or as a stand-alone team method
Units of MVP Release: Kanban vs Sprint

Units of MVP Release: Kanban, Sprint, and MVP

MVP (Minimum Viable Product) is a macro-level unit used to deliver a functioning, value-generating version of a product with minimal features. It can be built using different delivery methods, most commonly Sprints or Kanban flows.

Comparison of MVP, Sprint, and Kanban Work Units

Concept Type of Unit Timeframe Purpose
MVP Macro-release unit Weeks to months Validate product idea with minimal feature set
Sprint Time-boxed batch 1–4 weeks Deliver potentially shippable product increments
Kanban Item Continuous flow unit Variable (per item) Deliver value item-by-item, manage flow efficiency

Organise Governance Levels

Layer Method Role
ProgrammeWaterfallDefine scope, timeline, budget; set governance milestones
Construction UnitKanbanTrack continuous load issues, mapping tweaks, environment handovers
AssemblyScrumPlan sprints to build data extraction logic, validation logic, workflow logic, publish logic, subscribe logic etc. iteratively