Halcyon Technologies, a New Zealand-based, family-owned company, designed and manufactured premium commercial heating and cooling solutions. The company was founded 47 years ago by Sir Cyril Montgomery, and his son, Windsor, took over the role of managing director from him in 1998. Recently, the company was preparing to implement CCPM and scheduling, and approached Catalyst Consulting for support.
The planning team at Halcyon Technologies, led by planning manager, Gus Callaway, had a meeting with the on-site consultants shortly after their arrival. One of the consultants, Reginald Meadows, asked the planning team to go over the project plans with the consultants.
“Gus, if you wouldn’t mind, could you please talk us through your project plans? I expect you probably have a few different ones, probably four or five, and that’s fine. We can go through each of them.”
“A few?” Gus gasped. “We have 150 different project plans!”
“Sorry? 150? You are talking about project plans, right?” Reginald stared pointedly at Gus.
“Well, you see, we have 150 different designs of heaters, heat pumps, and air conditioning systems, and our customers range from small gift stores, right through to some of our country’s largest retailers.”
“Yes, I understand that,” Reginald replied. “But, what I am—”
“So, because we have 150 different designs, it means we need to have 150 different project plans.”
Reginald sat there for a moment. “Let’s see your project plans.”
Gus stood up, and walked over to a large shelving unit at the back of the meeting room. There, spread across six shelves, Reginald could see what appeared to be many, many grey ring binders, with the spine of each of the ring binders revealing the name of a specific project plan. The ring binders were categorised from A to Z.
After completing the exhausting task of looking through most of the project plans, it was clear to Reginald as to why Halcyon Technologies, and in particular the planning team, were having a hard time.
“The problem you have, Gus, is that your handover descriptions are action-based. You need to genericise the handovers, so that one project plan can be applied to multiple designs. You don’t need to have a project plan for each one of your designs. If you genericise your handovers, by rewriting actions as effects, you will have a greater understanding of what ‘done’ looks like and can apply that understanding to multiple pieces of equipment, rationalising the number of project plans you have dramatically.”
“I don’t think I understand,” Gus replied. “How are we supposed to plan, and keep track of each heater, heat pump, and air conditioning system if we don’t have a plan for each of them? That makes no sense.”
“Think about it,” Reginald said. “There are three types of appliances you design and manufacture, right?”
“Yes, that’s right. Heaters, heat pumps, and—”
“Air conditioning systems, right. So, my question, really, is how different is it to design and manufacture, let’s say, an air conditioning system for a small gift store, in comparison to a large retailer? What’s preventing you from having a generic plan for heaters, a generic plan for heat pumps, and a generic plan for air conditioning systems? In other words, you would have one project plan for each type of appliance.”
Gus sat there, clicking his pen repeatedly. There is no way that would work, he thought to himself. He sighed quietly. “OK, what do you suggest we do?”
Under the direction of Reginald, the planning and project teams at Halcyon Technologies worked together, meticulously going through each of the 150 ring binders, and genericising the handover descriptions.
When the handover descriptions had been genericised, they could clearly see making one heater was like making another heater, making one heat pump was like making another heat pump, and making one air conditioning system was like making another air conditioning system. It all made sense now.
When the handovers were standardised, there were not that many plans. In fact, Halcyon Technologies went from 150 project plans, each one stored in its own ring binder, to only eight project plans! Of these eight plans, several had the same base plan, with optional sections creating the extra variety.
All remaining variation in the execution of the plans could be accounted for by applying simple scale factor to the timing.
At the debrief meeting the following day, Gus thanked Reginald and acknowledged his initial scepticism.
“I couldn’t believe it. I honestly thought you were crazy when you said we didn’t need a project plan for each of our designs. However, what quickly became clear was that all the things we perceived as being material to the distinction between the different plans were not actually material to each plan at all.”
“Indeed,” Reginald replied. “And, well done for humouring us. I could tell you didn’t think it was going to work, but you went along anyway and ended up being pleasantly surprised at the outcome.”
“It’s incredible,” Gus exclaimed. “In just a couple of days, we have gone from having 150 project plans stored in ring binders to having eight project plans that we can view and update quickly.”
“So Gus, what do you think you have learned from this process? Does anything stand out for you?”
Gus thought for a moment, then responded. “Well, what this has taught me is that if you use an effect-based handover, you realise what is the same between plans, rather than focusing on what is different. Effect-based handovers enable us to standardise a quite varied set of action plans.”
“Yes,” Reginald confirmed. “Because, as soon as you start talking about actions or activities, plans often start to diverge rapidly. And therein lies the risk. By genericising and using effect-based descriptions like you have done, the plan commonalities come forth and enable a more system wide approach to managing operations, irrespective of how many designs you have or products you manufacture.”