Project Management

The Agility Series

The Agility Series focuses on agile and agility across the organization not just in software and product development. Areas of agility that will be covered in blog posts will include: - Organizational Agility - Leadership Agility - Strategic Agility - Value Agility - Delivery Agility - Business Agility - Cultural Agility - Client Agility - Learning Agility

About this Blog


Recent Posts

Guiding Principles for an Adaptive Organization

Reflections on 40 Years in IT - Agile by default!

InfoQ Podcast Interview of me on The Agility Series, Cultural Agility, and more

You might be a management red-neck if…

Strategic Debt  — What it is and how to avoid it

Leaders Inspire through Stories

Categories: agile, leadership, strategy

Excerpt from my upcoming book Leadership Agility: Enabling Sustainable Organizations 

Stephen Denning’s book The Leader’s Guide to Storytelling is a field guide on how leaders can use stories to motivate, build trust, transmit organizational values, get teams working together, share knowledge, tame the grapevine, and create a shared vision.

Leaders who rely on charts and graphs to communicate fail to recognize that organizations are made up of people and that leadership is first and foremost about people. No great achievement was ever realized because a leader gave an amazing PowerPoint presentation. Great leaders inspire people to action.

They do so by the way they communicate the story that describes their vision.

Leadership is not about technical things. A leader’s ability to create a shared purpose is the requisite step for their organization to create a shared future. Creating a shared future needs a good story. 

In The importance of storytelling for social change, Simon Hodges argues that 

Stories engage people at every level – not just in their minds
but in their emotions, values and imaginations

The role of a leader therefore, is to inspire their people to action towards a shared purpose so they can create a shared future together. 

This is not an exercise that is routine, meaningless, or void of emotion. It is values-based. It relies on the most basic of human characteristics to want to contribute to something meaningful that is bigger than ourselves.

The stories that leaders tell helps to frame the collective understanding of the organizations they lead, the vision they have, and the future they want to create.


How to contact me:

  1. Send me an e-mail directly
  2. Follow me on Twitter: @cooperlk99
  3. Connect to The Agility Series Webinar Channel

Want to engage me and my friends:

  1. Check out our LinkedIn Group
  2. Check out our learning portal: - lots of free stuff plus some great courses on Scrum  and PRINE2 Agile. Go get The Adaptive Strategy Guide andOrganizational Agility while you are there - both are FREE.
  3. We provide coaching and mentoring in Agile and Scrum for public and private sector clients. Contact me for more details
  4. We also offer classroom training  for courses plus other agile and Scrum training (



Posted on: October 15, 2016 11:56 AM | Permalink | Comments (3)

What? You don't know why you are doing your project?

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.


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:

  1. Send me an e-mail directly
  2. Follow me on Twitter: @cooperlk99
  3. Connect to The Agility Series Webinar Channel

Want to engage me and my friends:

  1. Check out our LinkedIn Group
  2. Check out our learning portal: - 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.
  3. We provide coaching and mentoring in Agile and Scrum for public and private sector clients. Contact me for more details
  4. We also offer classroom training  for courses plus other agile and Scrum training (


Posted on: October 13, 2016 07:17 AM | Permalink | Comments (5)

The Edge of Chaos: Missed it by that much...

The Edge of Chaos: Missed it by that much...

Previously published on

As a child growing up in the sixties and early 1970's one of my favorite TV shows was "Get Smart" (1965-1970) with Don Adams as Maxwell Smart from Control. Max and Agent 99 were constantly fighting the villains from Chaos. Invariably Max's bungling led to losing the small battles along the way to Chaos after which he would utter the iconic phrase "missed it by that much!" By the end of most shows Max, Agent 99, and Control would win out over Chaos (actually it was mostly Agent 99 (Barbara Feldon) that outsmarted Chaos). 

It's a great metaphor for the world that most leaders and their organizations now find themselves in as they face the chaos of accelerating change coupled with ever increasing ambiguity and uncertainty. Some are trying to control the chaos from afar with multi-year plans while others are trying to exhibit control at the edge of chaos.

This concept is also at the heart of complex adaptive systems  (CAS) theory which states that in order to harness change with no anarchy, CAS strives to maintain a balance between the completely ordered, “frozen” regime and the completely disordered, chaotic regime, which is known as operating on the “edge of chaos” (McKelvey, 1999). 

The "edge of chaos" is also where we need to be in order to manage at the pace of change. Does this mean that we always should expect to be successful? Of course not.

In Agile we talk about the need to inspect and adapt which is based in empiricism - we adjust based on what we now know based on what we just did. When operating at the edge of chaos it is highly probable that we will miss the mark occasionally. We will, as Max Smart would say, have "missed it by that much!". And that's OK. 

In a prior post on Being a Servant Leader I talked about the role of a leader in creating a safe environment for their teams to experiment and try new things without fear. When operating at the edge of chaos failures will occasionally happen. It is not that they will happen, it is that how we react to them that matters.

Do we follow our Agile ways and inspect what happened and why and then adapt and adjust based on what we find or do we start apportioning blame? 

Based on the accelerating nature of change in the modern world can we afford to do anything else but inspect and adapt? To do otherwise would actually put us over the edge rather being on the edge. Inspect and adapt is one of the ways in which we can bring order to the edge of chaos.

Inspect and adapt does not mean pressing on in the face of overwhelming evidence that something is not working.

We don't know what we don't know. It is through doing that we uncover the things we don't know. In Agile we call this emergence. Most typically, emergence has been contextualized to the concepts emergent architecture or emergent design. But it also applies to the problem space as well - we devote Chapter 7 of our book to the different types of emergence. Inspect and adapt, when considered as part of an emerging understanding and clarity around the problem we are trying to solve, can enable us to respond in more considered ways to what we now know that we did not know previously.

This leads to the main point of this post. Leaders will often afford their teams the ability to fail and recover but not always themselves. This kind of bravado can be dangerous to both you and your organization.

So it is important that you also have the courage to acknowledge when you miss it by that much in front of your teams. This level of transparency, rather than leading to a perception of weakness, will actually embolden them to also operate at the edge of chaos. Your stature as a leader will increase if you do. 

Continuing to exhibit control at the edge of chaos by inspecting and adapting to your emergent understanding of the problem will enable you to eventually overcome the current chaos so you can move on to the next set of chaotic challenges. 

As a leader, do you allow yourself to fail and acknowledge it? Are you willing to say "I missed it by that much!"?

Posted on: April 28, 2016 07:57 PM | Permalink | Comments (3)

Strategic Iteration versus Strategic Planning

Categories: agile, stategy, strategy

When I was first introduced to the phrase “strategic planning” in the early 1990’s I recall asking myself if it meant that the act of planning itself was strategic.

I tend to do that with phrases that I feel contain contradictions – like business analyst for example – business analysis is an activity that many of us do on a daily basis and sometimes multiple times a day. So why is it seen as role? But I digress.

When I visualize strategic planning I see the thick binder containing all manner of grand visions and statements as the end result. Each year's annual strategic plan joins the strategic plans from years past; on a shelf that no one dares to look at for fear of having to open one of them and actually read it.

Strategy is a concept that emerged in military planning over many millennia and was essentially made up of setting some objectives, gathering intelligence, and using that intelligence to make informed choices about likely courses of action.  Of course as was famously attributed to Dwight D. Eisenhower the approach was limited but useful,

In preparing for battle I have always found that plans are useless,

but planning is indispensable

Strategic planning  in corporate settings is based on the premise that we can use the past to predict the future. But is that realistic?

Defining and delivering on vision and strategy has been a hit and miss proposition for most organizations for many decades. The reason for this is twofold.

First, the world is not like it used to be. Traditional management and its accompanying models relied on the notion that we can use the past to predict the future. This was the era of 3-5 year plans. Change was slow, and at times imperceptible, and the problems were mostly discrete.

Organizations are now operating in a world of volatility, uncertainty, complexity and ambiguity (VUCA). Additionally, customers expect businesses to be more aware of and responsive to their needs.

Secondly, organizations now face holistic messes rather than discrete problems.

Traditional hierarchies are intrinsically ineffective at enabling the speed of decision-making required to lead at the pace of change. We don’t know what we don’t know and we have to stop the pretense that we do.

Rod Collins, in his forward to our book Agile Value Delivery: Beyond the Numbers said:

“Handling these holistic messes has more to do with having the ability to rapidly adapt to ever-changing customer expectations than with minimizing variances in a fixed plan.”

Handling holistic messes requires whole-of-organization approaches. These approaches encompass iterative strategic direction setting, execution, validation, and adaptability. It requires a mindset that embraces emergent thinking. The window of opportunity to deliver Value into business operations has gotten shorter; the window of stability following Value delivery is immediately followed by the next set of challenges that have to be solved.

Strategic iteration (or iterating strategy execution) recognizes that we cannot use the past to predict the future. Increasingly, many are starting to recognize that we need to adjust how we view strategy:

  • From being predictive and deterministic to running a continuous experiment and adjusting what we do next based on what we observe about what we just did (that is use an OODA approach)
  • From endless data collection and analysis to looking for and at patterns and developing our ability to both recognize the familiar ones as well as uncovering new patterns
  • From the top down wisdom-of-the-leader model to having a networked perspective that includes both internal and external players

That is, we need to move from the perspective of doing strategic planning as an annual exercise to doing strategic iteration as a continuous activity that involves everyone, and then focus our attentions and efforts on what we are actually observing as opposed to what we hoped might happen.

A high school  guidance counselor once told me what he would say to his students at the end of a session where he had to have a conversation about problematic behaviors “awareness is an awful thing “ – once you have been made aware of something you never become unaware of it again.

We no longer live in a world of slow and imperceptible change when strategic planning as a corporate exercise was incubated and when most people felt the problems we faced were mostly discrete. We now live in a world of rampant change and holistic messes. There, you are now aware.

So what do you think? Time to ditch strategic planning for strategic iteration?

Posted on: March 22, 2016 08:18 AM | Permalink | Comments (3)

"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."

- Tom Robbins