Wednesday, April 16, 2014

Enterprise Change Can Not Be a Project - Creating a Lean Enterprise

In my previous blog post Waste Is Everywhere and It Starts With You  I discussed that constructing enterprise transformations are difficult for a variety of reason (yes and it usually starts with you).  By definition an enterprise transformation is any series of organizational steps leading to improvements which create greater value to your customer and then your organization or resources.  This post will assist you in getting acquainted with starting a transformation initiative and some common techniques you can use to navigate the politics which will block your success.   Beginning a Lean  Culture Transformation can not begin as a project. Let me explain, by definition a project has something with a beginning and and end.  Regardless of how successful your organization is at project and project management at some point a lean project will have a completion date.  At the point of completion what happens to your lean transformation?  In the book Creating a Lean Culture we learn,  "Culture is no more likely a target than the air we breathe. It is not something to target for change. Culture is an idea arising from experience. That is, our idea of the culture of a place or organization is a result of what we experience there. In this way, a company’s culture is a result of its management system. The premise of this book is that culture is critical, and to change it, you have to change your management system. So, focus on your management system, on targets you can see, such as leaders’ behavior, specific expectations, tools, and routine practices. Lean production systems make this easier, because they emphasize explicitly defined processes and use visual controls." Mann, David (2012-01-24). Creating a Lean Culture: Tools to Sustain Lean Conversions, Second Edition.1. First any change initiatives need to have top down support.  This doesn't necessarily mean that upper management needs to manage the change but at a minimum they must fully support the change initiatives and be willing to change themselves.  Additionally with the top down support you must fully tap your intellectual capital but I'll get to that later. 
2. Create a blank slate. Do not come in to the initiative with a pre-conceived notion of what or how to change.  Spend time if you need to getting people on board who can be objective and provide honest input.   While being objective can be difficult, you will already have a room full of pre-conceived solutions if you do not take this step seriously.  After all if you already have the solution to the problem why haven't you succeeded thus far in eliminating it?  This is difficult additionally because most change initiatives within an organization are initially created because they want to solve a specific problem.  In the end the original problem will be solved but TOC and mind mapping will eventually identify your root cause. 
If you're new to this concept or your organization is very basic on conceptualization then start small.  Perhaps do it inside your span of control or as a personal improvement plan for your commission   It's very important that you involve all the intellectual knowledge available on the matter.  If you fear this can't be done initially then narrow your first step to where you can have full access to that knowledge base.  The largest disservice organizations can make is to not involve the knowledge workers and only involve management.  Management certainly can participate but in today's world most intellectual knowledge  is the tacit knowledge of your IC (regardless of industry I find this to be true.  Peter Drucker initially saw this as early as the 1950's and it has only continued to be proven true).  Getting the caveats out of the way allows us to finally talk about what is the first step.  This stride can often be the most difficult because there are so many potential ways to begin (and fail).  There are countless articles and books which describe how to create successful organization change and most are exceptionally good from certain frames.  I find them a bit too prescriptive and often complicate something which should attempt to be simplified.  Being too despotic out of the gate narrows the possibility of success when your case should need to deviate from their framework.  My personal experience has proven that beginning with a mind map is a solid common method to define what previously only exists in your mind.  The information you will discover in a mind map has likely never been mapped for your organization and your ability to learn from the experience is truly priceless.  
Mind mapping takes what are often considered complex relationships between organizational components and allows them to be visually simplified.  This method does a great job in minimizing what Chip Health and Dan Heath defined in their book Made to Stick: Why Some Ideas Survive and Others Die as the curse of knowledge.  The curse of knowledge occurs when we assume others around us have the some comprehension of concepts which we often consider second nature or back of our hand.  Alas we have a hard time often explaining our jobs, product specs or protocols to those who are not inside the organization day in and out.  For example,  if you ever have the opportunity to listen to air traffic controllers working, you will understand what I'm talking about.  Their instructions to pilots are firm and concise but if you're not educated in to their protocol you would not have any idea what they are talking about. 
For example, say you're mapping for IT Project Management role in an IT department.  You would place Project Management as the center section while each additional trunk off the main idea would be the major components of the Project Management role.  This information is identified and facilitated on the map by the members present in the mind mapping session who are calling out the responsibilities of each trunk.  The below example is a mind map created for an IT shop I was consulting several years back.  The participants were allowed to take the conversation as deep as they wanted without the worry of political fallout or conflict.  Recommendation - I often do not invite managers to the meetings as they will tend to take control of the conversation.  Managers tend to not want to discuss what  structure really is but what they think it is.  This does not facilitate an honest open session and can prohibit real improvement from occurring.  If you feel management needs to be involved I would encourage setting up a mind mapping session with only managers who are peers and allow them to speak freely.  Additionally I do not recommend sharing the results between groups.   The best test on the delta between the two groups is to have them create their maps organically and independently of each other. 
IT Department mind mapping of the Project Manager position
The facilitator of this session can be anyone but it's generally a good idea to use someone outside the group who doesn't have the curse of knowledge regarding the inner workings of the team.  Additionally it's a good idea to make sure your facilitator is just that, a facilitator and not driving the concepts.  Each trunk is a large concept that generally can't not be compiled to anything larger (agileists can recognize this as an epoch).  When creating your mind map I encourage you to go where the discussion goes.  This may result in jumping around to different trunks but it's unliekely people will be able to identify all components of one trunk at one time.  Furthermore you will start to find that people want to quickly point out the problems when discussing items.  Encourage this but do not dwell on it.  Quickly put it in the branch and move on.  Otherwise these sessions will get bogged down in negativity.  The image above  shows a trunk of Project Management and their role in facilitating as part of their job responsibility. Notice that concepts have been identified and some have the problem branch associated. This is as far as it goes, the purpose of this initial assessment is to understand current state, not to prescribe solutions. 
This is step one for your transformation.  If you want a more detailed example or have questions please feel free to contact me.  I believe the power of this tool is so valuable that it should not be reserved for highly paid consultants.  You should be using it daily to improve your job, department, company and life.  In the next post I will show you how to identify problems or areas for improvement and how to put structure around that second step. 

Defining a culture as a result of management systems by nature proves that you can not change a culture through a project.  Ok, now that we know this starts as a cultural transformation how do we start our journey.  There are many more cultural topics to discuss in this regard but for this post I want to focus on technical work which must be done. Standard lean advice calls first for stabilizing a process, followed by standardizing it, and then simplifying—or improving it. This advice also often applies to the sequence for implementing the elements of lean management.  Organizations that attempt to start their lean management implementation with leader standard work often find it difficult and confusing. Their difficulty makes sense when you think about the unstable state of many conventional operations before a lean conversion begins. Leaders spend their days firefighting and expediting, especially in areas closer to the floor in factory or office processes. It is tough to create a stable, standard routine under those circumstances. Organizations find they cannot make leader standard work effective because the leaders are constantly being pulled into a crisis or emergency. The leaders asked to try it say that leader standard work does not make sense, that it is not meaningful to them.

To begin with a metamorphosis of the enterprise you need to fully understand the current state of your enterprise.  In other words you need to take a step back, don't try to fix what you perceive as the most pressing issue but try to create a view of the Enterprise to show all your processes and workflows. Current state is plainly an agreed on visual representation for how the organization looks today.  It does not define solutions or place blame.  It simply is the baseline you will use to define and measure your organization transformation.  

The most common contention which commonly arises in enterprise transformation is what I call
climbing the mountain.  Intellectual Capital or IC (your employees) in most organizations have no problems identifying and defining all the inefficiencies within their organization.  Complications ensue though when they asked how to resolve those issues or how they came to be. Additionally much time is wasted arguing the merits of the issues when you're simply trying to identify your current state.  It's even more difficult when the IC are part of the problems which they are trying to identify.  No one likes to feel they are a liability to the organization and most IC rarely objectively realize they are.  Add on the bureaucracy of pet projects or emotional commitments and it's really no surprise the failure rate of these initiatives are so high (some estimates as high as 90% according to Bill Waddell

Second, when issues are identified, how do you objectively decide what to work on without adding the complexity of everyones flavor of the day?  The flavor of the day consists of what's current in your mind as your biggest issue (which is often the most recent) facing the organization.  This is rarely the largest non-value added component which needs the highest priority but is simply the one that pops in to your mind as the most recent (and likely the most important if we are being subjective).   A simple example of this is defined in The Goal written by Dr. Eliyahu M. Goldratt, a business consultant whose Theory of Constraints (TOC) explains that anything not a bottleneck should not get initial focus as it will not improve your process capacity.  This story though shows how easily the wrong item can be worked on and why it's so hard to identify the bottleneck or largets problem.  

While much of what I'm introducing was created in Lean cultures I don't propose calling yourself Lean when you successfully implement these steps (you still have more learning to actually "Be Lean"). Introducing Lean management and information systems requires discipline, time and reflection. Lean principles are even more difficult to embrace, yet they eventually come to influence behavior throughout the enterprise. Values and principles must have time to become internalized within the unique culture of each organization and this is simply a first step. Nonetheless, it is difficult to begin with values and principles alone, because they are intangible. This is where the principles of mind mapping will help (By far the best literature on Lean in IT is Lean IT by Steve Bell and Mike Orzen.  This is the most comprehensive book you will find if you're trying to start your lean journey in IT).  

Great, you want to begin your lean journey but where do you start?  I've told you all the problems you will face but haven't yet told you how to avoid them.  Where does one begin and who should be involved?  This blog post can not tackle that large of a concept but I suggest several books to read to get acquainted with some best practices (A great place to start is Making Strategy Work by Lawrence G. Hrebiniak).  At a very high level though your organization must tackle several components in order to launch.  

A mind map as defined by Wikipedia is "diagram used to visually outline information. A mind map is often created around a single word or text, placed in the center, to which associated ideas, words and concepts are added. Major categories radiate from a central node, and lesser categories are sub-branches of larger branches. Categories can represent wordsideas, tasks, or other items related to a central key word or idea."   Admittedly  the main goal of a mind map is for the facilitation of knowledge transfer from everyone in the session around one concept.  Granted it's not that easy, but the concept can range from the organization all the way down to a specific job role.  This simplified approach is successful primarily because simplifies what is  very difficult for people to state in a traditional strategic approach (Brain Storming, etc). 

Mind maps do a great job at minimizing the curse of knowledge by allowing a simplistic framework to state what  is often "obvious" .  Mapping can be done with software (I use Inspiration 9) or simply a white board or powerpoint.  The map starts with a center point concept or locus.  
This concept is the highest level of which your initiative focuses.  There can not be a higher level defined in the map.  If you were to start this map with your C level executives then you would have the name in the company in the center.  

Popular Posts