Close

Process Patents and Collaboration

Posted on by Robin Brooking


The patent process in the US is undergoing signification changes and among these changes is whether business methods are actually eligible to be patented. In an era where the ability to share information through collaborating and networking has grown exponentially and is changing daily, this is a subject worth keeping an eye on.

In "Why Technologists Want Fewer Patents" (Wall Street Journal Opinion Journal, June 15, 2009) Gordon Crovitz wrote:

"Thomas Jefferson, the nation's inventor-president, would support patent reform in a era when new information technologies build on themselves. An idea, he observed, is a rare thing whose value increases as it's shared. 'No one possesses the less because everyone possess the whole of it,' he wrote. 'He who receives an idea from me receives it without lessening me, as he who lights his candle at mine receives light without darkening me.'"

Words to live by even today...stay tuned for more updates.

Related articles:

BusinessWeek: Supreme Court to Review 'Business Method' Patents

Portfolio: The End of Business Process Patents 

ArticleBase: Software and Business Process Patents in the US: Not so Eligible 

IP Watch: US Supreme Court to Rule on Business Method Patents 

Collaborative Session Research Tips

Posted on by Robin Brooking

With so many research lists and knowledge options available to knowledge workers, consultants and meeting managers, aggregation sites often speed up research methods and project delivery time.

Newspapers:

http://www.world-newspapers.com
A comprehensive list of news publications (magazines and newspapers) covering everything from business to environment to fashion and entertainment.  

Library:
http://www.libraryspot.com/
A free virtual library resource center for educators and students, librarians and their patrons, families, businesses and just about anyone exploring the Web for valuable research information.

Research:
http://www.rcls.org/deskref/
484 research links.  

Web:
The best of everything on the web- all in one place and categorized for you. From
Bacon
http://bacon.alltop.com/
to
Consulting
http://consulting.alltop.com/

Got your own research list? Click on 'Post a Comment' to share your best. 

 

Yellow Pages

Posted on by Brandon Klein

The Yellow Pages assignment is very straightforward, and will require a minimal amount of adaptation. If anything, you may want to adapt the questions a bit to suit the focus of the client's work in the event. For instance, if the participants are designing a CRM approach, you may want at least a couple of the questions in the Yellow Pages assignment to focus on the customers of the merged entity. (For example: Who are the customers of the new business? How will you address the needs of both companies' customers in the new organization?)

Remember, keep this assignment short. The teams have very little time to complete their work. It should not be difficult for them to read and understand what they have to do.

The most difficult aspect of this module from the writing team perspective is selecting the Yellow Pages ads. Selecting good pairs of ads is fun, but it takes more time than it might seem. Budget at least an hour or so for this. 

UPDATE:

Instead of creating team lists and dividing teams into break out groups, simply have the participants break into small Kotter groups. This increases the energy in the room, speeds up the exercise while still generating all of the desired outcomes. 

 

 

 

Click to download an example assignment. 

Cups & Straws Module

Posted on by Brandon Klein

This module was originally developed by Sandy Worthing and Andy Heppelle.

This module is a small team activity that can be tailored for multiple experiential learning goals.

It can focus on:
 - Benefit of Rapid Prototype - for the team that is considering changing the way that they build products (IT or non IT alike)

 - Benefit of Client Intimacy - for the team that is trying to become more responsive/interactive with their Clients and more agile in the Market

 - Benefit of Cross Disciplinary Communication - for the team that is in an organization that has barriers to intergroup collaboration

Debriefs of the Session tend to be very rich with a focus on the "voice of the Customer" and "how it feels" when you are forced to "just do the job as laid out in the written requirements".

This module also relates to the Pattern Language article on The Value of Indirection.

 

 

Basic instructions:

Round 1: Customer Team Moderator/Facilitator: Brief the Customers on what the other teams are doing, then Launch them into building the prototype for round 2 (based on a prefab prototype we build the night before). Provide a template that makes it easy for them to record the successful results. Prompt them to think about what they expect, as a Customer, from their Suppliers, when it comes to communication and product delivery. Ask them to compare their prototype to the written requirements and see if they think it is easier to build from written specifications or from a model or picture.

 

Round 2: Customer Team Moderator/Facilitator: Have the team quickly change their prototype. As they will start to get products in and it stops their ability to do their jobs. As they make jokes or observations about the progress of their teams, it worked well to ask them if they would share their observations at the Debrief. Explain that in the next round they may indeed be asked to join their production team and ensure that they understand their mission is to continue to record successful products and to show the team what they want (whatever prototype they want) as soon as they get there (ask them to focus on a quick simple change that forces their team to react and change any products that they haven’t yet delivered ( hoping the focus here will be on agility and Client responsiveness)

 

Key Observations:

- Building the Prototype to start everything was genious (thanks Andy L)

- Having separation in the space by using the shipping/Receiving station Rocked

- Having the Shipper/Receiver either bring product to the Customers or tell them that a shipment had arrived worked well.

- Ensuring that products were counted and recorded as quickly as possible made a big difference. Those Customers that got behind, bogged down the process (although that was a good conversation point in the Customer team)

 

 

 

  Click to download all the assignment files

Experience Video; Photo Slideshow; Be An MTV Editor With Ease

Posted on by Brandon Klein


No matter what type of photographer or videographer you are, you now have a friend to make you look professional (even if you are already professional!)

Simply go to animoto.com and upload a few pictures and videos and they will do all the work of creating a video/slideshow for you. Don't like it... simply hit remix and you will get a new version. Prices for unlimited videos start at a totally reasonable $3.

Read a review on Mashable about the service.

Check out the Getty Images case study (yes, even Getty uses it.)

PulpMotion is another great software alternative as well.

Commitment Statements

Posted on by Brandon Klein

Clean, Clear Commitment Statements. Here are some general ones:

Register to upload new ones!

(1)

We have worked hard. We have addressed the tough issues. We have focused on the customers needs. We have considered many options and we have debated the approach. We have decided that we will dedicate ourselves to implementing XYZ as the first step in our journey to realizing "XYZ." Every member of this team is already a winner. The results of this project will help make our company a huge success and our customer will be the biggest winner of all.

(2)

The ______________________ management team met in XYZ on _____________ to decide how to propel our business from startup into the future. We took a look at our customer needs and realized we had gaps in our processes and needed additional touch points between our functions. As a result our goal is to ensure that the entire organization is process-focused and aligned to exceed our customer needs.

We validated our vision, mission and values upon which we based all our decisions. We focused on customer needs and decided that great transmission will be defined in terms of customer service. Customer service will be the differentiator for the transmission industry. Not only are our customers important to us, but also our stakeholders’ interests will be critical to our overall success. Our stakeholders include ____, environmental groups, ______, etc.

During the XYZ days we designed the _______ operating model and agreed upon the key ________ mega-processes. __________ will be process-based and we will transform our mode of operations to ensure success. Decision-making will be made at the appropriate level within the organization; we will promote delegation and foster accountability; we will work cross functionally to ensure that the touch points between our processes are efficient and that we meet customer expectations; we will be proactive with the big picture in mind.

We used the XYZ and spent time learning about different ways our solution might work, testing the options, and finally deciding what would become the ___________ solution. We expect that our initial design will grow and evolve as we become experienced with it and look forward to a complete rollout within the next few weeks. We developed a roadmap to move forward with key initiatives, targets and milestones. Your manager will be able to provide you with more information on our work and decisions.

 

Scenarios

Posted on by Brandon Klein

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.

  1. The Scenario — a paragraph that establishes the premise upon which a team's work will be based.
  2. 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.

  1. They require a fair amount of subject matter and client familiarity.
  2. Each team gets a unique assignment (although there can be overlap).
  3. The module usually takes place during Focus, which means work on it is often delayed until the event has already begun.
  4. 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.

Design Challenges

Posted on by Brandon Klein

Purpose

The Design Challenges 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 module can be used to test initial models of the solution. See Stress-Test Scenarios.)

 

Description

Each breakout team receives a different design challenge. In general, some groups receive design challenges that are based on success scenarios, and others receive design challenges based on failure scenarios.

Each design challenge 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 design challenges 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").

Each design challenge includes a series of questions, 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 Design Challenges 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 design challenge 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 design challenge in one or two clear, concise, and engaging paragraphs.

 

Start Writing

The advice presented here assumes that you have to write your design challenge 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 design challenge assignment is focused on two sections.

  1. The Scenario — a paragraph that establishes the premise upon which a team's work will be based.
  2. 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 playful 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 an 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 paragraph 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 design challenge. What are the implications of the situation the design challenge presents? What are the tough nuts to crack in order to be successful in that situation?

Let's walk through an example. One design challenge 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 design challenges. In that case, there may be one or more important questions can be asked in all of the design challenges.

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 design challenge 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 paragraph 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 paragraph, 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

Design Challenges are not just challenging to the participants. They can be one of the more challenging sets of assignments for a facilitation team to prepare for a number of reasons.

  1. They require a fair amount of subject matter and client familiarity.
  2. Each team gets a unique assignment (although there can be overlap).
  3. The module usually takes place during Focus, which means work on it is often delayed until the event has already begun.
  4. 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 design challenges 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 design challenge 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 design challenge 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 design challenge assignments. Go to the Design Challenges Examples page by clicking on the appropriate button at the top of this column or on this link.

Next, look at the two lists of design challenges 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 Design Challenges 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 design challenges until you have developed the list of topics that you will present to the sponsors.

One notable exception can be when you think you will be doing a failure design challenge. 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 design challenge 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 design challenge that says the goal was accomplished in half the time. Is flexibility an issue? Try a design challenge 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 design challenge that says they grew twice as fast as expected yet customer satisfaction has never been better. Failure design challenges 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 design challenges 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 design challenges.

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 design challenges 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 design challenge assignment on the prep day. (A failure design challenge can be a good choice to draft first, because the examples available here are pretty good and shouldn't need much changing.) Once one design challenge is drafted, you will have a template for writing the rest of the them.

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 design challenge 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 design challenge assignments before the sponsors see them.

Because the Design Challenges 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 design challenges assignments on the prep day. In this case, the discussion of the design challenge 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 design challenges. You want to make sure that you can iterate the design challenges at least a couple of times. Ideally, members of the writing team will draft the design challenge 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 design challenges. Usually, issues arise that were not anticipated. Sometimes, an idea for a new design challenge will emerge. Plan to get together with the facilitator at some point during the Scan phase to discuss the design challenges.

A Note About Pre-Writing of Design Challenges

Pre-writing of design challenges 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 design challenges 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 design challenges during pre-writing. Nevertheless, some effort spent drafting a preliminary set of design challenges 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 Design Challenges Examples section were called Scenarios at their events.

Another name for Design Challenges is 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.

Whether you call them Design Challenges or Scenarios, they achieve the same thing.

Why would you use this assignment instead of Build-A-There?

Use the Design Challenges 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.

Build-A-There

Posted on by Brandon Klein

Purpose

Every module in a design event can be considered pivotal, and probably in several ways. Build-A-There is no different. There are a number of ways in which this module can be considered pivotal.

It is generally the first time that we let the participants collaborate directly on the design of their solution. There is no misdirection or indirection in the way we frame the work. Usually, the assignment is extremely straightforward. We tell them what to create and provide some general specifications for the output they are expected to achieve. In essence, we point them at a piece of the solution and say, "Design it!"

By now, the participants should be ready to take a crack at designing their solution. They have spent all of Scan and half of Focus exploring and learning, shrugging off their normal structures, and developing the enlarged perspective and depth of understanding needed to create the problem. They also have been forging a new working culture, forming a common pattern language, and preparing for the emergence of group genius.

This is where the concept of "Decision by Design" really comes to the fore. Each team is given a manageable slice of the solution to model. They are also given a fairly large chunk of time to develop that model and reasonable latitude in what they can design.

The work they are doing suddenly feels very "real." We are no longer taking metaphorical approaches, nor putting stakes in the ground for them. Now, we ask them to put the stakes in the ground.

As a result, there can be a tendency for participants to get incremental in their thinking. Breakthroughs can and do occur. But when asked to make real decisions, to design the real future, it is human nature to pull back and retreat to what is safe, to what is already known.

Build-A-There is therefore a trial run for the Act phase. It lays the foundation. By getting in and actually engaging in detailed modeling, the participants gain an even greater understanding of what they need to create. It may not be apparent that they are creating it yet. (Some aspects of the eventual solution will be more apparent than others.) But they are eliminating options. Even the incremental thinking will be useful once they proceed into Act, because they will, as a group, react against it. They will know where they need to leap further, be bolder.

Build-A-There is also a trial run — a dress rehearsal, if you will — at handing control of the DesignEvent back to the participants. Up until this point, we have taken on the role of executive control. But we are getting them ready for the handoff that has to be made if the solution is to be of, by, and for the participants. This is how they take full ownership, full responsibility, full accountability for their solution.

In Build-A-There, we don't formally make that handoff yet, because we still assign the work and select the teams. But the participants may, in fact, seize control of the DesignEvent at this point. Be ready for this possibility.

 

Description

Usually, this module has two rounds, giving the participants the chance to attack the solution from two different dimensions or to take it to two successive levels of detail.

The facilitation team will have worked with the sponsors to slice the work up into meaningful chunks that individual teams can tackle. The result is parallel processing that adds up into a draft of the solution. Many of the Build-A-There topics can end up being topics that a team will take on in the Act portion of the event. But by going through Build-A-there, the group may realize that there is a new chunk of work that needs to be tackled. Or they may realize that some of the chunks are too big for one team, or can be combined with others.

Sometimes, all of the teams work on the same body of work in the first round and different pieces of it in the second round. Other times the two rounds of work come at the solution from different dimensions: for example, designing around products or markets in the first round and around processes in the second. There are many ways that the work can be organized.

In between those rounds, there can be a full group report out in the Radiant Room or a shift and share report out in breakouts. Either way, the teams are usually shuffled from one round to the next.

Sometimes a short module called Why It Won't Work is used immediately after the report out of the second round of Build-A-There work. (If this module is used, it is the last module of the Focus phase of the event). This enables participants to write down comments or questions they have about the work that has been reported and post them directly on the hypertiles, which are left on the Radiant Room walls. This can also be a way to keep questions after these reports to the minimum needed for clarification. The facilitator tells participants to capture their questions on the post-it notes with which they are provided.

Another common name for this module is First Draft/Second Draft. It has also been called a lot of other things, such as Building The There, Modeling the Future State, etc.

Critical Success Factors

Good Work Topics. The way the work is divided up in this module is critical, because it lays the foundation for the Act day. These topics should be co-designed with the sponsor team.

Clear Assignments. The written assignments should be clear and to the point. As with the work topics, there are many different ways to handle these assignments. Often times they are quite short. Sometimes they are quite detailed. There is no prescribed "right" model. Shape them according to what you think will work best for the participants. However you handle them, write them so that the participants understand what is expected of them.

Start Writing

In a three-day event, it is difficult to begin writing Build-A-There assignments until the event starts. First of all, the prep day is usually consumed with writing the day one assignments. If there is time to work on day two assignments, then other modules are usually easier to start on.

Part of the problem is that the way to chunk the Build-A-There topics may not become clear until the event begins to unfold. More often than not, the serious co-design of this module will not begin until the sponsor meeting the evening of day one.

Nevertheless, the facilitator and AR will often have a going-in position. It is good if the writing team gets a high-level understanding of this going-in position on the prep day. It can also begin to consider that model. But the team may not really understand the model until after it has written the day one assignments and begun to see and hear the participants work.

Things to think about include:

  • How does the Build-A-There 1 work relate to the Build-A-There 2 work? Does the second round take the work completed in round one and flesh it out to a deeper level of detail? Or does it focus on a different area of the solution?
  • How does the Build-A-There work relate to the objectives of the DesignEvent? If this module sets up the work on the Act day, then it should be targeting the keys areas of the event objectives.

Working with the facilitator, you need to come up with a game plan for this module. Once you have it, you can begin drafting your assignments. If this is a three-day event, then this writing is done during day one, with the understanding that it all may change when the sponsors review the day two straw dog that evening.

Part of your game plan will involve determining how robust the assignments will be. This can range from a lean assignment on a hypertile to a detailed assignment on paper. Also, you can determine whether the assignment for some or all of the teams will be the same. Sometimes, they actually all do the same assignment, such as designing an organizational construct. Other times, they work on different topics, but the assignment each team receives is essentially the same, with only the topic changing.

For instance, if each group was designing a different process, then all of the assignments might ask the same questions (or specify that the same elements be addressed). The name of the process would be the only thing changing.

On the other hand, one team may be drafting rules of engagement, another may be developing an operating model, and a third may be designing an eBusiness strategy. In this case, there is much more call for each assignment to be customized.

The assignment should always ask the team to develop a model. In many cases, you will want this to be a high-level visual model. Obviously, there are instances where this would not be as appropriate. (For instance, for the team that was developing rules of engagement.)

You will also want them to supply the details that support that model. The teams need to be pushed toward validating their models in this way. Often times, it is in the details where they will finally confront the controversial issues they have been avoiding.

As with the assignments for most modules, begin by developing a template that embodies the characteristics you have determined with the facilitator (lean vs. robust, generic vs. customized, etc.). Then write the assignment for one team. At that point, get feedback on this model if you can. That way, you won't have to make the same changes in multiple assignments.

Then draft an assignment for each of the teams. Do not worry about perfecting this draft. Build-A-There assignments require the most content and client expertise. Leverage the iterative process as much as you can.

Hypertile vs. Paper

There are some important considerations when trying to decide whether to use a hypertile or letter-sized paper assignment for Build-A-There. First of all, how much information do you want to include in your assignment? To be effective, a hypertile assignment should not have type that is smaller than 40 or 42 points. Nor should it be crammed margin-to-margin with words. It should be easy to scan and understand from ten feet away in ten seconds or less.

Second of all, how do you want the team to be focused? A hypertile assignment has a wider, group focus. A letter-sized paper assignment has a closer, more intimate, individual focus. If the assignment has several involved instructions on it that are critical to the module's success, then you should consider distributing these on letter-sized paper. Each person will then concentrate more on reading and interpreting the assignment. Their individual interpretations can come into play as the module unfolds.

Saving paper is not an important criteria by which to decide whether to use hypertile assignments. First of all, a tabloid sheet of paper is the equivalent of four letter-sized sheets of paper; so you may save half the paper normally used. Second, and more importantly, the written assignment is a facilitation element. It will trigger and define the work done by the teams for 90 minutes or so. The decision about the format of that element should be based on facilitation value, not on saving 20 to 40 sheets of paper.

I like hypertile assignments. They are excellent when used appropriately. If used inappropriately, they can compromise the success of a module.

Adapting Existing Examples

There are more than 120 examples of Build-A-There assignments provided here, catalogued by client event and by topic. It is therefore likely that you will be able to find examples that can at least provide a model for the Build-A-There assignments you need to write.

In looking for a good example, I look first for a structural example. I try to find an example that comes closest to matching the structure I want my assignments to embody. I use that as my starting point, and make whatever structural adjustments I see fit.

I cut and paste the example into the assignment template for my event. Then change the simple things, such as formatting, the name of the client, the name of any project, the title of the assignment, the time the team has to complete their work, etc. Doing these simple things up front will ensure that I don't overlook them.

Then I look for examples that can help me with assignment content. I look to see what kinds of questions and/or design specifications have been included in similar assignments in the past. This is helpful to me, especially the less I know about the topic area of an assignment. It helps me to learn and also helps me to see other things I might ask or specify in the assignment.

It is important to treat any assignment example— whether for structure or content — as a starting point only. It provides something to react against. It also provides a baseline, so that effort can be directed more toward adding value as opposed to meeting the bare minimum requirements of a good assignment.

 

Team Approach

Build-A-There assignments can be a challenging set of assignments for a facilitation team to prepare for three reasons:

  1. They require a fair amount of subject matter and client familiarity.
  2. The module takes place during Focus, which means work on it is usually delayed until the event has already begun.
  3. There are usually two rounds of work, each requiring a different assignment. Sometimes, each team in these rounds receives a unique assignment.

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 Build-A-There as long as possible, trusting that things will work themselves out. Things always do work themselves out. But not necessarily for the best.

Before The Event

The pre-event facilitation team (facilitator, AR, PF) can identify a preliminary design for the Build-A-There module 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 design below.)

Make sure that the engagement and sponsor teams understand that this is only a preliminary design. 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 Build-A-There 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 Build-A-There 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.

In particular, pay attention to the objectives of the event. Those objectives in large part define the work that will be done on the Act day, and the Build-A-There module is often a first cut at the Act day work. Therefore, the Build-A-There topics will usually be grounded in the event objectives.

Second, look over examples of assignments. 

Before you begin working on the Build-A-There 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.

Whether these assignments are challenging to write or not usually depends on how lean or robust they are and on how customized each one is to its topic.

It is important that you create/iterate a good design for this module and then figure out how best to communicate it at the sponsor meeting the evening of day one. This must be done in a way that is both comprehensible and easy to modify. In short, you need a good model.

The sponsors must be able to quickly see and understand your design. They must also be able to revise it easily. This calls for more than a simple list of topics on a straw dog. It is best if the module is laid out visually on the wall, showing how Build-A-There 1 topics relate to Build-A-There 2 topics. If there is a Shift & Share report out between the two modules, then this can be communicated graphically. All of this will make it easier for the facilitator to walk the sponsors through the design.

As you do this, the sponsors will stress test the design and perhaps suggest alerations. Once the design is finalized, you can get them involved in writing questions and/or design specs. One way is to simply walk through each topic, jotting down their comments regarding what each team should deliver.

Make sure that the writing team, AR, and facilitator are all on the same page regarding the design and how that design will be communicated in the sponsor meeting. If there are any mistaken assumptions, it is usually impossible to correct them once the evening sponsor meeting gets rolling.

A Word About Build-A-There Design

Sometimes, there is only one round of Build-A-There. This is more likely to be the case in shorter events. But even when there is a full focus day, the earlier modules will sometimes eat up so much time that you can only fit in one Build-A-There round. On the other hand, you will occasionally see an event with three Build-a-There rounds (or a Strategic Modeling assignment followed by two Build-A-There rounds).

If your event will have more than one round of Build-A-There, the first thing you need to determine is what the focus will be of each round. This varies from event to event. For instance, in the Microsoft event, each team in the first round worked to optimize a process. In the second round, they each focused on a profile area. At other events, each team will focus on one area in the first round, then some members will shift to other teams and the new team will drive deeper into the details of the same area.

There is no prescription for how to structure this. It is a matter of knowing the client, knowing the objectives they are trying to obtain, and applying good design principles to create a module that will enable the participants to take a good first cut at the solution. The module will also need to tee up an effective Act day.

Three-Day Events

If possible, get your list of Build-A-There done by the end of the prep day. This enables you to show them to the sponsors who review assignments the following morning.

If a template and model assignment hasn't been drafted during pre-writing, try to do so by the end of the prep day. Once one scenario is drafted, you will have a template for writing the rest of the Build-A-There.

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 may be replaced or 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 Build-A-There 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 Build-A-There module usually is scheduled during the last half of Focus, it is possible that the assignments will change after the sponsor's morning review. For instance, you may face a time crunch and need to adjust the time allowed for each round of work. Sometimes, new topics or issues can emerge during the report outs in the first part of the day, which can lead to the creation of a new assignment or new questions to ask.

Two-Day Events

You will need to finish your Build-A-There assignments on the prep day. In this case, the discussion of the topics will take place during the sponsor walk-through. This means that it is important to have a good list developed before the event.

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. As noted above, it can be very helpful to have the sponsors list the key questions or design specs for each Build-A-There assignment.

After the walk through, someone should start working on the Build-A-There. You want to make sure that you can iterate the Build-A-There at least a couple of times. Ideally, members of the writing team will draft the assignments, review and iterate them.

When I have an engagement team member on the writing team, I like to have them work on drafting the Build-A-There assignments. I set up the template and try to write one as a model.

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.

As mentioned above, expect that you will need to revise the Build-A-There assignments once the event starts. You may need to alter the times, add questions, or even draft a new assignment. Plan to get together with the facilitator at some point during the Scan phase to discuss the Build-A-There module.

A Note About Pre-Writing of Build-A-There

Pre-writing of Build-A-There can be helpful, especially for two-day events.

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.

It can be difficult to draft Build-A-There 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 create a robust first draft of Build-A-There during pre-writing. Nevertheless, some effort spent setting up a Build-A-There template and drafting a model is worthwhile.

The more you become involved in the advance preparation for the DesignEvent, the more context you will have and the easier it will be for you to write assignments at the event.

Skits

Posted on by Brandon Klein

Purpose

A skit module evokes a strong creative response from participants. Instead of simply asking them to report the results of their work (which certainly places a demand upon them), we ask them to bring those results to life — to entertain.

In essence, this gives them permission to have fun with the problem. It also gives them permission to say all sorts of things that they might not find a way to say in a straight report out. This is what satire is all about — finding a way to bring difficult, politically-charged issues into public discourse.

Beyond that, skit modules also get participants working in the realm of fictional stories. (Sometimes, teams extend into other creative modes: songs, poems, even interpretive dances.)

Story is one of the dominant means by which cultures define themselves, pass on values, and work through differences. Stories can be stablilizing forces. They can also be engines of transformation. Stories involve and engage their audience in powerful ways, transmitting and imprinting their messages deeply into the subconscious. A skit module in an event helps to forge the new working culture of the participants and deepen their collective memory.

The work that teams have been doing before they begin the skit assignment ignites their skit stories. Once the story gets burning, however, it takes on a life of its own. Tension is provided by the need to keep that story grounded in the previous work.

This tension between the will of the story and the intention of the team is a dynamic and creative one. Key breakthroughs in thinking and strategy can come out in a skit module.

A moment from a skit module can have a galvanizing effect and become a rallying cry or dominant theme that surfaces again and again as the event unfolds and the group pursues its solution.

Skit modules like Legends and Time Capsule place participants in a future-state setting where success has been attained and they are recounting highlights of that success story.

Description

Usually, each team will have worked on a separate body of work prior to receiving the skit module assignment. This assignment asks them to report out in the form of a skit. Depending on the module the assignment will either give them wide latitude in how they form their skit or it will give them specific instructions (e.g., Time Capsule, Ad Agency).

Often, costumes and props are made available. The teams then spend thirty to sixty minutes developing their skits. The space quickly fills with laughter and loud voices. If the skit module is the last module of the day, then the report out is held the following morning.

Critical Success Factors

Timing In Straw Dog. Skit modules are generally part of Scan. They are a good module to schedule at the end of the day (then reported out the following morning), but they also have worked well in the middle of the day. Because they are so much fun and energize the group, it is critical that the serious lessons of the skits be noted and mentioned by the facilitator. (In fact, this can be the basis for a debrief conversation after the skits are done.) The group should not be let off the hook. In fact, it is a good idea to follow a skit module with a round of work that is more serious in nature.

Good Work Upon Which To Build. The raison d'etre of a skit module must be to report out the results of an earlier round of work. Often, this is a reading module, but not necessarily (e.g., A Day In The Life). In fact, the Report Out In a Creative Way instructions could be given when you want to alter the energy and pattern of the event. But use skit modules with intention and understanding. This is a pivotal module.

 

Start Writing

The assignment for a skit module is an easy one to write. One assignment is all that is needed. The assignment need not be elaborate, though it can be if you feel the participants can use the extra framing and definition that an elaborate assignment provides.

Adapting existing examples. There are several examples provided here. They require minimal effort to adapt. Indeed, some can be used as is. As you get to know the participants early in the event, you may find it useful to revisit this assignment and subtly adjust the language and the instructions. It depends how much of a perfectionist you are. Of course, if you think it will make a difference, then it probably will...

 

Team Approach

Not much effort is needed to prepare for a skit module. There is no major transition to manage. The assignment is easily created. About all you need to do is decide how to handle props and costumes and make sure that this matches the instructions in the assignment.

In the case of a Time Capsule module, you may wish to create one or more boxes that teams can use for their time capsule skits.

Perhaps the biggest demand is in the area of music. Teams often want music or sound effects to enhance their skits.

Model Shop

Posted on by Robin Brooking

To crystallize your thoughts from today, it is important to take the language, ideas, readings, and concepts you have explored and make them more tangible as you integrate them more comprehensively. With this in mind, your assignment is to build a physical model of how you would implement your team's leading practices in the future xxx finance process.

How does this model work?  Demonstrate the relationships and structure between people, processes and technology. Show the control and feedback loops, the interaction with the environment, the integration requirements, and how they all work as part of the complex system. Consider the relevant constituencies: customers, owners, employees, suppliers, etc. Show as much detail as you can, and include your language, insights, and learnings from the day as well as those from your prior knowledge of the project vision and objectives.

You have been provided a set of materials out of which you can build your model. Use them in any way you wish. Feel free to barter with other teams for materials that could add value to your team's model. You may also use other materials from the environment as long as they can be returned in good condition when the assignment is over. Make sure your model represents your ideas clearly enough for an uninvolved observer to understand key concepts.

Be prepared to present your model to the rest of the participants tomorrow morning at 8:00 am. Use your model to educate us about the leading practices you identified and how you applied them to the finance processes. It is important to give us a detailed report of your work along with an explanation of your model.

INVENTORY

Plastic tub (shoe box sized or bigger) should contain an assortment of the following items:
Glue gun and sticks
Glue - assorted strength
Tape - regular and double sided
Balloons
Modeling clay
Assorted construction paper, and craft sheets (the stuff that's not paper but not fabric)
Crayons, markers, pens, etc.
Feathers (small pkgs at craft store) and other related things found in craft department
Eyes
Fishing line
Scissors
Pipecleaners
Foam core - 1 sheet per team
Stencils
Scrapbooking paper and materials
Brad fasteners
Staplers
Playdoh
Small styrofoam pieces
Stars
Stickers
Small dowel rods/popsicyle stiks
string
figurines - army men, cars, hot wheels, etc.

Syntopical Readings

Posted on by Brandon Klein

Purpose

The Syntopical Readings is a reading module that brings together an eclectic mix of material for the participants to read.

Years ago, the practice was to give each team a different mix of widely varied articles and books to read and synthesize. Now, the module is more focused, with each team reading about one piece of that eclectic mix.

Metaphors, case studies, and specialized business topics can all fit together in the Syntopical Readings module. It is a pretty big tent. But it is no longer about individual teams synthesizing readings across a broad spectrum of topics.

Sometimes the module is called Syntopical Readings, but all of the readings will be metaphors. Sometimes all of the readings will be specialized business topics. Sometimes they'll be a mix, with a case study or two thrown in.

As with other reading modules, Syntopical Readings is designed to help participants confront and consider solutions to the major issues they are facing. The Syntopical Readings module is also a major opportunity to expose participants to ideas and concepts that they may need in order to create effective solutions.

The module immerses each team in a stimulating body of knowledge from which new learning can be extracted. This is a fundamental principle of scanning: stepping back and looking about for fresh perspectives and rich insights.

First, the participants learn individually as they read. Next, they teach each other and engage in mutual discovery by discussing what they learned. It is only after they have completed these two rounds of work that they are asked to relate what they have learned to the challenge at hand.

They are now able to see and understand their challenge in new ways. By viewing their situation in light of what they have learned, they expand the boundaries of what is possible and begin to articulate the principles of what is desirable.

When you look at the examples of Syntopical Readings included on the Examples page (click here), you'll see that most of them are business-related (Alliance Partnerships, Balanced Scorecard, Change Management, Globalization, etc.). However, there is a sprinkling of more esoteric topics (e.g., Blur, The Death of Competition, The Innovator's Dilemma).

Examples of metaphors and case studies can be found in the sections of this site that deal with those modules.

 

Description

This module consists of three phases of work in breakout teams, followed by a large-group report out in the Radiant Room.

During the Read phase, each team member works individually, reading as much as he or she can in the time allotted. By the end of Read, the team should have covered all or most of the material collectively.

In the second phase, team members share and discuss what they learned. This discussion is stimulated by a series of questions contained in the assignment, designed to draw out the central themes of the reading. In the third phase, they apply this learning to the central challenge of the DesignEvent.

Critical Success Factors

Issues List. The facilitator works to identify a list of issues based on his or her conversations with the sponsors. Sometimes the sponsors are involved in creating the list. The facilitator can also extract the issues from the scribing, documentation, and notes created during meetings with the sponsors.

Good Readings That Address The Relevant Issues. For a syntopical reading to work at your event, however, it must have more than a clear correlation with an issue. It must be a reading that will take the participants somewhere they need to go. There must also be adequate articles/books available to support the syntopical reading. The researcher works to pull these together and the facilitator reviews each set of material to evaluate whether it is adequate. If not, another syntopical reading can be substituted to address that issue, or a syntopical reading that addresses a different issue can be substituted. It is advisable to have a list of topics that exceeds the number of teams that will take part in the module.

 

Start Writing

The assignments for the Syntopical Readings module usually represent the biggest body of work for the writing team during the prep day. Why? Each syntopical reading assignment must be specifically tailored to its topic. Plus it's a three-part assignment, meaning that you have to write 30 pages worth of assignments if your event has 10 breakout teams.

The advice presented here assumes that you are writing your syntopical readings assignments from scratch. If you're not doing this, then you are adapting existing assignments.

If you're in the adaptive mode, it will still be helpful for you to read all of the advice here. However, there is also specific advice on adapting existing assignments at the bottom of this page.

As with many assignments, about half of the content relates to logistics instructions and advice on how to go about doing the work. Take a look at some syntopical reading assignment examples to see what the basic logistics instructions are. Pay just enough attention to drafting these to get them right, and then copy them to each syntopical reading assignment. That is the easy part.

The rest of the work relates to the introduction (if you're using one) in the Read assignment and the questions in the Dialogue and Apply assignments.

Introduction. The introduction paragraph that is often used in the Read assignments serves as an entree, or hook, into the syntopical reading topic. The notion behind this is that the participants may resist this assignment initially. The introduction raises their curiosity and eases them past this resistance and into the reading. At that point, they're hooked.

To write a good introduction, you need to understand the syntopical reading. In many ways, this introduction is like the jacket copy on the cover of a book. Take a look at the covers and jacket copy of the books for your syntopical reading. Steal willfully and with abandon. You may also want to scan through the readings a bit — in particular the first paragraphs of articles or the first chapters of books — to see what catches your eye. Doing so will not only help you to craft this introduction, it will orient you to the topic.

Dialogue questions. The questions in a syntopical reading shine light on some of the ground the team should cover in its work. In the dialogue assignment, these questions are aimed at evoking a response to the key themes of the syntopical reading. Four to seven questions is a good range to work within.

In order to ask specific questions like that, you need to have an understanding of the syntopical reading and how it relates to the relevant client issue. Usually, it is difficult to get that understanding unless you already have some experience with the syntopical reading and/or with the client. That is why it is very helpful to discuss the syntopical reading with the facilitator and/or with a knowledgeable engagement team member. However, do the best you can if those conversations haven't happened yet. It is better to get a draft of the assignment done, no matter how sketchy or vague. It can be improved in the next iteration.

Apply questions. Design these questions in such a way that they get participants to consider how they would apply their key learnings to their solution, project or company. The questions should also get them to address the implications of doing this, the difficulties involved, and the changes that the company would need to make to do so successfully. Four to seven questions is a good range to shoot for.

Once again, in order to generate good questions you must understand the syntopical reading, the learnings it is intended to drive, and the relevant issue the client is facing. This is where it is helpful for you to visualize the world of the syntopical reading (in particular its learnings) and the world of the client. As you relate one to the other, areas of concern or curiosity will hopefully emerge. Let these lead you to your questions. (Or else, in the pressure of the moment, make something up and trust the iterative process to get it right.)

Occasionally, you may find that there is one apply question that makes sense to ask in all of the syntopical readings. For example, perhaps the client has way too many initiatives underway to effectively implement the solution they are designing at the event. It might make sense to ask the following question in each syntopical reading: "What would we have to stop doing in order to apply the learnings from this syntopical reading?"

Adapting existing examples. 123 examples of syntopical reading assignments are provided here, listed by topic. This is by no means an exhaustive selection. You may or may not find an example that suits your needs. On the other hand, you are certain to find an example that you can adapt.

Treat the example as a starting point — a foundation upon which to build. Cut and paste the example into your assignment template for the event. Then change the simple things, such as the name of the client, the name of any project associated with the event, 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 Read assignment and see whether it needs to be adapted. Is there an introduction paragraph? If so, does it need to be altered to better align with the relevant issue?

When it comes to the questions, if you have a good example it is likely that you can adapt the questions so that they apply to your assignment. It can also be helpful to look at the Take-A-Panel questions to see if any of them resonate with this syntopical reading topic and suggest questions for the Apply assignment. This will give you a good starter set, which you can then iterate.

If you took good notes during the sponsor walk-through, you may have found that the facilitator mentioned some of the key questions that get at the essence of each syntopical reading. If not, ask the facilitator to speak to this when you sit down with him or her after the sponsor walk-through (or before, if the walk-through is scheduled late in the day). If there is not time to talk through it with the facilitator, then you can review some of the readings and try to come up with a starter set of question, which the facilitator and sponsors can then iterate later.

Additional advice. Once again, review the readings if available. Glancing through the books and/or articles will enable you to recognize some of the key points. This can suggest questions that will get the participants to consider some of the relevant aspects of the syntopical reading. If the readings haven't been collected yet, however, don't let it stop you from doing what you can until you have a chance to look at them.

 

Team Approach

There are two main challenges with the Syntopical Readings module. The first is collecting a robust set of readings for each of the topics. It is best to get as much of this done before the event. To do this, the facilitator must identify a straw set of topics and work with the researcher to provide some definition for each. Then somebody needs to ascertain whether the books are available in the center. This should be done early enough so that an order can be placed to obtain the books that are not available.

It is difficult to pull together all of the readings during the prep day. There is a lot going on, and often the researcher is preoccupied with collecting material for case studies or a trade show. Lots of times it is someone other than the researcher or writing team who does it. Actually, more than one person usually gets involved.

The earlier these readings can be pulled together, the better. Especially, seeing as the writing team will find it harder to draft questions for the assignments if there is no material to review.

Speaking of the writing team, their task — writing all of the assignments — is the other major challenge with the Syntopical Readings module. It's a lot of work. It's best to have some pre-writing of the syntopical readings done before the event. This provides a baseline upon which the writers can build, and it enables them to expend their effort on those sections of the assignments where value can be added. It also allows them to focus on creating any new or unfamiliar syntopical readings.

Before the event. The pre-event facilitation team (facilitator, AR, PF) can identify a preliminary list of issues in advance of the event. Collaborate with the engagement and/or sponsor teams in this effort. The issues are then used to help identify syntopical reading topics. Identify several more topics than needed.

Make sure that the engagement and sponsor teams understand that this is only a preliminary list. It may change and will inevitable get narrowed down at the event.

Distribute this list to the researcher as soon as feasible, so that he or she can identify and perhaps pull together a preliminary set of readings before the event. You may also want to distribute the list to the event krew. That way, whoever ends up working on the syntopical reading assignments will have had a chance to consider the topics.

It is sometimes even possible for the facilitator to get together with the researcher and review the preliminary sets of readings before the event. But this is an exception and not the rule.

Another best practice before the event is to do some pre-writing of the syntopical readings. The least you can do is set up a syntopical reading template that contains all of the logistical instructions.

But go at least one step further. Copy this template into a separate file for each of the syntopical readings. This simple step will enable the team to split up and begin parallel processing on the work much earlier on the prep day. Trust me, the prep day is very hectic and full of interruptions. If the writing lead or AR tries to set up the assignment template and files on the prep day, the team will fall behind because the writers will be unable to get to work as quickly. OR, they will get to work before the template and files are ready, and the team will end up doing re-work in order to make all of the files and formatting consistent.

If you want to go another step further with your pre-writing (and I usually do), find good examples for some of the syntopical readings and adapt them based on what you know about the client and the central theme of the event.

NOTE: do pre-writing for all of the Day One assignments, and any of the Day Two assignments (if you can).

At the event. Preparing for the Syntopical Readings module is one of the responsibilities of the researcher and the writing team on the prep day.

The sponsor walk-through eats up a major block of time during the day. At the same time, it is the best way that members of the facilitation team can get plugged into the event. As many members of the krew as possible should sit in on the walk-through. Certainly, the writing team should take notes. If they have their files set up, they can even be working on assignments in the back of the room while they listen. The same goes for the researcher if possible, though this may not be realistic.

Once the syntopical readings have been collected, the facilitator needs to look through them. The earlier this can be done, the better. If the readings for a particular syntopical reading are inadequate, then a book run needs to be made or the topic may need to be changed.

After the walk-through, the writing team has to corner the facilitator and get him or her to talk through the design and provide definition around all of the assignments, including the syntopical readings. Each facilitator has his or her own ideas and preferences when it comes to specific assignments. The facilitator will also appreciate your input. Remember, if you're unclear about something, then it will probably be unclear to the participants. Ask questions. Repeat back what you think was said. Then get to work.

The writing team may want to look over examples of syntopical reading assignments to get some ideas for how they will write the assignment. However, it is key that anyone working on the syntopical reading assignments work from the same template and that the assignments be handled consistently.

If you want to review examples, go to the Syntopical Reading Examples page by clicking on the appropriate button at the top of this column or on this link.

As you work on an assignment, review the readings if available. Glancing through the books and/or articles will enable you to recognize some of the key points. This can suggest questions that will get the participants to consider some of the relevant aspects of the syntopical reading. Be careful, though. Your questions should not lead them to answers. You should be facilitating them to draw their own conclusions.

Also, pay attention to the language you are using. It is one of your most powerful facilitation tools. What effect will your language have in moving them toward a successful outcome — in this module AND in the overall event?

Remember, the key to writing team success is rapid iteration. The more iterations, the better. If the readings haven't been collected yet, don't let it stop you from doing what you can until you have a chance to look at them. That is why pre-writing helps. It gives you one or more additional cycles of iterations.

A final note about pre-writing. If you have political, moral, or other objections to pre-writing, then don't do it. The writing at the event can be accomplished without pre-writing. Nevertheless, I will keep you in my prayers.

Metaphors

Posted on by Brandon Klein

Purpose

Metaphors is a reading module used to help the group deal with the issues that are associated with the central challenge of the design event. These issues are often so divisive or deep-seated that participants cannot see their way around them. Or sometimes they have lived with them so long that they are blind to them.

The Metaphors module confronts these issues indirectly by taking participants to them through the back door. Each team reads about a topic that seems entirely unrelated to the central challenge of the DesignEvent. They are immersed in a stimulating body of knowledge (or in some cases an experience) from which new learning can be extracted.

This is a fundamental principle of scanning: stepping back and looking about for fresh perspectives and rich insights in unfamiliar places. This module puts participants on ground that is not controversial or "politically charged" (unlike the central challenge of the event), where they can learn individually, teach each other, and engage in mutual discovery. They have no stake in the outcome of this work; that is, beyond what is expected of them within the confines of the first two assignments (Read, Dialogue).

It is only after the teams have completed the first two rounds of work that they are asked to relate what they have learned back to the challenge at hand. They have journeyed together through a new realm and are now able to see and understand their challenge in new ways. By viewing their situation in light of what they have learned, they expand the boundaries of what is possible and begin to articulate the principles of what is desirable.

The Metaphors module is a major opportunity to expose participants to ideas and concepts that they may need in order to create effective solutions.

 

Description

This module consists of three phases of work in breakout teams, followed by a large-group report out in the Radiant Room.

During the Read phase, each team member works individually, reading as much as he or she can in the time allotted. By the end of Read, the team should have covered all or most of the material collectively.

In the second phase, team members share and discuss what they learned. This discussion is stimulated by a series of questions contained in the assignment, designed to draw out the central themes of the reading. In the third phase, they apply this learning to the central challenge of the DesignEvent.

Critical Success Factors

Issues List. The facilitator works to identify a list of issues based on his or her conversations with the sponsors. Sometimes the sponsors are involved in creating the list. The facilitator can also extract the issues from the scribing, documentation, and notes created during meetings with the sponsors. It is advisable to have an issues list that exceeds the number of teams in the module by at least one or two issues.

Alignment Between Topics and Issues. The issues list forms the basis for selecting metaphor topics. Over time, we have developed a set of tried-and-true metaphor topics that address certain issues. Many of these metaphor topics are broad enough to address a variety of issues. For example, the Mars Pathfinder metaphor has been used for such issues as better/faster/cheaper, innovation, and project management. Of course, there is nothing that says you can't develop new metaphors. That is how the canon of metaphors expands.

Good Readings That Address The Relevant Issues. For a metaphor to work at your event, however, it must have more than a clear correlation with an issue. It must be a reading that will take the participants somewhere they need to go. A metaphor that strongly challenges will usually end up having a more profound impact than one with which they are in tune. There must also be adequate articles/books available to support the metaphor. The researcher works to pull these together and the facilitator reviews each set of material to evaluate whether it is adequate. If not, another metaphor can be substituted to address that issue, or a metaphor that addresses a different issue can be substituted.

 

Start Writing

The assignments for the Metaphors module usually represent the biggest body of work for the writing team during the prep day. Why? Each metaphor assignment must be specifically tailored to its topic. Plus it's a three-part assignment, meaning that you have to write 30 pages worth of assignments if your event has 10 breakout teams.

The advice presented here assumes that you are writing your Metaphors assignment from scratch. If you're not doing this, then you are adapting existing assignments.

If you're in the adaptive mode, it will still be helpful for you to read all of the advice here. However, there is also specific advice on adapting existing assignments at the bottom of this page.

As with many assignments, about half of the content relates to logistics instructions and advice on how to go about doing the work. Take a look at some Metaphor assignment examples to see what the basic logistics instructions are. Pay just enough attention to drafting these to get them right, and then copy them to each Metaphor assignment. That is the easy part.

The rest of the work relates to the introduction (if you're using one) in the Read assignment and the questions in the Dialogue and Apply assignments.

Introduction. The introduction paragraph that is often used in the Read assignments serves as an entree, or hook, into the metaphor topic. The notion behind this is that the participants may resist this assignment initially. The introduction raises their curiosity and eases them past this resistance and into the reading. At that point, they're hooked.

To write a good introduction, you need to understand the metaphor. In many ways, this introduction is like the jacket copy on the cover of a book. Take a look at the covers and jacket copy of the books for your syntopical reading. Steal willfully and with abandon. You should also scan through the readings if they are available — in particular the first paragraphs of articles or the first chapters of books — to see what catches your eye. Doing so will not only help you to craft this introduction, it will orient you to the topic.

Dialogue questions. The questions in a metaphor shine light on some of the ground the team should cover in its work. In the dialogue assignment, these questions are aimed at evoking a response to the key themes of the metaphor. Four to seven questions is a good range to work within.

In order to ask specific questions like that, you need to have an understanding of the metaphor and how it relates to the relevant client issue. Usually, it is difficult to get that understanding unless you already have some experience with the metaphor and/or with the client. That is why it is very helpful to discuss the metaphor with the facilitator and/or with a knowledgeable engagement team member. However, do the best you can if those conversations haven't happened yet. It is better to get a draft of the assignment done, no matter how sketchy or vague. It can be improved in the next iteration.

Apply questions. Design these questions in such a way that they get participants to consider how they would apply their key learnings to their solution, project or company. The questions should also get them to address the implications of doing this, the difficulties involved, and the changes that the company would need to make to do so successfully. Four to seven questions is a good range to shoot for.

Once again, in order to generate good questions you must understand the metaphor, the learnings it is intended to drive, and the relevant issue the client is facing. This is where it is helpful for you to visualize the world of the metaphor (in particular its learnings) and the world of the client. As you relate one to the other, areas of concern or curiosity will hopefully emerge. Let these lead you to your questions. (Or else, in the pressure of the moment, make something up and trust the iterative process to get it right.)

Occasionally, you may find that there is one apply question that makes sense to ask in all of the metaphors. For example, perhaps the client has way too many initiatives underway to effectively implement the solution they are designing at the event. It might make sense to ask the following question in each metaphor: "What would we have to stop doing in order to apply the learnings from this metaphor?"

Adapting existing examples. 118 examples of metaphor assignments are provided here, catalogued by topic and client issue. This is by no means an exhaustive selection. You may or may not find an example that suits your needs. On the other hand, you are certain to find an example that you can adapt.

Treat the example as a starting point — a foundation upon which to build. Cut and paste the example into your assignment template for the event. Then change the simple things, such as the name of the client, the name of any project associated with the event, 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 Read assignment and see whether it needs to be adapted. Is there an introduction paragraph? If so, does it need to be altered to better align with the relevant issue?

When it comes to the questions, if you have a good example it is likely that you can adapt the questions so that they apply to your assignment. It can also be helpful to look at the Take-A-Panel questions to see if any of them resonate with this metaphor topic and suggest questions for the Apply assignment. This will give you a good starter set, which you can then iterate.

If you took good notes during the sponsor walk-through, you may have found that the facilitator mentioned some of the key questions that get at the essence of each metaphor. If not, ask the facilitator to speak to this when you sit down with him or her after the sponsor walk-through (or before, if the walk-through is scheduled late in the day). If there is not time to talk through it with the facilitator, then you can review some of the readings and try to come up with a starter set of question, which the facilitator and sponsors can then iterate later.

Additional advice. Once again, review the readings if available. Glancing through the books and/or articles will enable you to recognize some of the key points. This can suggest questions that will get the participants to consider some of the relevant aspects of the metaphor. If the readings haven't been collected yet, however, don't let it stop you from doing what you can until you have a chance to look at them.

 

Team Approach

There are two main challenges with the Metaphors module. The first is collecting a robust set of readings for each of the topics. It is best to get as much of this done before the event. To do this, the facilitator must identify a straw set of topics and work with the researcher to provide some definition for each. Then somebody needs to ascertain whether the books are available in the center. This should be done early enough so that an order can be placed to obtain the books that are not available.

It is difficult to pull together all of the readings during the prep day. There is a lot going on, and often the researcher is preoccupied with collecting material for case studies or a trade show. Lots of times it is someone other than the researcher or writing team who does it. Actually, more than one person usually gets involved.

The earlier these readings can be pulled together, the better. Especially, seeing as the writing team will find it harder to draft questions for the assignments if there is no material to review.

Speaking of the writing team, their task — writing all of the assignments — is the other major challenge with the Metaphors module. It's a lot of work. It's best to have some pre-writing of the metaphors done before the event. This provides a baseline upon which the writers can build, and it enables them to expend their effort on those sections of the assignments where value can be added. It also allows them to focus on creating any new or unfamiliar metaphors.

Before the event. The pre-event facilitation team (facilitator, AR, PF) can identify a preliminary list of issues in advance of the event. Collaborate with the engagement and/or sponsor teams in this effort. The issues are then used to identify metaphor topics. Identify several more topics than needed.

Make sure that the engagement and sponsor teams understand that this is only a preliminary list. It may change and will inevitable get narrowed down at the event.

Distribute this list to the researcher as soon as feasible, so that he or she can identify and perhaps pull together a preliminary set of readings before the event. You may also want to distribute the list to the event krew. That way, whoever ends up working on the metaphor assignments will have had a chance to consider the topics.

It is sometimes even possible for the facilitator to get together with the researcher and review the preliminary sets of readings before the event. But this is an exception and not the rule.

Another best practice before the event is to do some pre-writing of the metaphors. The least you can do is set up a metaphor template that contains all of the logistical instructions.

But go at least one step further. Copy this template into a separate file for each of the metaphors. This simple step will enable the team to split up and begin parallel processing on the work much earlier on the prep day. Trust me, the prep day is very hectic and full of interruptions. If the writing lead or AR tries to set up the assignment template and files on the prep day, the team will fall behind because the writers will be unable to get to work as quickly. OR, they will get to work before the template and files are ready, and the team will end up doing re-work in order to make all of the files and formatting consistent.

If you want to go another step further with your pre-writing (and I usually do), find good examples for some of the metaphors and adapt them based on what you know about the client and the central theme of the event.

NOTE: do pre-writing for all of the Day One assignments, and any of the Day Two assignments (if you can).

At the event. Preparing for the Metaphors module is one of the responsibilities of the researcher and the writing team on the prep day.

The sponsor walk-through eats up a major block of time during the day. At the same time, it is the best way that members of the facilitation team can get plugged into the event. As many members of the krew as possible should sit in on the walk-through. Certainly, the writing team should take notes. If they have their files set up, they can even be working on assignments in the back of the room while they listen. The same goes for the researcher if possible, though this may not be realistic.

Once the metaphor readings have been collected, the facilitator needs to look through them. The earlier this can be done, the better. If the readings for a particular metaphor are inadequate, then a book run needs to be made or the topic may need to be changed.

After the walk-through, the writing team has to corner the facilitator and get him or her to walk through the design and provide definition around all of the assignments, including the metaphors. Each facilitator has his or her own ideas and preferences when it comes to specific assignments. The facilitator will also appreciate your input. Remember, if you're unclear about something, then it will probably be unclear to the participants. Ask questions. Repeat back what you think was said. Then get to work.

The writing team may want to look over examples of metaphor assignments to get some ideas about how the assignment can be handled. However, it is key that anyone working on the metaphor assignments work from the same template and that the assignments be handled consistently.

 

As you work on an assignment, review the readings if available. Glancing through the books and/or articles will enable you to recognize some of the key points. This can suggest questions that will get the participants to consider some of the relevant aspects of the metaphor. Be careful, though. Your questions should not lead them to answers. You should be facilitating them to draw their own conclusions.

Also, pay attention to the language you are using. It is one of your most powerful facilitation tools. What effect will your language have in moving them toward a successful outcome — in this module AND in the overall event?

Remember, the key to writing team success is rapid iteration. The more iterations, the better. If the readings haven't been collected yet, don't let it stop you from doing what you can until you have a chance to look at them. That is why pre-writing helps. It gives you one or more additional cycles of iterations.

A final note about pre-writing. If you have political, moral, or other objections to pre-writing, then don't do it. The writing at the event can be accomplished reasonably without pre-writing. Nevertheless, I will keep you in my prayers.