A05 – Identify the expected outcomes

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

Programs are run to create outcomes. In this activity, you should identify the expected outcomes and list them in the Program Description.

Why

There’s a difference between the goal and the path towards reaching that goal. Uncertain environments only make the path unclear, not the goal. Because of the high level of uncertainty in programs, you shouldn’t lock yourself into a solution that’s fully designed upfront. However, that’s only about the solution; the goal, which is the set of expected outcomes, must be made clear as soon as possible so that you can align your activities with them. You may decide to adjust the expected outcomes later on, but the intention must be to create a complete and clear list of expected outcomes in this activity and use that until the end of the program.

Listing expected outcomes may sound simple, but in reality, it’s very difficult and, therefore, requires an explicit activity that the team has to spend considerable time on.

Who

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

How

For some stakeholders, such as the customer, you’d interview their representatives to understand their expectations. Limiting interviews to a single representative or even a few similar ones can be risky as their interpretation of the expectations would be biased because of their own perspective. For this reason, you should try to interview different types of people.

For some stakeholders, such as regulatory organizations, you might refer to their published codes and regulations instead of interviewing them. You may still have doubts after that stage, in which case, you may be able to contact them and ask for more information.

The expectations of some stakeholders can be defined indirectly based on their historical actions. In general, when possible, you should use more than one method of identifying expectations to make sure you’re not misled.

A common problem with many people, especially customers, is that instead of telling you about their expected outcomes, they describe the lack of what they understand as the “obvious” solution. In such cases, you have to ask good questions and gradually go deeper with them to identify the underlying outcomes they desire. For example,

• “Make it easier to find old documents” is good because it describes the expected outcome; however,
• “Change the current manual document management system into an AI-based one” is not good because it describes a single solution for achieving an implied outcome instead of describing the outcome and allowing the optimum solution to be discovered. If the predefined solution is a must, then what you have in hand is a project and not a program.

There’s a difference between what people need and what they want. Aiming for what they want would generate short-term success for you, while aiming for what they need creates long-term success. Ideally, you should have enough conversations with stakeholders to close the gap between what they need and what they want. In other words, what they think they need should match what they really need.

Don’t forget that some stakeholders may be passive and not tell you about their expectations unless you go to them and discover them or ask about them. However, if you don’t, they will stay quiet until the change happens, and if it doesn’t match their expectations, they will cause problems, and solving those problems late in the program may be expensive and time-consuming. So, you need to make sure you have a complete list of stakeholders in the Program Description and that you pay full attention to it when identifying expectations.

Finally, when the real expectations are identified, you will probably discover many inconsistencies among them, and this would be the time to resolve those conflicts and create a consistent list of expected outcomes.

The final output of this activity is a list of one or more expected outcomes. Normally, the number of related outcomes in a program would be less than ten. So if you have more, you should check to see whether they can be merged into a smaller number, or maybe they should be split into multiple programs if they are not too dependent on each other.

The list of expected outcomes is added to the Program Description.