We are honored today with a guest post from Roy Atkinson, a thought leader in Service Management and a mentor to many, Enjoy – Patti
And now, here is Roy…
While being fast in each leg of a track and field relay race is important, none of that speed matters if the baton is dropped. Winning relay teams practice the baton pass again and again until there is a high degree of confidence that the pass will be made smoothly and effectively, giving the team the best chance to win.
In businesses and other organizations, project handover also holds risk. The goal of any project is—or should be—the delivery of maximum value to the organization. That value is only realized when the project is brought into production and enables people to perform tasks as it was designed to do. Delays and mistakes in the handover result in a lost return on investment (ROI), either because the delivery into production was delayed or because the tool is not being utilized or supported properly.
There be several—or many—team-to-team handovers during a project, but the final step into production is the one that matters most.
One could make the argument that DevOps has emerged in part as the solution to the problem of new software so often being tossed from the development teams “over the wall” to operations teams with very little previous communication and feedback. Returning to the opening metaphor, this would be like tossing the baton into the air and hoping the runner of the next leg of the relay would catch it and start running without delay.
It should be borne in mind that all projects are business projects. Without a business purpose, expenditure on a project is waste. (And yes, this applies to IT’s own improvement projects as well.) Of course, the project should have a carefully defined scope, resource plan, and timeline, by definition, but there are some considerations that are often overlooked.
Consider All Stakeholders
When HDI looked at the impact of good communication between Application Development and Support back in 2016, we solicited comments as well as multiple choice selections. Some of the comments were straightforward:
“Support should be more involved in the requirements-gathering and testing process to ensure the final product is compatible with the desktop environment. The service desk should be made aware of the new release during testing so [staff] can be trained.”
“Prelaunch involvement should include clearly defined client-side needs so support teams can verify compatibility and prepare as well to start getting an initial support strategy outlined.”
Remember that the new project will produce a product that must fit into the production environment of the business users who need it. Chances are, your test environment does not 100 percent match your production environment, no matter how good your QA/Test is. Having support involved early checks two boxes:
- It greatly improves ongoing support when the product is released into production
- It reduces the risk of unexpected failures by including those with the best knowledge of the user environment
The short message is that no one should be blind-sided when your new project goes into production. Don’t think you’ve “checked all the boxes” when you haven’t included boxes that should be checked.
In other words, your project handover starts at the beginning of the project, not at the end.
Check Your Checklist
During the course of the project, changes will occur. Requirements or user stories will be added or dropped. Scope will likely expand—at least somewhat. Each and every change should be reflected in your handover plan and checklist, with new requirements deserving special attention. It’s a good idea to have a “risk register” in your plan to document the potential risks of each change. Failures will happen, but they should happen early in the process so they can be dealt with in the next product iteration.
Rehearse the Baton Pass
Just as the relay team practices that baton pass, again and again, project teams—and that includes stakeholders—can rehearse the handover through checklist run-throughs and simulations. Everyone involved should understand what will happen, when it will happen, and what their role is. If they don’t, you’ve missed something.
A word of caution: As you already know, involving too many people will complicate things, and your good plans may fall victim to “death by committee.” Involve suitable delegates from every stakeholder area, but don’t cripple the project by hampering clear decision-making.
As Stephen Covey said, “Begin with the end in mind.” The handover mechanism and process should be clear from the inception, and the goal is a good business outcome.
__________________________________
Roy Atkinson is one of the top influencers in the service and support industry. His blogs, presentations, research reports, white papers, keynotes, and webinars have gained him an international reputation. In his role as senior writer/analyst, he acts as HDI’s in-house subject matter expert, bringing his years of experience to the community. He was inducted into HDI’s Hall of Fame in April 2018.
Roy was a small business IT consultant as a member of the Apple Consultants Network and worked in service desk, service management, and desktop support at The Jackson Laboratory, one of the world’s premier scientific research institutions. He completed earned a Master’s Certificate in Advanced Management Strategy at Tulane University’s A.B. Freeman School of Business in 2011.
You can find Roy on Twitter: @RoyAtkinson