Technology Project Readiness Checklist

Planning an important technology project? Use this checklist to confirm that the business has clear ownership, realistic scope, documented supplier responsibilities, a risk management approach, testing arrangements and a defined project closure before delivery starts.

Outcome

• Define the business outcome — what will be different when this project is complete
• Define what success looks like in measurable terms
• Define acceptance criteria before delivery begins

Ownership

• Appoint a named executive sponsor who will make business decisions when required
• Appoint named project leadership — internal or external
• Define decision authority — who can approve scope changes, budget changes and go/no-go decisions
• Assign named business owners for each workstream

Scope

• Document what is included in the project
• Document what is explicitly excluded
• Record assumptions the plan is built on
• Define the change-control process — how scope changes will be assessed and approved

Suppliers

• List every supplier involved — internal IT, MSP, software suppliers, telecoms, consultants
• Record each supplier's specific responsibilities and deliverables
• Record dependencies between suppliers — what each one needs from another
• Confirm escalation routes for supplier disputes or failures

Plan

• Define milestones with owners and target dates
• Define dependencies between tasks and workstreams
• Define resource requirements for each phase
• Define and agree the budget
• Define decision dates — when specific decisions must be made to keep the plan on track

Risk

• Create a risk register — log, likelihood, impact, owner and mitigation for each risk
• Create an issue log for problems as they arise
• Create a decision log — record all significant decisions with date and owner
• Define escalation — what triggers an escalation and to whom

Users

• Identify all staff affected by the project
• Plan communications — what, when, who sends it and through what channel
• Plan training — what is required, when it happens and who delivers it
• Identify user champions who can support colleagues during transition

Testing

• Define test criteria — what must work for the system to be accepted
• Select testers — representative users, not only the technical team
• Plan remediation — how failures discovered in testing will be resolved
• Define rollback — what happens if go-live fails and how to revert

Cutover

• Confirm responsibilities — who does what during cutover
• Confirm support — who users contact if they have problems immediately after go-live
• Confirm communications — what users are told before, during and after cutover
• Confirm business-continuity arrangements for the cutover period

Closure

• Complete formal acceptance against acceptance criteria
• Resolve or formally accept all outstanding issues
• Transfer all project documentation to business ownership
• Confirm who owns ongoing support
• Remove all temporary system access granted to the project team
• Review whether the anticipated benefits were delivered

Warning signs

A project may need intervention where any of the following apply:

• Nobody can clearly say who owns delivery
• Meetings generate no decisions
• Actions repeatedly roll forward without completion
• Suppliers are blaming each other
• Deadlines move without documented explanation or replan
• Budget changes are discovered late
• Users are told about significant changes at the last minute
• Testing is being compressed because the deadline is fixed
• Project status is always described as 'nearly there'
• Nobody can describe what project completion looks like