by Sandy Ludington
April 21, 2026
A damaged bearing surface
An ounce of prevention is better than a pound of cure. It’s also usually better than the pain of living with the disease.
We once worked with Joe, a senior manager at a very special facility designed to complete integrated testing of a ship’s propulsion systems. The facility came about through some complex interactions of different parts of the organization and, as a result, power for the facility came from a mix of new and existing equipment, procured through different means. The facility depended on a dedicated gas turbine power plant and there was one part of it that Joe particularly did not like.
The gas turbine relied on a compressor in its fuel supply line, to ensure the turbine operated with the appropriate inlet pressure. It wasn’t that Joe disliked the compressor exactly. He disliked the way it was designed. Joe had joined the project after much of the initial engineering and procurement had already begun. As the facility came together and Joe stood up his team, he was on the receiving end of a compressor design he had not been able to influence. While it came from a company experienced in designing and delivering gas compressors for many varied applications, Joe was nervous about the degree of similarity used in defining requirements for his compressor. The vendor built Joe’s compressor based on borrowed requirements from others they had built (for oil field service), without any evidence they had evaluated those requirements for Joe’s power plant and its operating characteristics. Dissatisfied with the similarity argument, but with a stressed team and thousands (literally, many thousands) of requirements to manage in the integrated test facility, Joe moved on to other problems.
Once the plant was up and running, the compressor performed as expected. Joe didn’t have any evidence to prove that the compressor was a bad design, but he didn’t know what he didn’t know, and he remained uneasy about it. One cold morning in January the plant started up. The gas compressor’s oil pump drew cold, viscous oil from the sump, and pushed it through to the bearings as the compressor began to spin. But the high viscosity of the oil and the long distance to the furthest bearing meant that this most remote bearing saw little oil flow. Shortly after starting, the bearings seized, the compressor’s shaft twisted violently, and the gas turbine tripped off when the fuel supply was cut off.
The power plant, and the integrated test program it relied on, were now shut down. All progress in the facility now waited on a component that should have been simple and reliable.
Joe’s team went to work. They didn’t call the vendor right away – they had no trust in the vendor’s ability to resolve a design issue. Instead they started questioning every assumption. How much flow did the bearings actually need? How fast did heat load ramp up when the system started? Did it depend on how they operated the system? How did oil viscosity change with temperature? What were the temperatures they could reasonably expect throughout the year?
Ultimately Joe approached the problem as a product development process. He created a set of requirements, dependent on validated assumptions and sensitive to his system’s operations. His team anticipated secondary and tertiary effects of their proposed solutions. They performed tests to see how the system responded, analyses to validate their proposed solutions, and considered failures and their effects.
Most organizations find it difficult to think like Joe. Even when they do have leaders thinking like Joe, they have legacy equipment, embedded processes, or habits which prevent them from realizing the best principles of a high reliability organization. Novellum Partners brings lessons and tools from many industries to inject Joe’s thinking – sensitivity to operations, mastery of complexity, and suspicion of assumed similarity – into actual day-to-day performance. Joe likely learned a powerful lesson – his instincts were right and the risk turned out to be real. Don’t wait until a failure brings down your project. Strengthen your processes, test their implementation, and create the reinforcement mechanisms that prevent problems like Joe’s before they occur.