Orchestrate the onboarding and launch for a new, adapted service offering (live online training) within a 3-week timeline to preserve high-priority revenue streams.

Updated: Jan 2025

Project Details

To set the stage: the 2020 COVID-19 pandemic had just been declared, and our company’s primary means of generating revenue was live, in-person training. Half of our (small) company was already on their way to Asia to begin our Hong Kong conference, and within a matter of days, our events coordination team had to cancel events, appease the worries of thousands of attendees, and find a way to substitute other upcoming live, in-person events, with live, online events, to ensure our company could stay afloat.

Fortunately, I’d spent much of the last two years organizing and hosting live online events (albeit, at a much smaller scale - 1-hour webinars). So, I was tapped to lead the effort of establishing a standard operating procedure (SOP, to use military lingo) and leading the business transformation - which was to adapt our business model to provide the same value and engagement, but entirely online.

Our next scheduled live event was meant to be in London, 3 weeks later, which meant our team had to transform over 15 different courses from in-person to online offerings which could reach a European market. This task was hard enough, as-is, but with the firm timeline of 3-weeks, it was panic-inducing to the majority of the organization. However, I credit my experience in the military with preparing me to operate in high-stakes, high-pressure environments. In fact, the military decision making process (MDMP) played a significant role in the success of this effort.

Nearly 5 years later, this same SOP is still used to train new employees and contractors about our process, and continues to help orchestrate the work of event coordinator staff, moderators, instructors, and management in continuing to provide world-class education and professional training. It’s a project I’m incredibly proud to have led, and while much of that SOP is still proprietary, I’m still excited to share what I can about the business transformation process.

The “task force”

To make this happen quickly, we quickly created a “task force” which included the events team, select senior managers, and two fellow Senior UX Specialists to carry out the initial planning. We identified four key tasks to ensure a high-quality experience could be delivered

Communications: Maintaining clear and timely communication with attendees, while offering incentives (discounts) to bolster trust and retain business where possible
Technology: Update backend databases and frontend UIs with necessary data to reflect updated and relevant information for upcoming events
Support: Establish additional technical support channels and onboard temporary staff to assist with the forecasted increase in technical support
Service Delivery: Create an implementation plan and SOP to adapt existing offerings

We divided up the work such that the events team handled all correspondence, partial refunds, and discounts with attendees, our technology director handled all website and database updates, and my two colleagues assisted in procuring third-party support to assist with forecasted increase in technical support. Senior management further coordinated resource allocation and work priorities to ensure the 3-week timeline could be met. My primary responsibility was to establish a staged implementation plan and documented SOP for the entire company to utilize.

The plan

Due to the live event structure of our offering, the launch date was non-negotiable. So, we had to scale our work to fit within a firm, 3-week period. The rollout plan consisted of 5 stages:

Product audit & prioritization (2 days)
Research & planning (3 days)
Design sprint (5 days)
Roleplaying & interactive walkthroughs (5 days)
Launch

Before / after each stage we held periodic check-in meetings with all staff to coordinate efforts and answer open questions.

At the time, creating this plan felt largely instinctive; but, when I reflect back on this implementation plan, 5 years later, I realize now how much of it was impacted by my military experience. A core component of the military decision making process (MDMP) is the 1/3-2/3 rule: given any amount of allocated time, leaders should dedicate no more than 1/3 of that time on planning, with the remaining 2/3 of that time to execute the plan. Thus, if given about 15 business days to roll out a significant change, your plan should be established and shared with the team by day 5.

Further, if you want to stretch your time for implementation, you can follow a military best practice which is to “issue a warning order,” but, to phrase it less ominously: give your team a heads up what’s about to happen as soon as possible, even if your plan isn’t fully established yet. So, within a day of finding out our new challenge, we notified the team immediately with key tasks and outcomes, which gave them time to proactively start their own preparations - even before a full plan was created.

Product audit & prioritization (2 days)

Five days for planning may not sound like a lot of time to plan for a business transformation, but if that is truly your sole focus, it’s actually fairly reasonable. In fact, two days to audit and prioritize is also reasonable, if your staff are fully focused on those tasks alone.

The issue with prioritization for most tech companies and large corporations with in-house teams is an unwillingness to be ruthless in that prioritization. No one is willing to say, “This is unimportant, don’t work on it,” in fear of accidentally insulting someone’s work, or accidentally deeming a task unimportant forever. But, in high-stakes environments, the only way to move at the necessary speed is to triage. (Side note: Here’s a great TED Talk about triage as both a stress management and a productivity tool.)

We advised instructors to flag legacy multimedia files and activities that could potentially not translate well to the new format. From there, we asked instructors to prioritize specific interactions based on their relative importance for course learning objectives and ease to carry out during the session, as-is. The following priorities were established (a bit of an adaptation of the Eisenhower Matrix):

Low importance, easy to facilitate
Temporarily remove, but revisit later

Low importance, hard to facilitate
Remove interaction altogether

High importance, hard to facilitate
Make immediate changes

High importance, easy to facilitate
Make no changes, keep as-is

The instructors (though I’d argue they are instructional designers) then got to work on preparing for their week-long design sprint, while I continued to summarize and document customer research to finalize the plan for implementation.

Research and planning (3 days)

I pulled together the following from previous 1-hour webinar events and live, in-person events

qualitative feedback survey & focus group comments
competitive reviews & heuristic evaluations
observing attendees who watched live in-person and live online events on various platforms
secondary (desk) research on live online event best practices

We identified a 4 core customer needs from this research:

content clarity & relevance
presentation reliability (A/V)
genuine & easy engagement
community connection

The first need was already relatively well-met, given the company’s excellence with in-person offerings. However, the last three prove to be much more problematic in online settings. Further, over-indexing on content often means a reduction in engagement and connection (in-person or otherwise).

Due to the quick timeline, the task force coordinated with leadership to establish some S.M.A.R.T. goals and benchmarks for improving these three factors: A/V reliability, engagement, and connection. These goals were extremely specific and indicated frequency, type, and outcomes for course and conference interactions.

Creating the plan (SOP)

Based on these goals, I created an initial standard operating procedure (SOP), featuring preparatory steps and best practices to coordinate the efforts of multiple roles and employees before, during, and after live online events. While I cannot share the SOP due to its proprietary nature, it did the following for our company:

informed iterative changes to our custom design system,
provided contextual information,
assigned roles and responsibilities,
acted as a form of content style guide, and
acted as an initial operational prototype.

In the Army, there is a place for SOPs: the operation order (or OPORD, for short). In the operation order, you can find details like the situational context, the mission itself, execution guidelines, logistics support, and communication protocols. Some sections include, “key tasks,” “coordinating instructions,” and “desired end states,” but as you might guess - these are all transferable to pretty much any complex plan.

SOPs can be thought of as an “operational prototype” or “operational template.” These are frameworks and established best practices that are passed on from operation to operation. Creating an SOP is a lot like creating an initial, reusable plan to help ensure proper implementation and execution, at scale.

Important note: while the SOP established clear standards and protocols, it was never meant to micromanage the creative process. It is, itself, a living artifact, and is meant as a starting point for the design process, to provide governance and guidelines for proposed changes. That said, by establishing outcomes, tasks, and expectations very clearly, the SOP enabled team members to make better, more informed decisions about their own respective product changes.

SOP vs. Design Systems vs. Service Blueprints in Service Design

It’s interesting how much design systems and SOPs have in common. A standard operating procedure is meant to help onboard new staff, and create consistency and alignment in the execution of a process or plan across many people. Design systems achieve that same outcome, albeit with a more built out system of repositories and guides. A common limitation of design systems (as they’re typically implemented, nowadays) is their primary focus on UI and visual components, rather than the interplay of interpersonal interactions and digital interactions. This is where an SOP is especially helpful.

When it comes to the design of a service, SOPs are typically less popular in comparison to service blueprints. In part, this is due to their primary focus on internal processes, and the lack of attention toward customer experiences. However, a common issue with service blueprints is the difficulty in maintaining the right level of detail for the scope of implementation work. While we’d established high-level service blueprints in the past to reflect upon our customers’ experiences taking courses, the greater need was to align service delivery steps and business processes. So, the SOP served as a necessary complement to aid in actual implementation and collaborative iteration of a service offering.

Design sprint (5 days)

Upon releasing this SOP, team members got to work improving our design system and the “products” themselves: the courses. With the support of management, this was the sole focus for my colleagues. The result: a hackathon-like environment which fostered organic collaborative problem-solving and feedback gathering. By the end of the 5 days, course changes had been drafted were ready for review, and the SOP was further refined based on feedback from instructors and event staff.

Office Hours & Huddles

A common issue with design sprints is the lack of collaboration: in an effort to meet tight timelines, people go “heads down” and don’t come up for air, so to speak, until they’ve finished their round of design. This doesn’t do wonders to maximize the effectiveness of design solutions. To ensure people got consistent, informal feedback during the design process, we regularly held “office hours” blocks and scheduled huddles.

Office hours were open sessions during which people could meet with someone from the task force and/or other instructors to get informal feedback (design review) on their adjusted course offerings. There were times no one attended office hours. Other times, 3 people would show up at the same time. However, the goal of these was simple: seek and provide feedback to each other.

Scheduled huddles had a similar outcome, but had more structured agendas, were recorded, and shared with anyone who could not attend. The primary goal of these was to give specific, actionable guidance in specific areas.

Eventually, when products were in a place where they could be “tested,” we did virtual “bodystorming” - or to phrase another way: we ran rehearsals and walkthroughs with assigned staff members to identify potential areas of failure or confusion.

Rehearsals & interactive walkthroughs (5 days)

Anyone who has done a lengthy presentation to a large audience will tell you about the power of rehearsals. Personally, I’d spent many years as a rehearsal skeptic: why waste time going through all these motions if you knew well what your tasks and responsibilities would be? However, years of seeing failed training operations and poor execution of strategy have convinced me that “rehearsals” - literal or figurative - are a foolproof way to find the failpoints of any offering.

The primary goal of these sessions: Improve familiarity of the process for immediate implementation

The secondary goal of these sessions: Flagging areas for iterative improvement

The runthroughs were both a way to build confidence with the roles and responsibilities within service delivery, while also helping identify key interaction points for each designer’s offering and flagging any major issues early enough for resolution (which is why, even though the runthrough itself took about 2 hours at most, 5 days were allocated to allow for refinement of the offering).

Regarding refinement: I’ve learned from several past projects that design by committee can slow down decisionmaking, sometimes to a destructive point. This is especially true of service design projects, where multiple service providers play a role in delivering a service, and likely have opinions of how the service should be rendered. However, collaboration is still important to get less biased perspectives and reduce blindspots, even if you are pressed for time. So, while we were open to feedback from instructional designers and staff members on improving the offering, we naturally ended up prioritizing it into three categories:

urgent resolution: bugs, reliability issues, or barriers to successful delivery of the service
next iteration(s): easy-to-implement process-optimization ideas or ways to competitively differentiate
backlog & future roadmap: infrastructure issues which need long-term planning to improve; and ways to improve the value provided for customers

This ensured our project could stay on track, achieve the highest quality possible for the first release, and planning for intentional, near-term improvement without jeopardizing release timelines.

Launch

Thanks to the help of my colleagues who sourced third-party technical support and trained up our events staff to perform in a virtual environment, as well as colleagues who refined our customer communications strategy, our team was able to go live as scheduled, and address all the technical concerns of our newly-virtual audience (during a time when Zoom meetings were still relatively “new” to people). Coworkers were well-supported, and had easy access to both third-party help and fellow employees who were awake at odd hours (9am in London was 3am in New York, and 12am in California!).

Many other companies I’ve worked with would likely not have been nimble enough to achieve this launch goal, so while my planning certainly helped with execution, it’s important to give credit to the dozens of coworkers who stepped up in significant ways and supportive managers who were willing to operate with an undercurrent of chaos and unpredictability.

Key takeaways

I’ve mentioned a number of great lessons learned along the way, but to summarize four important ones here:

Throw away the idea that innovation or improvement is “everyone’s responsibility.” Assigning clear roles and responsibilities to specific people avoids confusion and allows people to get started right away. Flexibility is a great virtue, but a terrible org chart and project plan.
Prioritization is only as effective as how ruthlessly you deprioritize. Having seen many “vanity” prioritization efforts, you can’t simply label “high priority” to several initiatives and expect them to suddenly get done. True prioritization means focusing, and giving clear timelines and deadlines to that focus.
There’s no such thing as a perfect plan. Respect the timeline, communicate whatever semblance of a plan you have as early as possible, and adjust along the way. As Voltaire once said, “Perfection is the enemy of good.” A well-thought, 70% plan communicated early is far more effective than a 90% plan communicated too late.

Governance ≠ micromanagement. Ironically, governance enables autonomy. Establishing guidelines, constraints, and outcomes may sound like a micromanaging strategy, but it actually enables better autonomous decision making and improves trust. Micromanaging, on the other hand, is what happens when a strategy is not well-communicated, and a leader does not trust their team to carry out the mission. Governance and clear communication of standards helps teams make informed decisions and work quickly and reliably.

This transformation project is one I’m still proud of, 5 years later. While it was an honor to be trusted to lead such an important project for the company, it is more a testament to the resilience of the people I’ve been lucky to work with, and is truly exemplary of the best team work I’ve ever witnessed.

•••

← Back to all case studies

Next: Service Design Workshops for a Telecomm Company →

Leading a 3-Week Radical Business Transformation

The successful implementation of any solution depends on clear, realistic goals.