TOC & CCPM

My friend (and neighbor) Johanna Rothman has a piece in her newsletter which she calls, Park Projects You Can't Staff, For Now.  It's a very good way of describing the common problem businesses put themselves into: too much work in process.

How many projects are you working on now? If you're like most people, groups, and organizations, the answer is more than one. You, your group, and organization are suffering from multitasking. That means that you have more projects than you have people to staff them. It's time to park some work.

Of course, people are working on multiple projects.  From management's perspective, we push projects into the system to ensure that people are "always busy" under the belief that people are a waste.  (Which itself is a belief that if someone isn't ON a project, they must be idle.)  And from the individual contributor's perspective, they cannot say "no" or otherwise refuse once management activates a project that requires their expertise. 

The solution: park those excess projects.  The project isn't canceled or stopped, it's just in park until the system can afford to pick up this project and put it in high gear.  And parked means that no work is done on that project until management puts it back into drive.

By the way, while cutting work-in-process is a good idea in itself, organizations have interesting ways of pushing more work back into the system.  To make this stick, this needs to be part of a larger effort to improve management of the organization.

[Image: "PRND321" by Taylor Nelson]

I just finished both the classic book on "change management," Leading Change by John Kotter.  Next on my list is Kotter's companion set of examples and stories of successful changes, The Heart of Change: Real-Life Stories of How People Change Their Organizations.  Leading Change has been sitting on my should-read list for quite a while, particularly since my association with the MS-LOC program at Northwestern.  It's also come up a number of times on a Theory of Constraints mailing list as a must read to get a better understanding of why change implementations get stuck and what to do about it.

Leading Change has its familiar eight stages of change.  But the clear message is that big changes can only happen through leadership, taken on by people throughout the organization, not just the CEO and a few titular leaders.  For a change effort to work, the organization has to grant people leadership capabilities and let them run.  Organizations that want to change cannot work from command-and-control and "the old ways" of doing things.  Kotter makes reference many times to the 20th Century way of doing business that generally assumes everything will stay the same - business that just needs good management.  It is clear that everything will not stay the same, and that change demands leadership appear in many places.  In the closing chapters he talks about how to create those leaders and makes a strong tie to the idea of lifelong learning - allowing people to learn from their mistakes, their work, their curiosity and grow into leadership roles.  The book is both inspirational and somewhat fear inducing.  But then, no one ever said this should be easy.

Kotter's 8 stage process for change is as follows with some of my thoughts on each point.  I can't possibly cover the whole thing here.  If you are curious, go read the book.

1. Establish a sense of urgency.  If people in the organization don't believe the change is worth it, then they will be much less likely to get behind it.  And they will be more likely to drop the focus when the next shiny idea comes along.  And those shiny ideas come along frequently.
2. Create the guiding coalition.  Major changes cannot be accomplished by fiat, nor can small groups successfully complete the change.  But a guiding coalition or steering committee has to be built and committed to helping drive the effort across the organization.  It wouldn't hurt if one or two skeptics are in this core group.
3. Develop a vision and strategy.  What is the organization going to look like when this change is done?  What does it look like while the change happens?  I like that Kotter places a lot of importance on making the vision be something that makes sense to everyone, not just the people who wrote it.
4. Communicate the change vision.  One friend commented that Leading Change is all about communication.  It's a huge component all the way up and down these eight stages.  One thing I see in companies is that while top management believe they've told their people about X, most people in the organization haven't heard about it or recall only small pieces of the idea.  Kotter has seen this as well and reiterates the idea that important ideas have to be communicated many times in many ways.  More importantly, if it's such a big effort, people's daily communication needs to reflect the new way of working.  Internal leaders must "be the change they wish to see," quoting Gandhi.
5. Empower employees for broad-based action.  More leadership.  People throughout the organization must be able to take actions that they see is in line with the vision and the authority that they have to do something about it.  No more claims of "it's not my job." 
6. Generate short-term wins.  I was a little surprised to see this so far down the list, but then Kotter's discussion makes sense.  Many of the eight stages happen in parallel, and the short-term wins have to be clearly linked to the efforts made to get to the vision.
7. Consolidate gains and produce more change.  The core element of this chapter was, "Don't rest on your laurels" after a few good things happen.  Sure, you can celebrate, but you also need to redouble efforts, lest the progress you've made gets lost in the excitement of the Next Thing on the agenda.  Kotter also addressed an important aspect of procedures and policies that are tied to the "old way" of doing business.  These policies can be buried deep in the fabric of the organization and must be found and removed/changed to bring the organization in line with the new way of doing business.  And it's not a bad idea to write down the new policies, so you know why they are there.
8. Anchor new approaches in the culture.  While this is last on the list, I have to believe this comes into play with the development of the vision.  Once you know where you want to be, you also know how you want people to start behaving and what policies are in the way of the change.  As with Stage 7, the sooner the cultural and procedural barriers can be identified and removed the better.

One question I had while reading Leading Change was around the size and type of change under discussion.  Most of the examples were of major changes to the underlying structure or philosophy of a business.  But then as I read into the examples and stages of change, I can see the same problems appearing in seemingly smaller and smaller implementations - nearly anything that requires change to dive into the culture of a business could be under consideration of this model.  And this is where a link to Theory of Constraints appears.

In TOC, there is a set of "layers of resistance" or "layers of buy-in" depending on your point of view.  The layers of buy-in go something like this (layers of resistance are the opposites):

1. We agree on the problem.
2. We agree on the direction of the solution.
3. We agree that the solution solves the problem.
4. We agree that we can overcome any potential negative ramifications.
5. We agree that the obstacles to implementation can be overcome.
6. We commit to move forward.

This progression can be a helpful gauge to see where people are in a change effort and what actions need to be taken to help move the effort along.  Maybe it's because I am an engineer, but I like their logical progression on building an overall consensus to dealing with change.  However, all that is built into the layers of buy-in are the logical transitions.  There is very little in here directly about creating leaders and baking the change into the culture.  And depending on how you look at this model, it is all within the first few stages of Kotter's model (coalition and strategy, mainly).  That said, Kotter's model is probably not the be-all and end-all of change discussions either.

[Photo: "Inde Statue Gandhi" by laurent KB]

Do you want to do things well, or do the right things?  The difference between efficiency and effectiveness is exactly this difference.

Today, I came across this interview with Keivan Zokaei of the Lean Enterprise Research Center from last year where he says the same thing. Moving from efficiency to effectiveness using adaptive systems thinking.

Doing things efficiently is pointless if they are the wrong things. Here, we interview Keivan Zokaei of the Lean Enterprise Research Centre about how the best organisations, such as Toyota and Tesco, are adaptive to the market's needs whilst maintaining both quality and efficiency within their business processes.

Effectiveness is all about doing the right things.  Doing things that help bring money to the bottom line of the organization - or to help the organization achieve what it wants to achieve. 

But isn't "being efficient" a good thing?  Of course it is.  the problem is that most organizations focus on being efficient under the assumption that if everyone is efficient, then we must be successful in the end.  It should be obvious that this isn't true - but it isn't.  Organizations are complex beasts.  Doing things really well in one area might actually degrade the ability of the entire organization to do well.  

If you don't believe me, check around your organization for the way it is measured.  Is your plant equipment measured on "uptime?"  How does uptime everywhere relate to selling more product?  (No, not MAKING more product.  SELLING more product.)  Are you project team members measured by how well they are able to hit internal milestones?  Does that translate into projects finishing on time?  Are the sales people measured (rewarded) when they hit their targets?  Are they rewarded even more by exceeding targets?  Are they punished if they don't hit the targets?  I wonder how high their targets would be if these reward schemes weren't in place?  And how much does the organization suffer in lost sales because of it?

The best organizations know what the right things are, and then they have focused efforts on improving the efficiency of those things.  All the while, monitoring their business to check for other things that may get in the way of overall effectiveness. 

I'm looking forward to reading more of Bob Sproull's new blog on this topic, Focus and Leverage.  [Both this link and the link to the article above were mentioned by @Kallokian.]

[Photo: Excellent descriptive graphic, "Efficient VERSUS Effective" by Laura Dantonio]

I'm inspired here by Seth Godin's Getting unstuck: solving the perfect problem, where he suggests dealing with constraints by eliminating them:

The way to solve the perfect problem is to make it imperfect. Don't just bend one of the constraints, eliminate it. Shut down the factory. Walk away from the job. Change your product completely. Ignore the board.

If the only alternative is slow and painful failure, the way to get unstuck is to blow up a constraint, deal with the pain and then run forward. Fast.

What do you think of when you hear about constraints?  Do you want to eliminate them, as Seth suggests?  Do you want to change them?  Do you want to know why they are there?  Or do you know that they are a fact of life?  It all depends on your perspective and what you think those constraints do.

I'm a chemical engineer by training.  Constraints go into equations and set the boundaries of an optimization: temperature must be between 300 and 350 Kelvin.  Pressure must be ___.  Operating time must be ___.  Material of construction.  Ratio of materials.  Speed of addition.  In this scenario, constraints must not be violated for safety, regulatory, physics, and many other reasons.  They are just there.

In the world of business, we  run into a lot of other types of constraints (or roadblocks) to getting things done.  There's the classic "that's not how we do things here" that can hide layers and layers of decisions and behaviors and cultures.  There is the pointy-haired boss who creates artificial constraints.  There are market conditions that feel out of our control.  There are also things that seem similar to the previous paragraph: the factory can produce X widgets per week, or we can finish about 15 projects a quarter. 

The question is still: what do you do with them when you find them?

But first, how do you decide that a constraint is even worth looking at?  The obvious answer seems to be that if the constraint is preventing you from getting somewhere, you want to deal with it.  In the optimization world, this is an "active constraint."  From the Theory of Constraints, there is only one constraint "active" at any given time.  (Even in optimization circles, a solution where several constraints are active at once is undesirable because small shifts in other variables can push you beyond the edge into undesirable territory.)  For any system, the only interesting constraint is the one that is preventing that system from getting more of what it wants.  In business, that's typically sales.  In personal life, it could be all sorts of things.  But the constraint is the thing keeping you from getting more of what you want.

You know what you want, right?

Now if you know what you want, and you know what is keeping you from getting there, the response is obvious, right?  Follow Seth's advice: Just get rid of that constraint and get what you want. 

The funny thing about constraints, though.  There is always another one waiting for you: something else will keep you from getting more (maybe even your own limits in how you define your goal).

Another way to look at this from a process perspective is to try to get as much through the system in spite of the constraint.  Build (or rebuild) the processes around it so that you don't smash up against the constraint so hard.  Your machine can only make X widgets a week (and you can sell many more than that), then you had better not be making sub-par widgets.  Don't give the machine crummy materials.  Don't drop the widgets that its does make.  Make sure everyone knows what the constraint is, so they can work it into their operations.  And keep a vigilant eye out for the situation where the constraint moves.  (You've bought another machine, and now the constraint is in Sales instead of Operations.)

[Photo: "Friend or Foe?" by Jenn and Tony Bot]

How many times to you or a colleague have a brilliant insight that will solve the world's problems?  Does that insight go anywhere, or does it sit on the pile of other insights?  Or you try to do something with it but run into roadblocks that make the idea harder harder to implement.  Welcome to the half-baked idea. 

I thought about this today because of Holly Green's piece in Blogging Innovation, What If You Asked "What If?".

Every time you have a thought bubble that says, “I am right!”, deliberately pause and ask, “What if I’m wrong? What if there’s a different way to see this?” Innovation doesn’t mean you walk around wondering if you’re wrong all the time. The idea is to force yourself (every now and then) to open your mind, suspend your assumptions and judgment, and simply ponder, “What if…?”

While Holly is thinking about innovation, I think this has connections with any kind of idea: improvements, new hires, rearranging the furniture, etc. etc. 

Great ideas are only that.  There is no requirement that you take action on them.  But if you do, along with fitting that new project into all the others, you must take another look at the idea with the "What if" thought in mind: "What negatives could come out of implementing this idea?"  (I'm assuming the idea is there because you / the group believe it will have a positive impact.)  You certainly don't want to find yourself halfway through an implementation, only to discover those unintended consequences.

This is not a suggestion to kill ideas simply because there are negative ramifications.  It is a suggestion to verify that those negatives could really happen, and decide how to prevent those negatives from happening while still getting the benefit from the original idea.  This might be part of a risk management practice, or it could be part of being smart about deciding how to do things. 

The Theory of Constraints community has a specific logic tool, called Negative Branch Reservations (NBR) which is used to help understand how the negatives can come out of the great idea.  There are usually things like, "If we do X, then we'll run out of money before the benefits are realized."  Or "If we do that, then I will lose my job."  They aren't always articulated so clearly, so you have to listen.  But then job of the team is to first check the reality of these statements (will she really lose her job?).  If the negative could happen (the budget might run really thin), then you must develop ways to overcome the problems.  And decide whether the idea is still worth it. 

[Photo: "Book of Shadows II {closeup}" from Deborah Austin]

Another book in my long backlog was Ray Immelman's Great Boss Dead Boss (How to extract the very best performance from your company and not get crucified in the process) from 2003.  I finally picked up a copy and thoroughly enjoyed it.  As with many good books, the ideas have me looking at the world in a slightly different way.  Of course, the book has its own website.  (Disclaimer: I know Ray from consulting work he did with my employer around the time he was writing this book and from later interactions in the TOC community.)

I had no real idea of the topic of the book, other than the odd title and the fact that it had been recommended by a number of colleagues over the past few years.  I had assumed the book would cover the general topic Theory of Constraints book, but that is not the case.  It's about how people interact with one another, specifically around motivation and performance.  And it is (another) business novel with a fairly narrow focus on the protagonist and what he learns from his guru and his business.

The general idea beyond the story of the book is that people act in fairly predicable ways around their individual security and value perception - this isn't terribly surprising or new to anyone.  The additional piece that Immelman adds to this discussion is that this individual perception is also strongly tied to the association people have with their "tribes" or groups to which they belong.  People are members of many different tribes in their lives, from family to neighborhood to school affiliations to professional associations to office cliques to functional silos.  And just as people act to protect their personal security and value, they will work together to protect their tribal security and value.  And the individual and the tribal interact.  If you can understand these things and some version of the 5 Tribal Dimensions and 23 Tribal Attributes discovered in the course of the story, you should be able to act in ways to create a very different kind of organization.

Why does this make me see the world in a different light?  It's the way the story developed.  Type types of self and group interests and the attributes were illustrated with familiar stories from the business press, and through application by the protagonist.  I could see examples in my own history and in thoughts about how things work with our clients.  Resistance to change?  It's because the way we approach the change is perceived to threaten something in their security or value.  Or the change helps a different tribe "win" over "my tribe."  Frequently, in management-supported change efforts, it's the workers vs. management tribe - no wonder management initiatives don't get very far.

An element near the end connects back to the ideas of leadership: Along with the familiar discussions of leadership integrity and the like, the leader has to have the psychological "guts" to take the company in the right directions.  They can't be perceived as weak along those lines - even if they don't necessarily have all the answers.  Another piece of this is that leaders need to have mentors with psychological strength to help them grow even further.  I know I have grown and improved much better when I have mentors to help me reach new heights.

Now to ponder how to incorporate these ideas with my ongoing work. 

The book went through the familiar process of a business novel: Setup a big problem that the protagonist can't solve, no matter how smart he is (or has been in the past).  Discover a guru who has solved the problem and who is willing to help.  Grow in understanding as more of the things the guru has been saying are tried and implemented.  Succeed beyond your imagination.  The progression through the protagonist's education was pretty linear.  One thing that might have been interesting would be to have him make mistakes as he went along - not fully understanding what he was learning and applying it "wrong." 

A quick entry on Saturday night.  Update: changed the embed below to link to same docuement on scribd.

I came across Retrieving Projects from Bad Performance (embedded below, assuming Flash works) on LinkedIn, in the status update of the author, Shridhar Lolla.  It's a brief story / case study that describes the initial view of a project environment that is in trouble and poses some interesting questions about how one might start thinking about turning the system.  For Theory of Constraints aficionados, the path of the discussion will be familiar.  I liked that Shridhar doesn't dive all the way into the solution - just providing some things to ponder.  

Retrieving Projects From Bad Performance

How many systems are out there for tracking the status of a project and the tasks within that project?  Whose responsibility is it to gather and compile these status reports?  Is it the manager, project manager, some software?  Is "get the status" the wrong things to consider?

The Manager Tools podcast on Assign Work AND Reporting gives me a new view of this question.  First off, while acknowledging that task status is a valid concern, the Manager Tools guys suggest that the need to “get status” is the wrong view.  Instead, reporting of the task status is the responsibility of the task owner: she is the best person to know when a task is done (including handing off any relevant documentation, code, materials).  And she is the best person to know that the task is going to be done early or late.  And if there are problems, the owner most likely knows who might be able to help.  

The Manager Tools guys touch briefly on why this reporting of status has gotten away from the task owners.  In the world of primarily physical work, the status was obvious: the thing you were working on was sitting there for everyone to see.  But in knowledge work, much of the status is not obvious until the task is done.  And even then, people may not know the work is done until they ask for it.  It makes sense for the person doing the work to report this status. 

But why don't they report status?  The manager tools guys suggest that it's due to the way managers and business talks about tasks.  The tasks are "do X," and there is no longer the assumption that status is part of "X."  Without that assumed need, people naturally do not report the status.  Manager Tools argues that is it not obvious when work is done.  More importantly, it is easy to hide "not done" and "going to be late" if the standard behavior is not reporting the status.  So Manager Tools recommend changing task descriptions to "do X and report on status," where the status is something in the form of a report or proof that the task is complete (or the current state of the task).

So why is this so interesting?  One of the elements of the work I've been doing with Critical Chain Project Management has to do with task management.  Rather than holding people to specific dates, we ask them to to work as quickly as possible (single-task focus) to get tasks done when they start.  And while the task is in progress, report the status on a daily basis in the form of how much time is remaining on the task.  If there are problems / delays, that should be reported as quickly as possible, so the issue can be resolved and the task completed.  The goal is not to complete individual tasks "on time" but to complete the overall project as quickly as possible.  This dovetails nicely with the discussion from Manager Tools: the task owner should be responsible for communicating the status.

Another thing they touch on is the idea of status tracking software.  If it is built and set up with the mindset that it is there to "get the status" of tasks, the organization is going to find great resistance to the software.  This sets up the software as the enemy, and it's even worse if management don't bother using the status information to make decisions.  (Ever hear the argument that people can't get work done because they are spending so much time updating the status?  It's a smokescreen.)  Instead, if software is to be used, it has to be part of a logical response to how task owners can report status / troubles / successes in a standard way that helps them do their job AND helps the organization do something with the information.

[Photo: "Every year is getting shorter, never seem to find the time" by John Harvey]

I've come across a nice article by Bob Sproull that describes how he has combined Theory of Constraints with Six Sigma and Lean to create what he calls the Ultimate Improvement Cycle, Maximizing Profits Through the Integration of Lean, Six Sigma and Theory of Constraints, from Six Sigma IQ (IQPC).  Obviously, this is related to his book, The Ultimate Improvement Cycle.  Sproull is not the only one to talk about this concept, and there are a few pointers in the end notes of the article.

Although I am a huge supporter of both Lean and Six Sigma, the profits realized from these two initiatives, or even the hybrid Lean Six Sigma, pale in comparison to what can happen from an integrated Lean, Six Sigma Theory of Constraints (TOC) (or as I call it, the Ultimate Improvement Cycle [UIC]). In fact, one double blind study of 21 electronics plants has confirmed that an integrated Lean Six Sigma Theory of Constraints improved profits roughly 22 times that of Lean and 13 times more than Six Sigma if these were both singular process improvement initiatives.

The Theory of Constraints community is often given a hard time for the seemingly-blind belief that TOC is the way to run a business.  Maybe one of the elements of that has been the rejection or diminution of many other useful tools in the management toolbox.  Looking across the wider landscape, as Sproull is doing here, should help fit TOC into the big picture.  Where do each of these tools fit best?  How can they bring the most advantage to an organization?  This work clearly focuses on TOC and Lean and Six Sigma.  But there is nothing preventing one from looking at other methodologies in the same light: what can you use in an Ultimate Improvement Cycle of your own?

How do they fit?  Read the article or the book for the details and some explanatory graphics.  But the basic idea is that if you don't focus improvement efforts at the constraint of the business - the thing that is limiting your profits - then that improvement is going to show little to no return.  This is the biggest complaint about applying the improvement efforts to everything in the business.  You might get lucky and improve on the constraint, but you'll also spend a lot of time (and money) improving areas that don't necessarily need it.  This is Step 1 in the TOC parlance: Identify the Constraint. 

In Step 2 of TOC, you look for ways to get "improve" the constraint: get as much of the right thing out of the constraint and as little as possible of the wrong thing.  Ensure that whatever is happening at the constraint is of high quality (low waste, low rework).

In Step 3 of TOC - by far the hardest because it affects everything else - ensure that everything else in the business supports the constraint.  Make sure the constraint is never starved for work.  All work that is delivered to the constraint should be of high quality - get rid of defective work BEFORE it hits the constraint.  Any processes after the constraint should be careful that they don't create a rework situation where the constraint would have to redo what it has already done. 

In my reading of Sproull and other discussions on this topic, it is in Steps 2 and 3 where the improvement methodologies really come into play.  TOC doesn't provide any specific guidance on HOW to exploit and subordinate, it just directs you to do it.  (Clarification: the TOC applications guide you on the HOW at the high level, but there are many lower levels which are left to the specifics of the implementation.)  These aren't the only connection points that Sproull makes to the TOC Process of Ongoing Improvement, as the Five Focusing Steps are known.  But they are some of the most obvious in my mind.

Lisa Scheinkopf's Thinking for a Change: Putting the TOC Thinking Processes to Use came out over ten years ago, but it does a good job of describing and summarizing the Theory of Constraints (TOC) thinking processes.  As is often my bent on reading a business book, I couldn't help applying the ideas to my current business situation.  In this example, I filled up several pages in my notebook with partial trees and other notes inspired by discussions with a colleague this week.

Going along with the applied feel to the book, each thinking tool is treated as a stand-alone topic, with the specific recommendation on when to use the specific thinking tool.  The examples used throughout the book have a real-life feel to them, rather than something polished and perfect.  In fact, several of the examples come from personal life, rather than business life.  And it is only at the end of the book where she describes how the tools can all work together to help think through major changes, helping to understand What to Change; What to Change To; and How to Cause the Change.  Scheinkopf also has a brief section on how to use the Current Reality Tree (CRT) as a device for communicating with others: the Communications CRT, which is an interesting topic.

That said, one quibble I had with the book was that the order of introduction of each thinking tool was a bit random.  This included one chapter where she used an example for a Future Reality Tree (FRT) that came from the Current Reality Tree (CRT) example discussed in a subsequent chapter.  And the graphics used for the example trees felt a little clumsy.  I don't know if this is due to the age of the book and capabilities of the tree-drawing packages.  But that also gets back to the practical nature of the writing: use what you have to draw these things: paper, the drawing package in your word processor

The book has a different feel as compared to Dettmer's more recently published, The Logical Thinking Processes (my review).  Dettmer's book was more academic in feel (and thicker), and it seems somehow more thorough in the treatment.  While both books provided step-by-step instructions, the process for the individual thinking tools was clearer with Scheinkopf.  I also like Scheinkopf's description of the mechanism for challenging the thinking trees: there are challenges associated with what has been explicitly written (the boxes and the arrows), and there are challenges associated with what has not been written (additional causes; insufficient causes; predicted effects).  I preferred Dettmer's treatment and recommendations for the Prerequisite Tree (PrT) better, and I see why he recommends collapsing the Transition Tree into the PrT.  Rather than reiterate my take on all the thinking tools, just have a look at my review of Dettmer's book.  Or search for "TOC Thinking Processes" for other descriptions of the tools.

[Photo: "Thinking is Timeless" by Papyrarri]

I've had Brown and Duguid's The Social Life of Information on my reading list for a long time.  I finally picked up a copy at the library, and I was happily surprised that it holds up well after ten+ years.  Sure there are some dated examples, but the overall idea still makes sense.

I think the main reason it holds up is that it is not a book about knowledge management or innovation or technology or many of the other topics covered in the essays.  It is a book about design and how we tend to forget that there are many more factors than what the designers focus upon.  

The main point of the discussion is around the claims of evangelists for information systems, though the authors touch on other areas of extreme claims too.  The authors discuss the futurists and information evangelists who believe that we are just around the corner from a the end of <take your pick>, all because of of demassification, decentralization, denationalization, despacialization, disintermediation, and disaggregation (the 6-D's): elements that information availability and technologies will enable.  In the minds of the authors, all these discussions assume that the way people operate with respect to information has to do with only the information.  And, by the way, futurists have been predicting the end of <take your pick> for a long time.

But there is a social life that revolves around the information that is much harder to capture and codify...  We look to verbal and physical queues for validity of what someone is saying.  Our business processes have much more than just the inputs and outputs.  The interesting things we do aren't repeatable.  Location matters in many aspects of business and socialization.

In short, design that focuses strictly on one aspect of how things are done (the information; the process; the technology; the knowledge) will fail.  People do things for a reason, and these reasons must be understood.  In fact, the bigger the proposed change, the deeper the understanding of the entire system must be.  In this light, the famous failure of Xerox to pick up on the early PC innovations of Xerox PARC can be better understood: the scientists were proposing changes so vast in areas far away from the core business of Xerox, that there was very little chance for the ideas to be taken up by the engineers who would be responsible for implementing them.  There was no common framework for the scientists and engineers.  On the other hand, there were others in Palo Alto who could see the value: Apple.  And it still took them years to take the ideas to market.  The authors talk about many other examples where this tunnel vision, while producing interesting results, ended up not working as expected because all the social aspects of the work were downplayed or ignored. 

In fact, in the essay on reengineering (business process reengineering: BPR), the authors describe how all the social life around business process is downplayed and often treated as waste.  Businesses were re-engineered to remove much of the social lubricant that helped business flow.  The essay on knowledge management was hopeful that KM would be a shift away from the intense focus on information and account for the human aspects of knowledge: that knowledge requires a knower.  They have a great phrasing: information can easily be written down and transferred.  But it is much harder to detach (and transfer) knowledge from the know-er and the context in which that knowledge resides.  Look at best practices as an example.  This then tied to a discussion of process vs. practice and then to networks of practice and the narrower, communities of practice.  While these topics are very familiar to people who have been following KM, I enjoyed how they were put together.  I had to wonder, though, after reading the KM essay: what happened?  Why did KM miss on the promise that it seemed to offer in the late 1990's?  Some of the answer is right in the book: the focus on KM shifted from the how and who and into the stuff to be discussed.  The result?  Boasting about how many Lotus Notes databases that the company had running.

One of the topics in the book has to do with how technology was going to presumably remove the need for people to be co-located in order to get work done.  This assumes that the work people do is merely the exchange of information and could be done over computer networks or teleconferences.  But it's been shown again and again, that there is a non-information component to people working in offices together: the socialization that is needed to help people do their work and learn about the networks they've fit themselves into.  But then I look at what has changed in the last ten years and wonder if some of the problems of the way people work together in this way have been overcome.  I wonder if things like broadband and social software has helped some people overcome some of the missing connections they have when they work side by side. 

As I read the discussion around design, I was struck with a connection to Theory of Constraints.  There were several places in the early chapters that rang a familiar bell.  New software implementations, no matter how well-intentioned the design, can succeed without clear understanding of the situation into which the software is being implemented.   These are often called the Necessary and Sufficient Questions on Information Technology that come out of Goldratt's Necessary but not Sufficient:

1. What is the power of the software?  (That's usually easy to answer.)
2. What is the problem that this software is fixing?  How, exactly, will the software resolve the problem?
3. What are the (old) ways of doing business that are in place to deal with the problem?
4. What new ways of doing business must be created, now that the software is being implemented?
5. Understanding these old and new rules, does the software need to be changed?
6. How can we make the change to take advantage

It is that 2nd question that starts taking you away from "this stuff is going to change the world" claims of the evangelists and back down to the reality.  What is the problem that this software (or any change) is going to resolve?  And the next question gets you to thinking about how this cool thing will fit into the business or organization - into the way people are doing things now.  And this seems to be Brown and Duguid's basic suggestion: do interesting things, dive into the details.  But then when you come back up to the surface, take off the blinders and look around to understand how people would really take advantage of what has been developed.

[Photo: "Horse Blinkers" by Alex E. Proimos]

Dennis Stevens posted an article about Deming and the System of Profound Knowledge.  Of course, I know who Deming is, but I don't think I'd ever seen the System of Profound Knowledge before.  As Dennis describes things, I see an immediate connection to the Theory of Constraints.

Here is how Dennis describes it:

Deming believed that generating a shared understanding of the system, taking actions that optimize economic outcomes, and aligning the beliefs of the people within the system were keys to a sustainable ongoing improvement effort. Deming taught this as the System of Profound Knowledge (SPK). There are four points to SPK:

1. Appreciation of the system
2. Understand how variation impacts the system
3. Theory of Knowledge of the system (based on the above)
4. Psychology

While the Theory of Constraints words things differently, these four items are closely related to how TOC approaches systems. 

First off, if it's a system, you'd better look at the system, not just the pieces that make up the system (the whole is greater than the sum of its parts).  Deming is probably best known for the focus on understanding variability in the context of the system - something that many people and organizations don't spend enough time doing.  With that information, you can then build a theory of the system and go on to hypothesize some corrections.  And underneath all of this is human psychology: systems are made up of people who have long memories and deep understandings which color their behaviors in ways that are not always obvious on the surface. 

And as a reminder, the core process in Theory of Constraints is a set of Five Focusing Steps (5FS).  But even before you can focus, you need to answer a couple questions:

• What is the system?
• What is the goal of the system?

With that in hand, you can then analyze according to TOC

1. Identify the Constraint of the system (what's preventing the system from attaining more of its goal?)
2. Determine how to get as much as possible out of that constraint (time lost at the constraint is lost forever)
3. Align the rest of the system to the constraint (don't make decisions that optimize one sub-system to the detriment of the overall system)
4. If you still need more, elevate the constraint (hire, buy, etc)
5. Don't let inertia become a constraint.  If the constraint moves, start over at step 1.  (But maybe step 1 should be a strategic selection of the constraint, so that you don't have to keep re-aligning your business to different constraints.)

[Photo: "Edifying! Insightful! Profound! Intriguing!" by quinn.anya

Do people and groups have an overall level of risk with which they are comfortable?  If risk is reduced in one area, does it get consumed by increased risk-taking in another area?  This is the (under debate) hypothesis of risk homeostasis as proposed by psychology professor Gerald J. S. Wilde.

I've been reading Malcolm Gladwell's "best of" compilation, What the Dog Saw: And Other Adventures.  Several articles are very familiar, either from reading them previously or from the discussion and topics that they created elsewhere.  One story that caught my attention is the story from 1996 about disasters and risk, Blowup.  The overall story is about the Challenger explosion in 1985 and the efforts that went into determining what happened and fixing the problem.  The issue, though, is that while the o-rings on the booster rockets have been fixed, there are six binders full of other shuttle components that have a similar level of risk.  How do you fix all of these things to reduce risk?  You probably don't.  You have to gauge the acceptable level of risk (explicitly or not) and move ahead.

And how does this relate to the idea of buffers from Theory of Constraints?  It was the words Gladwell used - and maybe these are words used in the larger community of people who talk about risk too.  He uses the word "consume," as in 'They consumed the risk reduction, they didn't save it.'  For some reason as I read those words and the final sections of the article, I couldn't help think about buffer management and what happens in reality of TOC implementations if buffer management is not followed.  What I see is that while we make every effort to help people understand the intentions behind the implementation, if they do not follow a new set of rules, they consume the buffers that are intended to be there for variability and emergencies.  Instead, the buffers get consumed because they have the false idea that with the buffer they now have "extra time" to get their work done.

I wonder if there is a connection between the psychology behind risk homeostasis and the behaviors I have seen in some TOC implementations.  Is there an underlying belief that the buffers protect operations more than they actually do?  Or does it go beyond buffers?  Another thing that happens in TOC implementations is that the amount of work in process (WIP) goes down because things are supposed to flow through the system faster.  What if, as part of the initial WIP reduction, people slow down rather than speed up?  They've just consumed the time buffer that is supposed to be there to help them move faster. 

Interesting thoughts.  I hope this helps someone else too.

[Photo: "Puffer / Buffer" by pittigliani2005]

So often in business operations, the focus is on removing variability or eliminating waste or load leveling.  But how often do you hear about these projects and wonder whether it actually does anything for the bottom line.  I could write about why that is, but what has tickled me today is the idea that variability and "waste" can actually be helpful.

Really?  "Waste" can be helpful?  Isn't variability the focus of all those Six Sigma projects that GE and everyone under the sun are running?  Well...

Is excess capacity "waste" or good business?  Think of what happens when there is a glut of work, or if there is trouble that demands a quick response.  Without some excess capacity, it will be impossible to respond without Herculean efforts.

Variability is a bit harder to justify, it seems to make sense that you want to reduce variability everywhere.  But in most cases, it makes no difference.  There is still one step in your process that limits the overall throughput of the system.  If you reduce variability elsewhere, you don't increase the capacity of the system as a whole.  It's a waste of time and effort to reduce variability where it doesn't matter: and people get annoyed that all their efforts don't have a bottom line benefit.

I recently heard another nice connection between variability and innovation (on a TOC-related group on LinkedIn).  How will we know if can do better (faster, different) if there weren't good days and bad days to compare?  Isn't that what inspires the questions of "what was different here?"  If every day is the same, it's easy to get lulled into the belief that "all is well." 

Even worse is the idea of "load leveling."  Number one, it is nearly impossible to do: you'll more likely get people padding their time to appear level - and show a lower capacity.  If you manage to set every step to have the same capacity, what then?  What do you do when you need more capacity from the system?  You need to elevate the entire system, rather than having one place to focus (the constraint of the system).  And what happens when you have variability in a balanced system?  Any breakdowns, slowdowns or problems will ripple through the whole system, reducing the output.  And that loss can never be recovered.

Where should you reduce / remove variability?  You only need to do it in places that are damaging your ability to produce.  Does that business process frequently cause project trouble?  Is it always machine X that delays runs on your critical operating step?  Are deliveries from supplier Y so variable that you need to tie up funds in excess stock of their products?  You don't need to attack process, machines or suppliers: just those that are having a negative impact on your bottom line.

Feel free to add some more examples in the comments!

[Image: Drawing by Tom Fishburne in his article quality (out of) control thanks to Dave Snowden]

It's so easy to get caught up in measuring things and forget why you are measuring.  Here's a fun one from Glenn Alleman's Quote of the Day series

It is possible to measure virtually any activity in the program, but if the measurement does not support a key objective, it is not worth the cost of data collection and analysis.

- A caution in The Integrated Project Management Handbook, Dayton Aerospace Inc.

One of the things that is very clear to me in project management or even production: if the measurement doesn't relate to getting to done faster, then there is no point in measuring.  In the context of projects, that measure has to look at the Critical Chain of activities from Now until Done.  The events that happened in the past are only interesting from a higher level: lessons learned, for example. 

Some things to measure in projects:

• How much time remains for active tasks?  (Not "did the task finish on time?" or "when did it start?"  Because you have a buffer to deal with variation, right?)
• How are the projects progressing vs their buffer consumption?
• What problems cause the most buffer penetration overall projects: In other words, over the course of many projects, which types of problems cause the biggest delays?  This involves collecting any problems and their impact.  Then ignore those that don't have an impact.
• What is the load on the most heavily loaded resource?  If it gets too high, then the whole system will bog down.

What's the goal of project environments?  Get projects done as quickly as possible!  This applies whether those projects are sold to customers (and make money for the company), or they are for internal customers (and make life easier for the company).

[Photo: "Measuring time" by aussiegal]

Topical linkage at my new online homeProject Management
Productivity
Marketing
Management
Web DevelopmentRead all my linkage on Tumblr
http://frankpatrick.tumblr.com/
RSS FeedMy Tumblr site will get you stuff that would have ended up on Focused Performance, plus other stuff of just personal interest. There are tags on posts there to help you focus on particular topics if you don't like my politics, taste in music, or sense of humor.Follow me on Twitter
http://twitter.com/fpatrickIf you're interested in topics related to interactive or mobile marketing, social media, SMS text, web design and development, I'm also one of the contributors to my employer's Twitter presence at http://twitter.com/us_again. You won't get only me there, but also a bunch of really smart interactive marketing professionals.(As of May 1, Google is turning off ftp upload support for Blogger blogs, so reminders like this will end then.)

All good things must come to an end...

If you still read or subscribe to this blog, you haven't seen much in the past few months, and this will be the last post you see from here. My last previous post from back in September 2009 was a fitting final ironic link post.

Having originally set up Focused Performance to support my 1996-2004 consulting practice, my energy and time for writing meaningful pieces has dissipated and almost disappeared. Three jobs after my consulting days, I've become immersed in the world of social media, and have gotten into the worlds of Twitter (for primarily links to topics previously covered in Focused Performance), Facebook (for connecting with people I really know), LinkedIn (for business contacts and networking with folks with whom I have more tenuous connections), Flickr (photos), and Tumblr (for "micro-blogging" a mix of Focused Performance topics, personal fun stuff, and social commentary). And I'm still trying to figure out Google Buzz and Foursquare.

As a result of this spreading of my online life, I've been thinking of retiring the Focused Performance blog after 9 years. And this last month, Google's Blogger team (whose platform I've used since the beginning) announced the end of ftp publishing which I depend on to integrate the blog in the old FP site. It will be easier to just let this live on as is with no posts, and start a new blog, but I think I'll stick with my current collection of outlets for now. Maybe I'll revisit some of the best of this old blog in my new haunts. Maybe I'll launch another blog down the line. Who knows what tomorrow will bring?

It's been a good run. I've "met" a bunch of great people online through this blog. And I hope that you'll find it worthwhile to follow me through my other touch points in the interweb.

Read me and my linkage on Tumblr - http://frankpatrick.tumblr.com/ - (RSS Feed)My Tumblr site will get you stuff that would have ended up on Focused Performance, plus other stuff of just personal interest. There are tags on posts there to help you focus on particular topics if you don't like my politics, taste in music, or sense of humor.Follow me on Twitter - http://twitter.com/fpatrick- There's also a bunch of people in the list of people I follow that you'll recognize from my FP posts...Clarke, Joe, Jack, Jim, Johanna, Esther, Steve, and others. (To these folks, thanks for all the insights. I often counted on you for ideas to riff on here on FP.)

If you're interested in topics related to interactive or mobile marketing, social media, SMS text, web design and development, I'm also one of the contributors to my employer's Twitter presence at http://twitter.com/us_again. You won't get only me there, but also a bunch of really smart interactive marketing professionals.Friend me on Facebook - http://www.facebook.com/fpatrick...but only if we already have an offline relationship, please. I'm trying to keep my Facebook limited to family and friends (in the traditional sense of the word).Join my business network on LinkedIn - http://www.linkedin.com/in/frankpatrickAgain, I'll be more likely to accept a LinkedIn request if we have more than just a blogger/reader relationship, but unlike Facebook, I'm a bit more flexible with my LinkedIn connections.
Thanks for your support over the last 9 years.

Be seeing you...

-- Frank Patrick