This scenario has played out tens of thousands of times: your loyalty/mobile/fill-in-the-blank project, that your project team has been working on for months, is ready to go-live; eight months later, key members of that project team are still providing guidance as it relates to support, use, and everything else related to that project that supposedly launched months ago. The project team is growing impatient, as they had given up time just to be part of this special project unit, and now have day-to-day responsibilities in addition to whatever new project endeavor they are working on. When will the support end?
Document, document, and document some more
Nothing helps to better explain the project journey and go-live than thorough, thoughtful documentation or other similar guidance. How often, in 2018, do we find ourselves perusing the internet for the right article or YouTube video to guide us through a simple process? Project documentation can be that same beacon for whatever project was just completed. Documentation for both end users and whatever operational team is supporting the project launch are key to ensuring a smooth transition to support away from the project team. Even with the best documentation, there will still be outreach to those who helped design and launch, but even this can be streamlined by documenting which particular facets of the newly launched program can be answered by which member of the project team. For instance, listing the key technical contact and their contact information will ensure a high priority “SOS” email need not go to the whole project team when the question or issue is very technically specific.
Meet and discuss operationalizing the project launch
While documentation is key, there is no written rule that says handover and transition meetings to discuss ongoing operations are not allowed. The project team meeting with the operations team to review and discuss how the newly launched project works and what it does, to review the created documentation, and to help the ops team feel a greater sense of ownership in the newly launched project will go a long way to assuaging the ongoing need for project team involvement. Ideally by holding these meetings, the ops team will feel less inclined to grouse when issues arise, and they will work diligently to solve these issues on their own.
Plan the extra time
Even if you have the best documentation in the world and countless handover meetings with the ops team have been held, the project team will still contain the expertise regarding every feature and bug related to the project (and a compelling story of the journey involved to get there) as well as a thorough perspective on how things are to work and how to resolve issues that arise. Plan an extra multi-month buffer where the project team is still expected to dedicate some time to the project after launch. If the project team has an appropriate expectation of time allocation as they continue to fulfill their day-to-day jobs and prepare for a new project endeavor, they will be readier and more willing to help.
For further discussion, contact Tim at [email protected].
