My Approach to Managing Projects

1. Product Breakdown Structures (PBS) Enabled Artefacts 

A project brief almost always exists in some form, but not all artefacts are structured to support PBS tracking—which is precisely why this step matters. It’s about tailoring the artefacts so they can enable objective progress tracking towards the project/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 artefacts are developed through workshops and structured engagement, and I design them to support objective tracking of progress. Each has clearly defined Minimum Viable Product (MVP) criteria.

In essence: welcome to the foundations provided by Product Breakdown Structures (PBS). This underpins the arithmetic I use to quantify delivery progress—and, in turn, generates the progress metrics that feed into weekly, monthly, and phase-end reporting, making PBS a cornerstone of effective project governance.


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

Not all RAIDs need to surface externally to the workstream. For example, CxO stakeholders don’t require visibility into details that don’t impact the critical path—such as technical spikes at the Scrum level or backlog stories spanning multiple sprints.

I maintain a staging RAID log to enable internal triage and discussion before assigning each entry to the appropriate level—whether it stays internal or is escalated to the project or programme level, as needed.


3. 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.


4. 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.

5. 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.


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