Purpose
The Scenarios module usually serves as a transition from Scan into Focus. For the first time in the event, teams of participants are given a significant block of time to wrestle with problems that relate to the solution they have come to the Accelerated Solutions Environment to develop.
The scenarios pose extreme or challenging situations that constrain the scope of what each team can design.
These constraints are creativity drivers. Each team is put into a box and challenged to design their way out of it. This design process does not quite feel "real", giving participants the freedom to experiment more freely with their ideas. (Note: A related type of scenario can be used to test initial models of the solution. See Stress-Test Scenarios.)
Description
Each breakout team receives a different scenario. In general, some groups receive success scenarios and some receive failure scenarios.
Each scenario is set in the future---usually between one and three years later. It presents a situation that has already occurred and asks participants to explain how and why it happened.
As noted above, most scenarios involve some sort of constraint. These constraints can be in the form of obstacles (e.g., reduced resources, a new competitor in the market, etc.) or limits upon the type of solution they can design (e.g., "you were able to achieve this tremendous growth thanks in large part to your program of mergers and acquisitions").
A series of questions accompanies each scenario, helping to ensure that the group's explanation is robust and doesn't shy away from important issues.
Critical Success Factors
Good Topics. The solution that clients are trying to develop involves complex issues and problems. In the Scenarios module, we usually ask a group to focus on a narrow aspect of the solution or its associated problems. The ability to identify good topics depends upon a good understanding of the client, the client's problem, and the environment in which the client operates. The goal is to arrive at topics that are challenging, provocative, yet plausible.
Good Writing. The scenario must be written in a way that gets participants past their natural inclination to dismiss its premise as unlikely. Only then will they invest the sort of energy and creativity that will result in breakthrough ideas. The writing should sum up the scenario in one or two clear, concise, and engaging paragraphs.
Start Writing
The advice presented here assumes that you have to write your scenario assignments from scratch. If you're lucky, you may be able to adapt one or more assignments from existing examples. This section concludes with some advice about adapting existing assignments.
Most of the effort in writing a scenarios assignment is focused on two sections.
- The Scenario — a paragraph that establishes the premise upon which a team's work will be based.
- The Questions — a set of questions that raise important issues the team must consider if it is to accomplish its goal.
The assignment will also include a number of logistical elements — i.e., the time frame of the assignment, the goal of the team's work, etc. These should not take much time to draft. Once you have them right, they can pretty much be copied from one assignment to the next.
The Scenario
The scenario should state the situation clearly. It should do so with confidence. Helping to underscore this confidence is the fact that the scenario puts the participants into the future. It usually begins by stating that it is one, two, or three years in the future. Something tremendous has happened (or something terrible), and the team is asked to look back and explain how and why it unfolded that way.
A scenario written in a straightforward, no-nonsense way can be effective. On the other hand, a scenario that is layful and engaging can draw the participants into the situation. In fact, the scenario paragraph (a version of which is also used in Take-A-Panel) is about as creative as writing gets in a DesignEvent.
You are trying to get the participants to accept a premise that, to a lesser or greater extent, challenges their conception of the future. You want them to set that conception aside and envision and work within the framework of the scenario's reality. The more compelling that reality, the more likely they will be launched into it.
Here, then, is an example of a simple, straightforward scenario. It's from a Scenario assignment that was titled "Balance":
"It has been a year since the implementation of the project and the launch has been a tremendous success. With such a complex implementation, a key factor to the project's success was finding the optimal balance between utilizing legacy systems, implementing package solutions, and developing manual processes. You have been asked to prepare a brief report on how you reached this balance."
This is fine. It does the job. Most importantly, it is clear and easy to read. The team working on it should have no question about what they're dealing with.
Here is an example of a scenario that takes a more playful, engaging approach:
"It is January 2002 and the project has been implemented and beta-tested. It rocked! People across the company and outside it now have instant access to complete and accurate data — current as well as converted legacy. Data can be shared and reported real-time with hospitals, surgical centers, physician groups, pharmacies, and government payors to name a few. Inputs run as smoothly and efficiently as outputs.
"The system is such an unqualified success — far exceeding expectations — that it has become the benchmark for financial data management, and you have been asked to tell the story of our data approach at a global health care symposium."
Whether your intention is to write a simple scenario or a playful, engaging one, your level of understanding will determine how good a job you can do. You must be able to visualize the reality you are trying to convey. Otherwise, you will not be able to create a piece of writing that enables a group of participants to visualize and work within that reality.
The Questions
The scenario establishes the reality within which the team will work. The questions frame and direct that work.
Four to eight questions is a good range to work within. The average is about six. You want these to be meaty questions. They should point toward difficult issues that need to be resolved. They should set high expectations for the team's work, which will create a sense of urgency and hopefully result in a robust output.
Once again, in order to generate good questions you must be able to understand and visualize the reality of the scenario. What are the implications of the situation the scenario presents? What are the tough nuts to crack in order to be successful in that situation?
Let's walk through an example. One scenario we sometimes use involves rolling out an implementation much more quickly than people tought was possible. Let's call it "Fast Track Rollout." And let's assume that the scenario says the implementation was rolled out smoothly and successfully in half the time expected.
The next thing you might do would be to think about the issues you need to deal with in a rollout. You need to develop a rollout strategy. You need to decide where to rollout first. You need to decide how and where to do any piloting. You need to gain buy-in and involve users in the rollout approach. You need to handle any training needs. You need to run and meet the needs of the existing business while the rollout is occurring. You need to be able to measure the success of the rollout. You need to respond to unanticipated events. You need feedback loops in order to refine and adjust the rollout as necessary. There are more, but build an initial list of these issues.
You would also want to think about the issues that relate to speed and time compression. Sometimes you may want to list the issues first, and then use them to develop your questions.
However you approach it, you need to think in terms of this specific client and their specific situation. Some issues are bound to be more critical than others.
You should also think about how your questions are ordered. In general, it is best to put the most important and broadest questions at the top and work your way down through the questions from there. Ideally, one question leads logically to the next.
Here might be an initial draft of questions for the "Fast Track Rollout" assignment:
- What was your rollout strategy? How did you communicate that strategy and develop the buy-in critical to a successful rollout?
- How did you manage the rollout project? Who was responsible for what?
- What were the most important breakthroughs that enabled you to accelerate the rollout?
- What was your piloting and testing approach? How did you determine where to pilot? Where to rollout first?
- How were you able to establish this rollout as a priority without sacrificing the performance of the overall business?
- How did you coordinate the cooperation and synergy needed across the enterprise for such an accelerated rollout?
- What feedback loops did you build into your rollout so that you could refine and adjust your approach as needed?
- How did you measure the success of the rollout?
The above list contains more questions than you would want to end up using. Some people prefer to generate more questions and then combine and prune them as they iterate. Others prefer to start lean and then build on more questions as they iterate.
You also may find that some issues a client is facing may run across all of the scenarios. In that case, there may be one or more important questions can be asked in all of the scenarios.
Adapting Existing Examples
There are more than 300 examples of scenario assignments provided here, catalogued by client, by solution, and by topic. It is therefore likely that you will be able to find examples for some of the scenario assignments you need to write.
If you do find a good example, it is important to treat it as a starting point. In essence, it gives you a better foundation upon which to build. Your effort will be directed more toward adding value as opposed to just meeting the bare minimum requirements.
First, cut and paste the example into your template. Then change the simple things, such as the name of the client, the name of any project, the time frame in which the scenario is set, the time the team has to complete the assignment, etc. Doing these simple things up front will ensure that you don't overlook them.
Then look at the scenario and see how it needs to be adapted. Because you will have a good starting point, you can now focus more on taking the writing to the next level. In this case, you can also look at assignment examples that are not related to those you are going to write, just to get different ideas for how the writing can be approached
When it comes to the questions, if you have a good example it is likely that some of the questions will apply to your assignment. But as with the scenario, the more examples you have to to work with the better. You may be able to pick and choose good questions from a number of different examples. This will give you a good starter set, which you can then iterate in terms of your event.
Team Approach
Scenarios assignments are one of the more challenging sets of assignments for a facilitation team to prepare for a number of reasons.
- They require a fair amount of subject matter and client familiarity.
- Each team gets a unique assignment (although there can be overlap).
- The module usually takes place during Focus, which means work on it is often delayed until the event has already begun.
- The quality of the writing tends to be more critical to the success of the module.
These challenges can be approached from sane and insane directions. One sane approach is outlined below. The insane approach is to put off work on Scenarios as long as possible, trusting that things will work themselves out. Things always do work themselves out, of course; but you may not be happy with the results.
Before The Event
The pre-event facilitation team (facilitator, AR, PF) can identify a preliminary list of scenarios topics in advance of the event. Collaborate with the engagement and/or sponsor teams in this effort. This is not always done. When it is, it is very helpful. (See advice about creating the list of topics below.)
Make sure that the engagement and sponsor teams understand that this is only a preliminary list. It very well may change at the event.
Distribute this list to the Krew before the event (usually as part of the event straw dog). That way, whoever ends up working on the scenarios assignments will have had a chance to consider the topics.
At The Event. There are a couple of things that will help you prepare to create the scenarios assignments. First, listen carefully during the initial circle-up and then the sponsor walk-through. Overviews will be given about the client, its situation, and the objectives of the event.
Second, look over examples of scenario assignments.
Next, look at the two lists of scenarios in the sidebar window at right. You will use a list like this to iterate your topics and to get the feedback and approval of the sponsors.
Before you begin working on the Scenarios module, discuss it with the facilitator(s). Each facilitator has his or her own ideas and preferences when it comes to specific assignments. Ask questions. Repeat back to them what you think they have said. Then get to work.
It is often easiest to generate a starter list of scenario topics as a group. That helps to get everyone on the same page. Sometimes, you can start as a group and then one or two of the team members can finish it.
Creating A Good List
With a couple of exceptions, you really shouldn't start writing scenarios until you have developed the list of scenario topics that you will present to the sponsors.
One notable exception can be when you think you will be doing a failure scenario. Usually, these are pretty straightforward. Good examples exist that can be adapted with little work.
The list of topics is a series of one-line explanations of scenario premises. Each topic is numbered and has a short title, which makes the topics easy to discuss in the sponsor meeting.
Good topics will address the critical issues/problems the client faces in developing and implementing its solution.
Is speed an issue? Try a scenario that says the goal was accomplished in half the time. Is flexibility an issue? Try a scenario that says the market shifted, yet the client succeeded because their solution was so adaptable. Will running the business while the project is rolled out be difficult? Try a scenario that says they grew twice as fast as expected yet customer satisfaction has never been better. Failure scenarios are good, because they get participants to deal with weaknesses and threats.
Iterate and refine your list first with the full writing team and then with the facilitator. Make sure the facilitator understands what these scenarios are about, because he or she will be explaining them to the sponsors that evening. Make enough copies of the final list to distribute to everyone in the sponsor meeting. Then, draft a full set of scenarios.
Note: it is a good idea to create a list that has at least one or two extra topics. That way, when you present the list to the sponsors, they can simply eliminate the one or two they feel are the least powerful. (Sometimes they will combine a couple, or come up with a new one.) It is a lot easier for sponsors to pick the ones they like than it is to develop new topics from scratch. Having extras in the list contributes to a more efficient sponsor meeting.
Three-Day Events
If possible, get your list of scenarios done by the end of the prep day. This enables you to show them to the sponsors who review assignments the following morning.
Try to draft at least one scenario assignment on the prep day. (A failure scenario can be a good choice to draft first, because the examples available here are pretty good and shouldn't need much changing.) Once one scenario is drafted, you will have a template for writing the rest of the scenarios.
Anything you can get done on the prep day will be a blessing, because Day One can be pretty crazy. Early on, you'll be finishing and handing off the Day One assignments to production. After that, you'll be helping to support such modules as Take-A-Panel or Win As Much As You Can. It's likely you won't get a chance to work on the Day Two assignments until the participants are in a trade show or reading module.
When drafting assignments during Day One, start with the topics that seem strongest. Get at least a rough draft done on as many of the topics as possible. Ideally, you'll get a draft done for all of them. Although one or two will be eliminated during the sponsor meeting, it is easier to iterate an existing assignment than it is to start from scratch.
Once the sponsors have reviewed the topics and approved the final list, do not hesitate. Whoever will be working on scenarios should peel off from the sponsor meeting at that point (or work on their laptop in the back of the room).
In those cases where the sponsors have reviewed and approved the list of scenario topics at the beginning of Day One, you should certainly have a good draft of each of them done by the end of Day One. Sometimes, the facilitator will have had a chance to review and edit these. In this case, he or she may want the sponsors to review them that night instead of the following morning.
Usually, the facilitator comes in early the morning of Day Two to review and iterate the scenario assignments before the sponsors see them.
Because the Scenarios module usually is scheduled early during Focus, it is unlikely that the assignments will change after the sponsor's morning review.
Two-Day Events
You will need to finish your Scenarios assignments on the prep day. In this case, the discussion of the scenario topics will take place during the sponsor walk-through. This means that it is important to have a good list developed before the event. On the other hand, it is less necessary to have a list to distribute to the sponsors, because the topics will be built into the strawdog being reviewed with them.
Listen carefully during the discussion of the topics and take notes, because the facilitator and sponsors should provide excellent insight into the premise and questions for each assignment.
After the walk through, someone should start working on the scenarios. You want to make sure that you can iterate the scenarios at least a couple of times. Ideally, members of the writing team will draft the scenario assignments, review and iterate them. The facilitator review will enable another solid round of iteration. You should be able to get this done by a reasonable hour on the prep day.
Once the event starts, expect that you will need to revise the scenarios. Usually, issues arise that were not anticipated. Sometimes, an idea for a new scenario will emerge. Plan to get together with the facilitator at some point during the Scan phase to discuss the scenarios.
A Note About Pre-Writing of Scenarios
Pre-writing of scenarios can help on two important levels.
First, as with all assignments, pre-writing enables you to get the assignments into a template so that you can focus your effort at the event on the sections of the assignment that benefit from iteration.
Second, it can be difficult to draft scenarios before the event because you often don't have enough understanding of the client, its situation, the solution they're trying to develop at the event, etc. On the other hand, the struggle to establish a preliminary draft will enable you to frame the questions that will clarify the understanding you need. In short, it gets your head in the game.
As a result, you should not expect to a robust first draft of scenarios during pre-writing. Nevertheless, some effort spent drafting a preliminary set of scenarios is worthwhile.
Of course, the more you are involved in the advance preparation for the DesignEvent, the more context you will have and the easier it will be for you to create a solid draft during the pre-writing process.
FAQ
What is the difference between a Scenario and a Design Challenge?
Their names. Beyond that they are the same. In fact, about half the examples provided in the Scenarios Examples section were called Design Challenges at their events.
Scenarios are sometimes refered to as Future-State Scenarios, because they present situations set in a future-state framework.
They are also sometimes referred to as Scenario Takeaways, because they often force participants to overcome a handicap. For instance, a disruptive technology comes along and eliminates your marketplace advantage. How did you do it? Or budget constraints force you to complete the project with half the money. Or a new competitors enters the market, forcing you to compress the implementation cycle by half.
Design Challenges are also set in the future. By definition, they also involve some form of takeaway. Thatis what makes them challenging.
Whether you call them Scenarios or Design Challenges, they achieve the same thing.
Why would you use this assignment instead of Build-A-There?
Use the Scenarios assignment as a way of transitioning toward problem solving that feels real. Also use it when you want to drive creativity in approaching the problem at hand. We ask participants for a bold response to a challenge and know that they will often give us one; albeit at a pretty high level (not a lot of detail). That's OK.
Build-A-There, on the other hand, is very real. We tell the participants to decide what they should really do. We might as well douse them with a bucket of cold water. Again, that's OK. They've got to get it over with sometime. And midway through Focus is about as good a time as any for it. It's not that we don't want them to be creative. It's just that we know they will most likely get really conservative. They will also shy away from the details where all the land mines are lurking.