Skill Hub — Productivity and Execution Control

Delivery Checklist Management Working Skill

Build and maintain a delivery checklist that confirms every prerequisite is complete, every risk is addressed, and every stakeholder is ready before a milestone is declared done.

What this skill is for

Projects go live with missing prerequisites because no one checked systematically. A transport is imported but the authorization role was never updated. A report is delivered but the user training was skipped. A data migration is declared complete but the reconciliation was never run. This skill prevents those failures by creating a Delivery Checklist: a structured list of prerequisites, verifications, and approvals that must be satisfied before a milestone is declared complete. The checklist is not a generic template; it is built for the specific milestone based on the work packages, risks, and stakeholders involved. It is reviewed and signed off by the people who have the authority to say yes. The checklist turns a subjective "I think we are ready" into an objective "These 12 items are all green."

When to use this skill

A project phase, sprint, or release is approaching its end and the team must confirm readiness.
A system change, configuration update, or data migration is scheduled for production deployment.
A deliverable is promised to a stakeholder and the team needs to verify quality before handover.
A go-live or cutover date is set and the project manager needs a structured readiness check.
A previous milestone failed because a prerequisite was missed, and the team wants to prevent recurrence.
An AI agent is validating a delivery and needs a checklist to verify completeness against a standard.

Real work situations

SAP go-live: missing transport sequence

An SAP project team prepares for a go-live on Friday. The configuration is complete in the test system. The transport request is created. On Friday morning, the import to production fails because a prerequisite transport was never released from development. The team spends six hours reconstructing the sequence. The go-live is delayed to Saturday. A Delivery Checklist would have included an item: "All prerequisite transports are released and documented in the transport sequence document." The item would have been checked on Wednesday, the gap would have been found, and the go-live would have proceeded on schedule.

Integration deployment: untested error handling

A team deploys a new API integration between SAP and a warehouse management system. The happy path is tested. The deployment checklist says "Integration tested." It does not specify what "tested" means. In production, an invalid material number causes an unhandled error that crashes the middleware. The error handling was never tested because the checklist had no item for it. A Delivery Checklist would have included: "Error handling tested for invalid material, missing customer, and timeout scenarios." The team would have found the gap before go-live.

Report delivery: incomplete user documentation

A business intelligence team delivers a new management report to the finance department. The report runs correctly. The checklist marks it complete. The finance team tries to use it and discovers that the parameter definitions are not documented, the refresh schedule is not explained, and the data sources are not listed. The report is rejected. A Delivery Checklist would have included: "User documentation includes parameter definitions, refresh schedule, data sources, and known limitations." The documentation would have been completed and reviewed before delivery.

Inputs required

Milestone definition: what is being delivered, to whom, and by when.
Work Breakdown Structure or task list showing all work packages that feed into the milestone.
Quality checklist from each work package showing what was verified and what was not.
Risk register showing risks that could prevent a successful delivery.
Stakeholder list showing who must approve or accept the deliverable.
Environment and system details: clients, systems, transports, versions, and configurations involved.
Historical data from previous deliveries showing what was missed and what caused failure.
Regulatory or compliance requirements that must be satisfied before delivery (optional).

Questions to ask

What is the minimum set of conditions that must be true for this milestone to be considered successful?
What was missed in the last similar delivery, and how do we prevent it this time?
Who has the authority to approve each item on the checklist?
What must be verified in the target environment, not just in the development environment?
What happens if we go live without this item being complete?
What documentation must the user or operator have to use the deliverable correctly?
What rollback or recovery plan is needed if the delivery fails?
What is the last responsible moment to check each item before the deadline?

Working method

Define the milestone. State what is being delivered, to whom, by what date, and in what environment. If the milestone is vague, clarify it before building the checklist.
Identify the categories of readiness. Group checklist items into categories: technical readiness, data readiness, configuration readiness, testing readiness, documentation readiness, user readiness, operational readiness, and sign-off readiness. This ensures no category is forgotten.
Derive items from the WBS. For each work package that feeds into the milestone, define the prerequisite that must be verified. Example: if the WBS includes "credit management configuration," the checklist item is: "Credit management configuration is active in target client and verified with test customer."
Derive items from risks. For each risk in the risk register, define a verification that confirms the risk is mitigated. Example: if the risk is "API timeout under load," the checklist item is: "Load test confirms API response time under 2 seconds at 100 concurrent requests."
Derive items from history. For each failure or near-miss from a previous delivery, define a checklist item that prevents recurrence. Example: if the last go-live failed due to missing authorization, the item is: "All required authorization roles are transported and tested in the target client."
Define the verification method for each item. State how the item will be checked: inspection, test, log review, sign-off, or document review. An item without a verification method is a wish, not a checklist entry.
Assign an approver for each item. Name the person who has the authority to mark the item complete. If the approver is a role, name the person currently in that role.
Sequence the items by dependency. Some items must be checked before others. Order the checklist so that prerequisites are verified first. Example: system access must be checked before configuration testing.
Define the last responsible moment. For each item, state the latest date by which it must be checked to allow time for remediation if it fails.
Review the checklist with stakeholders. Walk through the checklist with the project sponsor, the technical lead, and the business owner. Confirm that every item is necessary and that no item is missing. Update the checklist based on feedback.
Execute the checklist. Check each item in sequence. Record the result, the evidence, and the approver. If an item fails, stop the checklist, remediate, and re-check. Do not proceed to the next milestone item until the current one is green.
Sign off the checklist. When all items are green, the milestone owner signs the checklist. The signed checklist is evidence of readiness. It is stored with the project records.

Decision rules

If an item has no verification method, it is not a checklist item. Define the method or remove it.
If an item has no approver, it is not a checklist item. Assign an approver or remove it.
If an item fails, the checklist stops. Remediate and re-check before proceeding.
If a failed item cannot be remediated by the milestone date, the milestone is delayed or the item is removed from scope with a change log entry.
If an item is waived, record the waiver with a reason, a risk assessment, and the authority who approved the waiver.
If the checklist is shorter than five items, it is probably incomplete. Review against the WBS and risk register.
If the checklist is longer than 30 items, it may be too granular. Group related items into a higher-level verification.

Deliverables

Delivery Checklist — Structured list of readiness items with categories, verification methods, approvers, sequence, last responsible moments, and results. See template below.
Evidence Package — Collection of test logs, screenshots, sign-off documents, and configuration exports that prove each checklist item was verified.
Sign-Off Record — Document showing who approved the checklist and when, with any waivers recorded.

Templates

Delivery Checklist (compact)

---
artifact: Delivery Checklist
milestone: <name>
target_date: YYYY-MM-DD
environment: <system / client>
status: draft | in review | executing | complete | waived
---

## Technical readiness
| ID | Item | Verification | Approver | Last responsible moment | Result | Evidence | Notes |
|----|------|--------------|----------|------------------------|--------|----------|-------|
| CL-001 | <Prerequisite> | <How to check> | <name> | YYYY-MM-DD | pass | <reference> | <notes> |
| CL-002 | <Prerequisite> | <How to check> | <name> | YYYY-MM-DD | pass | <reference> | <notes> |

## Data readiness
| ID | Item | Verification | Approver | Last responsible moment | Result | Evidence | Notes |
|----|------|--------------|----------|------------------------|--------|----------|-------|
| CL-003 | <Prerequisite> | <How to check> | <name> | YYYY-MM-DD | pass | <reference> | <notes> |

## Testing readiness
| ID | Item | Verification | Approver | Last responsible moment | Result | Evidence | Notes |
|----|------|--------------|----------|------------------------|--------|----------|-------|
| CL-004 | <Prerequisite> | <How to check> | <name> | YYYY-MM-DD | pass | <reference> | <notes> |

## Documentation readiness
| ID | Item | Verification | Approver | Last responsible moment | Result | Evidence | Notes |
|----|------|--------------|----------|------------------------|--------|----------|-------|
| CL-005 | <Prerequisite> | <How to check> | <name> | YYYY-MM-DD | pass | <reference> | <notes> |

## Sign-off
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Project sponsor | <name> | YYYY-MM-DD | <signature> |
| Technical lead | <name> | YYYY-MM-DD | <signature> |

## Waivers
| ID | Item | Reason | Risk | Approved by | Date |
|----|------|--------|------|-------------|------|
| — | — | — | — | — | — |

Quality checklist

Every item is derived from a work package, a risk, or a historical failure.
Every item has a defined verification method that produces evidence.
Every item has a named approver with the authority to sign off.
Items are sequenced by dependency: prerequisites are checked first.
Every item has a last responsible moment that allows time for remediation.
Failed items are remediated and re-checked before the milestone proceeds.
Any waived items are documented with a reason, risk assessment, and approver.
The checklist is reviewed with stakeholders before execution.
The checklist is signed off by the milestone owner when complete.
The evidence package is stored with the project records.

Common mistakes

Copying a generic checklist without tailoring it to the milestone. Consequence: irrelevant items waste time, and critical items specific to this delivery are missing. The checklist gives false confidence.
Treating the checklist as a formality to be filled after the milestone. Consequence: the checklist is completed from memory, not from verification. Failed items are not discovered until production fails.
Defining items without verification methods. Consequence: an item says "integration is stable" with no definition of what stable means. The approver guesses and signs off. The integration fails in production.
Assigning approvers who are not accountable. Consequence: a junior analyst is asked to approve a configuration change they do not understand. They sign to avoid conflict, and the error is not caught.
Proceeding with a failed item because the deadline is near. Consequence: the known risk is accepted implicitly instead of explicitly. When the risk materializes, there is no record of the decision to accept it, and accountability is diffuse.

Weak output vs Strong output

Weak output

A mental note: "We tested everything, the documentation is there, the users know about it. Let's go live." No written checklist, no evidence, no named approvers, no sequence. The team proceeds on collective optimism. When something fails in production, no one can say what was checked or who approved it. The post-mortem is a blame exercise because there is no record of the readiness check.

Why it fails: The readiness check is invisible and unaccountable. It relies on memory and assumption. It cannot be audited, repeated, or improved. The team learns nothing from success or failure because there is no evidence of what was done.

Strong output

---
artifact: Delivery Checklist
milestone: O2C Credit Management — Test Environment Ready
target_date: 2026-06-16
environment: S/4 Test Client 300
status: complete
---

## Technical readiness
| ID | Item | Verification | Approver | Last responsible moment | Result | Evidence | Notes |
|----|------|--------------|----------|------------------------|--------|----------|-------|
| CL-101 | Credit management config transported to client 300 | Import log in STMS shows success | Maria Chen | 2026-06-14 | pass | STMS log DEVK123456 | — |
| CL-102 | RFC destination for credit check is active | SM59 connection test passes | Dmitri Volkov | 2026-06-14 | pass | SM59 screenshot | — |
| CL-103 | Authorization roles for credit team are active | SUIM role comparison shows no gaps | Basis lead | 2026-06-14 | pass | SUIM report | — |

## Data readiness
| ID | Item | Verification | Approver | Last responsible moment | Result | Evidence | Notes |
|----|------|--------------|----------|------------------------|--------|----------|-------|
| CL-201 | Test customer C-10001 has credit limit 50,000 EUR | XD03 shows limit 50,000 | Sarah Okafor | 2026-06-15 | pass | XD03 screenshot | — |
| CL-202 | Test customer C-10002 has open orders at 48,000 EUR | VA05 shows open order value | Sarah Okafor | 2026-06-15 | pass | VA05 export | — |

## Testing readiness
| ID | Item | Verification | Approver | Last responsible moment | Result | Evidence | Notes |
|----|------|--------------|----------|------------------------|--------|----------|-------|
| CL-301 | Positive path: order below limit proceeds | VA01 creates order with status Open | Maria Chen | 2026-06-15 | pass | Test log TS-101-POS | — |
| CL-302 | Negative path: order above limit is blocked | VA01 creates order with status Credit block | Maria Chen | 2026-06-15 | pass | Test log TS-101-NEG | — |
| CL-303 | Error handling: invalid customer is rejected | Order creation fails with correct message | Maria Chen | 2026-06-15 | pass | Test log TS-101-ERR | — |

## Documentation readiness
| ID | Item | Verification | Approver | Last responsible moment | Result | Evidence | Notes |
|----|------|--------------|----------|------------------------|--------|----------|-------|
| CL-401 | Configuration guide updated with credit procedure | Document reviewed by peer | Dmitri Volkov | 2026-06-15 | pass | Doc v1.2 | — |
| CL-402 | User guide for credit team updated | Guide reviewed by credit team lead | Sarah Okafor | 2026-06-15 | pass | Guide v1.1 | — |

## Sign-off
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Project sponsor | Anna Kowalski | 2026-06-15 | AK |
| Technical lead | Maria Chen | 2026-06-15 | MC |

## Waivers
| ID | Item | Reason | Risk | Approved by | Date |
|----|------|--------|------|-------------|------|
| — | — | — | — | — | — |

Agent instructions

AI Prompt Pattern

Role: Delivery checklist manager for enterprise project milestones.

Context: You have a milestone definition, a Work Breakdown Structure, a risk register, and historical data from previous deliveries. You need to build a Delivery Checklist that verifies readiness before the milestone is declared complete.

Task: Derive checklist items from the WBS, risks, and history. Organize them by category. Define verification methods, approvers, sequence, and last responsible moments. Execute the checklist and record results.

Output format: Structured Delivery Checklist per the template, followed by an evidence package summary and a sign-off record.

Never use a generic checklist without tailoring. Every checklist must be derived from the specific WBS, risks, and history of this milestone.
Every item must have a verification method. An item without a method is a wish, not a checklist entry.
Every item must have a named approver. The approver must have the authority and knowledge to verify the item.
Sequence items by dependency. Prerequisites first. Do not check user readiness before technical readiness is confirmed.
Stop on failure. If an item fails, do not proceed. Remediate and re-check.
Record waivers explicitly. If an item is skipped, document the reason, risk, and approving authority.
Do not invent verification results. Only mark an item pass if you have evidence. If evidence is missing, flag the item as pending.
Store the evidence package with the project records. The checklist without evidence is not proof of readiness.
Link to Atlas diagnostics when checklist items involve SAP technical verification. Reference the relevant diagnostic page for the verification method.

Related skills

Work Breakdown Planning Working Skill — Use to create the WBS that feeds into the checklist.
Follow-Up Tracking Working Skill — Use to track checklist items that depend on external commitments.
Risk-Dependency Mapping Working Skill — Use to identify risks that become checklist items.
Test Scenario Derivation Working Skill — Use to derive testing checklist items from requirements.

Related Atlas pages

SAP Credit Management Diagnostics — Verification context for credit management readiness checklists.
SAP IDoc Status Diagnostics — Verification context for integration readiness checklists.

Verification status and limitations

This skill is a public working interpretation of delivery checklist practices. It is not official PMP, ITIL, or SAP go-live methodology. It focuses on practical readiness verification for enterprise milestones where missing prerequisites cause production failures and rework.

Known limitations: the skill assumes the WBS and risk register are available. It does not cover automated deployment pipelines, continuous delivery, or infrastructure-as-code verification. For organizations with mature DevOps practices, the checklist may be partially automated. The skill treats the checklist as a human-verified artifact, not a machine-generated report. For regulated industries, additional compliance checks and audit trails may be required beyond the scope of this skill.