Franklin D Roosevelt is credited with telling anyone doing public speaking to "Be sincere, be brief, be seated".  In the video below, Bill Dettmer throws out this quote in talking about his time in the military, doing briefings for various commanders.

And then we have the Theory of Constraints logical thinking processes that are anything but brief.  It's one of the frustrations for people who build these logic diagrams.  Dettmer's Logical Thinking Processes has an appendix that talks about an "Executive Summary Tree" that takes a detailed Current Reality Tree (CRT) and simplifies it for presentation and discussion with others.  

I like this concept.  It's been one of my frustrations - and it has been one of the things I like about how people do this well.  They essentially build up the executive summary in conversation - and expand those sections which aren't clear to people as they talk.

Here is the high level overview on how to do this:

Step 1 - Do a proper CRT with the complete solution. Probably over 30 items. It must be robust / completely finished).
Step 2 - Identify the UnDesirable Effects or UDEs at the top
Step 3 - Identify the few critical root causes at the bottom
Step 4 - Identify the main causal paths between
Step 5 - Identify where the paths converge
Step 6 - Identify the 2 or 3 key intermediate entities. They represent the longest leap of logic you believe the executives can understand.

The resulting Executive Summary Tree should have about a dozen items.

A colleague sent along this video from Smarter Every Day where he shows how he "unlearned" how to ride a regular bike and learned to ride a bike which handles opposite to the expected way.  And then tries to re-learn normal bike riding.  Fun ensues.  And the interesting comment that just because you know something, it doesn't mean you understand it.

In the January 2015 HBR, Andrew O'Connell has a brief piece in the "Managing Yourself" column that talks about multitasking and the research that generally suggests it doesn't work as well as we like to think. The Pros and Cons of Doing One Thing at a Time - HBR

The idea that it’s better to finish your tasks in sequence than to jump around from one to another is very hard to accept, at least for me.

The negatives of multitasking have been reported over and over again.  People struggle when they switch from one task to another to another without finishing. The tasks themselves take longer, and when those tasks are part of larger projects, those project suffer from loss of speed and flow (waiting for something to finish so the project can move to the next step).

But then the author looks for the loopholes in the "multitasking is bad" statement.  He finds it in the idea that it helps keep the creative juices flowing and there are even examples of artists who find they do better when they have multiple pieces going (and out in the open in the studio, not buried on their computer).  Of course, people need mental breaks from intense work.  But these breaks are not moving from one intense activity to another equally-intense item.  

The point behind these conversations is to help people see that things that block flow of work do much more damage than slowing down that one item.  It slows down all their work. And it slows down the work of people who are dependent upon the results.  If I were completely independent of others, then multitasking would only affect me.  But I am not - my way of operating affects those around me.  And visa versa.  

Eli Schragenheim has continued his thinking about handing uncertainty with his latest blog post The current TOC achievements in handling uncertainty.  He describes four key elements of how TOC thinks about uncertainty and why they are important.  Here is my take on these elements.

Buffers: TOC explicitly calls out time and stock buffers, rather than hiding or not acknowledging them. Explicitly creating buffers and deciding where to put them is a planning decision that lines up with the concept that there will be uncertainty in execution and that we must to plan for it more systemically, rather than assuming we can manage it locally.  When buffers are hidden, they are always wasted.

Buffer Management: Now that we have buffers, the execution process makes use of them.  Eli highlights a key aspect of buffer management: it only works if the buffers are usually partially consumed.  If they are fully consumed, there is nothing to manage.  And if they are un-consumed, there is no information from the buffers to guide operations.  

Protective capacity: The very common belief that we must have high efficiency everywhere leads us to hide the capacity in internal buffers.  Or it leads to the concept of trying to balance capacity.  When variability strikes, a balanced system is easily thrown off, whereas a system with those buffers can more easily absorb the variation.  And more specifically, the system must have capacity to absorb the variation - there must be excess capacity.  And looping back to buffer management, the statistics about buffers can point to the resources/work centers which are often the sources of significant buffer consumption, which then leads to focused improvement efforts - improve the items that are linked to the heaviest buffer consumption and the whole system will improve.

Thin and focused planning: Eli calls out this phrase - never articulated in TOC directly - as another result of the TOC Five Focusing Steps.  The mindset in TOC is to focus on the one thing that is limiting the business from achieving more of its goal.  We have the buffers to manage variability, in combination with protective capacity.  Rather than planning everything down to the minute, getting the flow right and letting people manage the details reduces the planning effort and simplifies even the idea of "replanning."

Eli's summary:

A superior level of performing well in spite of significant uncertainty will be achieved ONLY when a decision making process is established that verbalizes the uncertain potential results and lead the decision makers to contemplate decisions that would achieve high gains most of the time, but also take into account that in some cases limited damage will occur.  

We have generally left the days where people were regularly recommending new blog reading, which I still miss.  But Eli Schragenheim, author of a number of Theory of Constraints books and an active participant in ongoing TOC thinking has started writing his own blog.  And, as I have heard him speak a number of times, I can hear his voice in his writing style, which is always a plus.

For example, his recent post talks about The problems with “Common and Expected Uncertainty”, which is a familiar complaint that when people use estimates but then report only one number, not the possible range around that number.  He articulates a variety of bad effects that result from this common practice, such as this comment about sales forecasts:

The reliance on one number allows top management to judge their sales and operations people, however that judgment is flawed and the sales and operations managers have to protect themselves from the ignorance of top management.

Good stuff. If you care about these topics, go have a read!

There are plenty of job descriptions that make you scratch your head, wondering what they are really looking to hire.  The classic one, particularly for people clued into the idea that multitasking isn't such a great thing, are job requirements for "good at multitasking" - particularly when tied to positions that are geared toward continuous improvement or systems thinking.

I came across a job description, looking for a facility supervisor who knows Theory of Constraints.  But the key job functions include, "Drive cost reduction and continuous improvement in the attainment of corporate goals."  At least there is a mention of meeting customer commitment dates - listed after the cost reduction item.  No mention of driving improved performance to attract more customers or more repeat business.

In case it isn't obvious, driving cost reduction and hitting customer commitment dates will often create a conflict for the facility manager.  They only want to be successful, after all.  On the one hand, they want to be a good steward of the company's funds, so they are driven to reduce scrap, reduce overtime, etc.  On the other hand, they want to ensure they meet the customer commitments, so they are driven to do what it, which often requires spending some extra money (overtime; last-minute shipping).  

Of course, I have no idea what is the real situation behind the position and the company.  And I shouldn't laugh too much - there aren't that many job postings that mention Theory of Constraints so explicitly!

I came across the video from the University of Texas 2014 Commencement address by Admiral William H McRaven in which he describes his training and draws ten life lessons.  The story is engaging, and while the lessons out of context sound odd, they make sense in the way he puts it together.  Yes, I am aware that this is 9 months old and that others have commented on it when it was first published.  I liked it enough to post again.

  1. If you want to change the world, start of by making your bed.  
  2. If you want to change the world, find someone to help you paddle.
  3. If you want to change the world, measure a person by the size of their heart. Not the size of their flippers.
  4. If you want to change the world, get over being a sugar cookie (failing) and keep moving forward.
  5. If you want to change the world, don't be afraid of the circuses. 
  6. If you want to change the world, sometimes you have to slide down the obstacles head first. 
  7. If you want to change the world, don't back down from the sharks.
  8. If you want to change the world, you must be your very best in the darkest moments.
  9. If you want to change the world, start singing when you are up to your nose in mud.  
  10. If you want to change the world, don't ever, ever ring the bell.

He also summarizes in the last minute with what these mean: Start each day with a task completed. Find someone to help you through life. Respect everyone. Know that life is not fair and that you will fail often. But if take you take some risks, step up when the times are toughest, face down the bullies, lift up the downtrodden and never, ever give up, you can change the world.  [I slightly modified the above from the full text of his address.] 

Source: Glenn Alleman's often informative blog and his post on What is a Team?

I'm writing from the frozen northeast USA, where we've had more than the usual amount of snow packed into two weeks.

The CIO's Guide to Breakthrough Project Portfolio Performance: Applying the Best of Critical Chain, Agile, and Lean by Michael Hannan, Wolfram Muller, and Hilbert Robinson is a good, short description of how to take ideas from several disciplines and apply them to an overall portfolio management approach.  (Disclaimer I know two of the authors, though I did buy the book.)

The authors start out describing the three most important objectives of portfolio management: 

  1. Selecting the right projects
  2. Maximizing the portfolio's throughput of project completions
  3. Optimizing the portfolio's reliability of project completions

And the rest of the book clarifies what they mean by each of these objectives.

How to help selecting the right project?  The authors discuss the TOC Throughput Accounting idea of "throughput per constraint unit" - basically reviewing how much time projects consume on the system's constraint compared to the value of the project. They also add in a consideration of the investment required to deliver the project, which they calculate as an "effective ROI". Interestingly, there is a similar concept in the Factory Physics approach (I'm reading Factory Physics for Managers).  

I also like that they talk about analyzing potential projects from the TOC perspective of how the project will impact the constraint of the overall system.  There might be a project portfolio constraint - the resource that limits the ability of the portfolio to flow more and more projects.  And there will be a constraint at the business system level - these are not always the same thing.  When they are the same resource, care must be taken in deciding on projects: will the operational needs of the finished project reduce or increase the demand on the system constraint?  Are projects that require significant capacity from such a resource the best projects to run?  If it is unavoidable that the constraint must also be on projects, there are a few strategies: make sure those resources in particular are focused (no multitasking!); make sure all other resources do what they can to support the constraint; and finally, if necessary, develop more of that constraint resource (training, hiring, etc).  

So once you have selected the right projects, the focus becomes on ensuring they complete quickly and reliably.  The more of the right projects that finish, the more value the portfolio will deliver to the organization.  The focus here is has to be on ensuring projects are released to take advantage of the capacity of the constraint of the whole portfolio of projects: don't release more work than the resource can safely handle.  Don't force your most precious resource into the situation where they are forced to switch from project to project to project without finishing the work of the moment.  (This doesn't mean that they should have only one project - they should have only one TASK at a time.)

The authors describe a series of changes in planning and execution of projects that will create more and more benefit to the flow of work.  In the conversation, they suggest an original portfolio that finishes just three projects in 17 weeks could be rethought into finishing sixteen projects in those same 17 weeks.  People familiar with CCPM will find the discussion quite familiar: staggered release based on the constraint; reduce multitasking; elimination of internal task promise dates (change to finish as quickly as possible).  There are also ideas in the Agile community that can help speed the throughput of projects.

Not only do they use familiar CCPM methods, but they also suggest bringing in the idea of Value Stream Analysis to the project design: particularly for information technology projects, it is often the case that the IT organization is asked to automate an existing business process.  Rather than strictly automate it, a VSA would suggest places where the process could be improved to eliminate or reduce the number of steps.  Not only does this make the business process better, but the resulting technical component is often simpler and much more in alignment with the needs of the business.  And the project can be faster.

Finally, many of these concepts have to do with planning.  Execution is just as critical.  CCPM project execution techniques and tools help people focus on the key work required to bring projects in on time.  In addition, one of the authors of the book, Wolfram Muller, also wrote Taming the Flow, which talks a lot about how to turn these ideas into "ultimate Scrum" to maximize the flow in software development. 

And it is in execution where the third objective comes into play: reliable project completion.  Again, from CCPM comes the idea of project buffers and using buffer status as a primary mechanism for providing status and focus.  There are also scope buffers (backlog management) and budget buffers to help direct money to the places that need it.  

And these buffers and the resulting information help at another level.  Collecting information over time as to what most often causes significant buffer consumption is a great way to look for longer-term improvement opportunities.

The book isn't going to answer all the questions on how to make this happen, but it is a great introduction to the concepts and gives a good starting path.  I particularly like that it shifts the conversation away from project management - implications on managing projects.  In a portfolio, it is just as important to be flowing the right work in the right way for overall success.

Finally, they have a nice analogy in talking about "local efficiencies" and task-level promises.  They extend the familiar (to me) idea of a project as a relay race.  Everyone wants to do their best in the environment they are in.  But what does that mean for the leg that the individual runner is on?

No runners are asked to commit to a specific time or speed - and if you did ask them, they would likely look at you like you're nuts, because all athletes know that performance will vary from one race to the next.

Just like in knowledge work.  And most project work is knowledge work these days.

I haven't completely forgotten knowledge management. My life happens to be tied up in the process side of things these days, but KM hides under the covers of many conversations I have with people. How do we make sure the right people know how to operate?  

As such, Arthur Shelley posted his 12 Principles of Knowledge Leadership to a KM mailing list - turns out he wrote this a year and a half ago.  Good reference material!

12 Principles of Knowledge Leadership is a great place to start you practice of becoming more successful:

  1. Lead
  2. Engage
  3. Enhance performance
  4. Accelerate
  5. Create
  6. Prioritise
  7. Ensure
  8. Invest
  9. Share
  10. Stimulate
  11. Leverage
  12. Be the (knowledge) leader you want to serve - Channelling Gandhi there!

As usual, go to his website for more details on each of these.  I could argue several of these apply well beyond knowledge management.

Henry Camp has created a nice two-page summary of Theory of Constraints and made it available for all to use.  I've posted a copy here (with permission): TOC Reference Sheet.  His idea behind creating it was something that people could print and laminate for quick reference.

This covers TOC topics that Henry cares about, which is most of them. He covers the 5 Focusing Steps, the Pillars (he counts 5 instead of 4), Constraints, Layers of Resistance / Buy-In, and easily half of the content is related to the Thinking Processes. Interestingly, he doesn't explicitly include the supply chain or manufacturing applications, which is a bit surprising given his background and success with supply chain implementations. 

Henry has been involved in Theory of Constraints for at least 10 years. I met him through his colleagues from IDEA LLC and then at a couple TOC ICO conferences.

Pascal-Emmanuel Gobry has some nice praise for Theory of Constraints and The Goal in This simple theory from an Israeli genius will revolutionize the way you think about business (November 2014, The Week).  

TOC is the brainchild of an eccentric Israeli physicist, Eli Goldratt (now deceased), who produced the business novel The Goal, which became an underground bestseller and allowed him to devote himself fulltime to consulting and elaborating on his theory. Once I understood TOC's power, it came as no surprise to find out that Jeff Bezos, the greatest CEO alive today, makes all his senior executives read The Goal.

The brief article is a familiar statement that Bezos has his senior executives read The Goal.  The rest of the article does a nice job of describing TOC to people who may not be familiar with it.  

What I would love to see is someone dig into HOW Amazon is using the ideas of Theory of Constraints within their operations.  Given that they are primarily a sales and distribution organization, I would imagine that the supply chain application is where they would focus. But they have a lot of moving parts. The Thinking Processes, Critical Chain Project Management, Strategy and Tactics, and more could all be valuable techniques within the organization.

Has anyone written that article?

What is the goal of a company?  In the Theory of Constraints approach, this is one of the first questions to ask - even before you start down the path of the Five Focusing Steps (5FS).  

The first of the 5FS guides one to "identify the constraint of the system," which means you need to understand the system.  And the "constraint" is the thing which is preventing the system from achieving more of its goal.  Ah, the goal.

Again, in the TOC community, the goal has usually been generalized to "Make more money, now and in the future."  This generates a lot of conversation and discussion, as the terms are unclear and people react strongly to thinking that the only goal of a company is to make money.  Isn't there some kind of higher purpose?  To see how much discussion this generates, have a visit to LinkedIn to see the conversation Is "making money now and in the future" the real goal of a company?  It started 11 days ago and already has over 150 comments.  This isn't the first time I've seen a conversation like this - and it probably won't be the last.  

I happen to like Kelvyn Youngman's discussion of the Japanese Perspective on this kind of goal. Not all cultures see this question the same way.  And outside of Theory of Constraints, the question of the purpose/goal of a company is an ever-popular conversation.  Steve Denning talks about it in his thinking about Radical Management and in Is the Goal of a Corporation to Make Money? on Forbes. There are many other discussions on the topic as well.

In the last ten years or so, Goldratt and the TOC community developed the Viable Vision concept and modified the goal to become an "ever-flourishing company."  (There are two nice videos of Eli Goldratt talking through this topic: Part One and Part Two.)  

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