As mentioned previously, the canvas is a great way to build a change model and supporting change plan. One of its biggest benefits is that it is collaborative, it forces a certain informality and succintness that makes it easy to create a plan quickly, and tear it down when it turns out to be wrong.

The canvas forces change agents and recipients to consider all aspects of a change initiative, but only in brief, there simply isn't enough space on the canvas to get lost exploring a huge amount of detail.
But sometimes exploring things in a bit more detail is warranted, there are times that we need to understand the complexity of the current organization, perform root cause analysis on its problems, and spend a little more time designing the target state in order to come up with an effective change.

Where required, change agents can plug in different methods and tools to help them perform the analysis necessary to completing a certain section of the canvas.

There are a multitude of approaches and methods out there that can help change agents analyze pain points, define a target state, and identify key gaps.

I'd like to share some of the "plug-in options" which I have seen used to perform analysis on different sections of the canvas. This is by no means a definitive list, but I hope that some of these tools will be useful to you as they have been to other change agents, and that it will spark your imagination and creativity in terms of how to think about completing different sections of The change canvas.
For this post I'll focus on the urgency and change recipients

Urgency

The first section of the canvas that I am going to look at is urgency.

Completing the urgency section is all about understanding what pain is being felt by different intentional change recipients, and articulating back pain in a language that the change recipients understand and appreciate.

Establishing a sense of urgency is one of the first things that need needs to be considered when starting any change initiative. Many change groups out there talk about the need to visualize and communicate what is known as the burning platform. The idea here is to connect any change initiative with a powerful metaphor that speaks to the criticality of executing on this change initiative.

The idea here is not to be overly scientific, but to come up with a set of problems that resonate emotionally and get them charged up enough to engage in the change initiative.

We have personally had very good success using a tool known as the 5 whys to help people analyze problems that they are feeling, get to a particular root cause for particular problem, and collaborate with them to come up with a set of countermeasures that can help address the root causes of problems.

5 whys is typically executed using a facilitator and a number of change recipients. The facilitator helps the group list a number of problems that are currently causing pain, and then helping the group come to a root cause for that problem by asking the question "why is that problem happening" up to 5 times. Eventually the answer will come up with what is known as a would cause for the issue. The group can then try to discuss potential countermeasures for that root cause.

While This technique seems deceptively simple,Successfully facilitating the 5 whys session can actually be quite complicated. The relationship between problems, other problems root causes and solutions, is rarely linear.

In reality,problems end up having a many many relationship to other problems, other root causes, and countermeasures. This means running the session takes some skill in order to keep the group focused and keep getting them continually back on track. When running your first 5 whys session, don't be discouraged if things go off track. You will get much better at running the sessions after the first couple of them.

value Stream mapping is another analysis technique that is very complementary to five wise. a facilitator can work with a group of change recipients either a workshop style or one-on-one to help Map out the artifacts that are created and the activities that are completed for particular process.

As the process is mapped out into what is known as a value stream, specific issues and problems relating to either components of the process or the entire process itself can be discussed. These issues are often catalogued as a specific kind of waste, Mary and Tom Poppendieck authors of many books on a software development have defined a popular classification of waste that include:

partially done work
extra features
e-learning
DOS
delays
switching
and defects

each activity can be marked with a specific kind of waste, which can serve as a starter for performing five whys style root cause analysis.

one way of identifying waste as a part of value Stream mapping is to evaluate the ratio between the amount of effort it takes to complete an activity to the amount of calendar time elapsed between that activity starting in that activity ending.

For instance imagine that a business case document is typically around five pages long, and usually takes between 3 and 5 sessions with the appropriate stakeholders to get the right kind of information to fill it out. There is also probably some research time and analysis time that needs to be factored in.
If we look at the actual effort to complete this business case, a range of between six and 30 days is probably sufficient if we are being generous. Anybody completing a business case knows that it can take many weeks, months, and sometimes years to get it completed and approved. The disparity between effort and calendar time is a signal that there is waste within this process, meaning that this is a good place to start performing five whys style root cause analysis.

Here is an example of how five whys can work. Imagine a facilitator is working with a cross functional team responsible for developing web application logic to set of business customers.
The team is currently complaining that is extremely challenging working with their customers. A tangible piece of evidence is that it takes a long time to set up meetings with customers to get direction on what to do next, as well as to how those customers validate work has been done so far.

One issue contributing to this problem is that there are no regular reoccurring meetings, all meetings are set on an ad hoc basis. And it is challenging to coordinate schedules with business stakeholders were extremely busy because the other non-project related commitments.

When speaking to these business subject matter experts and customers their response is simply that they would like a fixed plan that spells out when they need to contribute, what effort that contribution will be, and how often they need to contribute to the entire length of the project. Customers feel they need this information in order to properly balance their workload with many of the other commitments they have nothing to do with this project.

a typical solution in the agile world and lean world is to simply establish a set of fixed meetings that occur on a regular reoccurring interval. For example the team and the customer may elect to meet once a week for possibly three hours to prioritize and do some preliminary analysis on the next set of stories to be delivered.

When this approach was mentioned to the team, they seem to get very nervous and were unwilling to establish any kind of fixed cadence for any customer oriented meetings.

Upon deeper inspection, it became apparent that the team was facing an unpredictable workload thanks to the number of defects that were being raised as a result of customer demos. The team felt swamped with managing this level of defects, and did not have confidence around how much time they had available to work with customers to prioritize the next set of stories.

What first appeared to be a problem with customers refusing to spend necessary time with the delivery team, in actuality was a problem rooted in the fact that the team did not want to commit to spending time with the customer because the amount of time they're spending dealing with quality issues.

When investigating these quality issues it became clear that the requirements gathering process that the team is using with sub optimal. Analysts were working with business clients to gather requirements "clean slate" then delivering those requirements to the solution designer and developers who would then try to add that an existing package solution to meet the needs of those requirements.

Just as often as not, the solution could not be configured to meet the details contained in those requirements. This meant that almost every requirement needed to be revisited and rewritten to support the constraints of the requirements. Even worse this is typically done only after the solution had a demo to the client meaning that almost every requirement was passing through the delivery lifecycle twice.
Upon reflection, the team and the facilitator able to come up with a specific countermeasure. One, was to establish a biweekly story analysis session between the business stakeholder/experts, business analysts and the lead solution designer who was an expert on the technical product that was being used for this project, including its limitations and constraints.
forward thinking would ensure that the solution subject matter expert would not only be available for all analysis sessions, but that he would train the business analysts in the inner workings of the technical product, so they could effectively gather requirements the right way to first time around.

A Value Stream Map could also be used to help facilitate discussion. If the facilitator and change recipients have elected to use this approach, then they would have drawn up the process using a value stream map, and then identified where waste was occurring. In this case delays were occurring during the story analysis activity, and a lot of rework was occurring during development. This would indicate that five whys style analysis was required at each of these two points.

All of this analysis could be refined and summarized so they can be properly reflected on the urgency section of the canvas. In this instance the team elected to describe this as poor collaboration between the business clients, business analysts, and the solution technology expert which was causing confusion and poor quality.

Anyone asking for detail behind the statement could be pointed to the value stream map and five whys analysis that was completed for this canvas.

Change Recipients

Filling out the change recipients box is all about finding effective change recipients within the organization that will emotionally connect with the urgency that you are trying to establish to start the change. We are typically looking at a cohort of change recipients who are all experiencing similar problems. By cohort we mean a set of change recipients who can all experience the same set of changes over period of time.

At minimum your change recipients should be thought of as customers of the change. As a change agent is your job to serve their needs and help them do their jobs better.

A better metaphor is the think of your change recipients as stakeholders that you want to engage in a co- creative manner. Your first change recipients are ones that can serve as change champions, and effectively become what is known as a guiding team for the change initiative. A good change recipients is one that will help you in defining what the change solution should look like, and will take an active role in changing behavior of both himself as well as people around him.

Another important attribute when thinking about starting a change is to find a change recipients who is already displayed some capability in improving in agile or lean methods. For example we may be
considering running in agile improvement change on two different teams.

Team A has previously tried to adopt some elements of Kanban on their own. They have had some successes with the visualization techniques provided by the method, but are struggling with getting to any kind of consistent throughput, and they are still how you deal with a large Number of defects. That being said they want to take things to the next level

Team B is in a much different state. There is a culture of "just getting it done". Often through heroics and last-minute scrambling. There is a general consensus that things need to improve, but people just feel like they are too busy right now to bother.

On first glance it looks like team B needs the change more than team A. But this would be the wrong team to implement improvement initiative on, at least right now. Team A is really the ideal choice, while struggling, they have an understanding that taking time to improve is worth the investment, and they will be more likely to engage with in agile change agent in a positive manner.

Whenever creating our first change is going to be introduced in an organization, we want to make sure that we avoid resistance to the maximum extent possible.

This is best done by simply choosing the area of the organization is most likely to deliver us change recipients who will work with us in a collaborative fashion so that we can negotiate our way to an effective change outcome.

Our change agent can thus put team Alpha into the change recipients section of the canvas, he also makes sure to call out every role within this team as each role may require different actions, commitments and benefits as a result of the change. Our change agent has also decided to list change recipients who are indirectly impacted by the change at the bottom of the change recipients section of the canvas, these include a business stakeholder, executive sponsor, and functional manager.

Identifying change recipients is done in parallel with identifying problems that can go into the urgency section of the canvas.

Using an iterative process, value stream mapping and 5Y sessions are facilitated with varying potential change recipients. Each source of waste, problem, root cause and potential countermeasure can be identified with one or more change recipients.

Looking at our previous example, describe any potential change recipients is as simple as annotating our root cause analysis with the appropriate people involved. In this case, the business subject matter expert and business analysts are most impacted by story analysis related issues, and the developers and testers are being most impacted by issues coming out of the development and customer demos.

Root cause analysis indicates that the lead developer who's playing the role of a product subject matter expert needs to be included in analysis sessions.

In many cases change agents will immediately know who the change recipients of a particular change are. This is true when the change agent is a member or manager of a particular team and he wants to improve the performance of that team. Executives, and external change agents may be more unsure around how to determine who the first change recipients should be.
In this case change recipients can be cataloged into a number of different segments by examining the work structure and project structure of the organization in question.
Some segments can come from organizing folks by their level, for instance change recipients could be either executives, managers, or line staff. Any change could be targeted at all members in a particular level.

Segmenting could also be cataloged by a functional categorization. As an example a specific change could be targeted on all project managers, business analysts, developers or testers within an organization.

Many segments of change recipients will be defined as a cross functional team dedicated to achieving a particular customer outcome. This is how most agile and lean methods recommend that change recipients be organized. This cross-cultural team would include a set of specialized folks from a number of functional departments as well as customers managers and executives who are acquired to support a cross functional team.
Examples of change initiatives that are targeted at cross functional teams include piloting a particular agile method or suite of agile methods to help the team improve their delivery. Adopting Kanban, scrum or extreme programming for particular project team and supporting specialists are good examples.

Changes should be targeted to specific needs of thy cohort. There is a wealth of agile methods and tools available to serve the needs of particular levels and functions.
Examples of change initiatives that could be targeted at these change recipients include helping managers and executives improve organizational agility through adoption of methods and tools found in urine apple is management 3.oh framework, or helping developers achieve better agility through adoption of tooling and methods such as continuous integration and test driven development.

Finally here is our previous example with a cross functional team described as the primary change recipients, with management and executives listed as secondary stakeholders of the change.