Decision record
The SHAMS Method / From discovery to delivery
Before the meeting.
Beyond the handover.
I have to live with what I sell. Here is how I prepare for the room, turn uncertainty into a scope someone can approve, and stay accountable for the architecture through delivery and operation.
A free working reference for architects, client teams and practice leaders.
One decision, carried through
- UnderstandAudience · workflow · evidence
- CommitOptions · scope · assumptions
- DeliverDesign authority · acceptance
- OperateOwnership · outcomes · learning
01 · The engagement
A specific problem. A visible boundary.
A field-service company receives requests through email and PDFs. Estimators reconcile them with ERP records, route exceptions through an approval queue and assemble reports from disconnected sources. I work through a proposed design that makes the evidence, commercial commitment and delivery responsibility visible together.
Worked design · illustrative organization and inputs
A quote the team can stand behind
This is a solution I designed to make my approach inspectable. It is not a historical client engagement, a live deployment or a claim of measured savings.
The business question: can the team prepare a reliable quote with fewer repeated handoffs, while keeping pricing and dispatch authority with the people responsible?
D-01 · Proposed pilot boundary
Prepare a quote draft from permitted, current source records. A named, authorized person approves the exact draft. The pilot ends there. Sending and dispatch stay in the existing authorized workflow.
- Success evidence
- Compare accepted drafts, rework, elapsed time and total handling effort against an observed baseline.
- Observed results
- Not measured. Baselines and thresholds must be agreed with the actual process owner.
Read the first meeting agenda
- Before the call: confirm participants, decision rights, business model, current tools and the question the meeting must resolve. Send a short pre-read. Mark hypotheses as hypotheses.
- First 10 minutes: ask the sponsor what decision is needed, then ask the operator to walk one ordinary request and one exception.
- Next 20 minutes: map handoffs, source records, permission boundaries and the baseline. Invite disagreement from security and delivery.
- Next 15 minutes: compare process improvement, deterministic automation and a bounded AI-assisted pilot. Demonstrate only the uncertain part, with approved or synthetic data and a failure path.
- Final 15 minutes: read back the decision, exclusions, unknowns, owners and next evidence request. Issue a decision note for correction before treating it as agreed.
An example 60-minute agenda, adapted to the people and decision in the room.
02 · Work the decision
Change the room.
Keep the facts.
Choose who you are speaking to, then change a requirement. The audience changes the explanation. A changed requirement changes the scope, estimate, verification and operating responsibility together.
- Ask
- Show
- Decision to seek
This audience framing describes D-01. Apply the current change assessment below before seeking any commitment.
D-01 · Current planning position
Scope / change record
What is actually included?
Acceptance record
What must be demonstrated?
Operating record
Who catches the exception?
Illustrative planning envelope
Sample labor rate: $150 USD/hour. Explicit 15% contingency. Software, cloud usage, licenses, tax and customer effort are excluded. These are teaching assumptions, not vendor prices, a quote from me or the $950 Architecture Decision Review.
| Role | Low | High |
|---|
The exercise runs in your browser. It creates no client case, submits no inquiry and makes no cloud or model call. Shareable page choices contain only the selected audience and example condition.
Read all four audience briefs
Executive sponsor
I am proposing a bounded way to help estimators prepare quotes with clearer evidence and accountability. I am not promising faster turnaround until we measure it.
- Ask
- Which delay matters enough to address, and who can authorize the investment?
- Show
- The current handoffs, proposed pilot boundary, effort range, dependencies and evidence required for a continuation decision.
- Decision
- Sponsor discovery and a bounded pilot. Keep approval, sending and dispatch with authorized people.
Engineering team
The proposed service reads approved sources, prepares a draft and records a human decision. It does not acquire permission to send quotes or dispatch work.
- Ask
- Can we preserve source identity, access boundaries and reproducible calculations across every draft revision?
- Show
- The data contract, read-only ERP adapter, deterministic pricing calculation, versioned draft and approval state machine.
- Decision
- Validate the integration and evaluation design before estimating an implementation as ready to build.
Risk and assurance
A plausible answer is insufficient. Every material quote detail needs an allowed source, and the software cannot approve its own work.
- Ask
- What evidence proves that unauthorized access, stale prices and bypassed approvals fail safely?
- Show
- The threat review, source permissions, retention plan, negative tests, approval record and revocation procedure.
- Decision
- Accept the bounded pilot only after its controls are demonstrated and residual risks have named owners.
Operations team
The draft should make an estimator's work easier to check. Missing information enters an owned queue instead of becoming a confident guess.
- Ask
- Who handles an incomplete request, a rejected draft or an unavailable source during a busy shift?
- Show
- The exception queue, source links, approval handoff, existing send process, support runbook and fallback workflow.
- Decision
- Agree ownership and rehearse the exception paths before people depend on the pilot.
03 · The complete workflow
Every stage leaves something the next person can use.
Follow the worked pilot from account preparation through delivery and practice growth. Open each artifact to see the actual questions, boundaries and handoff. Roles below describe responsibilities; an organization must assign named people and approval authority. These stages describe the original bounded pilot. Changed requirements above must be resolved before affected stages proceed.
01
Scope
Prepare before the first conversation
I prepare around the decision the business needs, not a product demonstration. I separate what I know from what I need to ask, then make the meeting useful for the people attending.
What I do
- Research the service model, request channels, current systems and likely business constraints.
- Identify the sponsor, estimator, ERP owner, security reviewer and delivery decision makers.
- Send a short agenda, evidence request and proposed decision for the session.
Inspect the artifact: Preparation brief
Worked example · D-01
- Known scenario: email and PDF intake, ERP records, an approval queue and fragmented reporting.
- Hypothesis to test: repeated reconciliation contributes more delay than drafting the response.
- Request: approved sample requests, workflow walk-through, access constraints and available timing data.
- Meeting outcome: agree the problem, owner and evidence needed before proposing a build.
- Accountable role
- Engagement architect
- Ready to move when
- The meeting has an accountable sponsor, a decision and the right operational voices.
- Hold when
- Do not assume a bottleneck or prepare a production promise from public research alone.
02
Scope
Know the room and change the explanation
I explain the same proposal differently to each audience. The sponsor needs the investment decision; the estimator needs the changed work; engineering and assurance need the boundaries they must prove.
What I do
- Confirm who decides, who advises, who operates and who can stop release.
- Open with the audience's question, then offer the supporting technical depth.
- Ask each group to explain the proposed boundary back in their own words.
Inspect the artifact: One decision, four views
Worked example · D-01
- D-01 remains constant: source-backed draft, named approval, human sending and dispatch.
- Sponsor: is a bounded pilot worth the effort and operational attention?
- Engineering and risk: can the draft be traced, constrained and independently checked?
- Operations: who owns the queue when a request cannot proceed?
- Accountable role
- Engagement architect with the customer sponsor
- Ready to move when
- The groups agree what is being decided and can identify their own responsibility.
- Hold when
- Resolve conflicting expectations before an audience-specific explanation becomes a different promise.
03
Scope + Measure
Observe the work and establish a baseline
I follow a request through the real handoffs before designing a replacement. I need to understand the exceptions, data ownership and existing controls as well as the happy path.
What I do
- Walk through intake, clarification, pricing, approval, sending and dispatch with their owners.
- Map source permissions, freshness, document quality and the authority for price changes.
- Agree how to measure preparation time, rework, approval waits and operating cost.
Inspect the artifact: Current-state evidence map
Worked example · D-01
- Request PDF → estimator → ERP lookup → approval queue → human send → dispatch team.
- Unresolved: which ERP fields are authoritative and whether request timestamps are reliable.
- Baseline: not measured. Record preparation time separately from time awaiting customer clarification.
- Process-only alternative: improve the intake form and queue ownership before adding AI.
- Accountable role
- Operations process owner and data owners
- Ready to move when
- The team agrees the workflow, evidence gaps, baseline method and decision to investigate.
- Hold when
- No savings claim or automation recommendation without a usable baseline and source ownership.
04
Harden + Anchor
Design the boundary before the assistant
I compare a better process, conventional automation and an assisted draft. The design earns its complexity only if it improves the work while keeping authority, evidence and recovery clear.
What I do
- Define the Azure foundation, identity boundaries, environment separation and read-only integration.
- Plan governed ingestion, OneLake ownership, Fabric workspaces, reporting and capacity assumptions.
- Evaluate Copilot Studio and Foundry against channel, integration, ownership and operational requirements.
Inspect the artifact: D-01 architecture decision
Worked example · D-01
- Email/PDF intake → controlled extraction → allowed ERP retrieval → draft → named human approval.
- Price arithmetic uses validated ERP values and deterministic rules; missing values stop the draft.
- Draft evidence includes source, revision and retrieval time. Document instructions are untrusted input.
- Software identities cannot send, dispatch or approve. A revised draft requires fresh approval.
- Platform choice remains conditional on a validated integration and operational fit.
- Accountable role
- Design authority with security, data and integration owners
- Ready to move when
- The chosen option has a recorded trade-off, threat review and testable boundary.
- Hold when
- Pause if source permissions cannot be preserved or human approval can be bypassed.
05
Scope + Measure
Turn the design into an honest commitment
I estimate the work as a set of deliverables and dependencies. The technical scope, commercial approval and customer acceptance belong to named roles, with uncertainty visible before anyone commits.
What I do
- Write the SOW with deliverables, exclusions, role effort, milestones and acceptance evidence.
- Validate delivery capacity, licensing, environments and access before promising dates or prices.
- Record assumptions and route scope changes through impact assessment and written approval.
Inspect the artifact: Illustrative pilot SOW
Worked example · D-01
- Included: one intake route, one read-only ERP adapter, draft review queue, reporting and handover.
- Excluded: automatic sending, dispatch, ERP writes, broad data cleanup and additional business units.
- Estimate by role and work package, with low and high person-hours, dependencies and contingency shown separately. The interactive planning envelope above carries the current example values.
- Dependencies: approved samples, API access, available reviewers, capacity and licensing confirmation. Effort is illustrative, not elapsed duration or a quote.
- Change example: adding an ERP write requires revised controls, effort and acceptance before approval.
- Accountable role
- Technical scope owner, delivery lead and commercial approver
- Ready to move when
- Customer and supplier approve the scope, commercial terms, dependencies and acceptance process.
- Hold when
- Do not absorb unapproved scope or turn a planning range into an unconditional deadline.
06
Anchor + Measure
Prove the uncertain part in a rehearsal
I use a bounded rehearsal to test the riskiest assumptions. A convincing demonstration needs a failure path and clear limitations, otherwise it can sell a level of readiness the team has not earned.
What I do
- Prepare approved or synthetic examples with expected results and source permissions.
- Rehearse missing prices, stale records, conflicting documents and embedded malicious instructions.
- Let the estimator reject a draft and explain what happens next.
Inspect the artifact: Rehearsal script
Worked example · D-01
- Normal case: draft cites allowed request and ERP records; the estimator checks its calculation.
- Missing price: hold for clarification, with no invented amount or silent fallback.
- Injected instruction: treat PDF text as evidence, never as authority to change permissions.
- Proof required: approval cannot be self-issued and no send or dispatch operation exists.
- Accountable role
- Technical lead and estimator representative
- Ready to move when
- The evidence supports continuing, changing the design or stopping, with limitations recorded.
- Hold when
- A passing rehearsal does not establish production reliability, savings or deployment readiness.
07
Harden + Sustain
Keep the build aligned with what was agreed
I keep design authority through delivery while the delivery lead owns planning and execution. We review risks together and make changes visible before they become customer surprises.
What I do
- Assign work to platform, data, application and quality owners with explicit interfaces.
- Review architecture decisions, pull requests, control evidence and deviations on a regular cadence.
- Escalate a breached assumption with impact, options, recommendation and the next customer update.
Inspect the artifact: Delivery decision record
Worked example · D-01
- Design authority: architecture integrity and exceptions. Delivery lead: plan, resources and dependencies.
- ERP delay: describe the blocked work, re-sequencing option and effect on the agreed milestone.
- Customer update: what changed, who owns resolution, the decision needed and when we report again.
- Every scope change links back to D-01, its estimate and its acceptance evidence.
- Accountable role
- Design authority and delivery lead
- Ready to move when
- The implemented scope has review evidence and no hidden exceptions to the agreed boundary.
- Hold when
- Stop affected work when an access, safety or scope breach cannot be contained.
08
Harden + Measure
Make readiness a decision with evidence
I make release readiness explicit. The customer should see what passed, what remains uncertain and who accepts the residual risk, including the practical route back to the existing workflow.
What I do
- Run authorization, source isolation, approval replay and stale-data tests against the release candidate.
- Verify operational monitoring, retention, cost limits and recovery with the responsible owners.
- Walk the sponsor through acceptance evidence and the remaining risks before release approval.
Inspect the artifact: Pilot release gate
Worked example · D-01
- Required: allowed sources only, reproducible calculations, revision-bound approval and attributable audit events.
- Required: failure paths route to an owned queue; sending and dispatch remain outside the pilot.
- Fallback: disable new draft creation and return requests to the established estimator workflow.
- Decision record: release version, evidence, residual risks, named approvers and recovery owner.
- Accountable role
- Customer release approver with security and operations owners
- Ready to move when
- Authorized owners accept the evidence and the team has rehearsed the fallback.
- Hold when
- An unresolved authorization failure or missing operational owner blocks release.
09
Measure + Sustain
Measure the work after the demonstration
I compare observed work with the agreed baseline. A shorter draft time is not enough if review effort, errors or operating cost increase. The continuation decision should use the whole workflow.
What I do
- Track preparation time, correction rate, queue age, adoption, availability and cost per reviewed request.
- Review source freshness, incident patterns, access changes and capacity with operational owners.
- Decide whether to continue, adjust or retire the pilot using recorded evidence.
Inspect the artifact: Outcome review
Worked example · D-01
- Baseline and observed results: not measured in this design exercise.
- Proposed comparison: similar request types, the same measurement definitions and a declared observation period.
- Record preparation and approval waits separately; distinguish assisted requests from requests handled manually.
- Keep business outcomes, platform consumption and commercial commitments as separate measures.
- Accountable role
- Operations owner with the sponsor and service owner
- Ready to move when
- The next investment decision has evidence, limitations and a responsible decision maker.
- Hold when
- Do not claim attributable savings from adoption counts, a demonstration or incomplete timing data.
10
Sustain
Leave a team that can own the system
I build enablement into the engagement from the first workshop. Handover is complete when another person can explain the boundaries and handle an exception, not when I have sent a document.
What I do
- Pair an architect or operator with preparation, delivery reviews and customer conversations.
- Use shadowing, teach-back and a short debrief to turn observation into independent judgment.
- Provide runbooks, decision history, access procedures and an owned improvement backlog.
Inspect the artifact: Shadow, explain, operate, teach
Worked example · D-01
- Prepare: learner states the audience, decision and risks before the session.
- Debrief rubric: accurate explanation, appropriate depth, clear ownership and honest handling of uncertainty.
- Operate: learner handles a missing source, rejected draft and fallback using the runbook.
- Teach: learner explains why human approval remains necessary and documents the next improvement.
- Accountable role
- Technical mentor and operations enablement owner
- Ready to move when
- The receiving team demonstrates the operating and communication skills it needs.
- Hold when
- Workshop attendance is not proof of competence or a substitute for an accountable service owner.
11
Scope + Sustain
Turn earned evidence into the next opportunity
I make partner collaboration useful to the customer. A joint account plan connects a real need to capable delivery, with customer permission and program eligibility checked before funding or co-sell is presented as available.
What I do
- Align the customer sponsor, account team and partner on the next decision and responsibilities.
- Verify current Microsoft partner, co-sell and funded-engagement requirements for the specific opportunity.
- Reuse sanitized architecture and outcome evidence only with the customer's permission.
Inspect the artifact: Joint account and evidence brief
Worked example · D-01
- Customer need: a next phase supported by measured pilot evidence, not a predetermined expansion.
- Account plan: sponsor, delivery capacity, technical owner, commercial owner and agreed next action.
- Program gate: verify eligibility, application, written approval and conditions before assuming support.
- Reference gate: customer permission, sanitized material and accurate separation of commitments and realized outcomes.
- Accountable role
- Customer sponsor, partner account lead and practice lead
- Ready to move when
- The next pursuit has permission, credible evidence, delivery ownership and a clear commercial path.
- Hold when
- No guaranteed funding, automatic co-sell entitlement or customer reference without permission.
04 · Architecture choices
The platform follows the operating model.
My first alternative is process improvement or ordinary automation. I add AI where evidence shows it improves an uncertain task. Existing ERP, service management and automation platforms retain their responsibilities when they already do the job well.
Intake and identity
Approved mailbox or form. Preserve the original request and its source ID. Authenticate the user; establish customer, role and purpose before retrieving business records.
Azure foundation: separate environments, network boundaries, workload identities, secrets, infrastructure as code and cost owners.
Operational evidence
The ERP remains authoritative for customer, asset, pricing and work-order state. Read through scoped APIs and check freshness. Missing ownership, stale prices or denied access stop the draft.
Fabric can support governed analytical copies. An analytical snapshot is not authority to commit a live price.
Prepare and validate
Extract the requested work and draft a quote with source references. Deterministic rules validate required fields, pricing and policy. Evaluate useful drafts, unsupported claims, refusals and failure cases.
Copilot Studio, Microsoft Foundry or conventional services are alternatives to assess, not a mandatory bundle.
Human decision
A reviewer sees the original request, current facts, uncertainty and proposed quote together. Rejection records a reason. Approval is bound to the exact version and does not grant general write authority.
The worked pilot ends at an approved draft. Sending and dispatch remain in the existing authorized workflow.
Separate measurement path: approved source events → Data Factory ingestion → governed OneLake data → semantic model and operational reporting. Reconcile missing and duplicate events before measuring outcomes.
Fabric decisions I resolve before promising the data layer
Sources and ingestion
Inventory sources and owners. Prove each connector's supported operation, authentication, gateway or network needs, refresh cadence, schema changes and replay behavior. Data Factory surfaces differ; an available connector does not guarantee the required action.
Connector reference →Workspaces and access
Separate makers, operators and consumers. Workspace management permissions and granular data access serve different purposes. Admin, Member and Contributor roles have broad access; do not assign those roles to consumers and expect row filters to restrict them. Test each actual query path.
OneLake security reference →Capacity and licensing
Measure ingestion overlap, query concurrency, peak load, throttling and recovery. Capacity and per-user licensing are different inputs. PPU alone does not provision capacity for non-Power-BI workloads. Check creator and viewer needs before choosing a capacity and commercial commitment.
Capacity and licensing reference →Value and operating cost
Record baseline, target, observed result, measurement window and evidence source separately. Include cloud, licenses, model usage, retries, human review and support in cost per accepted outcome. Leave observed results empty until there is real evidence.
Check the recovery budget →05 · Evidence and continuity
Useful to the client.
Repeatable by the team.
This walkthrough makes my approach visible. My existing work, the detailed technical playbooks and the runtime teaching studio provide different kinds of evidence. A new worked design is not a substitute for a delivered result.
Technical sources and what still needs checking
Primary references checked October 21, 2026. These support product capabilities and architectural considerations. They do not certify this worked design or a particular customer's eligibility.
- Copilot Studio: capabilities and operating model
- Microsoft Foundry: models, agents and controls
- OneLake: management permissions and data access
- Data Factory: connector capabilities
- Fabric: licenses and capacity
- Azure Well-Architected: operational excellence
- Microsoft: co-sell requirements
For any Microsoft engagement funding, verify the current program, partner and customer eligibility, nomination, written approval and delivery evidence requirements with the responsible account and partner teams. Keep a customer-funded plan; funding is conditional. Co-sell readiness and Azure IP co-sell eligibility are different statuses.