TECHNOLOGY PROJECT HANDOVER
COMMERCIAL/CONTRACTUAL
1. Requirements should be written into tender documentation/contracts in as much detail and as specifically as possible including engagement requirements, data environment and any standardisation of equipment or product that the client requires.
2. Whole life cost must be considered if at all possible. Does spending more now have an impact on the overall operating cost of the project throughout its life?
3. Incentivise success. If a scheme is well delivered, this should reward all parties.
PROCESS
4. Handover is a process not a date. Planning for it should be from the start of the project and it should be viewed as an incremental transfer of knowledge and operation from project team to business-as-usual.
5. The benefits and deliverables must be measurable and communicable from the start. Ask why are we doing this project and how will we know when it is done?
6. Involve end users from the outset. Through stakeholder analysis, understand who will benefit from the project, who will be required to facilitate the delivery of the benefits and how the project outputs will impact their role.
DATA AND KNOWLEDGE TRANSFER
7. Documentation must be written for the end users. It may require different sets of documentation for different users but for documentation to support knowledge transfer it needs to be meaningful, applicable and relevant to the end users.
8. Collate lessons learned as the project progresses. It provides more meaningful data for future projects, it can be tied to stage gateways or key deliverables.
9. Agree the information requirements at the outset. This ensures all parties have a clear deliverable, know what is expected of them and work towards achieving the goal from the start of project.
PEOPLE
10. Often overlooked but put simply get good people on your project and keep them for as long as you are able.
11. Definition of stakeholders should be carried out throughout and in detail. Who will be impacted by the project and who is needed to make it a success?
12. The client role is pivotal including client engagement.
TABLE / TEMPLATE
| Checks | Documentation / Deliverables |
| SYSTEMS INFRASTRUCTURE & NETWORK DESIGN (WHAT IT LOOKS LIKE) | |
| Have adequate system & architectural diagrams (under version control) been produced? Do they provides a basic description of the systems overall purpose as well as its primary functional components and their relationships? | Location of equipment Hardware configuration / specification Network configuration diagram Relevant logical and physical system diagrams and flowcharts Hostnames Database names Application names Interfaces Environments Dependencies upon / interdependencies with other systems and applications What support / maintenance agreements are in place |
| SOFTWARE OVERVIEW (WHAT'S INSTALLED ON IT) | |
| Have details of all software elements (OS, Application, Middleware etc) been produced? | What software / application versions are installed What licenses have been purchased Where the licenses are kept / recorded What support / maintenance agreements are in place |
| SYSTEMS BUILD INSTALLATION (HOW TO INSTALL IT) | |
| Has a detailed description of the installation process for the complete solution been produced? | Hosting requirements, installation & configuration including power, air conditioning, racking, secure access System installation procedures from bare metal including environment setup and configuration details Detailed Install Guides on how the applications is loaded including where the software is located / stored, and license installation procedures |
| VERIFY THE SYSTEM BUILD (TEST INSTALLED CORRECTLY) | |
| Has the basic build been tested | Test end 2 end functional and System acceptance test plan and expected results |
| DISASTER RECOVERY & FAILOVER RESILIENCE (WHAT IF SCENARIO TESTING FOR DIFFERENT OUTCOMES) | |
| Have all changes / amendments to the Disaster Recovery & Test plan been captured, including details on what is required to fail the system / application over to the contingent system in the event of a failure of the production service? | Identify the triggers for automatic failover What is the sequence of events during automatic failover How do you know the automatic failover has been successful or not How you recover back to the Live environment The level of disaster recovery required and the recovery procedures in the event of a disaster invocation Identify the triggers for manual failover What is the sequence of events during manual failover - partial and complete What is the sequence of events during manual failover How do you know the manual failover has been successful or not How you recover back to the Live environment - partial and complete The level of disaster recovery required and the recovery procedures in the event of a disaster invocation |
| VERIFY THE DR CAPABILITY (TEST FAILOVER & RECOVERY PLANS) | |
| Check DR is working | Performance & Stress test plan and expected results (including break point thresholds) Perform Failover and Failback Recovery Testing |
| BACKUP AND RECOVERY | |
| Have system backup details / procedures been produced? | What is to be backed up When it has to be backed up (what time, how often) How it is to be backed up Where it is to be backed up to How much data is likely to be backed up What media is to be used Retention period of data Has this been signed off by the business owners (where is supporting evidence) |
| Have recovery details / procedures been produced? | Full system recovery from bare metal Partial system recovery Full data recovery Selective data recovery Restoration requirements / dependencies Impact / inputs to other systems |
| ACCOUNT MAINTENANCE / USER SET-UP & MANAGEMENT INSTRUCTIONS | |
| Have user set-up procedures been produced that supports the way in which the Service Desk creates and manages user-ids? | How to set up a user-id How to change a user-id How to delete a user-id How to reset passwords User notification |
| BATCH PROCESSING INSTRUCTIONS | |
| Has a description of each individual process been provided? | Description of what the process does Source and target system interfaces are explained Details on data being manipulated |
| Have Operation, Frequency, and Processing Time details been provided for all of the processes? | How the process is started (manual or scheduled)? Operational activity required during the running of the process What inputs are required What outputs are required / produced How often the process runs How long the process should run for What the volume of data is processed |
| Have the process Success / Failure indicators been defined? | How you can tell if the process has completed successfully or not How you can tell if the process is looping What output is produced All status exception messages are explained What the impact of failure is What action should be taken in the event of failure |
| If the process were to be interrupted prior to successful completion, what instructions must be followed to restart the process? | Restart procedures |
| How can the process be safely interrupted, if it becomes necessary to do so? | Interruption procedures |
| Have full details been provided for the Scheduling and Recovery of the batch process? | Predecessor Requirements Successor Requirements Interface requirements Scheduling Recovery Details Callout Instructions Disaster Recovery |
| PLANNED SYSTEM START UP / SHUT DOWN INSTRUCTIONS | |
| Have instructions been provided to guide the operators during the startup and closedown process of a system or application, including emergency shut-down and startup procedures? | How to start / stop the system, application, or processes How to start / stop interfaces What messages are expected during start-up and closedown What sequence should be followed during start-up and closedown What responses are to be entered How to deal with unexpected responses Emergency start-up procedures |
| SYSTEM MONITORING & MAINTENANCE | |
| Have the procedures to be followed for monitoring the computer system been produced? | The tools to be used for monitoring the systems and applications The indicators and interpretation of those indicators Components monitored purpose / function Threshold level settings Severity level settings details of impact Operator actions required Escalation Are there detailed error handling procedures Are there detailed notification & reporting procedures |
| Have System Maintenance requirements been documented? | What are the agreed maintenance schedules / slots Have the maintenance schedules been agreed with the business List the terms of external maintenance contracts with suppliers and engineers |
| Have detailed trouble shooting procedures and FAQ's been produced? | The error messages or other indicators accompanying those problems The automatic and manual procedures to be followed for each occurrence Evaluation / trouble-shooting techniques Conditions requiring application or system shutdown Procedures for on-line intervention and the steps to be taken in the event that on-line intervention requires a restart Any special requirements for recording information concerning a problem / failure should also be included |
| SERVICE AGREEMENTS | |
| Has an SLA been documented and agreed with the Business? | Agreement in place between IS and the Business |
| Have Third Party arrangements been agreed and signed off and supporting agreements / documentation location idenfied? | Supplier 1 Supplier 2 Supplier 3 Supplier 4 |
| OPERATIONAL SKILLS, RESOURCES AND TRAINING | |
| Have resource or skills shortages been identified | Define roles and skills required |
| What training requirements have been identified | New Training for Existing staff Knolwedge transition required from project team members to operational staff Agree project team involvement in Operations during Warranty Ongoing Training Plan for knowledge sharing and personal development |
| SERVICE DEFINITION | |
| Have Service Owners been identified and agreed? | Business Service owner IS Support owner(s) Third Party Support owner(s) |
| Has the Support Model been documented and agreed? | Support relationships 1st, 2nd, 3rd line responsibilities Support Matrix Support obligations Service Hours and Service Levels |
| Have full support contact details been provided (a copy of project Communication Plan is sufficient) ? | Name Position Company & Department Location Land line number Mobile phone numbers E-mail address Alternative contact Escalation procedure |
| GLOBAL SUPPORT PROCESSES | |
| Has the Service Desk tool been configured in support of the Service and Reporting requirements? | Agreed and configured CTI's Resolver groups configured Resolution and cause codes configured Escalations and notifications configured Knowledge base populated Report templates produced Asset information captured in toolset as required Service Desk licenses procured and agents rolled out as necessary Training material produced |
| Have the Incident Management process and procedures been reviewed and amended in support of the Service requirements? | Reviewed / revised Incident Management process Process interfaces / dependencies 1st line support procedures Incident workflow Third Party Incident Management |
| Have the Problem Management process and procedures been reviewed and amended in support of the Service requirements? | Reviewed / revised Problem Management process Process interfaces / dependencies Known Errors Problem database Root Cause Analysis (RCA) template |
| Have the Configuration Management process and procedures been reviewed and amended in support of the Service requirements? | Reviewed / revised Configuration Management process Process interfaces / dependencies Populated CI database |
| Have the Change and Release Management process and procedures been reviewed and amended in support of the Service requirements? | Reviewed / revised Change and Release Management process Process interfaces / dependencies |
| Has the Anti Virus & Patch Management policy been defined and the process and procedures amended in support of the Service Requirements? | Policy / process in place Process interfaces / dependencies Procedures defined for Emergency, Critical, Standard, and Maintenance patches Deployment schedule defined Test schedule defined Responsibilities agreed |
| SECURITY MANAGEMENT | |
| Has the security model been defined? | Infrastructure (hardware, network) OS Database Application User profiles / access How is security monitored / maintained |
| Has the security model been tested? | Internal testing Independant 3rd Party penetration / application testing Risks / vulnerabilities identified Mitigation / corrective actions agreed |
| WARRANTY | |
| Is there a Warranty Statement agreement in place ? | Entry Criteria Exit Criteria Competencies Governance |
| Is the Warranty Support Model defined? | Organisation (People, inc Third Parties) Support processes Support tools Defect handling procedure Transition Plan |
| Are full support contact details provided? | Name Position Company & Department Location Land line number Mobile phone numbers E-mail address Alternative contact Escalation procedure |
USEFUL REFERENCES
Agile documentation: Handover to production support
https://kingsinsight.com/2011/02/10/agile-documentation-handover-to-production-support/
ITIL-Checklists [Incident Management / Service Desk]
https://wiki.en.it-processmaps.com/index.php/ITIL-Checklists#ITIL_Service_Transition_Templates
ITIL Service Operation Roles:
https://www.certguidance.com/processes-wise-itil-roles-itsm/#sorole
12 factors for the successful handover of projects
https://www.apm.org.uk/resources/find-a-resource/project-handover/12-factors-for-the-successful-handover-of-projects/
Code Documentation: How To Create Effective Handover Documentation
https://praxent.com/blog/software-handover-documentation-checklist
