As we learned in Boston this past winter, the ability to be productive and collaborate with team members, even if nature or other circumstances prevent us from being in the same place at the same time, is critical to success in modern business. More and more, our workplaces and teams are virtual, with remote workers and teams being asked to connect and collaborate. Teams that do so effectively can build a real competitive advantage by providing access to the best resources, delivering products and services more efficiently, and accelerating the pace of innovation.

His five items are sometimes obvious, and yet do we use them all?

1. Hire for it.
2. Foster a culture of collaboration.
3. Connect securely, from any device, anywhere. 
4. Invest in tools that work the way your teams do.
5. Know when to escalate.

And of course, other people write about this stuff as well, such as my friend Johanna Rothman's thinking on remote Agile teams, where she focuses on trust, flexibility and internal cohesion.

Since LeanKit tends to serve software developers and knowledge work environments, it feels like these ideas particularly apply to knowledge work, even though the blog post talks about business growth in general.  I also love how the writing here dovetails very nicely with more recent thinking in the TOC community around flow and how the primary goal of any system has to be around flow of value to the customer.  And a big implication of that statement is the removal of impediments to flow.  These wastes are one way to think about those impediments!

Here is the list from the article with some of my thoughts.

1. (Too Much) Work In Process. This is one of the biggest killers, and it is one of the hardest to see - particularly for those of us wrapped up in work that is invisible.  Getting this out into the open is one of the best ways to start the conversation around improving this.  And I have to love the comment that there is always a bottleneck (constraint) that limits the flow.
2. Delays. This seems obvious to state - delaying delivery to a customer is clearly bad.  But think about the flow of work from start to finish: how many delays, pauses, downtimes are there?  In TOC, we often talk about the customer tolerance time - will they put up with a one week lead time, or do they want it right way?
3. Extra Capabilities. 
4. Technical Debt. This a term I only see in IT / Agile circles, but it equate to quality in my mind.  I think there is also a context behind technical debt around developing usable products or products that don't require a lot of work arounds. 
5. Handoffs. I like the Relay Racer analogy.  Handoffs have to be well-practiced, and well-understood for the whole race to succeed. The same goes in projects - handoffs happen, but we have to understand they are a source of friction in projects.
6. Task Switching. I usually think of task switching and too much Work In Process as heavily intertwined. Too much WIP means people are switching between activities without getting anything done. They might also be in a situation where they are forced to switch due to delays, poor handoffs, defects, etc.  
7. Defects.  Goes without saying - no one wants to pay for defects. Pure waste.

For reference, here are the classical Lean Seven Wastes (from the Muda article on Wikipedia): Transportation, Inventory, Motion, Waiting, Over-processing, Over-production, Defects.  There are other lists and other articulations, of course.  

The book is a study of military history as a guide to seeing how leaders might deal with uncertainty - in particular the German military thinker Carl von Clausewitz (18th-19th Century).  Of course, while the military angle is interesting, there are clearly parallels into the business world.  And that is why Bungay wrote the book in the first place.

A lot of the discussion in the book had to do with the sources of uncertainty.  In war, this is classically the "Fog of War" and more.  It isn't clear what the enemy are doing.  Even more, it isn't always clear that your own people and equipment - and the plans for them - will do what you expect.  And doesn't this happen in business too?  

Of course, the opposite of accepting and working with uncertainty is to try to remove it.  While there are good concepts around reducing the sources of uncertainty, sometimes the effort required to do so is more expensive than simply expecting and working with the uncertainty.  This is the direction Bungay goes in the book. Dealing with uncertainty and various knowledge gaps is the reality of any business - businesses need to move forward, regardless of those knowledge gaps.  

There is a quote about one of the military leaders described in the book, "He remained calm and unruffled because he never expected his predictions to be correct."  This eventually led to a discussion of the idea of Leader's Intent and strategy and tactics.  And how these things should be discussed and communicated within organizations.  Bungay's claim is that many organizations spend a lot of time on strategy and tactics without clearly articulating the intent behind them.  He also suggests that many people find themselves being overly-specific in giving direction to their people, and this then leaves those people without much flexibility and power to make their own decisions.  It is as if the managers in these situations believe if they force certainty (in the form of specific direction), then everything will work out fine.  But this doesn't acknowledge the fact that we can never know everything - nor can we wait until the level of uncertainty becomes "acceptable."  

This was a good read, as it coalesced many of the concepts and ideas I've been hearing and reading about elsewhere.  With some colleagues, we had even been using the "intent" language more often, though it is nice to see it brought together with the other elements discussed in the book.

I flagged this article to read and ponder back in April, but only just got around to it recently.  Arne Roock wrote about his company on InfoQ, Culture is the True North - Scaling at Jimdo. Good stuff.

In essence, he talks about the situation at his company, particularly as they grow their business.  They don't want to (and can't) just "throw money" at the situation, so they have to be more careful.  

At Jimdo, our approach to scaling relies on three major factors: culture, communication, and kaizen. Let's discuss them in reverse order.

In this discussion of kaizen (from Lean terminology), he describes the heavy use of the Kanban Method, which I've used and written about previously.  Interesting to me, though, as he highlighted the six core practices, I saw something new in them.  They are (bolds intentional)

• Visualization
• WiP limitation (WiP = Work in Progress)
• Flow management
• Explicit policies
• Feedback loops
• Improvement through collaborative experimentation

I've been referencing the Four Concepts of Flow that Eli Goldratt came up with in looking at Ford, Ohno and others (in the article Standing on the Shoulders of Giants):

1. Improving flow (or equivalently lead time) is a primary objective of operations.
2. This primary objective should be translated into a practical mechanism that guides the operation when not to produce (prevents overproduction). 
3. Local efficiencies must be abolished.
4. A focusing process to balance flow must be in place.

While the language is not the same, the underlying concepts align closely.  It's all about flow - explicit in both of these lists.  "Preventing overproduction" is most often connected to limiting the work in process (WIP), whether that is in a manufacturing, projects, sales, or in retail.  And the policies that Kanban wants to make explicit are tied to the flow idea #3 around local efficiencies - changing away from metrics that unbalance the flow to policies that encourage more and more flow.  Kanban Method makes the improvement process more explicit, where the Four Concepts of Flow put it into the focusing process (and in other aspects of Theory of Constraints).

There are other great ideas in Roock's article in the sections that he categorizes as communication and culture.  I particularly like items in there on focus - the Spice Girls question, "Tell me what you want. What you really, really want!" from Stephen Bungay that has led Jimdo to talk about "Goal #1" - the one thing that will move the company towards its goal.  Again, one of the primary ideas in Theory of Constraints is that there is one constraint that limits your ability to get more of what you want.  Understanding that goes a long way to improving the system overall.

[Photo: "Flow" by Carlo]

This relates to observations I have made in working with organizations on critical chain project management.  I have found an interesting dichotomy with respect to the question how busy people might be.  Some project modeling tools allow you to model resources required on project tasks.  Taken in aggregate across many projects, this should give a sense of how much (project) work is upcoming for those resources.  And this should give a sense of how "busy" they are.  

What I often find is that the "busyness" based on the project models and the busyness claimed by the people on these teams is vastly different.  Of course, there might be discrepancies because the project models aren't right or because people do a lot of non-project work.  This can be checked.  But the interesting thing I've found is that there are many situations where it is not possible for team members to admit that they have available capacity.  They believe (and it may be true) that they are in an environment where "nothing to do" means they will be punished - even if that "nothing to do" is actually important protective capacity to enable fast response to emerging situations.

Of course, this links back to the HBR Ideacast above.  People have figured out how to appear busy, whether or not they truly are.  They operate in a system that almost forces them into this pattern of operation.  Unfortunately, this makes it difficult to help people realize there is extra capacity. And that this extra capacity can help improve the whole organization.  

In this episode two masters at the art discuss navel gazing and how it might just be a key business skill for the future. 

The thing that struck me hard enough to do a quick blog post is the idea that some people get wrapped around the axel of self-improvement without thinking why.  On the opposite end are people who have no interest in self-improvement (but who are happy to point out situations in which they are unhappy).   

I have always liked the idea that if I am upset about something / someone, it is because something inside me is out of kilter.  It is not the other person / situation is necessarily wrong, but my take on it has me upset.*  In other words, it is my responsibility to figure out why that business meeting made me so angry, and then DO SOMETHING DIFFERENT.  Take responsibility for which I have control, rather than pointing the finger at things I don't like.

To me this is the point of navel gazing, so that I can change those things over which I have control.  And where do I have control?   It's inside. 

* Yes, there are some world situations that are truly horrible, and I should be upset. But I think even there, what is my part in it? How can I make it better in my part of the world?

[Photo: "Navel Oranges" by Madhu Madhavan]

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.

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.  

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.  

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!

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!

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?

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.

Since certain of my synapses (i.e., all of them) don't connect right, I am fairly good at recognizing faces and terrible at then connecting faces with people. I actually remember you better from our email over the years than as a bodily presence. Which strikes me as pathological.

Anyway, nice to see you - and read you - again.

Jack -- Using Technorati's new keyword search capability for searching blogs, I entered "critical chain," and was led here. As a vocal proponent (as well as provider of training and implementation services) of Critical Chain-based project management, I'd be curious to see how your presentation on CCPM and risk management jives with mine at http://www.focusedperformance.com/articles/ccrisk.html

The key to knowledge continuity is preserving the relationship and building a network to enable communciation.

A recent book "Continuity management. Preserving corporate knowledge and productivity when employees leave" Beazley, Boenisch and Harden, 2002, Wiley, takes the view that you need to gather a 'knowledge profile'.

Most approaches that advocate an explicit 'capture' path overlook the importance of context and dialog. Access to the person rather than to their idealised notes is clearly the best option here.

Right on Denham. The context in which people work is clearly important to the idea of knowledge retention. Not only what people know, but how they get there and who helps them. I suspect social network analysis could play a role here as well.

Gary Klein in his book "Intuition at work" maskes a very strong case for NOT having prescriptive descion making and having data / information / knowledge collection drive the decision process. What is important is to 'listen', to be connected and concerned, and to take a decision being ready to redirect once the environment changes or the results obtained appear counter-intitive.

KM should be about awareness, learning, innovation and knowledge creation rather than about correct decision making. Good decisions are a by-product of healthy KM, not the driver.

Jack,

Methinks it is indeed possible to build relationships, engage in work, participate in a team and continue deep dialog in virtual space. The only difference is - it takes a lot longer.

Do you have to have f2f? - no - but it sure can speed up the process. The key IMO is not f2f but personal identity

Blogging is part of a larger social software genre. Collaborative writing, crafting distinctions and writing patterns in wiki is another example.

Wonder if there is not some form of tacit exchange without f2f?. Engaging in web conferences and bulletin boards can give rise to intuitions and anticipations which are based on tacit experiences - a form of complied knowledge that has never been made explicit.

Hi Jack,
I've posted some additions to the km dynamic at http://www.islandnet.com/~dmezei/kmexercise.doc

I've also started a km theory group on yahoo at:
http://www.groups.yahoo.com/group.kmtheory

Regards,
Don

Denham, I tend to agree that we can build relationships virtually. The time factor depends on all sorts of things -- shared interest (context), intensity/frequency of interchange, possibly even the medium of the exchange.

For some reason, I go back to thinking about my penpal days - writing to people around the world, exchanging letters and pictures of one another. This kind of relationship-building must apply to the online world as well.

PricewaterhouseCoopers solds its consulting arm to IBM. PwC is still in business - in fact, it is the world's largest provider of corporate accounting and tax services.

Patti has an interesting introducion piece at AOK. It got me thinking about ideas
What exactly are these ephemeral, fragile, objects?, who has 'ownership' in a meme?, how are ideas related to shared thoughts and to explicit concepts?

I go to wondering how ideas carry and 'participate' in knowledge flows? what quality of representation is an idea, is it less than a story but more than perception?

Looking forward to 'talking' with Patti next week.