“How do we carry one project issue from evidence to an accountable decision?”
Give the issue a governed evidence base, connect it to affected work, assign review and decision authority, and verify that the approved response was implemented. The workflow and record below make those handoffs visible.
Our One Management Truth series examines AI adoption, early intelligence and maturity. Together, these dilemmas point toward a practical commitment in our own work: make the path from principle to execution easier to inspect and apply.
Every step should make six things visible: what starts it, what it needs, who acts, what is checked, what leaves it and what happens when requirements are not met.
That last question matters. A workflow that only shows the successful path leaves the team to improvise precisely when control is most needed.
One workflow, from revision to accountable action
Illustrative example. An equipment requirement may change before a purchase release. The workflow below shows the checks and handoffs; it does not assume that the suggested change is approved.
- 1
Step 1: Register
- Responsible role and input
- Reviewer receives a permitted message or revision.
- Check / output / return path
- Create an issue record with package ID, source status, uncertainty, owner and last useful response date.
- 2
Step 2: Establish the governing basis
- Responsible role and input
- Document controller and technical lead examine issued records.
- Check / output / return path
- Check authority, version and context. Missing or conflicting records return for clarification; a concern may remain open without becoming approved scope.
- 3
Step 3: Connect exposure
- Responsible role and input
- Procurement and controls identify linked commitments and activities.
- Check / output / return path
- Record procurement status, affected quantities/resources, schedule logic, forecast and risk exposure. Unmapped links remain explicit gaps.
- 4
Step 4: Review options
- Responsible role and input
- Technical, procurement and controls leads prepare an assessment.
- Check / output / return path
- Compare options, assumptions, uncertainty, cost of waiting and limits of authority. Apply model assurance if predictions are used.
- 5
Step 5: Decide
- Responsible role and input
- Named approver reviews the evidence and options.
- Check / output / return path
- Record decision, conditions, rationale and implementation owner. Escalate beyond delegated authority; AI may assist but cannot grant approval.
- 6
Step 6: Implement
- Responsible role and input
- Assigned owners issue authorized instructions and update records.
- Check / output / return path
- Reconcile scope, procurement, schedule forecast, cost and risk records. Change the baseline only through the applicable approval process.
- 7
Step 7: Close and learn
- Responsible role and input
- Case owner verifies completion; reviewer checks outcomes.
- Check / output / return path
- Link execution evidence, residual risks and outcome-review date. Reopen if instructions were not implemented or records disagree.
In the worked example in our Early Intelligence article, an authorized temporary hold creates time for clarification. After clarification and the required change approval, the team updates the purchasing instruction and linked records. Closure requires evidence of implementation, not merely a recorded decision.
How the management areas connect
| Management question | Connected areas |
|---|---|
| What requirement and acceptance condition changed? | Scope / Quality |
| Which supplier or contractual commitment is affected? | Procurement |
| Which activities, sequence and capacity are affected? | Schedule / Resources |
| What happens to the forecast and exposure? | Cost / Risk |
| Who authorizes the response, and who must receive it? | Integration / Stakeholders / Communications |
Management questions and the areas each one connects.
- Management question
- What requirement and acceptance condition changed?
- Connected areas
- Scope / Quality
- Management question
- Which supplier or contractual commitment is affected?
- Connected areas
- Procurement
- Management question
- Which activities, sequence and capacity are affected?
- Connected areas
- Schedule / Resources
- Management question
- What happens to the forecast and exposure?
- Connected areas
- Cost / Risk
- Management question
- Who authorizes the response, and who must receive it?
- Connected areas
- Integration / Stakeholders / Communications
The point is to carry the same governed basis through these handoffs, rather than assessing each area in isolation.
Methods behind the workflow
Our design uses several distinct references rather than treating them as a single standard:
- Suppliers, Inputs, Process, Outputs and Customers (SIPOC) is a mapping technique for inputs and handoffs.
- Integration Definition for Function Modeling (IDEF0), documented in the historical NIST FIPS PUB 183 (1993), distinguishes inputs, controls, outputs and mechanisms. We use it as a modeling reference, not a claim of current FIPS compliance.
- Entry, Task, Verification and Exit (ETVX) is a checklist structure for defining work and completion conditions.
- OMG Business Process Model and Notation (BPMN) 2.0.2 is a process notation specification that informs how we show decisions and return paths.
- International Business Communication Standards (IBCS) provides a visual communication reference. The illustrations are not presented as certified or independently assessed for conformance.
The workflow below is our synthesis: what starts the work, what it needs, who acts, what is checked, what leaves it and where an exception returns.
A reusable decision record
Copy these fields into the team's existing record or workflow. Complete names and criteria for the specific project; this is a working template, not a certification checklist.
| Field | What to record |
|---|---|
| Case and trigger | Project, work-package ID, trigger, received date and as-of date. |
| Governing evidence | Source, authority for this use, version, context and unresolved conflicts. |
| Decision window | Last useful response date and consequence of waiting. |
| Exposure and options | Linked scope, quality, procurement, resources, schedule, cost and risk; options and uncertainties. |
| Authority and capacity | Reviewer, competent backup, approver, delegation limit and escalation route. |
| Decision and rationale | Chosen action, rejected options, assumptions, conditions and approval record. |
| Execution and closure | Instruction owner, due date, affected records, completion evidence and residual risk. |
| Outcome review | Baseline/comparator, accepted-response time, review/correction effort, observed result, interventions and limits on attribution. |
Decision record fields — a working template, not a certification checklist.
- Field
- Case and trigger
- What to record
- Project, work-package ID, trigger, received date and as-of date.
- Field
- Governing evidence
- What to record
- Source, authority for this use, version, context and unresolved conflicts.
- Field
- Decision window
- What to record
- Last useful response date and consequence of waiting.
- Field
- Exposure and options
- What to record
- Linked scope, quality, procurement, resources, schedule, cost and risk; options and uncertainties.
- Field
- Authority and capacity
- What to record
- Reviewer, competent backup, approver, delegation limit and escalation route.
- Field
- Decision and rationale
- What to record
- Chosen action, rejected options, assumptions, conditions and approval record.
- Field
- Execution and closure
- What to record
- Instruction owner, due date, affected records, completion evidence and residual risk.
- Field
- Outcome review
- What to record
- Baseline/comparator, accepted-response time, review/correction effort, observed result, interventions and limits on attribution.
The forthcoming workflow series
Our publication plan includes dozens of workflows and illustrations from our Integrated Project Controls work, organized across P1–P6 and strategic decision support (SD). Lessons will be released in stages as they are completed:
P1P1 — Control System Architecture
What the practical lessons will explore: How the Project Controls Plan connects its instruments, responsibilities and control points.
P2P2 — Master Coding & Shared Project Identity
What the practical lessons will explore: How common identity connects records and preserves meaning across systems.
P3P3 — Multidimensional Project Control
What the practical lessons will explore: How scope, quantities, time, resources, cost and actual performance relate.
P4P4 — Governed AI in Project Controls
What the practical lessons will explore: Where AI can assist, what evidence it needs and how permissions and review constrain its actions.
P5P5 — Evidence, RFI & Decision Architecture
What the practical lessons will explore: How a possible concern becomes a reviewed finding, a decision brief and an accountable response.
P6P6 — Economics of Control
What the practical lessons will explore: How timing, review effort, delayed decisions and intervention affect the value of control.
SDSD — Strategic Decision Support
What the practical lessons will explore: How to define a decision, examine evidence and options, communicate uncertainty, act and review outcomes.
Each lesson will start with a management question, show a concrete workflow or relationship, identify its limits and end with a check readers can apply to their own projects.
For example, “A Schedule Is Not Enough” examines the Project Controls Plan as the architecture and the schedule, budget, risk register and other records as its instruments. Its practical question is simple: who checks that they reflect the same approved basis?
The illustrations will show how responsibilities, information and decisions connect. They will distinguish illustrative scenarios from observed results and developing capabilities from established practice.
A practical starting point for collaboration
As a technology-enabled, senior-led Project Controls and decision-support consultancy, xPM works from the project decision and the capabilities already in place. A useful starting point is one real workflow. Bring the project question and the capabilities already in place; together, we can examine where evidence, responsibilities and decisions stop connecting—and whether there is a useful role for xPM.
That discussion can draw on project knowledge, controls expertise, experience with the team's existing systems or implementation experience. The shared objective is a workable decision process. Before any joint test, agree on the responsibilities, permitted data access, acceptance criteria and review boundary. A first scoped output could be a reviewed workflow and gap record; wider deployment depends on what the test establishes.
Continue the series
Structure First. Integration Second. Intelligence Third. Accountability Always.
AI can inform the decision. It does not own it.