B — HOW I WORK

How I Work

How I work

Complex work gets easier when the right people share the same picture. People → Picture → Plan → Perform → Pivot is a practical operating philosophy developed through experience — not a commercial methodology. See References for practices that inform it.

01

People

Find the people who know the work — technical experts, business owners, and people closest to the systems. Establish direct communication and understand who owns which decisions, systems, and dependencies.

02

Picture

Get the problem and system out of people's heads. Make current state, target state, dependencies, risks, and decisions visible — then validate. Show me how you see it.

03

Plan

Turn that understanding into scope, work, dependencies, and sequence. Decompose into workstreams, deliverables, and tasks — plans that serve execution, not replace it.

04

Perform

Get the people, vendors, decisions, and work moving. Communication, governance, RAID, status, and steering matter when they support delivery — not when they become the work.

05

Pivot

Revisit the picture when reality changes, then adjust the plan. Pivot is not failure — it is updating the shared understanding before the work drifts.

People. Picture. Plan. Perform. Pivot. A simple operating model for turning complex systems into coordinated change.

Fig. 1 — The Five P feedback loop, with communication and risk running throughout
reality changes People — meet the expertsPEOPLEmeet the experts Picture — whiteboard the systemPICTUREwhiteboard the system Plan — decompose into workPLANdecompose into work Perform — execute with disciplinePERFORMexecute with discipline Pivot — reality changesPIVOTreality changes COMMUNICATION RISK

I believe a project manager’s highest-value work is creating shared understanding, connecting the people doing the work, resolving dependencies and keeping execution moving. Project artifacts should support that work, not become the work.

The engineer is the expert. I don't need to be the deepest technical specialist in the room. The engineers and architects own the technical expertise. My job is to understand their world well enough to connect it to the wider program, expose dependencies, establish decisions, and lead the change.

"Show me how you see it."

Get the picture out of people’s heads.

B.01 — ARTIFACTS ARE TOOLS

Philosophy

Artifacts are tools

Project plans, RAID logs, status reports, governance decks and documentation are important. They create visibility and support decisions.

But the artifact is not the work.

The work is understanding the problem, connecting the people who know it, resolving dependencies and getting the project moving. Project artifacts should support the work, not become the work.

B.02 — PICTURE, IN PRACTICE

The whiteboard isn't dead.

Remote work changed where technical teams work, but it didn't change how people understand complex systems. We still need to draw the architecture, show the dependencies, challenge the assumptions, and build a shared mental model.

Ten minutes of drawing is worth ten hours of talking.

The whiteboard can be physical, or it can be Excalidraw, tldraw, Miro, FigJam, Mermaid, or another collaborative canvas. The medium changes. The cognitive process doesn't.

Physical whiteboard Excalidraw tldraw Miro FigJam Mermaid
B.03 — COMMON OPERATING PICTURE

One picture everyone is working from.

A Common Operating Picture is a shared representation of the system, the change, the important dependencies, the current state, and the decisions required to move forward. It's what a whiteboard session turns into once it has to hold an entire program.

Fig. 2 — Representative Common Operating Picture (generic composite, no client data)
PEOPLE / DECISIONS Architecture Security Network App Owners Business CURRENT STATE Compute Storage Network Identity TARGET STATE Compute Storage Network Identity DEPENDENCIES target platform confirmed rollback owner assigned WORKSTREAMS Discover Migrate Validate Cutover
See this applied to real project types in Project Maps →
B.04 — RELATIONSHIP TO PROJECT MANAGEMENT

The Five P Method doesn't replace project management. It gives project management a better understanding to work from.

The normal disciplines still apply. The distinctive move is what happens before and around them — people and picture, before plan.

ScopeScheduleCostQualityRiskIssuesDependenciesCommunicationsStakeholdersResourcesGovernanceChange ControlMilestonesExecution
Fig. 3 — From system understanding to project plan
EXISTING SYSTEM UNDERSTAND VISUALIZETHE CHANGE MAP COMPONENTS+ DEPENDENCIES DECOMPOSE WORK BREAKDOWNSTRUCTURE TASKS +OWNERS SEQUENCE PROJECT PLAN EXECUTE REALITYCHANGES PIVOT reality changes → replan