01
Outcome and brief record
I bring the audience, required outcome, deliverables, constraints, known inputs and unresolved questions into one working reference.
My framework · Project Management controls
I connect the work to the decision that moves it forward.
This is the practical control layer I use around delivery: a clear brief, named responsibility, visible dependencies, review decisions and an organised handover.
The framework is a practical working approach, not a proprietary or certified methodology. I adapt the artefacts to the real brief, team and tools.
What this page adds
The artefacts behind my working method.
How I Work explains the delivery rhythm from brief to handover. This page shows the practical records and controls I use to make that rhythm inspectable.
I do not force every engagement into the same template. I choose the smallest useful set of artefacts that keeps ownership, decisions, evidence and handover clear.
Working artefacts
Five records keep the delivery story connected.
The platform can change. The information each artefact carries should remain readable to the people responsible for the work.
02
Responsibility map
I distinguish the delivery owner, contributors, reviewers, approver and receiving owner so that a decision always has somewhere to land.
03
Delivery and dependency view
I organise work packages, dependencies, current state and next action in a shared view that can be read without reconstructing a conversation.
04
Decision and review record
I turn feedback into a named decision, owner, due point and version reference rather than leaving it scattered across messages.
05
Handover index
I connect accepted files, versions, credits, rights, accessibility checks, source locations and the person receiving the finished work.
Decision and review controls
A gate closes with a recorded state, not an impression.
The exact sequence can overlap, but each control answers a different delivery question.
- 01
Entry control
Before activity expands, I confirm the outcome, audience, deliverables, decision owner, constraints and the evidence that will define acceptance.
- 02
Delivery control
During production, I keep dependencies, blockers, review dates, versions and next actions visible beside the work they affect.
- 03
Review control
A review closes with an explicit decision: accept, revise, hold or escalate. I record who decided, what changed and which version continues.
- 04
Release control
Before release, I check the approved output, destination, accessibility, attribution, rights, filenames and remaining non-claims against the brief.
- 05
Handover control
The work closes when the receiving owner can find, understand and use the final bundle, with open items and future responsibilities made clear.
Handover logic
“Done” changes meaning as the work moves.
I use explicit readiness states so that a review request is not mistaken for a release, and a released file is not mistaken for a complete handover.
- Ready to review: the intended output, version and decision needed are named.
- Ready to release: the approved output and its quality, access, rights and attribution checks are recorded.
- Ready to hand over: the final bundle, source locations, receiving owner and open responsibilities are clear.
Applied with proportion
The control should earn the attention it asks for.
A short assignment may need one brief, one delivery view and one handover index. A multi-contributor project may need separate responsibility, dependency, decision and release records.
I confirm the real scope before choosing the format. Tool names, response times, availability and project outcomes are never implied by the framework alone.
Inspect bounded Work / Proof recordsPut the framework around real work
Send me the context the next decision depends on.
Share the outcome, audience, deliverables, contributors, current state, review route and blocker. I will use those facts to identify the smallest useful control set.