Case Study: Strategy That Needed New Technology

Whenever technology is needed, many people believe that we must always want the latest inventions because our founder started out in the American space programme. That is not true. NASA uses tried and true technology where possible and only wants leading edge inventions where necessary.

Sometimes it’s necessary, and that is as true for business as it is for space exploration.


Our client’s industry faced a devilish squeeze. The cost of raw materials was going up. The price the market was willing to pay for finished products refused to go up, and in some product lines was under pressure to go down. The business was already aggressive about capturing and repurposing as many byproducts as possible that would otherwise become waste. The workforce had been cut back as much as anyone dared. A moratorium had been imposed prohibiting any new projects that were not directly essential for current operations.

There were still large inefficiencies to correct in the business, but even doing that would not be enough to put finances in the black. Red ink was gushing and the parent company group was losing patience with propping up the business.

Anticipated competition loomed on the horizon from low cost, low end imports from China. That looked like oncoming doom.

Desired Strategy and Barriers to Implementation

At a strategic level, management wanted to be able to make more sophisticated types of products with higher reliability. These products would command higher prices from approximately the same costs for materials and low end imports could not compete with them.

Researchers working with PhD specialists in the business had come up with a plan to evaluate product quality in realtime. However, it would create enormous long-running floods of data to be correlated and analysed on the fly. Over the course of more than a decade, the business tried three times to build software that could cope with that task. Each attempt failed so badly that it was useless. Highest on the list of reasons for the failures was failure by information technologists to fully understand the software’s purpose and the technical hurdles it had to jump.

It was such a leap ahead of existing technology that in all those years, no one else in the industry had devised anything resembling what the business wanted to build. It seemed like science fiction.


Our founder was initially engaged by the business for another purpose. When she met with the PhD specialists about that project, they saw an opportunity. They got her redirected to look at trying again for the software they envisioned.

Initial work was entirely to develop enough understanding of what needed to be achieved, the sources from which disparate data streams must be pulled and correlated, and the platforms and tools available.

Some of the platforms and tools were simply not capable of doing what was needed from them. With our guidance, specifications were adjusted. The foundation of the system would still be commercially available standard packages. It would unavoidably cost somewhat more than what the business’ original specification called for, but the original would not have been able to meet project needs. A project plan, estimate and business case were drawn up and taken to management.

Due to cost limiting measures in place company-wide, the proposal needed approval considerably above the management level that would normally approve or disapprove such projects.

The business case was so strong that an exemption from the moratorium on new projects was granted and funding was allocated.

Success Factor:  The business recognised an unexpected opportunity and changed its plan instead of doggedly carrying on with the original. Both parties genuinely listened to each other—us to get a grip on what was needed, and the business to step outside its earlier thinking about specific underlying technologies and their costs.


Although commercial confidentiality prohibits us from identifying the client or its industry, we designed and built the central engine for the new system—the cornerstone that had eluded technologists for so many years. We handed it over to the company’s leading information technology specialist for the platform we had used.

He was steeped in standard programming practices with higher overhead and lower throughput. We are steeped in complex realtime and near-realtime systems. Our implementation was based on deep comprehension of the way operating systems, database engines and data communications work. He took some time to understand our approach which seemed baffling and counterintuitive at first.

When the business fired it all up in live production, on the first runs it only kept up for about 20 minutes and then gradually slowed to a halt. We sent one email message explaining where a research programmer in the business had probably gone astray with an essential data feed, and that was enough to make the system keep pace with production easily.

Outcome:  A few years after the project…

  • The system we built is now fully hooked into production, product grading, quality assurance, etc.
  • The dreaded low end Chinese imports hit the market. The system helped fend off this threat until market conditions became more normal, with a more reasonable relationship between material costs and product prices—the system was a key part of saving the business from going under.
  • No other business in the industry has anything like the system, so it provides a large competitive advantage.
  • The business now focuses on making sophisticated high end products with better profit margins. Many quality-related tasks that used to be done manually are now automatic with greater reliability and standardisation, allowing the workforce to concentrate on the many tasks that must be done by people.
  • All of this combines to deliver better value to customers for higher satisfaction, and a healthier bottom line for the business.

For a downloadable PDF of this case study, click here.