Subtitle: Outcomes-focused Agility - Story Mapping our Strategic Intent
I am going to make a bold statement.
More than 50-60% of project managers don't know why they or their project teams are doing their projects.
How can I possibly say that? Surely there are charters and project plans with backgrounders and scope statements? Maybe there are. But that does not mean they know truly know why the project is being done.
Why say that?
Numerous studies over the years have shown project failure rates of 50-60% (some studies are higher and some are lower to be sure). Likewise, where software development projects are concerned, it is estimated that 60-70 per cent of features built are never used or rarely used. Both of these statistics (and others) point to a lack of clarity on why the project is being done in the first place; The sponsors, the teams, the PM, and others really don't have a clear articulation of why they are doing it.
Another factor is that most projects are proposed - that is, someone has an idea for a project, they then write a business case or lobby the executive ranks to get it approved. Some even tie it to strategic goals or objectives. But that still does not mean they know why it is being done.
Projects focus on Outputs
Most project management books, when they distill the essence of project management, will show a diagram similar to the one below. Some project management practices may also refer to the Activity box as Tools and Techniques, but the premise is basically the same; Inputs are consumed through some form of Activity to produce Outputs which are the project’s deliverables.
While this model is simple, it is focused on the wrong things. It does not answer a very important question – why is this project being done? Focusing on why establishes the desirable Outcomes that the project would create if it were successfully completed.
Agile approaches are not immune from this phenomenon as they also start with the Outputs (i.e. deliverables, products, features, etc.) and then identify the activities and inputs needed to create them. The difference between traditional and Agile is in what the activities are and how they are accomplished. But it still does not answer the why questions.
Interestingly, normal business operations and projects both focus on using inputs to activities to create out-puts. Ditto for business processes work. None focus on knowing why.
Outcomes – The Source of Why
Outcomes Management enables organizations to define and use specific indicators to continually measure how well services or programs are leading to the desired results. Outcomes Management is used extensively in health care (it did start with Florence Nightingale after all) and the not-for-profit sectors.
For IT, it was articulated in the book “The Information Paradox” by John Thorpe of DMR in 1998. Before the book was published I was working for DMR and we were taught the Benefits Realization approach (based on what was in the book) as part of being consultants. It was also embedded into the “ValIT Framework” from the IT Governance Institute, with John Thorpe as the lead author.
Some of the questions we can ask ourselves and our Business colleagues to help us identify desirable outcomes include:
- Why do we want to affect the current situation and what would a new set of outcomes look like?
- What will it look like when we achieve the desired solution or outcome?
- Why do we want to affect current behaviours?
- Why are we doing this?
- What benefits would we get if we achieved a particular outcome?
- How will we measure the benefits?
There are two important ideas to understand about Outcomes – their type and their timing which we look at next.
Outcomes Types
There are three basic types of Outcomes that can be achieved from any action we can take as shown below:
- Good and Intended: Ones that we planned for and intended to happen
- Good but Unintended: Ones that we did not plan for, but that have a positive effect on the organization or its Customers/Clients
- Bad and Unintended: Ones that we did not plan for and that have a negative effect on the organization or its Customers/Clients
The first two types of Outcomes are ones that are desirable – that is they have a positive effect.
The last one is an undesirable Outcome type that we would wish to avoid. There are everyday examples in the non-project world of Outcomes that are bad and unintended. For example, introducing a new species into a habitat to overcome one particular problem with another non-native species can lead to the new species becoming equally invasive and also destroying native species’ which clearly was not an intended consequence and is not desirable.
We try to maximize the first outcome type, hope we get some of the second type, and try to avoid the third outcome type entirely.
Outcomes Timing and the Outcomes Map
Outcomes also have different timing. One of the concepts that was introduced by Thorpe in his 1998 book was the Results Chain (aka Outcomes Map) as shown below:
The Outcomes Map as illustrated above highlights that Outcomes may be delivered at different points in time as follows:
- Immediate Outcomes (yellow): Immediate results that flow logically from the activities and Outputs. They represent the change brought about by the existence of Outputs created through the activities. That is they accrue and are observable immediately upon delivery of a particular Output from a Project.
- Intermediate Outcomes (purple): Events or results that are expected to lead to the End (or Ultimate) Outcomes, but are not themselves an “End”. These may also include characteristics relating to the quality of the service provided to clients, such as accessibility, response time, and overall satisfaction.
- End (or Ultimate) Outcomes (green): The consequences/results of what was done – the Ultimate Outcome is the highest level of change that can be achieved, it is the change of state that a project or set of projects in a programme or a portfolio had hoped to achieve. They are the highest level of Out-come that can be reasonably attributed to the project in a causal manner, and is the consequence of one or more intermediate Outcomes having been realized. These outcomes are the raison d'être for the project and are required in order to achieve the Strategic Outcomes of the organization
An Outcomes Map is premised on helping us answer the why question which helps us to identify the Outcomes that we desire to achieve. The possible Outcomes Types (Good and Intended, Good and Unintended, or Bad and Unintended) that were described in the previous section can occur as any of the above timings (Immediate, Intermediate or Ultimate Outcomes).
Assumptions and Risks are also important to know. Risk Management does not go away because we will be applying Agile approaches – but some of the Risk Management practices we will employ will be different than those used with traditional project Management.
Mapping Outcomes is Counter-Intuitive
A counter-intuitive feature of an Outcomes Map is that you actually create it by starting on the right and working backwards to the left:
- The Ultimate Outcomes are defined first and help us answer the why questions
- We then start to identify the Intermediate Outcomes that would precede an Ultimate one and continue working to the left until we can no longer identify any more
- We then start to identify projects that we would need to undertake to achieve the identified Out-comes (whether Intermediate or Ultimate) - this is how we define a Portfolio or a Programme of related Projects
- Project identification is where we typically uncover the Immediate Outcomes
An Outcomes Map is one of the most important Products that a team will create on their way to understanding why so they can deliver Value that matters. As we create the Outcomes Map we also create the following artifacts:
- An Outcomes Register that provides basic descriptive information about the Outcome such as a their Type, Timing, and their Owner (i.e. who is responsible for tracking and reporting)
- A Projects Register that provides basic descriptive information about the projects that will need to be executed and their sequence along with links to the Outcomes they are intended to support
- A Benefits Register that provides basic descriptive information about the Benefits that would be achieved such as their Type, Timing, and Owner as well how they will be measured and how often they will be measured. Benefits are the Key Indicators that enable the Business to determine that the desired Outcome are being achieved. Benefits therefore are a Leading Indicator for Outcomes
But that's a lot of Work!
For those who think this is a lot of work, what we have essentially described is a diagram and some spread-sheets that are developed iteratively and incrementally and then updated as the portfolio of projects move along towards completion. It fits very well with the ideas of simplicity, time-boxing, and focusing on Value that are fundamental principles for Agile thinking.
The Outcomes Map with its associated artifacts is a reviewable and updatable Output throughout the execution of the portfolio during Agile Value Delivery. It also adheres to the basic Agile tenet of being driven through empiricism – we let the facts we uncover during execution guide us. Same for our Outcomes Maps - as we understand more, we get to update those as well.
Conclusion
The Outcomes Map and its artifacts also enable the Business and the Portfolio Teams that have to deliver to quickly and effectively:
- Answer the Why questions
- Know the relationship between Projects, Benefits, and Outcomes
- Know the order in which Projects ought to be done
- Know the consequences of not doing a particular Project or of deferring it until later by seeing which Outcomes would be delayed or foregone
- Gain insight into the relative size of what is being considered
Projects that are initiated in this way are purpose-defined as they are tried to specific Outcomes and their associated benefits.
This approach also means we don't need to do a business case or benefits case at the individual project level as they literally fall into our laps - knowing which Outcome a project is being stood up to contribute to means we know which benefits it will be enable.
Have you ever used this practice?
In the next post I'll provide some examples of where I have used this practice to identify the people, process, technology, facilities and organizational structure implications of major transformations before any real work was actually done. It also supports what I call Outcomes-Focused Agility which helps us to story-map our strategic intent. But then, would the post have caught your eye if I had used that title?
********************************************************************************************************
How to contact me:
- Send me an e-mail directly
- Follow me on Twitter: @cooperlk99
- Connect to The Agility Series Webinar Channel
Want to engage me and my friends:
- Check out our LinkedIn Group
- Check out our learning portal: www.MPlaza.ca - lots of free stuff plus some great courses on Scrum and PRINE2 Agile. Go get The Adaptive Strategy Guide and Organizational Agility while you are there - both are FREE.
- We provide coaching and mentoring in Agile and Scrum for public and private sector clients. Contact me for more details
- We also offer classroom training for Scrum.org courses plus other agile and Scrum training (http://bssnexus.com/education/)
