Whether you need extra help building your digital product, a soup-to-nuts development team, or some support finding your product-market fit, we can help. Get in touch today to learn how.
This is the second in a two-part series. Read part one here.
At this point, you understand what an Orchestration Plan (OP) is and have a foundational understanding of how to start building one (if you need a refresher, you can find it in part one of this series).
But how can you keep your team engaged through the entire process of building an OP, especially when that process involves reviewing the same plan several times? And how can you finish the OP development process so that your team is set up for success?
That’s what we’ll cover in this post.
Work Backward
At this point in the OP process, you’ve already had two meetings with your team to plan your OP. You’ve gotten the broad strokes of what you need to get done to successfully launch during meeting No. 1, and then filled in any gaps to make sure nothing is ambiguous or undefined during meeting No. 2.
For meeting No. 3, start from the end of the OP this time. Celebrate with everyone that you’ve made it to the last step and the event was a huge success! Then back your way out of that win, line by line, to the first step in the OP. Examining your steps in reverse order mixes it up just enough to keep people engaged and (hopefully) helps the team see things they might miss in the chronological walk-through that they’re used to.
As usual, you’re asking questions, encouraging others to interrogate the steps and the ordering, making notes, and updating your shared doc as you go.
In between walk-through sessions, part of your job to build a durable OP is working with smaller groups, departments, individual contributors, and stakeholders. During these meetings, you’ll give them opportunities to review, call out dependencies, concerns, and risks, as well as highlight any needs they have when it comes to the actual event.
For example, your communications team may not need to be in every session for a full walkthrough, but they will need to understand at a high level what is going on, when it’s happening, and what the impact will be to internal and external customers. They can help determine how much you share with your customers and which channels you use to communicate about the event. They can craft the messaging and be on call to send email blasts, update notification banners, or support with any feedback or data-tracking.
Here are some guidelines for building a durable OP:
- Break down the final intended result into the steps to get there and keep each step as small as possible.
- Determine dependencies between/across the steps.
- Ask lots of questions, even if you think you might be the only person who doesn’t understand.
- Encourage everyone involved to ask their own questions and leave space for them to do so.
- Ask “What if?” and “How will we?” and “Who can?” questions.
- When appropriate, add checkpoints for rollback contingencies. Ask the team what those contingencies entail and when they should be considered.
- If there is a “point of no return” in your event (e.g. opening up your product to user logins or a significant data transfer), stop and take stock before that step to ask if there are any blockers, concerns, or issues to address first.
- Consider communications: What stakeholders should be apprised of the status and when? If something goes longer than planned, who should you contact?
- Include the body and subject lines for different communications and when you will send each one. For example, if the event runs longer than planned, but will still continue and you need to let your customer success team know that account login will be delayed, have a message prepped with that info and you can simply copy and paste with the specifics
SUBJECT: DB Migration - Outage Extended
BODY: The migration of customer data and decryption process has taken longer than we expected and is still in progress, so customers are not yet able to log in to the new system. Instead of a 4 a.m. completion time, we anticipate access will be restored by 5 a.m. If that changes, we’ll let you know by 4:30 a.m.
TEST. IT. OUT. TWICE (or More).
While there is no 100% guarantee of a successful event, testing your OP after several iterations of writing it will move the needle closer to success than you would be without a couple of dry runs. A dry run is a simulation for your event that will highlight where your failure points are, where you need to make adjustments, and (hopefully) how high your chances of success are.
Simulating your event in an environment that is as close as possible to what you have in production is an excellent metric to predict future success or failure. And there are lots of ways to do them.
Walking through an OP simulation in separate phases, testing and refining steps as you go over several days is one option that’s particularly helpful when you have disparate teams in charge of each step and not too many interdependencies.
If your implementation is more interconnected within a single platform or relies on a few key steps that will filter down throughout your system quickly, it’s best to work through it in one go with your full team online for the event.
Go into your dry runs with more time scheduled than you think you’ll need and give them the weight and focus they deserve. Don’t try to squeeze them in between other meetings. And don’t fit them into a one-hour meeting if they need three hours to run through and another hour afterwards to make updates and revisions to the OP.
Expect to find variances in timing, access, and data structure in your lower environments. Work around them when you can and learn from them as you’re able. We have often found that a dry run will reveal data variances that need accommodation or mitigation before that data can successfully be handled—and that’s a success.
If there’s bad data in your test environment, chances are that you’ll find similarly shaped data in production. Now you have a chance to handle that before it’s 3:40 a.m. and your DBA is bleary eyed from getting the same error for the last 27 attempts at their INNER JOIN that will never work without first normalizing the data in the old_descr column.
Wrap it Up
The ROI on a strong Orchestration Plan comes at the execution of the planned event. It may seem counterintuitive, but if your team leaves the migration or upgrade or re-platform feeling like they spent way too much time and worry over building the OP, the advance work you all put in has just paid dividends.
The goal of a solid OP is to decrease surprises and ensure reliable, repeatable results. If your stakeholders think you were way too cautious and concerned about the “What if?” scenarios because none of them came up during the event, that is proof of the value of this plan.
A well-crafted Orchestration Plan that has critical details, contingency protocols, rollback plans, and communication strategy built-in is like insurance; you hope you will never need it and you are super grateful it’s there when you do.
