Capability template for project and delivery
Project handover readiness check
When a finished deliverable is ready for the team that will run it, the project manager brings one checklist against that team's own requirements: acceptance evidence, instructions, access, training, support owners and open items. The receiving owner accepts or names the conditions still to meet.
Listed under
Add it to a workflow in the Fully Powered Planner, beside the teams and roles that will run it. Book a fit call
The outcome
The handover meeting starts from facts instead of goodwill. Every requirement the receiving team wrote down sits on one page with a plain status beside it: met, partly met, not met, not evidenced, or for the receiving owner to judge. Every gap is spelled out: which access is still only requested, who has been trained but has not yet done the work alone, which support topic has a name against it but no agreement, which serious defect has no workaround yet.
The rules are strict where handovers usually go soft. A guide on file does not count as the team being able to do the work; someone from the receiving team has to have done it. A name in a plan does not count as an owner until that person has agreed. Anything planned for next week is planned, not done. When support cover would lapse between the project team leaving and the new owner starting, the checklist names the dates and counts the days.
Each unmet must-have arrives already written as a condition. The receiving owner decides: accept, accept with those conditions, or not yet. The AI assistant grants no access, signs nothing and decides nothing.
Who starts the work, and when
The project manager starts it a few working days before the planned handover, once the deliverable has been tested and the handover pack is assembled, and runs it again on the day. The receiving owner, the manager whose team will run the result, reads the checklist and makes the call.
What they supply
- The handover details: what is being handed over, to which team, the check date, the planned handover date and when the project team's own support ends.
- The receiving team's requirements, written by the receiving owner: each with its area, whether it is a must-have, and the evidence that would satisfy it.
- The evidence register: sign-offs, test records, guides and records of the receiving team doing the work, each dated.
- The access list: who in the receiving team holds which access, and whether it is granted, requested or not yet asked for. No passwords, ever.
- The training record: who was trained, and when each person first ran the work for real without help.
- The support owners: each topic, who owns it after handover, whether they have agreed, and from when.
- The open items: defects, known issues and unfinished work, with severity, workaround, owner and due date.
Each list has set column headings. If a heading does not match, the assistant stops and asks rather than guessing.
What comes out
One checklist, in a fixed order. At the top, a count: how many must-haves are met and how many conditions are open. Then every requirement by area with its status, the evidence behind it and what is missing. Then the proposed conditions, each written as what must be true, with the owner and date left for the receiving owner. Then the support cover after handover with any gap in days, every open item carried into operation with the most serious first, and anything supplied that answers no requirement. It ends with a blank decision box for the receiving owner to complete.
An invented example
Illustrative example with invented data. The firm, the supplier, the people, the system and every date below are invented. The firm is an invented 90-person building-survey practice. An internal project has replaced its paper and spreadsheet diary with an inspection scheduling system bought from an invented software company, called Supplier A here. The project manager is about to hand the system to the scheduling team, whose manager will run it. People are named by role or by letter. First come the inputs the project manager supplied, in full, then the checklist the capability returned.
The inputs
1. Handover settings
Deliverable: Inspection scheduling system
Project manager: Project manager, operations projects
Receiving team: Scheduling team (roles: Scheduling manager, Senior scheduler, Scheduler)
Receiving owner: Scheduling manager
Check date: Thursday 12 November 2026
Planned handover: Monday 16 November 2026
Project team support ends: Friday 11 December 2026
2. Requirements list (written by the scheduling manager)
req_id,area,requirement,must_have,evidence_expected
R01,Acceptance,User acceptance test passed and signed off,yes,sign-off by Scheduling manager
R02,Acceptance,Load test at 400 bookings a day or more,no,test record
R03,Instructions,Daily operating guide for schedulers,yes,document
R04,Instructions,A scheduler has run the morning schedule build from the guide without help,yes,demonstration
R05,Access,Scheduling team holds the access it needs to run and administer the system,yes,access granted
R06,Training,Every scheduler trained and has run a live day unaided,yes,ran unaided
R07,Support,Every support topic has an owner after handover who has agreed to it,yes,owner accepted
R08,Open items,Every open item has an owner after handover and no high-severity item is left without a workaround,yes,owners and workarounds
R09,Instructions,Supplier contacts and escalation route written down,no,document
R10,Support,Response time for system faults agreed with IT,no,service levels confirmed by IT lead
3. Evidence register
ev_id,req_id,description,kind,dated,by
E01,R01,User acceptance test summary: 46 of 48 scripts passed; the 2 failures are logged as OI-02 and OI-03,test record,2026-11-06,Project manager
E02,R01,Sign-off meeting booked for Friday 13 November,note,2026-11-10,Project manager
E03,R02,Load test: 450 simulated bookings in one day with no failed booking,test record,2026-11-04,Supplier A
E04,R03,Daily operating guide version 1.2,document,2026-11-09,Project analyst
E05,R04,Daily operating guide version 1.2 section 2: morning schedule build,document,2026-11-09,Project analyst
E06,R09,Supplier A contacts and escalation route,document,,Project analyst
E07,R10,Message from IT lead: faults reported before 2 pm are answered the same working day,note,2026-11-10,IT lead
E08,,Data move check: 1212 of 1212 open bookings moved from the old diary,test record,2026-11-02,Project analyst
4. Access list
req_id,system,access_level,receiving_holder,status,date
R05,Scheduling system,Scheduler,Scheduling team (4 schedulers),granted,2026-11-02
R05,Scheduling system,Administrator,Scheduling manager,granted,2026-11-02
R05,Scheduling system,Administrator (backup),Senior scheduler,requested,2026-11-09
R05,Supplier A support portal,Named contact,Scheduling manager,not requested,
5. Training record
req_id,person,role,topic,trained_on,ran_unaided_on
R06,Scheduler A,Scheduler,Daily scheduling,2026-10-28,2026-11-03
R06,Scheduler B,Scheduler,Daily scheduling,2026-10-28,2026-11-05
R06,Scheduler C,Scheduler,Daily scheduling,2026-10-29,2026-11-13
R06,Scheduler D,Scheduler,Daily scheduling,,
6. Support owners
req_id,topic,owner_after_handover,accepted,from_date
R07,Day-to-day scheduling questions,Scheduling manager,yes,2026-11-16
R07,System faults and outages,IT lead,yes,2026-11-16
R07,Changes to booking rules and templates,Senior scheduler,no,2026-11-16
R07,Supplier A account and renewals,Operations director,yes,2027-01-04
7. Open items
req_id,item_id,description,severity,workaround,owner_after_handover,due
R08,OI-01,Calendar updates reach inspectors' phones up to 15 minutes late,medium,Inspectors refresh the app before leaving,IT lead,2026-12-04
R08,OI-02,Repeat bookings that fall on a public holiday are not moved,high,Schedulers check holiday weeks by hand (guide section 5),Scheduling manager,2026-11-27
R08,OI-03,Cancellation emails to clients show the old office address,high,,Supplier A,2026-11-20
R08,OI-04,Monthly utilisation report not yet built,low,,,
The output
HANDOVER READINESS CHECK: Inspection scheduling system
- For: Scheduling manager, Scheduling team. Prepared by: Project manager, operations projects.
- Check date: Thursday 12 November 2026. Planned handover: Monday 16 November 2026. Project team support ends: Friday 11 December 2026.
- Supplied: requirements (10, 7 must-have); evidence register (8 rows); access list (4 rows); training record (4 rows); support owners (4 rows); open items (4 rows).
Position by the rules: 1 of 7 must-have requirements met. Conditions open: 6. For the Scheduling manager to judge: 1. Not must-have and still open: 1. This is a count, not a decision.
Requirements
Acceptance
- R01 User acceptance test passed and signed off (must-have). Expected: sign-off by Scheduling manager. Status: Partly met. Evidence: E01 test summary, 46 of 48 scripts passed, Friday 6 November; E02 note, sign-off meeting booked for Friday 13 November, Tuesday 10 November (not counted: a note, not a sign-off). Finding: no sign-off by the Scheduling manager; E02 is a note of a meeting, not a sign-off. E01 records 2 failed scripts, logged as OI-02 and OI-03.
- R02 Load test at 400 bookings a day or more (not must-have). Expected: test record. Status: Met. Evidence: E03 load test, 450 simulated bookings in one day with no failed booking, Wednesday 4 November. Finding: nothing missing.
Instructions
- R03 Daily operating guide for schedulers (must-have). Expected: document. Status: Met. Evidence: E04 daily operating guide version 1.2, Monday 9 November. Finding: nothing missing.
- R04 A scheduler has run the morning schedule build from the guide without help (must-have). Expected: demonstration. Status: Not evidenced. Evidence: E05 operating guide section 2, Monday 9 November (not counted: a document, not a demonstration). Finding: document only: nobody in the receiving team is recorded doing it.
- R09 Supplier contacts and escalation route written down (not must-have). Expected: document. Status: Not evidenced. Evidence: E06 Supplier A contacts and escalation route (not counted: undated). Finding: E06 is undated.
Access
- R05 Scheduling team holds the access it needs to run and administer the system (must-have). Expected: access granted. Status: Partly met. Evidence: access list, 4 rows linked. Finding: 2 of 4 rows granted. Scheduling system, Administrator (backup), Senior scheduler: requested Monday 9 November. Supplier A support portal, Named contact, Scheduling manager: not requested, no date.
Training
- R06 Every scheduler trained and has run a live day unaided (must-have). Expected: ran unaided. Status: Not met. Evidence: training record, 4 rows linked. Finding: Scheduler D: not trained. Scheduler C: trained Thursday 29 October; ran unaided dated Friday 13 November, dated after the check date. Schedulers A and B: trained and ran unaided.
Support
- R07 Every support topic has an owner after handover who has agreed to it (must-have). Expected: owner accepted. Status: Not met. Evidence: support owners, 4 rows linked. Finding: Changes to booking rules and templates: Senior scheduler named, not accepted. Supplier A account and renewals: cover from Monday 4 January 2027, after the cover limit of Saturday 12 December 2026.
- R10 Response time for system faults agreed with IT (not must-have). Expected: service levels confirmed by IT lead. Status: Owner to judge. Evidence: E07 message from the IT lead, faults reported before 2 pm are answered the same working day, Tuesday 10 November. Finding: the expected evidence is outside the fixed list; for the Scheduling manager to judge.
Open items
- R08 Every open item has an owner after handover and no high-severity item is left without a workaround (must-have). Expected: owners and workarounds. Status: Not met. Evidence: open items, 4 rows linked. Finding: OI-03 is high severity with no workaround. OI-04 has no owner after handover.
Conditions still to meet (proposed)
- R01: The Scheduling manager's sign-off of the user acceptance test is recorded; the test summary shows 2 of 48 scripts failed, logged as OI-02 and OI-03. Owner and date: for the Scheduling manager to set.
- R04: Someone in the scheduling team runs the morning schedule build from the guide without help, recorded as a demonstration. Owner and date: for the Scheduling manager to set.
- R05: The Senior scheduler's Administrator (backup) access to the scheduling system and the Scheduling manager's named contact on the Supplier A support portal are granted. Owner and date: for the Scheduling manager to set.
- R06: Scheduler D is trained, and Schedulers C and D each run a live day unaided. Owner and date: for the Scheduling manager to set.
- R07: The Senior scheduler agrees to own changes to booking rules and templates, and Supplier A account and renewals has an agreed owner from Saturday 12 December 2026 to Sunday 3 January 2027. Owner and date: for the Scheduling manager to set.
- R08: OI-03 has a workaround, and OI-04 has an owner after handover. Owner and date: for the Scheduling manager to set.
Also open (not must-have)
- R09: Not evidenced. E06 is undated.
For the Scheduling manager to judge
- R10 Response time for system faults agreed with IT. Expected: service levels confirmed by IT lead. Supplied: E07, a message from the IT lead saying faults reported before 2 pm are answered the same working day, Tuesday 10 November. Question: does this meet the requirement?
Support after handover
- Day-to-day scheduling questions: Scheduling manager, accepted, cover from Monday 16 November 2026.
- System faults and outages: IT lead, accepted, cover from Monday 16 November 2026.
- Changes to booking rules and templates: Senior scheduler, named, not accepted, cover from Monday 16 November 2026.
- Supplier A account and renewals: Operations director, accepted, cover from Monday 4 January 2027. Gap: Saturday 12 December 2026 to Sunday 3 January 2027, 23 days.
Open items carried into operation
- OI-02 (high) Repeat bookings that fall on a public holiday are not moved. Workaround: schedulers check holiday weeks by hand (guide section 5). Owner after handover: Scheduling manager. Due: Friday 27 November 2026.
- OI-03 (high) Cancellation emails to clients show the old office address. Workaround: none. Owner after handover: Supplier A. Due: Friday 20 November 2026.
- OI-01 (medium) Calendar updates reach inspectors' phones up to 15 minutes late. Workaround: inspectors refresh the app before leaving. Owner after handover: IT lead. Due: Friday 4 December 2026.
- OI-04 (low) Monthly utilisation report not yet built. Workaround: none. Owner after handover: not assigned. Due: not stated.
Supplied but not linked
- E08: data move check, 1212 of 1212 open bookings moved from the old diary, Monday 2 November. No requirement named.
Decision of the Scheduling manager (left blank for them)
[ ] Accept the handover [ ] Accept with the conditions above [ ] Not accepted yet
Name, role and date: ____________
Prepared for the Scheduling manager's decision. Nothing has been granted, removed, signed, sent or changed.
Where it fits
- Project and delivery, which owns the moment a project's work becomes someone else's to run.
- Operations and process improvement, often the team on the receiving end of a new system or a rebuilt process.
- Professional services, where internal projects hand new tools to the people who serve clients every day.
- Software and technology, where a release passes from the people who built it to the people who support it.
- Construction, where a finished site or system passes to the team that will operate and maintain it.
- Engineering firms, where delivered systems and processes need an owner the day the project team moves on.
- Growth & scaling, when new systems arrive faster than teams can absorb them.
- Established businesses, where a handover too often means one email and a shared folder.
What has to change for your company
The receiving owner writes the requirements list once for each kind of deliverable your teams take on, and adjusts it per project; the capability supplies no standard list. Agree the evidence each requirement may ask for and add any of your own. Set your severity scale and whether a medium item also needs a workaround. Decide whether the project team supports the result for a period after handover, and for how long. Decide who confirms that the project team's own access is removed, which this checklist does not cover as written. Name who signs the decision box and where the signed checklist is kept. It runs in ChatGPT, Claude, Copilot or Gemini from the lists you supply, with no connection to any system.
What has been checked
Fully Powered AI wrote this capability template from its own published map of the work. It was editorially reviewed on 10 November 2026. It was tried once on its invented example on 10 November 2026, and the record is published with it. Small edits made to the template after that run were not run again; the record lists them. It has not yet been tested in a client environment. It has not yet been tested as a packaged version in ChatGPT, Claude, Copilot or Gemini.
Testing in your environment means running it on two or three past handovers your receiving owners remember, plus hard cases written in advance, each with its expected result: a guide offered where a demonstration is required, a support owner who never agreed, a gap in support cover, a list with a renamed column, an access list with a password typed into it. The project manager and the receiving owner check every status and every date before anyone relies on the checklist. Pilot acceptance-test preparation sets those cases up, and SOP from how the work is done writes the operating guide the receiving team will need.
The full capability template
Everything above is the outline. The complete capability template is the working version: the roles, the inputs, the procedure, the exceptions and stop conditions, the output format, the reviewer checklist, the acceptance tests, the instructions for an AI assistant and what to customize for your company. It comes with a download and the link to its folder in Fully Powered’s public repository.
Free with an account. Sign in by email: no password and no card.
Next step
Put this capability to work for your team: on your plan, or built with you in a sprint.
Build this in a sprint
In a sprint, Fully Powered adapts this capability template to your rules, proves it on your own work and puts it in the hands of the roles that own it.
Two ways to begin: