Thermostatic Control

    There is a popular misunderstanding that the thermostatic control paradigm is how projects are managed in the real world. This starts with the misunderstanding of how "Program Planning and Controls" are applied on projects and how the notion of control is defined in places like PMBOK.
    NO WHERE in PMBOK and I mean NO WHERE does it define that a Thermostatic Control process should be used. On the other side, the Thermostatic Control process is actually not defined - it is used as the basis of criticism without a context, a domain, or a definition. This is one of those redherring approaches so popular these days. What PMBOK does say is that schedule control is concerned with:

• Determining the current status of the project schedule - where are we along the path to completion?
• Influencing the factors that create schedule changes - what's driving change, what's the impact of these changes, are these changes beneficial to the project, if not, how can we protect the project from these undesirable changes?
• Determining that the project schedule has changed - what is an acceptable change, what is an unacceptable change? How can we tell the difference between the two?
• Managing the actual changes as they occur - managing change does not mean restricting change. It means making good decisions about accepting change, its impact on the schedule and the beneficial outcomes from change on the delivered value from the project

    So, as a project manager would you say "these are NOT in my job description?" PMBOK goes on to say things about what are the inputs, techniques, and outputs of the schedule control processes.
    Before that is answered, what is the concept of "control" in general. As a recovering control systems engineer (missile, torpedo, and submarine guidance controls, fault tolerant turbine and nuclear power plant controls and other little gadgets like that), the notion of control ranges from simple (and simple minded) to complex and to very complex.
    There are two basic classes of controls - open loop and closed loop. The closed loop control has feedback, that can be linear or non-linear. One simple example is the home heating control for a furnace.

• Too cold in the room, turn on the furnace and measure the temperature rise
• When the measured temperature reaches the set point, turn off the furnace
• Repeat forever

    There are some minor details like the error band around the set point, the hold or dwell time on the set point, so the furnace doesn't "hunt," the delay time so the furnace doesn't constantly cycle. But that's the general theory.
    With the closed loop controls, feedback is the primary data element, along with the "set point" (the drive) and the "command" (the output). One parameter of these simple controls is the "sample rate." The furnace control is usually a continuous loop - an analog device. But digital devices are used as well. They implement some sort of digital algorithm - read computer program - that samples the environment and decides what to change in that environment. This "decision" process is itself an algorithm - the control algorithm The cruise control on your car is a digital controller that sense the speed, the "set point," the torque on the engine (shifting the transmission) and other sensor inputs. It then "commands" the throttle to "hold the set point speed."
    The sample rate is relatively fast on my Honda Civic SI. It can hold the set point within 1 MPH over a variety of conditions. Our GMC Suburban had a poor cruise control that would get confused in the mountains and put itself off line when heavy engine loads occurred.

Project Management Control Systems
    Projects are human, technical, and organization activities that are subject to "controls." In the absence of some kind of control a project would be a an open loop free for all. But are projects controlled by the simple minded thermostatic control loop? I say simple minded because those conjecturing that thermostatic controls don't work haven't described the control loop:

• Sample rate
• Loop response function
• Linear or non-linear characteristics of the sensors, control loop algorithms, output actuators and the response function of the "system under control."
• Is there feed forward as well as feed back loops?
• Are these loops adaptive, self tuning, operational in the presence of noise, spike disruptions, out of band transits?

    These authors don't say how control loops work. But that's to be expected, since it much easier to take that approach - "Thermostatic control don't work," than to actually understand the principles of control in general and project controls specifically. I guess the use of "magic beans" to manage projects can take you a long way in the project management seminar business.
    The concept "sample rate" is the core concept of project management controls:

• eXtreme Programming (XP) samples the project status and makes steering commands every      two weeks.
• The Rocky Flats Environmental Technology Site (www.rfets.gov) project management control      systems gathered sensor data and made steering commands every day. The Plan of the Day and the Plan of the Week were the basis.
• Scrum's sample rate is a month and a week.
• The conventional water fall - the redherring of agile and feral project managers samples on too long an interval

Remember from a past post...

How Long Are You Willing To Wait Before You Discover You Are Late?

Make the sampling rate half or less than that. But not too fast since that can create digital noise as well and the loop will be overcontrolled.

So Where Do the Proponents of Thermostatic Control as an Obsolete Theory Go Wrong?
    The core missing element in the design of any control system is to first characterize the "system under control." To not do this would be like taking your furnace control and attaching it to the F-35 Strike Fighter's fuel throttle control loop to maintain supersonic cruise. A really dumb idea. Remember another previous post

Don't do stupid things on purpose

    Using the wrong control algorithm is doing stupid things on purpose. Just like writing the schedule and not updating it, like calculating the critical path and do redoing it every week with "actuals to date." Or like defining the requirements and assuming they're not going to change. Or not measuring the "capacity for work," and assuming everyone is working at 90%. Doing stupid things on purpose is bad project management.

Sample Rates, Control Response, and Control Algorithms
    Without getting into the details of project controls, the project manager needs the following to make decisions. These decisions may not result in success. Only those with "magic beans" are selling success.

• What is the business rhythm for the project? On our project this is actually called the "Business Rhythms Meeting." In our case it's once a      week, mid week.
• What is the response time of the "system under control?" How fast can we turn the ship? An hour, a day, a week, a month? Depends on the culture, work environment, regulatory environment, safety consideration, management style. Tons of explicit and tacit variables.
• What is the actual control algorithm? Linear input, process output.
  • "We're driving too fast, slow down to the speed limit."
  • "We're driving into the ditch, move the car back into the proper lane, but no  further or you'll crash into oncoming traffic."
  • "We're landing hot on the carrier, bring the nose up, but not too much, slow  down with the spoilers, but not too much, add a little power to keep on  the bubble, but not too much, add a little left rudder as we pass the  island wake, but not too much, ..., ..., ... and catch the number 3  wire."
• How noisy is the input data and the output commands?
  • The autosteering on a boat has the dynamics of the hull in the loop.
  • Steering your car automatically includes the dynamics of the mechanics of the car.  My Honda SI is ultra sensitive. It took a few weeks to drive a speed and  not drift while commuting. Driving the Suburban is a point and watch  process. With summer tires the Honda is "twitchy" - you  gotta pay attention.

    Finally the notion that feedback is the cause poor control is misinformed. The processing of the feedback – how it is used in the algorithm is the first critical item. Second is that most modern controllers, other than simple furnace controls use “feed forward” control algorithms. These anticipatory commends keep airplanes on course, trains running at optimal fuel consumption levels, pace makers keeping their hosts alive. It’s the anticipatory aspects of a control system that make it applicable to project management.
    Driving in the rear view mirror – using a simple minded control loop to manage a complex system with built in and external variances is “doing stupid things on purpose.”

Back To Projects
    To claim the project control system of today "sorta" work is of course nonsense. There are spectacular failures - Big Dig, IRS system replacement. But these critics never seem to provide examples of working projects, the ratio of working to failed, or any sort of analysis as to why a specific project failed and the casual connection with the project control system. Too much work, selling "magic beans" is easier.
    I was witness to the last launch of Titan. It was scheduled to go from Vandenberg at 11:05 October 19, 2005. There was a glitch a few minutes before launch and a hold caused the "Planned" launch to slip. The 2nd stage was burned longer to make up the time, because there was a multi-billion $ National Reconnaissance Office payload that needed to be on orbit at a specific time.
    Now this is an extreme I know, but the project controls algorithm to get Titan off is adaptive, incremental, iterative, based in EAI-748B Earned Value, risk adjusted for every work package from design to flight, and managed by profession project, program, and planning and controls engineers - and most importantly tuned for the rhythm of launch vehicle operations.
    Scrum, XP, DSDM, Prince2, RUP and other project management methods also have natural business rhythms, different rhythms for different problems. Pick the right one, don't pick the wrong one. Don't do stupid things on purpose.

The Final Test Question
    What ever project control algorithm is used, no matter how cock-a-mammy it might be or how field proven it is for the business rhythm it needs to answer the following:

1. How much will this project cost in the end?
2. When will we be done?
3. What does done look like when we get there?
4. How many and of what types of people, materials, resources, and facilities do we need?
5. How do these people, materials, resources, and facilities need to interact with each other?
6. What risks to our success exist and what mitigations are we going to take against them?
7. How will we recognize that the products or services resulting from the project are acceptable      to the "customer" in whatever way you define the customer?

    So conjecturing the thermostatic algorithm is ineffectual, needs to be replaced with the answers to those questions in some definitive way in order to have project managers consider them credible. Otherwise, you're still in the "magic beans" business, not the project management business.