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?

As usual, I'm exhausted after four days of listening and thinking and talking about the Theory of Constraints. Today was loaded with shorter sessions and more interesting conversations.

The day started with two TOCICO International Achievement Awards, presented to Omron Healthcare (Japan) and Godrej Security Solutions (India). Both companies have implemented TOC in multiple areas of the company, and they both have brought their success to the bottom line - enabling growth and surviving downturns with innovative solutions to the challenges in their industries.  I particularly liked an insight from the Omron speaker, 

It is not Gemba to be changed, it is management to be changed; if management changes, Gemba will also change.

"Gemba" is the place where the action happens in a business - where the value is created.  If management changes the way they operate, the way value is created will change as well.

John Koehler talked about a new strategy for business development that he is developing, called Nu-Business. He used a TOC framing to talk about some of the challenges that new businesses find themselves running into, and he has developed some injections to resolves several of these.  For example, he has found that many new businesses fail because it takes too long to get to positive cash flow. And that takes too long because they invest too heavily at the outset: they create far too much capacity before they know that the business will be viable. I heard a lot of similarity to the "lean startup" concept of starting small and testing ideas.  Koehler has created a phased approach with Nu-Business that acknowledges the changing constraints a business owner has to face as the business grows. I'm curious to learn more as he develops the concept. Koehler is applying the concepts of Nu-Business to his own craft distillery.

Retail operations aren't my forte, but it was interesting to hear Guilherme Almeida and Mathias Fischer of Goldratt Consulting talk about Deep and Narrow Seasonality Strategy work at a large retailer.  During peak sales times retailers struggle keep up with sales, so they often push massive amounts of stock to the stores, in hopes that it will sell. Unfortunately, they often end up with excess stock and then massive discounts after the peaks. They did analysis of SKU sales and discovered that the strategy of pushing everything doesn't work - it is only the top sellers that people want to buy, no matter if it is the peak selling period or the off-peak times.

Patrick Wilson presented some thinking about some of the underlying ideas within the TOC Thinking Processes. In the Evaporating Cloud, for example, we talk about the Goal, shared Needs, and conflicting Actions that result.  But one can think about this from a different perspective as well.  Any action has behind it some measure, which is established by a rule or heuristic, which is created by a belief, which is based on a need, which ties back to the goal.  The actions are tangible manifestations of intangibles.  Actions are physical (tangible) manifestations of a need or goal.  Wilson is hoping that this might be the start of some additional developments of the Thinking Processes.

James Holt and Skip Reedy introduced a CCPM Maturity Model and a mechanism for evaluating CCPM implementations.  The maturity model is based on the CMU maturity model, going from (0) Chaos to (1) Initial Steps to (2) Repeatable to (3) Defined to (4) Managed to (5) Optimizing. And they suggest five key areas that a full portfolio management with CCPM implementation will cover: Initiation, Planning, Execution, Recovery, and Evaluation.  An important note here is that CCPM primarily covered the Execution and Recovery aspects, though I would argue that one should acknowledge the impact of CCPM on project planning and pipeline planning.  The end result of this is a mechanism for evaluating an organization on these five dimensions with a spider chart - over time one should see maturity growing in these dimensions, and it might be a sign of problems if maturity stagnates or reverses.

Dimitar Bakardzhiev talked about another take on the issues of CCPM in software development, where the primary project consists of a number of small tasks (develop a feature) which don't have explicit interdependence. He suggests Project Planning using Little's Law.  The thing that was new for me was the "z-curve" (or s-curve) of completed tasks on the cumulative flow diagram (CFD) has a defined initiation, productive, and close-out phases.  The overall project should be sized based on the rate of completion in the productive phase, while the buffer should be sized to account for the higher variability initiation and closeout phases.  This applies for specific types of projects, though I bet it could be incorporated into larger projects that include this type of work.  He's got a slideshare and video posted that follow a similar discussion.

David Ojeda, Matias Birrell, and Salvador Peña presented a case study from Más Capital. In particular, they embedded the use of the TOC Thinking Processes to enable better problem solving.  I love how they talked about breaking the familiar challenge in large businesses where people see issues, but don't have a standard mechanism for resolution - usually resulting in slow decision-making. Embedding the TOC thinking processes in their organization helped them speed up the process.

Steve Holt followed on his talk from yesterday with a discussion of Breaking the Management Constraint: Using Mission Command and TOC to Create a Culture of Action.  I missed the bulk of his talk, but my ears pricked up when he talked about the fascination we have with "management" (ensuring the right resources at the right time) vs "leadership" (skilled and motivated people). His wide reading of military strategy points out another key element of "command," which is the capability that creates the right strategy.  It is this lack of command which creates an environment where people often have no idea why they are there - imagine if that were the case in the military.

Silvério de Souza and Guilherme Almeida spoke about a familiar element of TOC implementations - choke the release. Choking the release is often one of the first steps taken in both manufacturing and project management implementations.  They focused on manufacturing and the hidden assumptions under which choking the release creates positive effects. I'll leave the details behind, but the goal of choking the release is to unstick the flow of work on the manufacturing floor, which should reduce lead time and improve due date performance.  However, if there are already a high percentage of late orders or if there are work centers full of WIP, the basic guideline won't be sufficient to get the desired effect.  Knowing that there are some special cases, they have proposed a couple additional elements of the guideline.

I attended a number of talks on CCPM today at TOCICO, as that is work I am doing these days.  And these weren't even all the material that was available on CCPM.  There were also some interesting hallway conversations.

David Brown-Brulant talked about extending CCPM with concepts from Lean and Six Sigma. He talked in particular about implementing in a high uncertainty environment like R&D, where the projects themselves aren't guaranteed to deliver the hoped-for result. In these cases one needs to extend the standard CCPM work to include better mechanisms to kill projects that aren't getting to where one would like.  The big challenge is always the "one more experiment" mindset.  I've also liked other suggestions around developing "killer experiments" that should be done early on in these environments. 

Kaoru Watanabe of Hitachi talked about a user-centric design methodology they had developed within their CCPM practice that has helped them develop applications that better meet the needs of their users. In particular, they describe the use case from the perspective of the "flow of desirable effects" - pulling on two threads that are familiar in the TOC community: Flow and Desired Effects.

Chizuru Soejima of NTT Data talked about their enterprise-wide implementation of CCPM. She focused on the mechanisms they created for promoting and supporting CCPM within the organization, but I found most interesting the fact that CCPM project execution is one of the 8 engines of growth for NTT Data that they have acknowledged in their annual reports. 

Duncan Patrick and Jack Warchalowski of CMS Montera presented a last-minute replacement on the schedule on a challenging topic: the hidden costs of CCPM - "too big to change".  They talked about the issue that public companies which make their money selling projects have to report their financials on a regular basis - and those financials must include actual and expected revenues from projects: revenue recognition and revenue forecasting.  This includes reporting the "cost" associated with people allocated to projects.  Cost allocations and forecasting is normally an anathema to TOC professionals, but it appears to be a reality.  Complicating this reporting in a CCPM environment is the idea that CCPM seeks to shift from scheduling people to scheduling tasks and then executing those tasks as quickly as possible.  That's great from a project execution perspective, but from the finance perspective the calculations still need to know how much effort was expended by which people over a given time period.  They don't have a specific solution, but they hinted at a few.  I prefer the one that relates to the other part of the current reality: most "project management" software that does financial reporting isn't used for project execution - let's keep it that way.

The day closed with Sanjeev Gupta of Realization talking about a high level recommendation to combine CCPM and Kanban in order to deal with the situation I have seen in many project environments where there are activities that must be completed, but they have no a priori interdependencies. Simplify the project network to represent the 20 percent of the work that is truly sequentially linked, and put the remainder of the work into a "task list" and have the work owners manage the work in a Kanban mechanism. This has been done by many people in the CCPM community, and Gupta wanted to acknowledge that it is a valid way to operate.  

The TOCICO conference has shifted from longer talks and workshops to 30-minute updates and case studies. This gives me the excuse to summarize in one post, rather than a post for each session. I'll do a separate one with notes on CCPM-related presentations.

And to demonstrate the nature of the day, Debra Smith (Constraints Management Group) gave a rapid-fire talk on "The Right Rules & Tools before Smart Metrics."  She's been writing and focusing on a concept called Demand Driven MRP (DDMRP) lately, about which I know more today than I did yesterday.  But a key insight here is that while flow of material and information is important - they have to be relevant. And relevant in this context is that it is material that is being sold (not going into a warehouse).  And if you are using that information to make decisions, it has to be relevant to the decision - not just all the information you can collect.  She talked a lot about the problems created by MRP and ERP systems and some of the underlying assumptions about linearity and determinism. Today's environments are more like Complex Adaptive Systems, and the rules and tools we use should operate with that in mind.  

Humberto Baptista and Silverio de Souza presented a concern they have with pilot implementations in TOC - they don't always do what they are supposed to do. It's not a perfect analogy, but the pilot should represent an experiment - and that experiment should have a hypothesis, a control, defined expectations. It shouldn't be a iterative, larger and larger "pilot" implementation. They presented the stub of a Strategy and Tactics Tree related to implementing changes, in which a Pilot is only a portion. The full implementation needs to follow from the pilot. I'm curious if they will do more with this thinking.

As seems to be his style, Steve Holt, brought a smile to our faces with an interpretation of the implications of becoming an ever-flourishing company - TOC companies should hire more managers because management attention is the constraint.  Of course, it is not their attention (and their attention is not equivalent to the number of managers), it is their FOCUS on the right things. And then thinking further, why does it have to be "managers?"  Couldn't anyone with the right perspective be able to make decisions and take action?  And - as is also his style - he pointed the audience to read the the Marine Corp Documented Procedure 6 on Command and Control.  From the abstract:

A main point of this doctrinal publication is that command and control is not the exclusive province of senior commanders and staffs: effective command and control is the responsibility of all Marines. And so this publication is meant to guide Marines at all levels of command.

Somewhat outside my normal perspective, I attended a talk about a wide-ranging TOC implementation at Riachuelo, a fashion retailer in Brazil. They do everything from make the cloth to selling and even financing. And their TOC implementation has been a great journey.  The comment about the journey I particularly liked was, "It's a journey to Everest, not a trip to Disney." And of course, they are still climbing.

Rob Newbold of ProChain held a session, diving into one of the big themes of his book, The Project Manifesto.  (I wrote about this a couple months ago.) It was good listening to him talk about it, as I picked up some things I hadn't appreciated from reading the book alone.  

He opened in talking about an interesting aspect of implementing changes in organizations. We are often fascinated with the change we want to implement: the process, the technology, the new rules. Our customers are fascinated too - they are sure this new thing will be the solution.  But with any change there are going to be conflicts between the new way and the old way.  TOC traditionally addresses conflicts head-on (see "evaporating clouds").  But Newbold suggests that we often ignore the inconvenient conflicts that a change creates - particularly a change on the scale of TOC operational changes, whether CCPM, DBR or Replenishment. This is why Newbold wrote his latest book.

In CCPM implementations, we tell people to focus, stop multitasking, finish the current work, don't introduce new work right away, focus on the goals of the organization.  But these things run heavily against common practice, and many of the processes introduced in an implementation don't provide enough guidance on how to change common practice.  

So instead of fighting against the common practice, why not nudge people in the right direction by talking about what we prefer - what we value. This runs against the familiar TOC perspective of removing the conflict. This describes the paradigm of the Relay Race (this obviously borrows from the Agile Manifesto):

  1. We value priorities over responsiveness.
  2. We value finishing over starting.
  3. We value speed over deadlines.
  4. We value shared goals over individual goals.

These values describe a subornation. We prefer A over B, but both exist.  For example, Starting something new should subordinate to finishing what you already have in flight.  Obviously, you have to start things at some point, but make sure you finish first.  Newbold talked about how these values interact to create a virtuous cycle, driving toward the "relay racer" mentality in project environments.  Newbold's development of these values also created a parallel set of work standards.  These emerge from discussion of the values - what do people do to make these values come to life?

Surprisingly, his thinking around these elements leads him to de-emphasize the familiar "stop multitasking" mantra.  It's something that has been bothering me from time to time as well - sure I can describe the ill effects of multitasking and encourage people (and myself!) to multitask less.  But how do I do that in an environment that appears to value responsiveness, deadlines, starting the next exciting activity, and focusing on personal goals?  These values point in a different direction - emphasize what you value instead of these things.  Help people think about what it means to value A over B.  

Along with the values driving the work practices, the values should drive the need for technology, rather than the technology being introduced without context.  From a CCPM perspective, these values suggest a number of topics that we normally bring into an implementation.  But do they necessarily suggest CCPM alone?  

Another aspect of these values - maybe they aren't exactly the right relative values for your implementation.  Maybe the work standards don't quite fit.  Talk with your colleagues and partners to find the "inconvenient conflicts" and devise the right relative values that will help move the organization in the right direction.

The second day of the TOCICO conference opened with a great keynote from Kristen Cox on "Better, Faster, Cheaper State Government."  What a great way to open the day - TOC and systematic thinking really can come to an environment like state government.  And there are lessons for other implementations. 

Cox is the head of the Utah Governor's Office of Management and Budget which has responsibility for 24 agencies with something like 120 major systems and tens of thousands of employees.  

The basic challenge in government (and beyond) is that there are always more demand than availability of resources (dollars).  But the problem in government, as in business, is that everyone has good ideas and valid needs.  Cox framed the challenge as one of understanding how to manage resources to begin with.  If you don't know how to manage your resources, you will NEVER have enough.  If you know how, you have a chance of having enough.  

In the case of state government, Cox described a scenario where there are many architects of change / improvement / better living who create interesting drawings and then tell someone else to go build it.  But then there are implementation issues that have to be resolved and create conflicts (and extra spending).  She suggested that maybe there is a better way - a more systematic approach to the situation that will make the work of the architects and the builders more effective.

There were many exciting things that came from Cox's keynote. She is clearly energized about the work they are doing, and it is great to see TOC being a centerpiece of this work.  She is also working with leaders in other states to spread the word on how this can work.  It's exciting to see this in combination with the efforts of Alex Knight in TOC for Healthcare.  

An interesting theme that Cox talked about was also raised in a later session: People get enamored with technology as the answer, rather than understanding the underlying problem and finding the right technology to address the problem.  This is one of her "fatal four" types of initiatives that are often pushed on state agencies.  The other three: another reorganization; more training; spend more money.  

What about implementing changes?  Isn't it hard to do in an unwieldily state bureaucracy?  Of course! But it is a change worth making.  Cox made an important clarification about the change matrix. We can intellectually describe the change - why change (or not), dangers of changing (or not).  But you also have to have the heart and guts to see it through.  

Cox also talked about her SUCCESS framework - something I think could apply to any major initiative along these lines.

  • Set measurable goals and targets 
  • Use thinking and analysis tools - and spend the time to do it well
  • Create your strategy and tactics
  • Create your organization
  • Engage staff and customers
  • Synchronize policy and projects (technology isn't the solution for everything)
  • Stay focused

Being a good TOC-led initiative, they have a Strategy and Tactics Tree that is guiding their efforts. The top of the tree?  "Be the best-managed state in the nation."  

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