From the perspective of viability, IT projects are not different; especially large IT projects.
The average cost overrun of large IT projects, according to the study that is cited on this slide, is 45% with a benefits shortfall of 56%.
According to this study, 17% of these projects go so bad that the very existence of the company is being threatened.
While these latter may be outliers, they do give an indication of the risk profile of large projects.
How can these overruns and shortfalls be explained? Bent Flyvbjerg suggest three plausible explanations:
<click>
The first explanation speaks for itself: Using imperfect forecasting techniques and inadequate forecasting data.
<click>
The second reason is related to cognitive biases that are deeply ingrained in the way people think. One such cognitive bias is that people have a tendency to underestimate how long it will take to complete a task; especially experts. People alos have an optimism bias, believing that they are less at risk of experiencing a negative event compared to others.
<click>
The third reason has more to do with deception, or what Bent Flybjerg so nicely calls strategic misrepresentations. It means that the party that wants to execute the project has an incentive to underestimate the costs, and the party that commissions the project has an incentive to overestimate the benefits.
<click>
The net result of these delusions and deceptions is a misinformed commitment.
From our own experience with large projects and programmes we have identified a broader number of classes of root causes of why projects/programmes are not delivering according to expectation. Again we want to emphasize that it is not just about cost overrun but also about benefits shortfall.
Lack of informed commitment is just one of the classes of root causes.
Another one is a lack of shared visual understanding.
The reason why we single out shared visual understanding here is that, together with learning and improvement, shared visual understanding is a lever to address all other causes of project failure.
Let’s focus on shared visual understanding.
In the parable of the 7 blind men and the elephant, there are 7 blind men that each feel a different part of the elephant.
One touches the elephant’s tail, and concludes that the elephant is a rope. The other touches the leg and thinks the elephant is a tree. The third blind man, thinks it is snake because he is touching the trunc. And so on.
Each has a different perspective and different understanding.
This is how many projects feel like where the different stakeholders have a different, sometimes even conflicting, viewpoints. And nobody sees the whole.
When the different perspectives are not integrated, we do not see the whole. The result is patchwork.
The result is not an elephant.
So how do we create that shared understanding?
Often we try to create a shared understanding by having one person (the expert) talk with all parties and then integrate the information that has been obtained.
Obviously by doing so, only one person has an overview of the situation: the expert. Like in the blind men parable, all others still only see their own perspective.
<click>
A better way is to have all parties collaborate around a shared visualization.
Shared understanding means that we create a visualization that integrates and aligns the perspectives of everybody that is involved.
And that everybody that is involved sees the whole picture.
This taps into one of our most powerfull cognitive abilities, that of visual processing.
With the right visual representation, our visual process capabilities allow us to literally see the problem; or to see the solution to a problem.
To illustrate this, please have a look at the game of 15 on the left hand of the slide and try to give an answer to the question at the bottom.
<pauze>
I bet most of you really have a hard time figuring out what player B needs to do. Many of you where probably not even ready reading the entire tekst. Surely this game must be a very difficult game.
May be it is, may be not.
<click>
To understand why not, let’s look at a visual representation of this very same game. In this form the game is called three in a row. Player A plays with crosses, player be with O’s. The first playerthat has three in a row wins. You are the player that is playing with the “O”s and it is your turn, what is your move? <short pause> Most people will imediately see that they need to put an “O” in the bottom-right cornere.
On the left we find a textual representation; on the right we find a visual representation of that very same game. While only a few people will be able to see the solution to the game on the left; most people will imediatly see the solution for the game situation on the right.
People in general have good visual processing capabilities (better than our numeric processing capabilities). Visualization let’s people actually “see” problems and solutions.
Exactly because visualization creates a shared understanding and because it allows people to see problems and solutions, visualization is often a trigger for change.
This is a phenomenon that is very well known in the Kanban community. It is so fundamental that it is the basis for what is called the Kanban Method.
The Kanban Method is a proven method for delivering change in technology organizations. It takes an evolutionary approach towards change: start where you are today, create a shared visual understanding that helps trigger a change towards a more desirable future. Visualization plays a key role in The Kanban Method.
It is exactly the key role that visualization plays in triggering change that is of interest to us. Especially in triggering a change to address the root causes of project and programme failure.
Let’s see how this works.
This brings us to the second part of this webinar: What is visual project management?
In this part of the webinar, we will gradually build up the different elements of a virtual project room or oobeya.
While doing so we will also show how such a visual project room triggers the needed change towards addressing the root causes that we talked about.
Specifically we will show how it triggers a change towards a better balance between risk aversion and entrepreneurship.
Let’s start with a few examples of visual techniques that are, today, commonly used in agile projects.
A first well known example in agile projects is story mapping.
Story mapping is a technique that was developed by Jeff Patton. It is used to create a shared visual understanding of the product or application that you are planning to build, focused on the user and their experience.
Building a map is a collaborative experience. It starts with telling stories of the product and then placing them in a simple grid-like structure.
The resulting story map tells a story from left to right and breaks it down into details from top to bottom.
A story mapping exercise allows the participants to integrate and align their perspectives. It facilitates the creation of a shared vision on the end-product.
In my own experience, the story mapping technique can also be a trigger for change.
Story maps create a shared language between those that are going to use the product and those that will develop it.
In my experience this triggers a change towards a more collaborative way of working between users and developers.
It address one of the root causes of project failure by creating stakeholder engagement.
Another example is Kanban as it is used in software and IT organizations.
Kanban calls for a visualization of the work. The board that is shown visualizes work items like user stories that need to be delivered and bugs to be fixed in a workflow of ready, develop, test, ready for UAT and done.
The visualization of work on the kanban board is a trigger for change.
As the work is visualized, the team can now literally see how the work is flowing. Are there bottlenecks in the flow (is work piling up at a certain place)? Or on the contrary, are there steps in the workflow that are in danger of not having work?
It is a triggers for change for helping teams to think about how they can improve the flow of work.
Again this addresses one of the root causes of project failure in terms of improving team collaboration.
Work is not the only thing that needs to be visualized.
In large projects or programmes many other elements require a shared visual understanding.
We also need to ensure a proper balance between all those elements.
For example, the focus should not only be on just risk, but on risks and opportunities.
Not just on issues, but also on learning and improvement.
Not just outputs, but outputs and outcomes.
As we will explain, the purpose of a program is not just to deliver systems (which we call outputs) but to deliver benefits (which we call outcomes).
Moving beyond outputs, we also need to take adoption and change into account. It is not because we deliver something that that something is also used.
Let’s look at two examples of kanban boards that visualize more than work alone.
This is a programme management board that we have used in large transformation programmes. The purpose is to visualize key aspects of programme management including issues, risks, opportunities, countermeasures and actions.
The board creates a shared visual understanding among the members of the programme management team that includes, business, IS and suppliers.
The product management kanban visualizes the different types of value.
It does so in two different value creation loops that will be explained next.
How is value created?
Again we will see that we have two loops.
The first is the build-measure-learn loop.
<click>
Because of the fundamental uncertainty of differentiators and the intangible nature of delighter, differentiators and delighters will typically need to follow a validating learning loop, otherwise known as the build-measure-learn loop in the lean startup community. For these types of features, a minimum viable product is build to validate the assumptions with users and customers. Based on this validation, a decision is made on whether to further develop the differentiator or delighter or to abandon. To persevere or to pivot.
The purpose of the build-measure-learn loop, in other words, is to discovery of what has value under conditions of uncertainty.
<click>
The second loop, mainly followed by enablers and table stakes, is a straightforward plan-execute-verify loop. For enablers and table stakes the main concern is to deliver the outputs and to deliver them efficiently. The focus of the plan-execute-verify loop is delivery because uncertainty is low.
On the product management board we find the build-measure-learn loop on the top and the plan-execute-verify loop on the bottom.
The purpose of the product management kanban is to trigger a change.
The product management allows to see the flow of value.
It allows us gain a visual understanding of whether there is an even flow of value so that our customers and users or business stakeholders stay engaged.
The product management kanban board can also trigger a more fundamental change.
In order to understand this, we need to explain the monkey traps that programmes and organizations may find themselves in.
The product management board triggers a change towards more balanced decision making.
The visualization makes it easy to gain an insight in the balance between exploitation and exploration , delivery and outcomes.
<click>
Too much tickets in the bottom lane of the board and no tickets on the top lane may be an indication of a programme that is stuck in the monkey trap of delivery.
This happens, for example when a business transformation programme gets trapped by a focus on delivery only and loosing sight of the fact that a critical business problem needs to be solved and that user adoption is a key success factor. The organization is stuck in output thinking.
<click>
Too much green “delighters” and purple “table stakes may be an indication of being stuck in the monkey trap of exploitation.
This happens when product development organizations get trapped in an existing value/revenue stream. As their management system is mainly focused growing and sustaining the existing value stream, the innovation process is hampered.The organization is stuck in the exploitation loop unable to explore new opportunities for future customers.
Going all the way back to the beginning of the presentation, the kanban board is a trigger for change towards not just thinking about keeping cost under control, but also thinking about creating benefits.
We have given 4 examples of shared visualization.
Each visualization can be used in isolation.
As a whole they can be part of a very powerful virtual project room also sometimes called an oobeya room.
They create a comprehensive visual understanding of the different aspects of a large project or programme.
Taken together these visualizations can trigger a change to address the common root causes of project failure.
Story maps address stakeholder engagement.
Development kanban boards address team collaboration.
Programme management kanban board address learning and improvement
The product management kanban board address balanced decision making.
The programme and product management kanbans that we have discussed in this presentation are a part of what we call discovery kanban. The templates for these boards can be found on the discovery kanban website.
This leads us to the conclusion of this webinar.
People have very strong visual processing capabilities.
It allows us to see problems and to create a shared understanding.
Often this is a trigger for change for the better.
This visual capability is heavily underused in most project environments.
In this webinar, we have demonstrated different visualization that go beyond the visualization of work on a task or kanban board.
We have shown examples from large IS programmes and product development programmes.
The visualizations that we discussed are the cornerstones of a virtual project room.
We have talked about the why and the what, leaving out the how. To learn more, we invite you to our website or to join one of our upcomming kanban trainings.