Use this checklist before launching a new system or making a major process change. Complete it with the person leading the change, a daily user, and the people whose tasks support the launch.
You will leave with a list of what is ready, what still needs attention, and who will take each next step.
1. Define what this review covers
| Field | What to enter |
|---|---|
| Process and affected roles | Which process are you reviewing? Who does it or receives its results? |
| Launch scope and date | What will change now, and when? What will stay outside this launch? |
| Required result | What should happen when the task is done correctly? |
| Decision owner | Who can approve, reduce, or delay the launch? |
| Essential controls | Which safeguards cannot be skipped? Include required approvals, access limits, and accurate records. |
| Review team and date | Who took part, and when? |
Process and affected roles
- What to enter
- Which process are you reviewing? Who does it or receives its results?
Launch scope and date
- What to enter
- What will change now, and when? What will stay outside this launch?
Required result
- What to enter
- What should happen when the task is done correctly?
Decision owner
- What to enter
- Who can approve, reduce, or delay the launch?
Essential controls
- What to enter
- Which safeguards cannot be skipped? Include required approvals, access limits, and accurate records.
Review team and date
- What to enter
- Who took part, and when?
2. Check the preparations
Choose a status for each check:
- Demonstrated: You tested it and saw the required result.
- Gap: Something needed is missing or does not work.
- Unknown: You have not checked it yet, or the result is unclear.
- Not applicable: This check does not apply. Give a reason the decision owner accepts.
Record what was tested, who checked it, and when. Having a document does not prove that the process works.
| Check | What to look for | Status and test notes |
|---|---|---|
| Required tasks can be completed | Watch a daily user complete key tasks with the access they will normally have. Include rare tasks where a mistake could cause harm. Check the results. | [Status; test; person; date] |
| Required safeguards work | Ask the person in charge to test required approvals, access limits, accurate records, and service rules through the full task. | [Complete] |
| Records and connected systems are ready | Check the needed records, settings, access, and system connections. Compare records and fix mismatches where needed. | [Complete] |
| Each handoff has a clear owner | Confirm that the next person or system accepts the task. Show what happens if a handoff stalls or is rejected. | [Complete] |
| People can follow the new steps | Watch users complete the task, check the result, and respond when something goes wrong. Let them use their normal guides. Attending training does not prove they can do the task. | [Complete] |
| Owners, residents, and vendors know what to do | Give them clear instructions for any steps that change and a way to get help. Check their understanding if the process relies on their action. | [Complete] |
| Support has enough people and time | Check that staff have the skills, time, and authority to help. Include questions, practice, and problem solving. Name backups, hours, urgent contacts, and who can provide more help. | [Complete] |
| SOPs match the new process | A standard operating procedure (SOP) explains the overall process. Check who does each part, who decides, and how handoffs and problems are handled. Identify old or conflicting guides. | [Complete] |
| Work instructions cover changed tasks | These explain how to do a specific task. Check the steps, needed information, choices, result checks, and responses to problems against the actual system. | [Complete] |
| Job aids are easy to use during the task | Job aids are short guides, checklists, or reminders. Users should be able to find and use them without searching through a long document. | [Complete] |
| The team knows how to pause and recover | Name who can pause the change and how service will continue. Explain where temporary records go and how they will be checked and merged later. | [Complete] |
Required tasks can be completed
- What to look for
- Watch a daily user complete key tasks with the access they will normally have. Include rare tasks where a mistake could cause harm. Check the results.
- Status and test notes
- [Status; test; person; date]
Required safeguards work
- What to look for
- Ask the person in charge to test required approvals, access limits, accurate records, and service rules through the full task.
- Status and test notes
- [Complete]
Records and connected systems are ready
- What to look for
- Check the needed records, settings, access, and system connections. Compare records and fix mismatches where needed.
- Status and test notes
- [Complete]
Each handoff has a clear owner
- What to look for
- Confirm that the next person or system accepts the task. Show what happens if a handoff stalls or is rejected.
- Status and test notes
- [Complete]
People can follow the new steps
- What to look for
- Watch users complete the task, check the result, and respond when something goes wrong. Let them use their normal guides. Attending training does not prove they can do the task.
- Status and test notes
- [Complete]
Owners, residents, and vendors know what to do
- What to look for
- Give them clear instructions for any steps that change and a way to get help. Check their understanding if the process relies on their action.
- Status and test notes
- [Complete]
Support has enough people and time
- What to look for
- Check that staff have the skills, time, and authority to help. Include questions, practice, and problem solving. Name backups, hours, urgent contacts, and who can provide more help.
- Status and test notes
- [Complete]
SOPs match the new process
- What to look for
- A standard operating procedure (SOP) explains the overall process. Check who does each part, who decides, and how handoffs and problems are handled. Identify old or conflicting guides.
- Status and test notes
- [Complete]
Work instructions cover changed tasks
- What to look for
- These explain how to do a specific task. Check the steps, needed information, choices, result checks, and responses to problems against the actual system.
- Status and test notes
- [Complete]
Job aids are easy to use during the task
- What to look for
- Job aids are short guides, checklists, or reminders. Users should be able to find and use them without searching through a long document.
- Status and test notes
- [Complete]
The team knows how to pause and recover
- What to look for
- Name who can pause the change and how service will continue. Explain where temporary records go and how they will be checked and merged later.
- Status and test notes
- [Complete]
Check support staffing and time
Naming a support person is not enough. They also need time to help.
- Expected requests: How many people may need help? With what? When will demand be highest? Explain your estimate.
- People available: List staff, backups, skills, hours, timezone, and time set aside. Include the decisions they can make.
- Other duties: Which duties will be reduced or given to someone else so support staff have time?
- If requests exceed capacity: When will you act? Who can add help, change priorities, or reduce what launches?
If demand is uncertain, state your estimate and how you will check it. Do not mark staffing as ready just because you expect it to be enough.
Check that each task has the guides it needs
Documentation coverage means having the SOPs, work instructions, and job aids needed for this change. Match them to the tasks and roles they support. A folder of files or a link to a vendor help center is not enough on its own.
| Changed task or process / role | Guide needed and current link | Who keeps it current / version or date checked | User test | Status and next action |
|---|---|---|---|---|
| [Process and role] | [SOP: overall process, decisions, and handoffs] | [Complete] | Can the user find the guide, identify their part, and find who can help? | [Status; gap; owner; next step] |
| [Task and role] | [Work instruction: steps and result checks] | [Complete] | Can the user follow it in the actual system and get the right result? | [Complete] |
| [Action and role] | [Job aid: quick checklist, reminder, or task card] | [Complete] | Can the user find and use it during the task without relying on memory or live coaching? | [Complete] |
[Process and role]
- Guide needed and current link
- [SOP: overall process, decisions, and handoffs]
- Who keeps it current / version or date checked
- [Complete]
- User test
- Can the user find the guide, identify their part, and find who can help?
- Status and next action
- [Status; gap; owner; next step]
[Task and role]
- Guide needed and current link
- [Work instruction: steps and result checks]
- Who keeps it current / version or date checked
- [Complete]
- User test
- Can the user follow it in the actual system and get the right result?
- Status and next action
- [Complete]
[Action and role]
- Guide needed and current link
- [Job aid: quick checklist, reminder, or task card]
- Who keeps it current / version or date checked
- [Complete]
- User test
- Can the user find and use it during the task without relying on memory or live coaching?
- Status and next action
- [Complete]
Add rows for the launch you are reviewing. Include important problems and changed actions by owners, residents, or vendors. One guide can serve more than one purpose. You do not need three separate documents for every task.
Before marking a guide Demonstrated, check that:
- It matches the new process and does not conflict with other guides.
- The people who need it can find, open, and use it.
- A named person keeps it up to date.
- Old instructions are removed or clearly marked as replaced.
Record missing, old, blocked, or untested guidance as a gap or unknown. Carry it into the next section.
3. Make a plan for each gap
Copy this block for each Gap or Unknown. A gap is not fixed just because it has an owner.
- What is missing or untested? [Requirement or test still needed]
- What could go wrong, and who would it affect? [Impact and affected part of the launch]
- Does it affect a required safeguard? [Yes / No / Unknown; person responsible]
- Who will fix it, and by when? [Name; deadline]
- Planned action: [Fix before launch / leave that part out / allow a temporary exception]
- For a temporary exception: [How to limit harm; who owns it and accepts the risk; end date; checks for problems; recovery plan]
- How will you check the fix? [Required test result; who will review it]
4. Record the launch decision
| Decision | What it means and when to use it |
|---|---|
| Hold the affected scope | Stop that part of the launch. A required safeguard has failed or is untested, a serious gap has no safe temporary plan, or an owner or test result is missing. Fix it or leave that part out, then review again. |
| Proceed with a narrower scope | Launch fewer parts. Check that the part you leave out is not needed by the rest. Repeat the review for what remains. |
| Proceed with bounded exceptions | Launch with temporary gaps under clear limits. Required safeguards must work. Each gap needs an owner, an accepted risk, a way to limit harm, an end date, and a review. |
| Proceed within the reviewed scope | Launch the parts you checked. All checks that apply have passed, with no open exceptions. Keep watching for problems; this review cannot rule out every unknown issue. |
Hold the affected scope
- What it means and when to use it
- Stop that part of the launch. A required safeguard has failed or is untested, a serious gap has no safe temporary plan, or an owner or test result is missing. Fix it or leave that part out, then review again.
Proceed with a narrower scope
- What it means and when to use it
- Launch fewer parts. Check that the part you leave out is not needed by the rest. Repeat the review for what remains.
Proceed with bounded exceptions
- What it means and when to use it
- Launch with temporary gaps under clear limits. Required safeguards must work. Each gap needs an owner, an accepted risk, a way to limit harm, an end date, and a review.
Proceed within the reviewed scope
- What it means and when to use it
- Launch the parts you checked. All checks that apply have passed, with no open exceptions. Keep watching for problems; this review cannot rule out every unknown issue.
Decision / what can launch / reason / decision owner / date: [Complete]
Conditions and next review: [What must stay in place? When will you check again? Who can pause the launch?]
Do not calculate a readiness percentage. Many passed checks cannot make up for one untested required safeguard. If a problem is already causing harm, use the right support or recovery process first.
Illustrative decision informed by a turn problem from my experience: If a daily user can create a turn-related order but it does not appear under the correct turn, mark task completion and the handoff Gap. The decision owner must check whether that failure affects a required safeguard or dependent work. Hold the affected turn workflow if either is untested or unsafe. A narrower launch is possible only if other work does not depend on it. Repeat the user test after correcting the steps or system setup; record the order under the right turn and the next person's ability to see it. This is a proposed decision path, not a report of Northpoint's launch decision.
Next action
Use the gap framework to investigate an unclear problem, the task guide to explain changed steps, and the support plan to arrange help and recovery.
Supporting source
- Year One, Episode 5: Property Meld to AppFolio — The Hardest Maintenance Migration — I discuss my experience with preparation, missed task details, affected owners and vendors, and early support. This checklist's statuses and decision rules are proposed guidance.