How Do We Land This Thing? Planning for Go-Live and Beyond
Much like the dog that doesn’t know what to do when it finally catches a car, some project managers have little experience bringing a project in for a landing, so they can be dismayed or just blindsided by organizational change needs and stakeholders’ expectations at delivery.
To my surprise, this problem seems to be getting worse in some quarters, as organizations struggle with new agile approaches and software as a service (SaaS) or new project managers work with their first systems integrator.
I’m not blaming organizations, and I don’t think people are getting dumber. I think some hard-won cultural lessons have been lost in the upheaval that has largely merged what used to be formal “operations” in many smaller organizations into a blurry “DevOps.”
What seems to surprise the inexperienced project manager is that finishing a software project often consists of more than tossing the production system over the wall and wishing the end users good luck. It seems project managers are often pushing so hard to get to their destination that they don’t make time to learn how to land when they arrive.
Here is a checklist of some commonly forgotten items to address when a project goes live. Make sure they are in your plan or backlog, and don’t wait until the last minute to address them.
End-user organizational change: Plan for end-user and administrator training materials and sessions, job aids, and handholding at cutover to overcome fear of the unknown.
User support: Train help desk staff to be prepared to answer phones on day one and provide them with likely frequently asked questions.
Warranty period: Normally there is a “breaking-in period” for the first thirty to ninety days after a system is installed to correct any deficiencies identified after go-live and implement any desirable or optional functions that were deferred from the minimum viable product. After this period, the system is officially in operations and maintenance mode. Don’t let too much of your team escape before the end of the warranty period.
Backup and recovery: Integrate the system and its data into the backup and recovery scheme. If the system is mission-critical, assure it is documented as part of disaster recovery.
Knowledge transfer from the development team to the maintenance team: Give the people who have to operate and maintain the system a break. Include them in the run up to go-live, give them some basic training in how the system works, and document the architecture before the development team wanders off.
Key operational milestones: If the system has scheduled events such as month-end closing for an accounting system or check printing for a payroll system, make sure that support is available when those milestones first occur and remains available until they run reliably.
Decommissioning systems displaced: Has all essential historical data been either imported to the new system or mothballed somewhere? When can the old system hardware and software be released?
Building and implementing a data system is an accomplishment, but if customers can’t use it or it can’t be supported after go-live, the project has failed.
