TOC Handbook: Project Management

I picked up the TOC Handbook when it came out and nearly broke my foot when I dropped the brick of a book on my foot.  This is not airplane fodder.  I've heard many people already comment that this book is an excellent reference manual for all the Theory of Constraints applications.  Rather than review the whole thing, I am going to take it in chunks.  And since I've been doing work in project management recently, I figured this would be a good place to start.

The first section of the book is on the TOC view of project management, Critical Chain Project Management.  It has six chapters that cover a variety of elements of CCPM: why it is needed, comparisons with traditional management methods, and some thoughts about sustaining implementations of CCPM (or anything for that matter).  For me the material ranged from the familiar to nice stretches of my existing knowledge.  The full entry contains my take on each chapter.

Chapter 2: The Problems with Project Management by Ed Walker

The basic problem with project management is the projects are not completed on time, in budget or in scope.  Walker walks through many of the struggles associated with project management.  He also provides a set of guidelines against which a project management solution should be judged.  I hear echoes of familiar project management vs. CCPM discussions throughout the chapter: topics like estimating activity time; variability; inevitable delays at integration points; planning to dates, rather than flow; resource contention; multitasking; etc.  As I have learned, and Walker repeats, one of the biggest changes in CCPM is a shift to flow-based management at the task level, rather than focusing on start and stop dates.

One perspective that was presented in a new way was "the project management dilemma."  It is a version of the classic "if we are busy, we must be successful" mindset, but I particularly liked the dualities that he highlighted.  Project managers want resources available for their projects, and the organization wants those projects to move along.  But then the organization drives resource managers to "keep costs down" and that usually translates into keeping their staff lean and busy, rather than having some slack time to be available when the next project comes along. 

The chapter closes with a quick introduction to CCPM and how it addresses a number of the 12 guidelines Walker proposes.  Walker also provides a long list of academic references to CCPM, both of people critical of the approach and those who are more favorable to CCPM.  Actually, the whole chapter is loaded with references - the bibliography is four pages long.

Chapter 3: A Critical Chain Project Management Primer by Charlene Spoede Budd and Janice Cerveny

This chapter is a thorough coverage of the elements of CCPM and how they help overcome the common problems with project management.  Based on my experience, most of what they recommend follows fairly common practice with CCPM.  (I'm not sure how many implementations are using resource buffers.)  

While the chapter covers the elements and many of the how-to's, it has a brief treatment of how to implement Critical Chain Project Management in an organization.  That is left to the Chapters 4 and 5.

Chapter 4: Getting Durable Results with Critical Chain - A Field Report by Realization

This chapter describes Realization's perspective on how to implement Critical Chain Project Management, based on their many implementations over the past 10+ years. 

I like their recap of key effects of traditional project management: waiting.  Waiting for resources, which are busy doing other things.  Waiting for supporting materials because the people doing that work are busy elsewhere.  Waiting for experts to help resolve issues - guess what they are doing.  Waiting for management decisions - too much on their plates.  Waiting at integration points.  Rarely are there any opportunities for speeding up tasks or projects.  And the result is always late project. 

The Realization approach, as I described a few weeks ago during their Project Flow conference, Realization's Mantra, is to establish three key rules to take best advantage of CCPM: Pipelining, Buffering, Buffer Management.  The chapter goes through these in detail.  And it also goes through the step-by-step process that they use in implementations.  These steps look familiar, as they parallel the first legs of the Strategy and Tactics Tree for Projects (pdf hosted by Prof. James Holt):

1. Achieve management buy-in
2. Reduce WIP and implement "full kitting"
3. Build buffered project plans
4. Establish task management
5. Implement surrounding processes
6. Identify opportunities for continuous improvement
7. Use superior delivery as a competitive advantage to win more business (when applicable)

I note that it is steps 3, 4 and 5 that are what most people see as the core of Critical Chain Project Management.  But without the other pieces, CCPM has little chance of taking hold and succeeding.  In the detailed descriptions of each step, there are useful insights into how to make each of these happen and areas where implementers need to be cautious. 

I liked the comment under #3 above that project plans are not reporting tools.  They are a tool to plan for execution priorities and provide early warning signals.  Reporting uses the information from task management to provide clear information about task-level priorities, as well as helping management focus on those tasks and projects that are in the most danger.

Chapter 5: Making Changes Stick by Rob Newbold (of ProChain Solutions, Inc)

What are some of the new behaviors expected in CCPM implementations?  Work should preformed in relay-race mode, rather than a train schedule (I love this wording!).  Actions should be prioritized based on their impact to the project or portfolio level, not through their impact on individual productivity or achieving task deliver dates.  Commitments are treated as ranges, rather than specific dates - accounting for inherent variability of project environments.  These new behaviors go up and down the organization.  There are many aspects about the way businesses operate that make these new behaviors quite different.  CCPM works, but without a sustained effort to embed these new behaviors across the business, there will be - as Rob puts it - an Uptake Problem.

This chapter presents Rob Newbold's perspective on creating lasting change within organizations.  The topic may be focused around Critical Chain Project Management, but it's clear that his Cycle of Results (CORE) © model could apply just about anywhere that change is required.  Change isn't something that just happens. 

His CORE model attempts to reflect that there are actions to be taken as well as milestones to hit in any large change implementation.  He talks about analyzing the system to create urgency.  With the urgency, then build a vision and set expectations.  With expectations, start planning and creating ownership to achieve commitment.  With commitment,  begin to implement and gain value.  With the value achieved, connect that to measurable results to validate the approach.  Finally, with validation, loop back around to communicate and reinforce and set renewed expectations.  Alternately, analyze the system anew and rebuild urgency around the change.  Notice how close this model is to many of the other change models - Kotter's in particular.  (I note that Kotter doesn't explicitly have reinforcing loop though.)

Among the many interesting elements of this discussion, Newbold reinforced the importance of trust.  He talks about feedback - particularly the feedback built into the CORE model - as a key element of trust.  I took a note that said "trust requires feedback?" but I don't see that he said this directly.  He talks more about the importance of trust in the sense of being able to rely on both the people and the process to produce the desired outcomes.

Of the chapters on project management, I liked this one the best because it gave me a larger perspective beyond strictly doing CCPM implementations.  I might have to go out and read Rob's recent book, The Billion Dollar Solution.  I've read Project Management in the Fast Lane, but it's been a while.

Chapter 6: Project Management in a Lean World - Translating Lean Six Sigma (LSS) into the Project Environment by the AGI-Goldratt Institute

I kept expecting this chapter to be the typical TOC perspective on Lean and Six Sigma, but it never went that direction.  It was as the title suggests - a discussion of how Lean principles, which come from manufacturing, apply in a project environment. 

I enjoyed their translation of the Categories of Waste from manufacturing into projects.  And I liked the discussion of complexity in multi-project environments.  In this case, they identify four interacting business systems that contribute to projects and whose functioning competes with one another, rather than supporting one another.  There is the task management system (getting work done); the project management system (monitoring and managing individual projects); the portfolio management system (deciding what projects to execute; monitoring all projects); and the resource management system (hiring and allocation of resources).