A07 – Ideate Scenarios

This is a draft of the manual for review. If you have any comments, please email them to info@omimo.org. Please check back for the final version.

What

Projects are run to create tangible outputs, whereas programs are run to create abstract outcomes. The outcomes of a program are created by the outputs of one or more projects. The set of projects and their outputs that can potentially create all the desired outcomes along with a rough timeline for their execution is called a solution. The combination of a complete solution and its assumptions, including the imaginary behavior of the environment toward that solution, is called a Scenario.

Your program must come up with multiple viable Scenarios and select the most promising one. That’s the purpose of this activity.

Why

On average, programs are a lot more uncertain than projects. In fact, many of the highly uncertain initiatives that are called “projects” are in fact programs mistaken for projects.

Because of the higher level of uncertainty in programs, your plans must be more creative and adaptable. Ideating Scenarios is a practical alternative to more deterministic forms of planning.

Besides keeping the plans more adaptable, you also need to have more than one viable Scenario, because after you start executing the program, you may receive signals that your selected Scenario won’t work well or may even lead you to a dead end, in which case, you should be ready to quickly switch to another viable Scenario.

A big mistake in some programs is that they are started without any viable Scenarios, relying on the idea that there are a few obvious implementation steps that should be taken first anyway. Doing so causes major problems:

• The first few steps they take may not fit any viable Scenarios. It may
  • cause serious problems for the status quo, and
  • make it more difficult to fix the situation in future programs.
• Even when there are undiscovered, unanalyzed viable Scenarios for those steps, options become limited to those compatible with the steps taken. Better viable Scenarios may have become unviable as a result of taking those steps.

If you really believe that a few initial steps are necessary, you must, at least subconsciously, be thinking about a few Scenarios that share those first steps. When this is so, all you have to do is to write down those Scenarios and check to see whether you’re missing any other viable Scenarios before taking the steps.

Who

The solution ideation team creates the Scenarios under supervision of the program manager. The program manager ensures, among other things, that the text of the Scenarios is clear and easy to understand.

How

The expected outcomes are identified in A05. In this activity, the team decides what types of outputs can create those outcomes and how those outputs can be created by different projects. Some of those would enable the outcomes, and some would sustain them.

For example, to make it easier to find documents in the company, one Scenario might be as follows:

We believe that sophisticated document management software is not necessary, and we can make it easier to find documents in the company if they are stored in a well-formed hierarchy of directories in our internal network.

Project 1: So, our first project would be designing the structure of the directories. It should be done by carefully checking the historical and current documents. Four weeks is probably enough for it.

Project 2: We’ll have another project to define a set of rules that can be followed to simplify how we use our documents. For example, a few years after a project is finished, we won’t need its source files anymore, and the PDF reports of the source files would be enough. By removing the files that won’t be needed anymore, it will become much easier to find the files we need. Four weeks should be enough for this project, and it can be done in parallel to project 1.

Project 3: When the previous projects are finished, we can start cleaning up and then moving the old files into the new structure. Given the large number of files we have, we will probably need about 10 weeks for that. People who need to access files occasionally would probably find it easier after this change, but those who access the files frequently may be used to the old structure and feel some friction for a while. We should identify those people and work with them to make sure they are as comfortable as possible with the change.

Project 4: We’re now ready, and we can migrate the files of all ongoing projects at this point. To make sure it won’t cause too much trouble, we’ll do it on a weekend and an extra day before or after that. During those 3 days, no one should work so that there’s no conflict. Not many people work on weekends anyway, but we must communicate it long before the date, so that everyone’s ready.

Project 5: The first day after project 4, we’ll have training for all employees, followed by 2 weeks of one-to-one mentorship. Some people may not be present for the main training, so we may need to have a second training as well. Also, some people may not be open to the mentoring program because they are busy or just not in favor of the program. We should identify them, and if there’s anyone like that, we should find a solution for them.

Activity: After project 5, to make sure people don’t forget how to use the new system, we’ll have weekly audits for 6 months. After that, we’ll switch to monthly audits for a year. After that, the program will be closed.

There could be other Scenarios for the example above; for example, those that use different types of automation, those that use external consultants or outsource different parts of work, etc.

Ensure that the Scenario is not too detailed, because programs must be adaptable and allow the details to emerge gradually based on what you learn from the environment.

Remember that no program shall be started without at least one viable Scenario, though normally, it’s expected to have more than one viable Scenario. When more than one viable Scenario is ideated, the one that seems the most promising should be selected as the target Scenario. The target can switch from one viable Scenario to another during the program, and, at any given time, there must be one and only one viable Scenario marked as the target.

The solution ideation team should consider both convention and innovation, and they should avoid superficial trends:

• Conventions are useful because they provide you with tested solutions for common problems.
• Innovations are useful because
  • the problem may be new, without a conventional solution, or
  • you may find a new solution for the old problem that was overlooked by everyone else.
• Superficial trends are harmful because they are based on short-term hypes formed by a few people who want to make quick money at the expense of others.

The solution ideation team should carefully examine the nature of program and its environment to decide between conventional and innovative solutions. In some programs, some viable Scenarios may be innovative and some conventional.