Pilots?  Yes, but...!  
about Your consultant is guiding you into a minefield.  
 
 
 
It's not uncommon for a senior team to want to test a newly proposed process or organizational solution, before the team accepts the solution and deploys it throughout a large business, nor is it unwise.  Many refer to such tests as pilot-programs or simply as pilots.
 
When the right pilots are done the right way, pilots are very good things.  They provide understanding and experience, while minimizing risk to a business.  However, pilots also can be damaging mistakes.  In my case, the mistake was a so-called critical-chain pilot, and at the time, some fourteen years ago, I was fully qualified as a very inexperienced consultant.  
 
A critical-chain pilot, as it is proposed even now by some, is described best as an attempt to apply the critical-chain model to one project among many, all of which share the same set of resources.  On the surface, this seems like an obvious thing to do.  In reality, it's a dangerous mistake. 
 
 
Tests with Scale-Models
 
A pilot is nothing less than a test that's performed with a scale-model of a much larger, physical system.  The larger, physical system may be an airliner, a ship, or a multi-billion-dollar business.  We certainly can perform tests with the full-scale versions of such systems, but the lessons that we learn from full-scale tests often tend to be unnecessarily costly, sometimes even in lives as well as in dollars. 

Appropriately designed tests, with scale-models of large systems, limit dramatically our costs in dollars and eliminate entirely all costs in lives.  These are good things.  Consequently, engineers study a mature body of knowledge that's dedicated to the proper testing of scale-models. 

Don't panic.  I don't intend to teach you the engineering intricacies of scale-model testing.  I want only to share with you the one nugget of wisdom that might have spared me an embarrassing failure during my early years, had I known then that much of what I had learned as a student of engineering applied also to the systems of business.  Here's the nugget: 

A test with a scale-model of a large, physical system is useful only if the test with the scale-model duplicates the physics that govern the performance of the full-scale system.

As Billy Shakespeare might have responded, there's the rub.  The use of the critical-chain model with a single project, among many projects that share resources, is a pilot with a scale-model that fails to duplicate the physics of the full-scale system. 

The results of such a pilot are inconsequential at best, and at times they create a devastating effect.  If by some miracle such a poorly-designed pilot should yield a project that exceeded expectations, the ill-conceived pilot would demonstrate nothing, which might be capable of melting away anyone's resistance to a very useful change.  This would be the inconsequential outcome. 

The devastating outcome might be this:  Should the corresponding project disappoint, as is the case with nearly every misguided pilot, the ill-conceived pilot could create among influential individuals a long-lasting perception that the critical-chain model shouldn't be used by the business.  As a consequence, the business could become blocked from adopting a very lucrative management-process for several generations.  If this were to happen, the financial damage would equal all the additional profits that the business might have earned as a result of using the more effective management-process. 

If you do the math, you'll see that there's considerably more than mere lunch-money at risk. 

 
 
The Right Pilot
 
You can take advantage of all the benefits offered by pilots, even if most of the projects of your business do share the same resources.  The key is to identify the right organization that can serve as a control-volume, as one client calls it, and with which your people can conduct a pilot that does duplicate the right physics on a small scale. 
 
To identify a useful control-volume, look for one or two departments around which you can draw a boundary that satisfies the following conditions:
  1. The work that comes into your control-volume can be modeled as projects for the resources within the control-volume.
  2. No resources within the control-volume are required to contribute substantively (except for very brief periods) to projects external to the control-volume. 
Once you've earmarked the right organization as your control-volume, you have a scale-model of your much larger, multi-project system.  With it, your people can do much more than perform a proper pilot.  Without risk to your  business, which might employ many thousands, your team can learn on a small scale how to deploy effectively a very powerful solution, which then you and they can scale confidently for use with your full operation. 
 
If your projects share resources, that's the right pilot for you!
 

top

 

--- END ---