Enterprise Wide Problem Mapping: Step 2 in Enterprise Transformation

This post is focused on identifying and prioritizing constraints within an organization as part of the transformation process.  It's important as leaders and knowledge workers that you take the problem solving (or as some call it Root Cause) step very seriously and more importantly patiently.  After all problem solving is usually the original intent for the majority of transformation efforts.  Womack describes four essential Lean management states of mind that must be cultivated for an authentic transformation with problem solving being a large component:
1. The Lean manager eagerly embraces the role of problem solver.
2. The Lean manager realizes that no manager at a higher level can or should solve a problem at a lower level—problems can only be solved where they live, by those living with them.
3. The Lean manager believes that all problem solving is about experimentation by means of Plan-Do-Check-Act.
4. The Lean manager knows that no problem is ever solved forever.
James Womack, “The mind of the Lean manager,” Lean Enterprise Institute Electronic Newsletter, July 30, 2009.

My first blog post was a summary of the steps which need to be taken in order to start an enterprise transformation by briefly discussing the management components which much be in place for any transformation to begin.  This second blog post was written to introduce the idea of thinking about organizations horizontally (value stream).  The first steps in an enterprise transformation are slow but are very important.  What is often overlooked is most organizations simply don't grasp how much help the average manager needs in learning to see the value stream or how eagerly managers  embrace the mind map once they see them. Now if only every manager and every mapping team can achieve and sustain the effort to understand current state.

Without a mind map (or other identifier) of the current state picture defined, your problem identification and consequent solutions will be hard to socialize.  Furthermore this activity is likely the first time you or your leaders will have seen your organization in this light. It will be  shocking with how large and thorough this map will be, especially considering this isn't an "organizational map".

All this work has not yet provided anything which traditional change programs would be considered a "win".  That's just the point, this is not a program.  This is a cultural transformation which will take time  between when this starts to when you will start to measure improvement.  It's important at this point to be patient as this phase in the process sees the problems and must have restraint to not try to solve them as they are identified. Be patient, you will get there.

The mind map is complete, now what?  Edward Deming said it right when he said most problems are because of process not people.  As a result it's important not to assess blame in these exercises.  There is little value in blaming others for the problems as it creates an atmosphere which does not facilitate positive results.  It's a good idea at this point to continue involving members of the team who created the mind map(s).  No manager at a higher level can or should solve a problem at a lower level. (And one of the worst abuses of lean tools lies in trying to do just this.) Instead, the higher-level manager can assign responsibility to a manager at a lower level to tackle the problem through a continuing dialogue, both vertically with the higher-level manager and horizontally with everyone actually touching the process causing the problem. Womack's lean law of organizational life is that problems can only be solved where they live, in conversation with the people who live with them and whose current actions are contributing to the problem. But this requires support, encouragement, and, yes, relentless pressure from the higher-level manager.

This point is where different methodologies and frameworks will diverge as well.  There is no right or wrong way to move forward from here.  The many variables of your situation as well as what type of organization you are will dictate the most sensible path.  You can use many different methods to determine the size of a problem as well.  The suggestion I will give is simply one path of many that can be successful.  Once a problem map has been identified you can easily insert it to the method which you find best suits your company (Theory of Constraints, BPR, TPM, Lean, Six Sigma, Agile, ETC).

Create a mind map of your issues.  What I mean by that is take the original mind map and create a correlating issues map.  Don't stop with the first few problems you encounter.  Try to make it as thorough as the mind map.  This is the map where you will look at activities to improve and/or ignore. We know it's not possible to fix everything now, but with this list you will be able to quickly take issues off the map when they are resolved as well as (and this important to do) add items when they appear.  Below is an example of a problem map I facilitated with a Quality Assurance (QA) group in a software development department.  You will note there are no solutions or assignment of blame.  Simply a map of what the problems are.

Again this map will likely be a first for your company.  It's not often a company has a map of their largest issues/complaints.  With this map you are now prepared to take a step which can start to deliver measurable results.  It's best to have your team who created this map sit on this for a couple days.  Have them think over what they have come up with.  Then get the group back together to discuss the problems and narrow down where to start.
Take the complete map and start talking about what are the biggest issues.  It's likely that the room will already have a consensus on the largest issues.  When there is a consensus on what the largest problem is.  Use what is known as the "5 Whys".  The 5 whys is a proven method to determine how to get to the root cause of a problem.  Rather then explain it myself I will borrow from a great book titled "Lean IT" by Steve Bell.

"The Five Whys is the simple method of asking, “Why?” repeatedly until the root cause of a problem is uncovered. Normally the root cause is reached by the time we ask the fifth why. When the team believes it has identified a root cause, it works backward using “Therefore…” to test its logic and ensure it hasn’t missed a step in the sequence. For example, if the team investigating IT service request delays would have used the Five Whys, it might have gone as follows: Had the team performed root cause analysis, it may have discovered that there was a need for improving underlying business processes and developing standard work before considering technology-based solutions (a common theme throughout this book)."

Bell, Steven C. (2012-01-04). Lean IT: Enabling and Sustaining Your Lean Transformation (Kindle Locations 4004-4010). Taylor & Francis.

Once you have found what you consider to be the largest problem in the mind map and the problem if fully agreed we will now take that issue and make it our first actionable item which we will focus on for our enterprise transformation.  That will be the topic of my next blog post - Value Stream Mapping.

Please let me know if you have any questions.  This topic is very broad and I am the first to admit there are many ways to achieve what I've explained .

Starting Enterprise Change Step 1- Current State Mind Mapping

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 resource.  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.   To begin with a metamorphosis of the enterprise you need to fully understand the current state of your enterprise.  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 are 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 and can be offended with the assessment.  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 everyone's 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 larget 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.  

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.  

A mind map as defined by Wikipedia is "A 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 words, ideas, 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 mapping takes what are often considered complex relationship 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. 

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.  


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. 

Executing Change in Your Organization. Part 4 on Organizational Change

Part four of this blog series on initiating change in the organization through Future State Mind Mapping and the execution of the change.  This part consists of the actual change, which most people are patiently waiting for.  The secret lies in how you and the project team use the Future State Map to develop this action plan. Remembering that the Future State Map is the blueprint for change is the single focal point for developing a good plan for improvement. Trying to create the perfect plan must not bog down the team. As General George S. Patton so bluntly stated, “A good plan today is better than a perfect plan next week.” The logic behind this statement was simple: It really doesn't matter what you plan, or how perfect you may think the plan is; when the plan is put into action, things will change. Therefore, get a good plan in place and move forward to implementation.

We often don’t see or understand the entire process, which includes the complexity hidden behind the scenes, and the interdependencies with other processes and systems. Cross-functional teams using tools such as value stream mapping thus uncover comprehensive problems, where everyone understands the process.  For those reasons we spent a great deal of time preparing to understand the organizational issues and evaluating the value stream. We are now ready to improve value delivery by creating a Future State Value Stream Map (FSVM).

Let me add a caveat to all this work I have defined for you.  This is only scratching the surface of continual improvement.  That's the point of writing these series.  You don't have to know it all to get started.  Having a basic should be enough to get going.  You likely have enough constraints facing your company that these high level suggestions will get you started.  There is much much more to learn though and that's why we call it continuous improvement. The time for strategy is over. Now the process of change can begin. But this does not mean that Value Stream Mapping is complete. Just like all other aspects of continuous improvement, Value Stream Mapping is never finished. As the project work progresses, the team may find that it is necessary to return to the map set and to update and modify both the Future State Map and the action plan.

The future state value stream map is a visual representation of the application of the various Lean tools in the Future State map.

It is created by:

• Arriving at a consensus

• Brainstorming

• Problem solving

• Testing tools for practicality and use

• Resource availability 

The future state value stream map will never be implemented all at once. It is meant to be adopted over a time period (i.e., six to eighteen months). The following icons can be used to create the future state value stream map.

Steve Bell in his book Lean IT comments. "Perhaps the highest accomplishment in Lean is to achieve value stream flow. So here are our simple (but not necessarily easy) guidelines for creating Lean IT flow: Position and evolve each value stream toward your competitive sweet spot; maintain a fluid balance between flexibility and efficiency in every process and practice. Stay light on your feet; keep your focus moving in the direction of competitive advantage as the market and your competitors evolve. Strive for simplicity and stability in every process before investing in electronic information systems: apply people, process, and technology—in that order. Listen to your customers often, and proactively manage demand to support just-in-time operations Flow every process where you can. Keep a simple line of sight (physical or virtual) along the entire length of every value stream and supporting process, so they become self-regulating, leveraging the creativity and problem-solving capability of every participant." Bell, Steven C. (2012-01-04). Lean IT: Enabling and Sustaining Your Lean Transformation

We are finally there.  We have mapped our value stream.  What components on our value stream we want fixed.  If this is your first time it's likely that you have a large amount of Non-Value Added activities.  Likely it's below 5% of your total value stream.   Don't worry this is normal.  Most companies run with this VA/NVA ratio.  If you are above 5% then likely you have left parts out or you've been working on this for a while and these blog posts are already achievements you have completed.  In looking at your value stream look for long wait times.   Those long wait times may not be a bottleneck in terms of how much work you can process but can contain a large part of your value stream non-value added activity.  Additionally wait times are the easiest to fix because they involve little process redesign or investments needed.  For example, if you have weekly meetings to plan work or approve components of your value stream then you're likely adding a minimum of 7 days to your total cycle time.  Find a way to reduce meetings to daily standups or eliminate them all together and you've shortened your cycle time by 7 days (Just think if one day's inventory is worth $10,000 then you have eliminated $70,000 of inventory just by eliminating a meeting).  

Along with the list of items you will be working it's a good idea to prioritize the items to prohibit boiling the ocean.  "Mapping the Total Value Stream: A Comprehensive Guide for Production and Transactional Processes" by Mark Nash has a great list which I would recommend for prioritization. 

• Are fast and easy to complete        
• Are most visible to the workforce (to demonstrate the power of continuous improvement)        
• Address the biggest problem to the customer        
• Address the biggest problem to the supplier        
• Address the biggest problem to employees within the value stream        
• Address customer satisfaction issues        
• Effect biggest ROI        
• Effect fastest ROI        
• Facilitate employees' acceptance of change (fastest buy-in)        
• Pertain to the toughest employees to convince

Regardless of the continuous improvement methodology employed by the organization, Value Stream Mapping lends itself well to the concept of kaizen. Although kaizen is literally translated from Japanese as “good change,” it is more appropriately defined as “rapid, good, continual change.” This concept, which is used in a cultural fashion with many Japanese companies, empowers the work force to immediately stop a functioning value stream at any time when a problem is encountered. All persons required to identify the root cause and a solution are gathered, and the issue is resolved as quickly as possible. Use your whole team to determine what activities or wait times on the value stream you will work on.  Involve as many people as you can in the process.  I'm not suggesting the solution needs to be by consensus but it does go a long way to get as much input from your intellectual capital (employees) as possible.  After all they know the problems all too well because they live in them daily. 

Once the fundamentals of the current value stream map and the future map have been addressed, there is a strong need to ensure that the implementation of improvements is carried out in a structured and methodical fashion. Without someone driving forward the improvements, they are unlikely to happen and the improvements to performance will be negligible. Similar to how you created your mind maps and value stream maps have someone who's watching the value stream and looking for opportunities.  This doesn't mean they are in charge of the value stream.  That role is for everyone within the value stream.  Everyone in charge of improving the value stream is also responsible for it.  

In order to keep track of your progress a lean improvement chart is one method I prefer.  A Lean improvement chart lists each Lean concept that the project team wants to introduce and sustain within the value stream. Each concept is shown with a section devoted to training, implementation, and sustainability. The overall success, as well as that of each component, is measured as “percent complete” on the chart, allowing for the team and the employees in the area to see their progress.

Finally, as progress is observed, the results should be conveyed to management in a format that allows for financial impact to be understood. Because any change that is implemented should ultimately result in improvement to the bottom line, it is critical that metrics provide data to support and substantiate the change. However, when dealing with the financial impact, it may be necessary for accountants and financial analysts to rethink the traditional ways of financial reporting. Implementing change at a fast pace may create a situation where traditional financial reports are misleading. The executive council must understand these potential situations and be prepared to have the financial staff of the organization retrained to think differently and also to strongly support the mapping and project team.

Your success will come from accepting change. Winning comes from a culture that embraces change and pursues perfection.  Setting lofty goals, empowering employees to do the things necessary to accomplish those goals, and accepting the rough spots along the road are the things that set great organizations apart. Success comes from understanding that the road to perfection is a journey of continuous improvement. Making change in small pieces, at a pace in the beginning that is acceptable to both employees and management, is how change starts. As the culture comes to accept change, the speed and amount of change will grow as well. By starting with those things that are easy to change, and by working with the employees accepting or wanting change, success will come.

But you must remember: this is only the beginning. Value Stream Mapping is not a “one and done” tool used at the beginning of the journey, never to be repeated. Value Stream Mapping, just like so many other continuous improvement tools, is to be used from now on. If you quit, it's not continuous improvement. Do not believe those who say: “We've achieved the future state. We're done.” You are never done. When the team, management, or employees within the value stream begin to realize they are close to the Future State Map, it is time to remap. This is the time to remap the Current State Map and create a new vision of the future.

Your Budgets For Next Year Are Likely Now Complete, Now See How it's Ruining Your Value Delivery.

Everyone has to deal with budgeting.  Budgeting is simply the process of determining how to fund your expected needs in a project.  Budgeting is not a process with an extensively long history.  Much like most modern management it is a function of how organizations with tremendous growth planned spending. They determine how people behave in any given situation. Focusing leaders' minds on the stewardship of shareholders' funds and ensuring that managers worried about controlling costs were its original functions, and leaders and managers, by and large, behaved accordingly. But budgets have since been hijacked by a generation of financial engineers that have used them as remote control devices to "manage by the numbers." They have turned budgets into fixed performance contracts that force managers at all levels to commit to delivering specified financial outcomes, even though many of the variables underpinning those outcomes are beyond their control. This leads to undesirable and, in many cases, unethical behavior.

How has budgeting and the finance process stiffed innovation to the extent where over 90% of professionals look at budgets in negative terms.  Why is there not more outrage regarding how the process denies agility?  Lean and agile models work towards delivering value while adapting to changing business needs.  I believe there is nothing more threatening to an agile and lean process then the limitations set forth with a budgeting process.  When budgets are calculated to forecast something a year to six months out how can this possibly foster value creation? Budgets are a modern day contract where the budget contract is usually fixed for a period of twelve months. Its purpose is to commit a subordinate or team to achieving an agreed-upon outcome and then to enable a superior to control the results against that outcome (reserving the right to interfere and change the terms if necessary).


How have we arrived at such high levels of dissatisfaction with budgeting? There are three primary factors: (1) Budgeting is cumbersome and too expensive, (2) budgeting is out of kilter with the competitive environment and no longer meets the needs of either executives or operating managers, and (3) the extent of "gaming the numbers" has risen to unacceptable levels. Few senior executives seem to be aware of these problems. They see outcomes in terms of numbers rather than behaviors. In this context, budget contracts can act like drugs. They seduce executives into believing that they have control over their future financial outcomes. But, like most drugs, they have serious side effects. They lead both senior executives and operating managers into an annual performance trap from which it is difficult to escape.


In these turbulent times the budgeting process struggled to cope. Goals and measures were internally focused. Intellectual capital was outside the orbit of the budgetary control system. Innovation was stifled by rigid adherence to fixed plans and resource allocations agreed to twelve to eighteen months earlier. Costs were fiercely protected by departmental managers who saw them as budget entitlements rather than scarce resources. The internal focus on maximizing volume collided with the external focus on satisfying customers' needs. And far from being empowered to respond to strategic change, front-line people found that it was easier to do nothing than to try to get multiple signatures on a document authorizing a change in the plan.


The organizations I have worked with used to set targets on the basis of financial numbers that, more often than not, were negotiated between superiors and subordinates before the start of the year. These numbers were fixed for the year ahead and represented the key component of the annual fixed performance contract. All actions were then focused on meeting the numbers not on value delivery. However, whether this process maximized the profit potential  is doubtful given the desire for superiors to stretch ambition and the desire for budget holders to play safe.


What does the Lean Technology Transformation do to solve this?  Well it's not so simple but here are some ideas.  What holds your organization together is not a plan, but a commitment to a clear purpose and to a set of clearly articulated principles and values.  To create value intellectual capital needs to be set free from stifling bureaucracies, free from the restrictions of predetermined plans, free from the fear of failing to meet fixed targets, and free from the forced cross-company actions designed by central planners.  Agile leaders set targets based on high-level key performance indicators (KPIs) such as return-on-capital, free cash flows, or cost-to-income ratios. Goals are typically set at levels aimed at maximizing short- and medium-term profit potential at every level of the business. Managers are willing to accept (or propose) these stretch goals because their performance will not be evaluated and rewarded against them. They will subsequently be measured and rewarded using a range of relative indicators such as peer group performance, internal and external benchmarks, and prior years' results. "Baseline" goals set a lower reference level of expectations. Though goals are primarily financial at the highest level, they become more operational the nearer they are to the source of value delivery.

By making this transition The benefits are that the process of setting targets is fast (days rather than months) and because it is based on relative measures it will seldom need to be reset. Also, because the benchmarking bar is always being raised, it is more likely to maximize profit potential. Some project leaders figure they have saved 95 percent of the time that used to be spent on budgeting and forecasting. This time is more usefully spent on planning how to create more value for customers and shareholders as well as how to respond more effectively to change.

Changing to a more updated model fundamental matches the goals of a lean organization.  The impact on the behavior of front-line people must not be underestimated. It leads to what Harvard professor Chris Argyris calls "internal commitment." The hidden problem, according to Argyris, is that people have to deal with two types of commitment. First, there is external commitment, which, by and large, leads people to fulfill contractual obligations specified by others, and in which performance goals are top down. Second, there is internal commitment, which allows individuals to define their own plans and the tasks required to fulfill them, and which is participatory, comes from within the individual, and leads to people taking risks and accepting responsibility for their actions.This is the behavior that the relative improvement contract seeks to encourage. The rhetoric of leaders does not produce internal commitment any more than it leads to effective empowerment or personal responsibility. Such changes require a fundamental change in the process that determines the behavioral context.

Finally, what needs to happen in the firm is a decentralization which enables leaders in your high performance teams.  Below are six common principles which organizations who have made this break posses:

1. Built a governance framework based on clear principles and boundaries
2. Created a high-performance climate based on the visibility of relative success at every level
3. Provided front-line teams with the freedom to make decisions that are consistent with governance principles and strategic goals
4. Placed the responsibility for value creating decisions on teams
5. Focused teams on customer outcomes
6. Supported open and ethical information systems


The leaders in question have abandoned the notion that employees base their commitment on mission statements and detailed plans prepared by someone else. They have abandoned the command, compliance, and control approach that assumes that strategy formulation and execution take place in separate compartments. And they have abandoned the assumption that front-line managers cannot be trusted with the responsibility to think and act on the latest information in the best interests of the firm as a whole. They have built a relative improvement contract based on mutual trust, with clear responsibilities for high-level performance from front-line people. They have also built a community spirit that reflects the interdependence of the organization and that supports seamless solutions for customers. Above all, they have recognized that people respond more positively to clear values and principles than to nebulous mission statements and detailed plans.

Claim Code - QJ225G8B6PJC