Applying PDCA to the Obligation-Promise Cycle

PDCA Applied to Obligation/Promise Cycle

An obligation is a requirement the organization must fulfil. It may be mandatory or voluntary, external or internal, and it stays active for as long as it is imposed or adopted.

A promise is a voluntary commitment made by an agent about its own behaviour. Obligations give rise to promises. That is how an obligation becomes operational.

The cycle runs between them. Obligations produce promises, promises are kept through operational capability, and what that capability delivers is assessed back against the obligation. PDCA belongs on this cycle.

Where you place it determines whether you get a management ritual or a working regulator.

Why PDCA belongs here at all

Lean and compliance are separate disciplines working on the same problem. Variation that escapes control produces waste, creates risk, and results in non-compliance. Those are three expressions of one condition.

PDCA came out of that same problem. Shewhart built it for variation. Deming taught it as a way to learn about a system.

PDCA gives you four questions. What are we promising. What will produce it. How will we know when it drifts. What will we do about it.

You answer them once, when you design how a level regulates itself.

Answering is a sequence. The four functions the answers describe are concurrent. They run at the same time, at different speeds, for as long as the work continues.

Plan and the positive prior

You cannot detect what is missing until you have defined what should be present. Every compliance failure is an absence, and an absence only makes sense against a stated presence.

Plan is where the presence gets stated. The obligation gives the requirement. The promise states what the organization will do about it, written so someone else can assess it, with an obligation owner named, a stakeholder entitled to judge it, and a date it took effect.

How much and what work this takes depends on the regulatory design of the obligation.

• A rules-based obligation arrives nearly specified. Store personal data in encrypted format. The promise adds little beyond scope and ownership.

• A practice-based obligation names a body of practice and leaves interpretation to you. Implement process safety management. The promise has to say which elements, to what depth, and how competence is established.

• A performance-based obligation gives a measurable target and leaves the means open. The promise states the path to it, with reference points close enough together to detect drift.

• An outcome-based obligation gives an end result and nothing else. Ensure process safety. Achieve net zero. Nearly all the specification work is yours, and this is where obligation debt accumulates fastest.

Most registers cover rules well and thin out toward outcomes. Voluntary obligations mostly sit at the outcome end, which is why ESG targets and community commitments are so often unmanaged.

The four functions on a single obligation

Take a commitment to reduce carbon footprint by thirty per cent within three years.

Plan sets the reference. The thirty per cent is the requirement. It states an endpoint and nothing else. The promise states the path. Which sources are in scope, what will be done to each, and what the footprint will be at the end of each year. Without those interim points there is nothing to compare against until the deadline has passed.

Do produces the behaviour. Equipment replacement, fuel switching, procurement terms, changes to how work is scheduled. Operability is the question here. Whether the budget, the people and the authority exist to deliver the reductions the promise depends on.

Check detects deviation. Measure the footprint against this year's point on the path, often enough that a shortfall can still be recovered. Reporting once a year on a three year commitment gives you two chances to correct.

Act changes the means. Bring projects forward, add capital, change suppliers. When the range of responses runs out, the level escalates. The failure to watch for is the target moving instead. A rebaselined starting year, a narrowed scope, offsets bought to close the gap in the report.

Every obligation in the register can be walked this way. Where the walk stops is the finding. Most stop at Plan, with a target and no path.

What Check has to reach

Adherence and conformance are where most measurement stops. Are we doing what we said we would do, and does our approach meet the accepted standard of practice. Both are necessary and neither tells you whether the promise is being kept.

Performance asks whether the targets are being met. Effectiveness asks whether the work is producing the outcome the obligation exists for. Integrity asks whether stakeholders can trust the organization to keep delivering on their obligations.

The effectiveness gap opens between effort expended and outcomes achieved, and it stays invisible to a measurement system that stops at conformance. Audit tells you what happened. Assurance tells you whether the promise will keep being kept, and it is built from operational capability and continuous monitoring rather than periodic inspection.

The same functions at every level

Level	Primary behaviour	What its loop regulates	Speed
Governance	Sets direction	The promises the organization makes	Years
Programs	Introduces change	Capability being built	Months to two years
Systems	Resists change	Variation around control limits	Weeks to months
Processes	Does the work	Accuracy, timeliness, completeness	Hours to weeks

The tension between programs and systems is designed. Programs are the engines of adaptive control, introducing change to build capability. Systems are stabilizers, damping variation to hold what has been built. Both run the four functions and their loops pull against each other, which is healthy while each stays inside its own mandate.

Requisite variety applies at each level. The range of responses available has to match the disturbances arriving at that level's speed. When everything escalates to governance, the lower levels were never given a range. When nothing escalates, the signals generated by processes are not reaching the levels above them.

Reading your register

Obligation debt is the volume of obligations left unaccounted and unmanaged. You can see it in the column headings.

Most registers carry the obligation, its source, applicability, an owner and a status. The missing column is the promise. Add it, sort by it, and the blanks are your obligation debt.

Then look at what status measures. Status is usually implementation. The procedure was written, the training was run, the control was installed. That is a project measure, and it says nothing about whether the thing operates under the conditions you face.

A register built on implementation status will show a mature program on the morning the control stops working.

Who promises

Every obligation has an obligation owner, a named individual with delegated authority and accountability for fulfilment. Promises are made by autonomous (but supervised) agents, and an agent may be a person, a team, or a system able to declare what it will do within its own capability and monitor its own fulfilment.

Accountability does not transfer to the system. When a promise in the register has no person behind it, the review after a failure ends with a description of what the equipment did.

Try this

Pick one obligation. Walk it.

What does it require, and is it rules, practice, performance or outcome based. What have you promised, and who owns it. Can the organization operate that promise today. What does Check measure, and does it reach past conformance. What is this management level allowed to change when the promise is missed.

Documentation shows intent. Only operations deliver outcomes.