Critical Chain

What’s The Goal?

by Josh

Last weekend I wanted to read “The Goal: A Process of Ongoing Improvement” by Eliyahu M. Goldratt again. It’s been a few years since I had, and it was one of the first books that really helped me to internalize many of the concepts I take for granted today.

I was delighted to find it on Audible.com, especially because I’m already a Platinum member and get a few audio books per month as a part of my subscription.

I listened to the sample, and it sounded good so I grabbed it.

It was even better this time around. The production was great, and it was great to get re-acquainted with Alex and his crew in this wonderful novel. I’d like to share some of my thoughts on the book with you today.

Perspective is Everything
Common Practice is not Necessarily Good Common Sense
Local Optimums are Not Optimal

Perspective is Everything

In the book, there are many occasions where the team is faced with a major problem and it turns out the solution was right there in front of them, staring them in the face.

They had to change their perspective. Ingrained assumptions were blocking everyone from making the shift in thinking necessary to find the solution.

Once they had made the paradigm shift, it seemed plain silly they hadn’t seen the solution earlier.

I have had similar revelations over the past few years, including limiting work in process (WIP) and multitasking on my projects as much as possible. Many of the strides I’ve made in terms of resource and release planning, time-boxed agile methods of working, and kanban have been a direct result of my own paradigm changes. Now that my thinking has shifted, it’s almost painful for me to remember how I used to manage my projects and lead my teams.

Common Practice is not Necessarily Good Common Sense

Many of the measures common in our professional lives do not really move us towards The Goal. In the book, a major example was efficiency. Parts of the system would be run at high efficiency in order to look productive, but in reality they were just creating large amounts of WIP that clogged the system and tied up material.

An example in my world of software development is the case where many people and organizations value a highly detailed plan over just about everything else. Isn’t a better goal to produce a quality product that perfectly meets the customer needs, on time and within budget? Isn’t everything else just window-dressing? I won’t spoil it for you, but zooming out just a bit more gets you to the goal of the organization, which is the true Goal that should be kept in mind.

Most standard waterfall-ish teams end up putting tons of effort into design and documentation up front, code like crazy, and then try to update and create new documentation at the end. The design WIP builds and builds, and by the time you start implementing you have to re-work your design anyway. And when you save documentation updates for last, you end up having to go back to the code and remember what you did in order to update the documentation appropriately. Then you release it to the customer and find out you are meeting requirements, but it isn’t really what they want or need.

WIP in software and many other domains can be thought of a perishable to an extent. The longer it sits there as WIP, the more value you waste due to rework and time to re-familiarize yourself with the WIP. If you put a set of functionality into play, you’d better be working on it, getting feedback on it (testing, customer reviews), or documenting it. Every moment you are not doing one of these things ends up as waste on your project “factory floor”.

This is a major reason I’ve been driven towards mapping the value stream of each of my teams in a visual manner using kanban as our vehicle. Minimizing WIP by focusing on one item and taking it through the entire value stream before moving to the next is a critical piece for my teams to achieve our Goal.

Local Optimums are Not Optimal

This is another critical point this book drives home again and again. It is very easy to only look at your own little piece of the system. Stove pipes rise up everywhere, with individuals, teams, and departments trying to achieve local optimums for themselves.

The only way to increase quality throughput on your projects is to look at the whole system, not just pieces of it. The broader your scope for applying systems thinking, lean concepts and others, the better chance you have at making a real improvement to the bottom line.

Daily stand-ups and a shared, visual representation of the entire project team’s work and focus is a perfect example of this principle in action. In this way (again I love my kanban!) everyone’s perspective is broadened to the team as a whole, and not just local optimums for individuals. Several times each week, my teams and I discover opportunities to enhance throughput by working together in specific ways. In fact, this week we discovered that for a portion of one system, we should actually stop work for a short time until a constrained resource (team member from another team) is freed up to work on it with us. Without the shared vision we now have, part of the team would have started work on it and created rework. Not only that, but the rework would have been pushed towards a constrained resource with a specific and unique skill set.

We may have felt productive locally getting “our part” done, but overall it would have taken more time (duration) and effort (work hours). The local optimum would have decreased overall throughput of the system (our project).

Have you read “The Goal” yet? If not, you can get it in audio format for free by trying out Audible.com today.

{ 4 comments }

Are You The Bottleneck?

by Josh

Jason was frustrated.

As the developer in charge of the system to integrate third-party data from another contractor (XYZ, Inc.), Jason had requirements and some initial specifications, but as things changed there were questions that came up.

Bottleneck - by Aidan Jones via Flickr

Because it was another contractor and company who was going to be producing the data, Jean didn’t want to expose Jason to the politics or potential sharing of company intellectual property. As the project manager, Jean saw part of her role as “dealing with the other contractors and the client to free up my team to be productive.”

By the water cooler, Jason was sometimes heard to say something like, “It’s really hard to know what I should be working on when the people I should be working with are ‘over there’ and the only way I interact with them is through documentation and my project manager. I have to make so many assumptions and it’s hard to be motivated when I know everything I’m working on this month might be wasted effort if one of those assumptions is wrong.”

Let’s use one of many possible toolkits to evaluate the situation, the Theory of Constraints.

Step 1 – Identify the system’s constraints

The constraint in this system is the communication between Jason and the XYZ’s developers. There is so much friction there and degrees of separation between the minds that need to work together.

Step 2 – Decide how to exploit the system’s constraints

Let’s look at a few options.

Jean could be better about communicating between Jason and XYZ. Perhaps it could be her highest priority to do this. But wait, there are lot of other demands on Jean’s time. And at any rate, this solution doesn’t solve the degrees of separation problem.

A better option might be to open up communication channels between Jason and the XYZ’s developers. Looking for the root cause of the constraint, we can find that fear and a lack of trust is really the underlying cause, so this option addresses that root cause directly. One of Deming’s 14 points is to Drive out Fear and Create Trust.

Step 3 – Subordinate everything else to the above decision

This may be difficult. Perhaps XYZ is very fearful too and doesn’t want their developers talking directly to other developers and potentially sharing company secrets. Jean may need to work on building trust and bridging the gaps.

We have decided that communication between Jason and the XYZ developers is the constraint to optimal throughput (productivity) in this system. Therefore we don’t try to address other potential areas for improvement in this system until we have elevated and broken this constraint.

Step 4 – Elevate the system’s constraints

The process of 1)trusting your employees and 2) garnering trust between you and the other companies you work with can take some time. Jason may need some training on ITAR or export compliance depending on the nature of the work and if XYZ has foreign developers. He may need company-specific training on IP and non-disclosure.

Then Jean can really get out of the way and focus on removing more obstacles from Jason’s path, instead of being one.

Now Jean and Jason can focus on elevating the communication further. Perhaps what started as weekly conference calls with project managers involved moves to developer-only discussions. Then perhaps remote collaboration tools are brought in like online white boarding, collaborative coding/documentation applications, and video conferencing.

Step 5 – If in the previous steps a constraint has been broken, go back to Step 1

Once this constraint is broken, it means that something else is now the limiting factor in Jason’s productivity. At this point we go back to step 1 and look for other constraints. Perhaps some specialized technical training would take Jason to the next level.

An important point is that all the technical training in the world wouldn’t have made much difference to this system as a whole unless the bottleneck (Jason’s communication with XYZ) had not been addressed first.

Another important point is that this is just one sub-system among many that make up the whole “system” that is a project. If we zoomed out we may find other areas of the project that are in much greater need, and as we broke those constraints we would eventually reach this one.

What did you think of this little thought experiment, and how would your analysis be different than mine?

{ 2 comments }

Introducing “Critical Chain Project Management”

by Raj Menon June 5, 2009 Critical Chain

…an effective scheduling technique that enables project managers to truly plan a project instead of merely stringing tasks together to an end date. True planning calls fot a great deal of thought that should go into executing a project and steer it towards success. But to do that, we need to first understand project failure.

Click to continue…

Theory of Constraints – 4 minute video on What to Change

by Josh September 17, 2008 Critical Chain

“Just ask anybody in the organization what to change, and you will find out to what extent people are real experts at bitching and moaning…”

It wasn’t me, it was Goldratt who said it! Wow, I hope I don’t lose my G-rating on this website….

Click to continue…

Critical Chain Project Management Overview

by Josh July 19, 2008 Critical Chain

A 10 minute video today on Critical Chain Project Management. A good introduction!

Click to continue…

Critical Chain Benefits From Traditional PM

by Josh January 20, 2008 Critical Chain

Today I was trying to think of ways to integrate some of the methods and benefits of Critical Chain project management into the traditional PM methodology most companies use. I wanted to pick out one element of CC that would potentially yield the most benefit without much, if any, additional overhead to the project manager. [...]

Click to continue…

← Previous Entries