Only As Fast As The Slowest Process

by Rick Carlton

Have you ever experienced an unidentifiable ‘slowness’ in your company’s business efficiency? I don’t mean a corporate ‘bad hair day’ kind of problem; but a serious sense that something is wrong deep in the bowels of your operation? Of course you have. As a matter of fact, anyone who has managed or owned a business has; but then, the next and most obvious question becomes. what do you think it might be? Since I have gone to the Rodeo once or twice myself, and in order to provide a short and sweet solution to your conundrum I, therefore offer the following hoary hypothesis; ‘a chain is only as strong as its weakest link.’

To operate a business efficiently these days (read as making money consistently), one has to continually critique, refine and grease a friction-prone collection of moving intellectual, corporal and virtual business dependencies. If you handle those macro-sized elements correctly most of the time, you at least get a ticket to the next day’s game, after which the evolution begins again. But, if you fail to efficiently deal with them over time, cracks begin to appear in your economic foundation, leading to bad things happening at higher and higher frequencies.

To largely mitigate the potential of these events, however, if one will take the time to consider a business in terms of discrete, yet interlocking processes rather like a chain, as opposed to a singular entity viewed ‘as a thing that makes money,’ you will undoubtedly begin to quickly identify weaknesses that could be better measured, developed or streamlined before trouble hits. This is, in essence, the central theme of Eli Goldratt’s “Theory of Constraints,’ (TOC), and whether your business exists on the basis of hard-goods manufacturing, sales, or intellectual property development, the same value applies; ‘a business can only go as fast as its slowest process.’

From an overall management perspective, how does one begin to break a business down into a series of necessary or non-necessary areas of interest? Consider these initial, but central questions first:

1. Which areas of your business are considered ‘weak’?
2. What people, parts and/or systems will need to be changed to alter and enhance the efficiency of the weak areas?
3. On the other hand, and in the context of item 2, what systems will NOT need to be changed?

Once you have fully developed a general understanding of items 1-3, you can begin to drill into the specifics of each individual area of interest. In this case, I use a four question system, which is entirely congruent with TOC theory:

1. What do you CHANGE?
2. What do you CHANGE TO?
3. How do you CAUSE THE CHANGE?
4. What subsequently motivates CONTINUAL IMPROVEMENT?

In general this overall approach, allows the manager to ‘work a problem’ in real-time while at the same time, creating more and more granularity, since the 7 question series is easily replicated from area to area and process to process.

Although what I have given you in this short treatise is just a taste of what is in store should you begin to consider a ‘Constraints-based’ improvement program, even this primer will be a useful tool going forward, and should allow you to feel somewhat better about how to protect yourself from the effects of typically hidden and malformed business processes. Nonetheless, the concern is real, as is the system, and should you consider more education regarding the TOC methodology, the effort will clearly help create more effective business processes, thereby generating more revenue. After all, that’s why we’re doing this in the first place – right?

To learn more about the ‘Theory Of Constraints’ go to: TOC-ICO

Thaw The Chicken: A Cautionary Tale

by Rick Carlton

It is said, that in the heady days leading up to the first Space Shuttle launch, engineers at Rockwell Aerospace wanted to measure the negative potential of bird strikes on their shiny new spacecraft. In order to produce a test regime that could be quickly measured and replicated, given the numerous sizes and weights of birds the aircraft might encounter in flight, the wonks in Palmdale hit on the novel idea of shooting raw, grocery store chickens at the Enterprise testbed using high-pressure air cannons. Allegedly, the process worked so successfully that the company published a series of technical monographs establishing its essential test requirements, followed by the effort’s detailed metric findings. 

At about the same time, engineers at British Aerospace (BAC) found themselves in the midst of a host of bird-strike incidents resulting in windscreen cracks on the supersonic Concorde. After hearing of Rockwell’s work, and being clever engineers themselves, the BAC bird team decided to adopt and apply Rockwell’s Shuttle test requirements to their own problem, since the American methodology appeared to be generally relevant to their own engineering problem, while also offering a quick way to develop their own high-speed ‘chicken-thumpin’ program. 

Unfortunately, however, things did not go well, since the BAC team experienced different results each time they pumped air through their cannon. After struggling to find a solution, and after relaxing its corporate stiff upper lip, the Brits finally decided to ask for help. Subsequently, a junior engineer was tasked with sending an early electronic BITNET message to the Rockwell team, listing all of the steps involved in the off-shore effort, then closed by suggesting that either the American requirement was in error in someway, or failing that; asking for any remedies they might offer. After a tense wait of several days (engineering is engineering, and competition is competition after all), the young boffin received a short, and entirely Americanized response in turn; ‘Thaw the chicken.’

Now, I can’t prove that any of these events actually happened, but what I do know from my own development experience is that the story of the cautionary ‘chicken-thumpin’ affair is as relevant today, as it may have been in the early 80’s. Why? Because technology has certainly evolved in the last thirty years but, to be frank, engineers haven’t, and well-educated ‘smart people’ rarely enjoy working within the limits of a formal requirement when simply being ‘creative’ is so much more fun. 

If you don’t believe that there’s a concern here, take a look at the qualities of today’s standardized and incremental software methodologies like AGILE, or globally standardized systems development protocols like ISO. The common denominator in both cases is the word ‘standardized’; and why does that word apply specifically and rigidly? Because left alone, engineers will ‘assume a fact’ that doesn’t exist within a requirement’s fine print, in the same way that the BAC team missed Rockwell’s temperature note. In the real world, however, the impact of even a small error, like acknowledging the density difference between an entirely thawed, versus a frozen-as-a-rock roasting hen, frequently costs time and money that a developer doesn’t have. 

In the end of the day, then, if you find yourself facing a go-to-market slowdown you can’t fathom, you might want to go back to the beginning, re-analyze the requirement and initiate a paper simulation to identify the problem before your ‘chicken is entirely cooked.’ Chances are that someone in the development team either didn’t ‘get the memo’ as it were, or more importantly, didn’t think to consider the impact of a small but important ingredient necessary to the entire meal.