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!]

VelocityIsLikeABalloonBVLogo

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.  

Less Is More coverThe title "Less is More" has several hits on your favorite book list website these days - weight loss, simplifying your life, etc.  But Jason Jennings version of Less Is More takes this line of reasoning into business.  What are the things that super-productive companies do that help them stand above the rest? (Are there any such companies? Do they last?) Of course, this kind of question is fraught with problems - mainly, there better not be non-productive companies that do the same things.

The main idea: focus. Focus on one thing - one thing for the long term, not one thing this quarter.  And that one thing is the big idea of the organization - why is the organization on the planet?  That big idea sets the direction and the yardstick by which everything is measured.  

Of course, it would be a short business book if it didn't have a list or a set of principles below this idea of focus. Jennings has a chapter on each of these topics, some with even more lists, but I'll leave those for your own reading pleasure. These items all seem to either relate directly to the idea of focus, or they create the conditions in which focus can happen:

  • Trust / Openness: "People only trust someone to lead them if (they believe) everything they say is true."  This extends out to customers, suppliers and partners - they won't come back to an organization they don't trust, or the working relationship will be gummed up with bureaucracy.
  • Destroy bureaucracy (simplify): This sounds a familiar theme to the Four Principles of Flow - specifically, eliminate those local measures so that the work can flow.
  • Get rid of the wrong people (executives and managers) fast and No Layoffs.  I like this pairing, as it says the people in leadership positions need to be on board, and if they can't they should go. But the people in the organization who do the work should stay through thick and thin.  This also links back to the long-term vision implied by the BIG idea.
  • What's the good business reason for doing this (WTGBRFDT)? This question and variations on it link to that BIG idea. In my consulting work, one of the questions we ask is "What is the significant limitation to be overcome" by taking some action.  If that can't be answered in a useful way, what is the point of the action?
  • Understand the real financial drivers. For many people, financial statements are gibberish. I don't think Jennings is suggesting that everyone needs to become an accountant - he's saying that everyone needs to understand how the company makes money, and where money goes within the company.
  • Systematize everything. This is a classic: if you don't know how it works, you can't change or improve it.  And Jennings makes another point that if the system isn't defined, then anyone can monkey with it and the results will be similarly undefined.
  • Continuous improvement. Just as you can't improve what you don't understand, if you don't have an object (that BIG idea), you don't know in what direction to change.
  • Compensation should be directly linked to productivity. This is an interesting topic, as it requires many of the topics above to be working well: Trust/Openness, reduced bureaucracy, understandable systems.  And of course, this creates an impressive drive to improve the systems in which people work to enhance productivity.
  • The plug-in myth: Technology doesn't create a competitive edge - neither does knowledge(!). These can be copied.  It is more important to understand the flow of value and how the technology (or other change) are going to significantly change that flow - and the change had better offset the required investment and additional operating expenses.
  • Motivate: Keep everyone on the same page. Keep people aligned to that familiar objective - the BIG idea.  This section also talks about the motivational effect of setting up an us-against-them environment, which I've mentally linked to the idea of tribes.  
  • A lean spirit. The book references Lean obliquely - it seems that Jennings' example companies all use many ideas that embody the spirit of Lean. This closing chapter lists 11 traits of leaders of highly productive companies - many of which reflect back on the preceding chapters. Many of which are good traits of any leader. The idea here is that they come together around their BIG idea.
Some quotes and topics that stood out for me:
  • "Expensive solutions to any kind of problem are usually the work of mediocrity." (from Ingvar Kamprad of IKEA)
  • Unfortunately, most corporate leaders act as though they suffer from ADD when it comes to keeping their companies focused on mastering a simple BIG objective.
  • Closed-door conversations are a sign that something needs to be hidden, and people jump to the conclusion that its bad.  Even if it is just a personal call to your doctor. Closed management structures are even worse.
  • If you trust people to do the right thing, you will largely discover that they do.  
  • All bureaucracies are a case of "mine is bigger than yours."
  • Employees (of highly productive companies) play as much a role as management in deciding what the systems will be. That's real empowerment.
  • The real challenge (to motivation) is to spend less time trying to design motivational programs and more time figuring how to get out of the way of people trying to do good things.
  • "The danger is when the financial objectives of an organization are placed in front of its mission or purpose." quoting Frederick Taylor - a man who is oft-maligned for creating Taylorism and turning people into robots.
As I listen to people in the weeks since reading the book - and particularly listening to the speakers at the recent TOCICO conference, I hear the ideas expressed in this book over and over again.  Interesting how that happens.

A theme has emerged for me at TOCICO 2014 across many of the talks and discussion this year.

Theory of Constraints implementations generate big changes in organizations. And those big changes by their very nature create conflicts - between new behaviors and old behaviors; between new requirements and old requirements; and even between new mindsets and old mindsets. If the implementations don't seek to resolve these conflicts in some way, they are bound to not reach their full potential.  Rob Newbold's talk clearly highlighted this. But it also came up with Sanjeev Gupta and many others.

Do we respond by ignoring the inconvenient conflicts and push ahead with the implementations? Do we build the conflict clouds and look for erroneous assumptions? Do we move in the direction of relative values and balance the conflict by guiding people in the preferred direction?  Maybe there are other ways to resolve them?

Good food for thought. And maybe some food for thought on your current projects?

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