<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>A little bit better than how I found it</title>
	<atom:link href="http://www.kyelight.net/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.kyelight.net</link>
	<description>Learnings about process improvement and corporate life in general, by Kye Leslie</description>
	<lastBuildDate>Sat, 01 Jan 2011 06:09:29 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>Organisational Change meetings &#8211; Part Two: Helping the Group Navigate the Problem</title>
		<link>http://www.kyelight.net/organisational-change-meetings-part-two-helping-the-group-navigate-the-problem/</link>
		<comments>http://www.kyelight.net/organisational-change-meetings-part-two-helping-the-group-navigate-the-problem/#comments</comments>
		<pubDate>Sat, 01 Jan 2011 06:09:29 +0000</pubDate>
		<dc:creator>kye</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://www.kyelight.net/?p=43</guid>
		<description><![CDATA[Once you have established a working group and discussed the current state enough for the members to become comfortable with each other, you can start to make real progress. During discussions on Organisational Change (and most other discussions) the group will encounter many problems to be solved.  The approach to solving each of these problems [...]]]></description>
			<content:encoded><![CDATA[<p>Once you have established a working group and discussed the current state enough for the members to become comfortable with each other, you can start to make real progress.</p>
<p>During discussions on Organisational Change (and most other discussions) the group will encounter many problems to be solved.  The approach to solving each of these problems follows the same basic framework:</p>
<ol>
<li>Create a shared understanding of the problem</li>
<li>Generate ideas</li>
<li>Create a shared understanding of each idea</li>
<li>Evaluate each idea, identifying and understanding the implications</li>
<li>Deciding between ideas</li>
</ol>
<p>It is likely that the group will go through this cycle dozens or hundreds of times before reaching a mature end state.  Decisions at a high level will reveal many subsequent more detailed problems to be solved.  Some groups will want to discuss how they should approach discussing the problems.  Often groups will make a decision at a high level and get part of the way through solving the subsequent problems when they hit a problem that causes them to re-evaluate the high-level decision and perhaps decide to explore a different path.  These are all normal patterns for groups, but as facilitator it is your responsibility to ensure the group doesn&#8217;t get lost, try to talk about too many problems at once, go in circles, or miss things.</p>
<p>Let&#8217;s talk about some common pitfalls and what can be done to prevent or cure them:</p>
<p>The group discusses the approach to discussing the problem and this takes up too much time.<br />
This was covered in the <a href="http://www.kyelight.net/organisational-change-meetings-part-one-forming-the-working-group/">last post</a> so I don&#8217;t want to recap too much, but basically unless someone can quickly explain a better method that the group likes, ask the group collectively if they will try your approach and see how it goes.  This is normally enough to get the group back on track, but if it&#8217;s not then likely there is an underlying issue in the group dynamic that needs to be dealt with.</p>
<p>Many of the pitfalls are varations of where the group deviates too far from the optimal path.  What I mean by the optimal path is where a group starts with one problem, solves it and then discusses the subsequent problems, solving them along the way, reaching a completed solution with no back-tracking.  This is rarely the case as groups rarely understand all implications of each decision and will want to re-evaluate previously-made decisions once they learn more through exploring the sub-problems.  Problems are often not simply a case of &#8220;A means B which means C which means D&#8221;, solutions to one problem will have implications on the solutions to other problems, so many problems must be discussed simultaneously, often revealing a number of scenarios to address the problems.</p>
<p>Problems can start occuring when the group deviates too far from the optimal path.  There is no way of telling in advance how far is too far, but normally you can tell that the group is reaching that limit when you start to get confused, when others start becoming confused, when people disengage from the conversation, or when the conversation becomes fragmented or jumps around between individual problems rapidly.</p>
<p>As strange as it might sound, the solution to a group getting lost is to draw a map.  This is what everyone is doing mentally anyway, so creating a shared map that everyone can follow shouldn&#8217;t disrupt the discussion too much &#8211; even for those who weren&#8217;t confused.</p>
<p>Maps can take any format that makes sense to the group for that topic.  Some maps I have seen used:</p>
<ul>
<li>A decision tree, where options are listed and sub-options listed for each option.<br />
<em>This option is purely a navigational aid and would normally be suplemented with some kind of final documentation outlining the details of the solution selected.</em></li>
<li>A grid showing all combinations of several variables.<br />
This is normally used to show all combinations of several variables allowing the group to confidently explore these, ruling out combinations that don&#8217;t make sense and then discussing and selecting between the rest.<br />
<em>This option is mostly a navigational aid however it may be included in the final documentation which outlines the details of the solutions selected.</em></li>
<li>Listing each option, the implications and the associated pros &amp; cons.<br />
This can evolve into a decision tree if next to each option the sub-problems are listed and then for each sub-problem the options are listed following the same format.  This can quickly map which options lead to implications the group would like to avoid and prevent discussion from dwelling on options that have been ruled out.<br />
<em>This option produces a skeleton format for what could be the final documentation outlining the details of both the solution selected and the options explored but rejected.</em></li>
<li>Documenting the final solution and details as you go.<br />
This works well when the discussion takes place over many sessions as it clearly shows the outputs of the discussion to date.  Should the group stop liking the decisions already made and want to explore a different high-level option then the current version of the document can be set aside and a new version produced.  Should the group want to re-assess any previously explored options then the documentation can simply be reviewed.<br />
<em>This option provides the least assistance as a map, but if the group remains focussed and doesn&#8217;t skip between options it produces the final documentation outlining the details quickly and with the most group understanding of the selected option.  The risk here is that the group may choose the wrong option through not identifying or understanding the other options sufficiently.</em></li>
</ul>
<p>Map selection is normally a trade-off between mapping the structure of options versus exploring each option in detail.  A working group may choose to develop more than one map, perhaps starting with a structural map and finishing with a document outlining the selected option in detail.</p>
<p>Good use of maps will help the group to: see what options they have; discuss each option to the point where it can be ruled out, or for the selected option discuss it until sufficient detail to proceed with implementation is known; and for everyone involved to understand why the group made the decisions it did (even if they don&#8217;t agree with them).</p>
<p>Not all use of the above maps will accomplish all of these things in all situations and if the group doesn&#8217;t systematically explore and discuss the options it might neglect options, miss things or make errors in logic.  For these ommissions or errors it is up to the facilitator to detect these and raise them for group discussion.  Depending on the complexity involved or the knowledge of the facilitator it might not be until after the session that these are discovered.  Often the person who documents the progress of the group is the one who will find these as writing documentation can trigger insights which may not have been discovered or discussed by the group.</p>
<p>Another dynamic is that some groups will want to discuss things forever without making a decision.  It is the job of the facilitator to get the group to follow the steps through to making a decision and moving on.  There is a balancing act between rushing the conversation and missing things, and between never reaching a decision and never reaching the end.</p>
<p>There is a lot more to cover in this area and I will focus on these elements in greater detail in future posts.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.kyelight.net/organisational-change-meetings-part-two-helping-the-group-navigate-the-problem/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Organisational Change meetings &#8211; Part One: Forming the working group</title>
		<link>http://www.kyelight.net/organisational-change-meetings-part-one-forming-the-working-group/</link>
		<comments>http://www.kyelight.net/organisational-change-meetings-part-one-forming-the-working-group/#comments</comments>
		<pubDate>Tue, 14 Dec 2010 11:51:59 +0000</pubDate>
		<dc:creator>kye</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://www.kyelight.net/?p=25</guid>
		<description><![CDATA[In my last post I gave a quick overview of organisational change, and a significant component of the process is meetings.  I have found there are a number of types of meetings or phases that occur during this process.  In this post I will talk about getting the group to form so they can work [...]]]></description>
			<content:encoded><![CDATA[<p>In my last post I gave a quick overview of organisational change, and a significant component of the process is meetings.  I have found there are a number of types of meetings or phases that occur during this process.  In this post I will talk about getting the group to form so they can work together productively.  Often this takes place over a single meeting, but can take longer for larger groups or more complex or sensitive topics.</p>
<p>The first meeting is where you&#8217;re getting together this group of people for the first time.  It may be that many of the people already know each other, but unless all (or almost all) have worked together in harmony recently, the first step in the process is for the people to get comfortable with each other.  This fits well with the first 3 steps in Tuckman&#8217;s Group Development Model  which follows the steps: forming; storming; norming; and performing.  Tuckman suggests that groups form &#8211; where afterwards the people consider themselves part of a group, storm &#8211; where they test the other members to determine who holds the power in the group, and norm &#8211; where the group members define and conform to the accepted behaviours of the group.<br />
In my experience the forming / storming / norming takes a certain amount of time and will continue to happen for some time after you get the group actually working on real material, but will mean that the first meeting will be very unproductive in terms of getting &#8220;real work&#8221; done, because people aren&#8217;t yet comfortable with each other and are reluctant to contribute openly.  They will, however, likely be open to listening and perhaps criticising things they dislike or disgree with.</p>
<p>A format I have had success with for the first meeting is:</p>
<ul>
<li>Have everyone introduce themselves to the group, starting with yourself</li>
<li>As the chair of the meeting, provide an overview of what the meeting is about, how it will be run (ie, the agenda) and what you&#8217;re hoping to achieve by the end of the session</li>
<li>Give a high-level overview of the information you have gathered about the problem space</li>
<li>Get each person to comment on the information provided &#8211; saying what they agree with, what might be incorrect from their point of view, and to perhaps elaborate on how the issue looks from their perspective</li>
<li>To wrap up the session it is useful to thank everyone for their contributions, quickly sum up any progress, and give an overview of when the next meeting is and what you hope to cover in it</li>
</ul>
<p>Depending on how large, complex, or sensitive the problem space is, this first phase of getting to know each other and the problem space could take more than one session.  This is a very important stage to get right, and although the temptation may be strong to skip ahead to the parts where &#8220;progress is being made&#8221;, time spent here is a very worthwhile investment.</p>
<p>The primary purpose of this phase is to create trust between the members of the group, and (as much as possible) a shared understanding of the problem from all the relevant perspectives.  The less time spent creating these the more the process is open to people back-tracking, closing up or becoming hostile later.</p>
<p>Danger signs during this phase:</p>
<p>1. Members of the group not participating, holding back information, or resisting being part of the group.</p>
<p>Some people will hold back because they want to hold onto information which they believe gives them power, want to saboutage the change process, are afraid of change, or a combination of these or other factors.</p>
<p>During these first meetings pay attention to how often each person speaks, the level of openness in what they say, and their body language.</p>
<p>Dealing with people who are behaving in this way depends on several factors.  If you haven&#8217;t already met 1:1 with all the group members beforehand then you should meet with each of these people individually as soon as possible.  Ask them about their views on the subject at hand, what concerns they may have with the approach you have taken and who you have included in the working group, and what they might be able to get out of the sessions if everyone works together openly for a mutually beneficial outcome.  The emphasis in these conversations is to only ask enough questions to get the person to start talking &#8211; normally once you get someone to open up they&#8217;ll share their concerns with you and you can address them.  Often simply by listening and being sympathetic to someone&#8217;s concerns they feel safer and will be open to the process.</p>
<p>2. Talking about the change process instead of the material.</p>
<p>Some people will want to talk about how the organisational change effort should be run instead of participating in it.  This isn&#8217;t inherantly bad as it is normal to expect that people will want to understand how they are going to be working together, but the risk is that the session will get sidelined and too much time in the session will be taken up discussing this and not the material.  I would suggest a short discussion on this is healthy, and if it does occur try to get everyone to agree to try your approach and then get back to addressing the material.  There are a number of potential motivations behind this but they boil down to three basic motivations, the person wants to help, the person is nervous and is deflecting away from the material, or the person wants to actively saboutage the effort. Regardless of the motivation, if the issue takes up too much time, speak to the person 1:1 and try to address their concerns (as described in the previous point).</p>
<p>3. The conversation taking place at varying levels of abstraction, often simultaneously, with no progress being made or the conversation going in circles.</p>
<p>As an example, the conversation may talk about principles, and then ramifications and then specific details, then back to principles again.  This is very common as most people find it hard to talk about undefined problem spaces without the level of detail already established.</p>
<p>The way to address this is to set a level for the group and then only waver from that level if the conversation demands it, and then make it clear to the group what level the current conversation is taking place at.  The written material you provide will often do this as people will normally discuss what materials are provided for the session.  You may find it useful to  discuss principles and then once they&#8217;re agreed then start talking about something at a lower level of detail (eg, operating models) and then go into the detail from there.  There is often a need to go from operating model level to real-world examples and back up again as this is a form of validating the model by applying it to reality and seeing if it makes sense, but if the conversation wanders too much or you see that people are becoming confused then you may want to intervene.  If you need to intervene one approach can be to ask the group how they think the conversation should be approached &#8211; this can often reveal peoples opinions on the topic or other hidden motivations, such as lessons from failed previous improvement attempts.</p>
<p>There are many other patterns that can occur, but I have found these to be the most common in my experience.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.kyelight.net/organisational-change-meetings-part-one-forming-the-working-group/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The 5-minute guide to organisational change</title>
		<link>http://www.kyelight.net/the-5-minute-guide-to-organisational-change/</link>
		<comments>http://www.kyelight.net/the-5-minute-guide-to-organisational-change/#comments</comments>
		<pubDate>Sun, 24 Oct 2010 07:03:02 +0000</pubDate>
		<dc:creator>kye</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://www.kyelight.net/?p=15</guid>
		<description><![CDATA[Making significant change in an organisation is easier than you might think.  Here&#8217;s some thoughts. Step zero: Take your ego out of the equation. You should be performing organisational change to get the best result for the people involved in the situation.  The moment that you start putting yourself in the picture you will start [...]]]></description>
			<content:encoded><![CDATA[<p>Making significant change in an organisation is easier than you might think.  Here&#8217;s some thoughts.</p>
<p>Step zero: Take your ego out of the equation.</p>
<p>You should be performing organisational change to get the best result for the people involved in the situation.  The moment that you start putting yourself in the picture you will start to skew the outcome.  The best result may be that nothing changes &#8211; the ego will fight to &#8220;leave it&#8217;s mark&#8221; and this will negatively effect the whole process.</p>
<p>Step one: Find something to work on.</p>
<p>Choose something important &#8211; if you choose something insignificant, no-one will show up to help you because no-one cares enough about it.<br />
Find something that is big picture enough to affect a range of people.  If you choose something that involves lots of people then chances are that no-one is focusing on fixing it, everyone will probably be polishing their part of the process in isolation and not looking at the big picture.<br />
Don&#8217;t bite off more than you can chew.  Some indicators that something might be a bit big (for now anyway): you are completely unfamiliar with how this process works and who does what; a previous attempt to fix it failed relatively recently; the people involved are too busy to be involved; someone with veto power likes the current practice and will fight attempts to change it.</p>
<p>Step two: Work out who is involved and talk to them about it.</p>
<p>Find out the background to the situation and get your bearings.  Often problems exist because there are aspects to them that aren&#8217;t immediately obvious &#8211; these are the reasons the pain still exists and you need to find them.<br />
Find out who the influential people in the situation are.  Remember that influencers can be people with organisational power (ie, managers / bosses), people with informal power (ie, &#8220;if Bob is ok with it, then so am I&#8221;), or people that the process has made powerful (ie, &#8220;Jill is the only one that can process these in the system and she&#8217;s really picky&#8221;).<br />
Meet with the influential people and see how willing they are to look at how well the process is working.  Be very careful not to take sides at this stage &#8211; just because some parties are feeling pain doesn&#8217;t mean that there isn&#8217;t a legitimate reason for it, and coming in with assumptions about the outcome will only make things harder to find a positive outcome.  The primary thing to focus on here is how willing these people are to work with others, to share information and to listen.</p>
<p>Step three: Work out the approach.</p>
<p>For less controversial items, just get everyone in a room, set the scene and then let them talk through it.  For trickier items you might want to meet with everyone individually beforehand to set the scene and to give them a chance to be heard so the main meetings can be smoother.  For items where the power players don&#8217;t want to be open, perhaps meeting with some/all of them before the main workshop might be helpful.  Once you believe everyone is willing to attend and be open to what others might have to say, then you&#8217;re ready to start the main discussions.<br />
The focus here is to get everyone in a room to talk about it.  Often, the huge pain one person experiences can be averted by someone making a relatively small change.  At first most won&#8217;t understand why they should change something they do but hearing what life is like for the other person and how much pain is involved is often enough for them to volunteer to help out.  This approach appeals to people&#8217;s good nature and puts them in a position to offer to help rather than be forced into it.<br />
When writing meeting agendas be realistic about time.  Unless the participants work together regularly, people will still need time to form and bond before trust is created and they can work together.  It takes time for people to feel they have been heard and to hear and understand others.  Keep the approach flexible and don&#8217;t try to hurry people unless you absolutely have to.</p>
<p>Step four: Have the meetings.</p>
<p>Set the scene for why you have called everyone together and what the approach will be.  Try to follow the agenda and if you can&#8217;t, discuss how you should proceed with the group.  Facilitate well and stick to time &#8211; a well run meeting will ensure people will attend the next one.<br />
The primary outcome of the meetings are that each person involved understands the challenges that all the others involved face in that scenario.  Once the common understanding is reached, switch to solutioning mode and get the group to talk through possible improvements.  Often these are quite obvious from the earlier discussion and simply gathering these may be enough.  The last step is for everyone to agree what will be implemented.</p>
<p>Step five: Communicate with the wider audience.</p>
<p>If everyone involved in the scenario was at the workshops then there isn&#8217;t much do here.<br />
In larger organisations the people in the workshops are normally representatives of other people who are involved in the scenarios discussed.  If this is the case the outcomes need to be communicated so that everyone knows how to proceed and why this is the way things should occur.<br />
It may be that the pain point was that people were required to do something without knowing why, and afterwards they understand there is a good and practical reason for it, so don&#8217;t feel so bad having to do it.  Of course, if there are changes then these also need to be communicated out, with an emphasis on why the changes were made and who represented their interests during these discussions.</p>
<p>Step six: Gather feedback</p>
<p>It is always a good idea to solicit feedback around how well the process went as this is the only way for you to improve over time.  This can be as formal as a survey with statistics, or as informal as having a chat over coffee offsite with those involved.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.kyelight.net/the-5-minute-guide-to-organisational-change/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

