A couple recent articles in the India press related to Theory of Constraints.  (Disclaimer: I have been working with Goldratt Consulting, which features in these articles.)

Capitalising on the after-market by Chandrashekhar Chaudhari in The Financial Express talks about the TOC approach to replenishment and distribution.  I like the emphasis that the replenishment policies should be defined by their consumption rate.  Recent TOC approaches have divided products into the fast-moving "head," the middle "belly," and the slow-moving "tail." 

Companies resort to Theory of Constraints to stay ahead in the game in The Economic Times talks about several companies that have used Theory of Constraints: Doctor Reddy's Laboratories, Bajaj Electricals, Tata Steel, Godrej & Boyce, Kurlon, and Liberty Shoes.  It's a nice sampling of the different applications of TOC in a wide variety of businesses.  My only question is why they use the phrase "resort to" in the title - at least in my interpretation this suggests that TOC is a method "of last resort," rather than something you go to first.

And this interview with Rami Goldratt in The Economic Times reminds everyone that TOC is primarily about focus: both what not to do and what to do.  The article seems to be disjointed pieces of a conversation, but it gives a quick introduction to many of the ideas that appear in Theory of Constraints: focus, constraints, projects, innovation.  

PrideandjoyHow do you feel about your work place? Are you excited about the people and the work?  Or have the well-meaning policies and ineffective "improvements" grown wearying?  Even worse, have you started dreading going to work because of all the chaos?  Depending where you are, reading a story about such a situation could be painful or it could be very engaging.

Linda Seed finds herself thrust into the leadership of a hospital that seems to be stuck in perpetual chaos in Pride and Joy by Alex Knight (book website). And for me, I found the book quite engaging - I didn't even take time out to write many marginal notes.  

Pride and Joy is a business novel written by a long-time Theory of Constraints consultant.  The characters in the story do not talk about TOC directly. Of course, they use TOC principles and concepts, but the focus is on telling the story and showing how those various principles might fit into a larger whole.  Of course, since this is a TOC novel there is a business that is failing (the hospital), a guru character (Linda Seed's graduate school friend - who works for free!?!), and some minor outside-of-business life plot elements.  

Knight does an interesting job of showing the high level process of describing What to Change, What to Change To, and How to Cause the Change which is a core way of thinking within the TOC community. This is also connected to how people react to proposed changed: if they don't understand the "what to change" or the direction of the change, the specific steps to get there are going to look suspect.  Not only at the overall view of the organization, but as people or departments come into the picture, Knight shows what happens if you skip steps here (people resist change).  And how those same people can become true believers, if you take them through the thinking and incorporate their perspective on building the solution.  "Treat people like adults" is a theme that Knight repeats a few times.

While Knight didn't mention Theory of Constraints in this book, he clearly articulated some of the more recent concepts that have come out of the TOC community: flow and core TOC beliefs. He talked about flow - in this case the flow of patients through the hospital - and throughout the story, I picked out several ways in which the Four Concepts of Flow apply (more detail on these in an early blog post).

  1. Improving flow (or equivalently lead time) is a primary objective of operations. - Shorten the time people are in the hospital (usually waiting for someone) to ideally what is only clinically required.
  2. This primary objective should be translated into a practical mechanism that guides the operation when not to produce (prevents overproduction). - Difficult to do directly, as the incoming flow to the hospital is not in their control. But they still described a few actions to help this.
  3. Local efficiencies must be abolished. - There were many examples of local optimizations that significantly damaged the overall flow of patients: batching, blanket budget cuts, etc.
  4. A focusing process to balance flow must be in place. - They designed a buffer management system designed around the flow time for each patient and used it to drive priorities everywhere.

The other aspect is the TOC core beliefs.  The guru character in the story articulates a number of these explicitly as he is talking to other characters, and others of them come out in the story.  I'm not sure what these are called exactly, but they largely come out of thinking around "inherent simplicity" of systems.  This is best articulated in one of Goldratt's last books, The Choice (my re-review from earlier this year)

  • Reality is exceedingly simple
  • People are good
  • Every conflict can be removed
  • There is always a win-win (solution)
  • Every situation can be substantially improved

One aspect of the story that didn't get emphasized was a clarity of thinking that came as the characters started describing the problem.  Specifically around the goal of the system: why does the system exist? Why do we do the things that we do? The characters in the story went from all the measures and rules to becoming laser-focused on the patient and the policies/practices that get in the way of that focus. I would have been interested in some discussion of how they clarified the goal.  Maybe for hospital personnel this is already clear, but I suspect not.  Having a well-articulated, shared understanding of the goal of the system helps start the discussion of what to change, what to change to, and how to cause the change.  It is often listed as "step 0" of the TOC five focusing steps.

Why Pride and Joy?  By the end of the story, Linda Seed and her colleagues are once again excited about the work they are doing. Characters who were considering retirement or career changes are reenergized in their work at the hospital. The place is becoming a point of pride for the characters.

This book is similar to a previous hospital-focused TOC novel, We All Fall Down (my review from 2008).  In that story, the TOC elements were much more in the fore.  And the specific solution developed in the story went in a different direction because the problem they were solving was different.  I kept thinking of that solution in the context of this book, because I suspect it could have been a small part of the larger effort described here as well - but diving into those specifics would have detracted from the story presented in Pride and Joy.

An interesting crowdsourced challenge came across my screen the other day.  InnoCentive is hosting this particular challenge on Capturing Institutional Memory and Knowledge:

The Seeker desires suggestions and best practices for knowledge management in a corporate setting.  As employees age and retire, valuable knowledge is often lost.  In addition, with the realities of today’s workplace, employee turnover needs to be expected.  How can a company proactively capture institutional memory and knowledge, and make sure that it is not lost?

The due date is 14th of October, and the website is showing over 300 active solvers to this point.  

I originally heard about Freek Vermeulen's Business Exposed: The naked truth about what really goes on in the world of business from the HBR Ideacast with him - go there for a nice summary of the book and his take on the world. 

Vermeulen casts his skeptical eye across many familiar practices to debunk our beliefs in the value of those practices. I particularly like that he largely uses published research from a wide variety of business school researchers to show these things.  It also helps that the tone of the writing makes me think Vermeulen was smiling as he wrote, which makes it enjoyable to read as well.  

Vermeulen takes an extreme angle at times, just to get the reader to tilt their head with a quizzical look on their face. He even touches on some topics relevant to my work, including knowledge management.

On knowledge management, he repeats some of what he wrote in a 2009 blog at HBR, When KM Hurts. My take is the same thing many people in KM have been saying for years, gathering "knowledge" (mostly documents) for the sake of having a massive database doesn't particularly help anyone. It is the context, the situation, the experiential knowledge that are so important to the ability of a knowledge management effort to add value to an organization.  His recommendation in this makes perfect sense: stop spending so much time and energy on collecting stuff. Rather, setup "systems that help people identify and contact experts in your firm, because that can sometimes be helpful."  In the research he cited, KM-like systems were most helpful for people new to the firm.  He also cited research that suggested experienced people who hop from one company to another are at a significant disadvantage in terms of performance until they develop their networks within the new company.

Me-too-ism is not a term that Vermeulen uses in the book, but it seems to be connected to a number of ideas he exposes as not quite right. Many companies adopt the latest management fads just because other companies are doing it because they don't want to appear to be behind the times - even if the approach isn't appropriate for their circumstances. For more fun, Vermeulen points to research that shows companies who adopt the latest trends do well on the "Most Admired Companies" lists - regardless of the actual performance impact of the trends.  Or other research that showed merely announcing you were going to do something with corporate social responsibility had a positive impact on analyst coverage and the stock price.

A similar idea that struck me is that companies tend to pay close attention to what industry analysts say about them, largely because there is a strong correlation between analyst coverage and stock price - if an analyst covers your business, your stock price goes up.  This means that if the analysts don't understand your business, they won't cover you or they will give you poor ratings.  This applies even when the business is well-run and doing sensible things for the business. As a result, companies find themselves reorganizing to follow trends that analysts understand.  

scopeIn the world of product development and software development, customers often come to you with a request for specific things.  "It should be green with four wheels." or "Build me a web site to sell my origami." or "It should work just like Google."  The thing is, these are specifications or requirements.  They could describe just about anything, and often the result doesn't quite do what the customer was thinking of.  Why is that?  

Partially, this is due to the very familiar problem that people don't know what they want until they have it.  One of the reasons that Agile development methodologies have taken hold is to try to solve some of this.  Work with the customer directly, create prototypes and iterate, iterate, iterate.

Another direction, inspired for me by Theory of Constraints, is to develop an understanding of why they want these features.  Rather than describe the solution - a description that is always going to be lacking - understand what problem they are trying to solve.  What limitation or barrier do they need to overcome?  And why do they want to do that?  Knowing this, it is much easier for everyone in the process to understand what features / capabilities are truly needed to solve the problem and which might be nice-to-have.  This doesn't eliminate the need for iteration - it helps people focus on the customer's needs.

[Photo: "scope" by ben dalton]

Clarke Ching has been working in public on his book, Rolling Rocks Downhill, for quite a while.  I've read at least one version of it.  Last week, he posted an update of one of the chapters where one of the ideas of the book come together: That (software) developers are creating recipes for a cake,  rather than baking the same cake over and over.  This implies one should be careful about applying manufacturing concepts in such a world.

Here is a quote from Where it all went wrong

'Okay.  Here's the bit that puzzled me.  Development teams in other industries start iterating - and therefore testing, since testing is an intrinsic part of iterating - very early in their development processes.  They cook version 1 of the cake, test it, tweak the recipe, then cook version 2, and so on.  They test throughout the entire development process, but you computer people don't start testing - or iterating - until mid way through a project.  Why is that?'

Why do (software) developers act as if the recipe is fixed, when it clearly is not?  

Dave Snowden has written and talked about a parallel to this problem many times in the context of knowledge management. Are we asking people to simply pick up an item from a knowledge repository and re-use it (like we might see from someone following a recipe)?  Or do we want people to develop enough expertise and understanding to be able to see the key bits of many recipes and create their own (the chef)?

Nick Milton mentioned an old saying from the Middle East, and I had to go find the source.  Turns out it comes from Ibn Shihab, an early Islamic scholar:

"Knowledge is a treasure chest and its keys are questioning." -Ibn Shihab

I like the sentiment here.  You can't just put knowledge somewhere (knowledge repositories anyone?) and expect it to be useful.  People learn through asking questions and a back-and-forth process with others.  

[Thanks to Boris Jaeger (and Twitter) for helping with the sleuthing on the source!]


What holds your efforts at improvement down?

Big Visible posted a great photo / poster a few weeks ago with their article Velocity Is Like A Helium Balloon. While their focus is Agile development, the thinking behind it can be applied to just about any area of improvement.  

Attempting to directly manipulate team velocity is risky and often counterproductive. It can result in the team simply increasing their story point estimates or in taking shortcuts of quality and design so they can get a better number. Such actions damage the utility of the velocity as an input to planning and hide reality from the decision making process. Rather than worry and work over making velocity go up, remember this: [Velocity is like a helium balloon. It will rise on its own, if nothing is holding it down!]

In this case "velocity" is a measure of how fast things are getting done.  It is one way to measure the output of the system in which the team is operating.  Of course the real measure is value delivered to the customer.  (All sorts of assumptions about working on the right things and the larger process in which development is happening.)  Similarly, in other environments, there are internal measures that provide a signal as to how the system is operating.  But they had better be tied back to creating value.  Making more products that just sit in the warehouse to improve "machine efficiency" ratings does not create value.  Activating more projects into the portfolio to keep people busy doesn't help - finishing projects is what your customers care about.  These, and many other examples, tend to create knock-on problems related too much work in process.  You need measures that relate to systematic benefits, not local optima.  

The reason this graphic struck me is the last part of the caption, if nothing is holding it down.  As I mention above, the measure MUST look at the right thing.  But with that, what kinds of things prevent your measure from improving?  What actions are you taking to change the system so that your measure improves?  Did the action have the expected impact?  If not, what made it better or worse than expected?  Is the process working as anticipated?  Are their policies that prevent the process from working as smoothly as expected?

What is it about the system that prevents your balloon from rising as fast as you want it to do?

One of the many people I follow on Twitter, Richard Cushing, has been interviewed by "find accounting software" and the results posted as Where Does Your ERP Selection Fit with Your Continuous Improvement Efforts? 

Richard's discussion follows very familiar territory for people who are interested in Theory of Constraints and other continuous improvement concepts: Focus on the few things that are truly limiting your performance.  Use something like the calculations provided by Throughput Accounting to determine if a change is going to be beneficial or not.  He even describes the Thinking Processes, and the written interview goes to some lengths to describe how these begin to work to help people understand their system.

Maybe it is the name of the website, but I kept a wary eye on the language.  And I was not surprised by the last several questions, which all seem to be of the form, "But isn't ERP software great?" I think Richard did an excellent job of answering - better than I would have done.  Essentially, the way most ERP software is setup does not help companies ask useful questions when they begin to think along the lines of TOC (or Lean!) with respect to their organization. 

Is ERP or accounting software ever the weakest link in an organization?  No.  

How does one evaluate ERP software?  The same way as any other question in a business. What is the real power behind the opportunity?  (Is it different from what we have already?) What limitation does the new software remove?  How are we going to change the business if that limitation were to be removed?

Can ERP help identify or manage the constraint?  No.  I love Richard's response here.  "The very best computer to identify system constraints is human intuition applied in a systematic process of understanding the cause-and-effect relationships between activities within the enterprise."

Sometimes I have a technical issue that is surprisingly difficult to solve by the normal methods, usually because the search terms are not specific enough to uncover the solution.  Or the solutions that I do uncover aren't relevant.  This is one of those cases.  Nothing to do with knowledge management or continuous improvement - other than I want to have this recorded somewhere, so I don't have to go through it all again.

The steps to change password settings:

  • Type "cmd.exe" in the search area on the "Start" button
  • Right click on the "cmd.exe" that appears, and select "Run As Administrator"
  • The Command window opens
  • Now all the "net accounts" settings will work, including setting the maximum password age to unlimited: "net accounts /maxpwage:unlimited"
  • Celebrate

If you are interested in the details...  

My situation: My password on a Windows 7 machine expires every so often.  It's a personal machine, and I don't want to have to re-set the password.  Or I want the option to set the policy myself, rather than taking the default.

Some background:

  • I am running Windows 7 Home Premium. 
  • I am the only user, and I am an "Administrator"
  • I am not a slouch when it comes to these things

Most of the help I found told me to start the "Local Users and Groups Manager" or find the "Local Security Policy" editor.  Unfortunately, these tools aren't available in Windows 7 Home Premium.

Then, I saw the suggestion to run a function directly from the Command window.  I know how to do that, so I dutifully opened cmd.exe and tried

net accounts /maxpwage:unlimited

And got a message that I am not allowed to do such a thing. ("System error 5 has occurred. Access is denied.")  But I am the Administrator, what the heck?!

Then it turns out that even though I am an Administrator, I need to be "elevated" somehow. No, that doesn't mean breaking out my old 2" creepers.  It means that I have to "run as Administrator" on the applications.  I'm sure there is a logical explanation as to why that is, but it seems rather obscure.  

Follow the steps above.

Here is more information on running applications in Windows 7 as Administrator with Full Elevated Rights.

And here is information on the "net accounts" options, if you are interested in other policy settings, like password length and the like.  Customize the Password Policy in Windows 7 - This page has the same information I just typed here, but searching for it is rather frustrating in the results that come back often don't get you to useful content.

TOC Thinking 193x300Yishai Ashlag's new book, TOC Thinking: Removing Constraints for Business Growth, is a good overview of the Theory of Constraints approach to thinking about running organizations. Yishai Ashlag is a senior partner at Goldratt Consulting and brings experiences across many different types of project into short anecdotes in the book.  And he is Eli Goldratt's son-in-law.  

The intro describes the aim of this book as articulating Eli Goldratt's management philosophy through the lens of many key topics.  As such, this book covers a lot of familiar ground for people familiar with TOC, along with bringing in the more recent thinking that can be seen at TOC conferences and hasn't been published as widely. Even though much of the content is familiar to me, I have dog-eared every 3rd page with notes about interesting aspects and useful pull quotes.  

I had heard an early version of this book back at the Chicago TOCICO conference in 2012 (my notes), particularly the first section on the challenges (fears?) of dealing with uncertainty, conflicts, and complexity - and our strangely strong fascination with overly-sophisticated "solutions" to these challenges.  The first section - and really the whole book - is a discussion of where management attention should be focused and how these challenges tend to divide attention while the TOC way of thinking tends to focus attention.

Where to focus attention? Many books and thinkers will tell you - on the most important things. Not on the urgent or the current fire.  (But please do evacuate the building.)  Less Is More and many others tell you that there has to be a guiding light. Theory of Constraints completely agrees.  TOC's body of knowledge contain a number of ways to think about focus, which may be a focus problem of itself.  There is the classic TOC Five Focusing Steps that creates the process of ongoing improvement. And in the past ten years, long-term TOC implementations have preferred to build business strategy with the Strategy and Tactics Trees that define how to Build the capability, Capitalize on it, and Sustain it for the long term.  And more recently, or possibly in parallel with the S&T Trees, are the Four Concepts of Flow that talk about what a manager / organization should do.  All three of these are interconnected.  It might be helpful if they were more clearly related to one another.

My take is that once an organization decides on its Goal and the key Constraint to getting there (Five Focusing Steps), the Four Concepts of Flow help put the Exploit and Subordinate steps into context.  How do you exploit? Get salable work to flow across the constraint.  How do you subordinate?  Make sure nothing gets int the way of flow.  They are inter-related.  The connection to the S&T Tree isn't as obvious because in Theory of Constraints, the thinking processes are a separate line of thinking from the Five Focusing Steps.  However, the S&T Trees work under the assumption that the market is the true constraint, and that the operational capacity must always be kept subordinate to this fact.

[Disclaimer: I received a free copy of the book, as I am doing a large project with Goldratt Consulting.  My opinions are likely to be swayed.]

PowerofhabitCharles Duhigg's The Power of Habit: Why We Do What We Do in Life and Business has a lot of familiar material in it. The concepts he discusses have come up in the popular media over the last couple of years, and people have expressed amazement at the things science has found in terms of how we form habits.  Duhigg puts it together in a compelling story that talks about why we get stuck in ruts - in personal life and in business life - and the paths to breaking out of the rut.

The pattern that shows up again and again is the habit loop: There is a cue, which triggers a routine, which leads to a reward.  It's a habit when the reward isn't even there, but we follow the routine anyway.  Classically, this is the gambler or the alcoholic. But in business life, its the organization that continues to follow a practice long after the need has gone away.  Or its the person who constantly checks their email - is the reward the distraction or the one in 100 chance that the email might be truly important?

There is a lot of fascinating detail in the book about how the various aspects of the habit loop work. Duhigg uses anecdotes to draw in the reader and then jumps to the scientific literature to develop a deeper understanding, and then uses that back to the same or other anecdotes. He does the same with mechanisms people have found for changing the habit loop.

Science has found that once a habit exist, it is baked into the pathways of the brain (or the organization). It is only by training the mind to prefer a different response or to focus on a different cue that the habit can be "broken."  It is not simply a matter of "will power" or "strength of character." The admonition to "change" or "stop doing behavior X" doesn't work, if it is a habit.  The underlying link between the cue and the routine needs to change.

How does one change the habit loop? Duhigg describes people and organizations that have changed the habit loops by attacking it at various points: change the response to the cue; change the social system so that the response is different; change the belief system; re-focus people on different cues; and others aspects.  

I liked the epilogue that suggested there was one more element to changing the habit loop: One might have all the knowledge in the world about hows and whys of a habit, but if there is not a desire to change, it will likely not happen.

The evidence is clear: If you want to change a habit, you must find an alternative routine, and your odds go up dramatically when you commit to changing as part of a group. Belief is essential, and it grows out of a communal experience, even if that community is only as large as two people.

Throughout the book, I found a lot of elements that parallel the Heath brothers' Switch (my review). The habit cycle has its Cue - Routine - Reward. And the Heath's talk about three aspects of behaviors: the Elephant, Rider and Path.  While they aren't perfectly parallel, I see the Rider as taking an intellectual look at things - maybe like the person who has the habit looking at her cues and routines.  Both the Elephant and Path are linked to the routine: there is a path/routine that people follow in response to the cue.  

Picture a steaming coffee cup. Better yet, grab one and have a read!

KJolt Memberships

Follow jackvinson on Twitter

View Jack Vinson's profile on LinkedIn