In 1945, Pablo Picasso prepared a sequence of 11 fascinating lithographs depicting a detailed, lifelike bull transforming into an elegant abstraction. You’ve probably seen these images, and perhaps read an article or two on how art and design teachers like to use these as an excellent object lesson when they teach the principle of stripping your subject matter down to its essence, peeling back the onion, and discovering the object’s first principles before starting to piece together what innovation or variation you may want to introduce.
Although trained as a physicist and then pivoting into a world-class consultant, author, thought leader, and the founder of the Theory of Constraints (TOC), I like to think Dr. Eliyahu Goldratt would have made one heck of an amazing product designer!
When he went into a new subject area, he seemed to “Picasso” it. He would slowly dismantle the long-held assumptions, “best practices,” and sacred cows to get down to its essence. He then seemed to build simple theoretical models that showed the key dynamics at play, and then he would use the TOC thinking tools to carefully rebuild a unique understanding, which would spawn a novel set of insights, that would often shake the arena in question to its foundation.
That certainly seems to be the case when Dr. Goldratt set his sights on engineering and other project-rich environments.
What is the final bull lithograph of projects? Dr. Goldratt does an incredible job detailing this in his lecture series/audiobook Beyond the Goal which you’ve probably listened to a dozen times or more like I have, so I won’t attempt to reiterate that here, but this is where I think we may have missed the point. At least I did for many years.
I got hung up on trying to learn and apply the project “rules” Dr. Goldratt introduced with his Critical Chain Project Management (CCPM) solution, which might be loosely characterized as follows:
- Strip the “baked-in” wiggle room out of individual task estimates and put a portion of that into the project buffer at the end of your network.
- Don’t get so hung up on each individual task finishing on-time. Rather, watch the percentage of the buffer consumed relative to the amount of calendar you’ve traveled through (maybe through a cool fever chart).
- Strategically place other types of buffers throughout your schedule (e.g., resource buffers, feeding buffers) to account for Murphy’s Law.
- Keep your schedule at a high-enough altitude to be useful, but not so detailed that you get lost in the weeds and the time to keep it updated becomes ridiculous.
- And perhaps most obviously, know that your schedule is most definitely not complete when you’ve prepared the critical path, you’re only done after you’ve taken the critical path and resource-leveled it (the critical chain).
Now, before we go on, I am pretty sure that bullet list alone will get a number of you jumping over to the email program on your second screen to dash off a heated note to clarify one or more of those bullet points, or to tell me some CCPM rule I forgot. Just hold your horses for a second. I welcome the clarification. I really do. I’ve found there are sometimes as many different understandings of what CCPM is as there are CCPM experts, so go ahead and set me straight…but later. Right now, all of that is missing the point.
What if Dr. Goldratt never gave us CCPM? Would we still have a TOC project management solution (TOC PM, perhaps)? We would.
I admit I got sidetracked with the CCPM rules for many years and went through the almost obligatory “religious” phase about it–thinking it was all about adherence to the CCPM rule set. I acted like CCPM was the TOC project solution, instead of seeing it as being a key piece under a larger project toolset umbrella.
In short, I forgot to simply see a project as a workflow. Projects have a direction of flow. We get requirements for the software before we design it. We design it before we develop it. We code and test it before we send the deployment package on its way up the environment stack toward PROD (and hopefully we’re all moving rapidly toward the DevOps model to do this). And this flow is true whether you still work in a waterfall shop or if you’ve converted to Agile iterations. The flow is still there, we’ve just drastically varied its length and how much we expect to bite off in each chunk.
Things that flow often have friction points. TOC taught us to recognize these friction patterns just like a skilled fly fisherman can spot a “rise form” from a trout that would be invisible to a newbie or to see where a trout has sipped a fly into its mouth two feet under the water by seeing the slightest of pauses in the line on the surface.
When we see these friction points, we apply the rules of flow to optimize throughput. That, to me, is TOC PM at the final lithograph—maybe not CCPM, but there is a very powerful TOC solution for projects that pre-dates CCPM: applying the five focusing steps to our project flows.
Enough theory and pontificating. A quick example is in order.
Let’s say you manage a software development project. On your project team are three, hot-shot developers. They’re really good, really knowledgeable about your domain, and everyone knows it. Let’s also say that not only do you have them on your project, but they are so good and so well-known, they are also matrixed to two other project teams at a given percentage (and if you think the two other PM’s strictly adhere to their 15 or 25 percent allotment, or whatever they have, you are fooling yourself).
You’ve been around, so you know the story. Your product owners, stakeholders and business analysts max these three out. In fact, you overclock them. Then, they have two other bosses and teams and sets of product owners who blow past their agreed-upon allocations and also max them out. Each PM is acting like they are the only game in town and they have exclusive access to these three developers. The three developers are working their tails off, putting in the overtime, and secretly looking for other jobs where they only have one boss at a time.
Now what do the TOC Five Focusing Steps tell us to do in this situation–without taking any of the CCPM tools out of your toolbox? Let me ask that another way: if this were an assembly line at a plant, what would you advise the plant foreman to do?
Control the work in process (WIP-pronounced “whip”) that goes to the three developers. Synchronize your backlogs as PM’s. Only give full-kitted work to the developers. Remove unnecessary work from their plates so we maximize their time. Let their pace become the drum beat that the rest of the organization synchronizes to. We could go on, but you get the point.
Let’s start managing our projects from TOC first principles, dramatically improve throughput, then work our way into the cool buffer management and other insights Dr. Goldratt brought to the table with the full CCPM solution.
So, here’s the challenge I have for you (and I’ll be doing this right alongside you): take your CCPM propeller hat off for a minute and just go back to what we read in The Goal. Pretend CCPM doesn’t exist yet. See your project with new eyes. Look for the flow. Look for the friction point patterns. You know what to do from here.
Here’s the extra credit homework: look up Picasso’s lithographs and stare at them for a while. Look at how he had to shift his mindset and probably had to radically alter his final objective in order to move through the various progressions. Then, comment below with what you think the final project lithograph should be.
Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.
|Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE|
|We hope you will consider joining our Facebook Community as well. Click on the image to your left to visit and join, or you can CLICK HERE|
Reading this article qualifies you to submit a request for PDU’s from PMI.
This Article qualifies as follows:
PDU AMOUNT: .25 PDU’s
For more information on registering your PDU’s with PMI – CLICK HERE
At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!
If you believe in what we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.
This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE
Randy received his undergraduate degree in Business, Corporate Communication, and Applied Information Technology from the University of Baltimore, and his MS in Information and Telecommunication Systems from Johns Hopkins University. He also has five professional certifications: PMP, PMI-ACP, CSM, SAFe, ITIL along with a certificate in Finance and Accounting from the University of Utah.
He’s worked as a business analyst, senior business analyst, IT project manager, IT program manager, and now as a senior IT project portfolio manager for a variety of organizations that include mom-and-pop companies as well as such household names as T. Rowe Price and The Washington Redskins.
Randy has a particular interest in the nexus of Agile and the Theory of Constraints, and consults on a limited basis with select clients through Epiphany Associates, LLC. Randy is the founder of the Projects and Systems Podcast
Projects and Systems Podcast - hosted by Randy Cox - CLICK HERE