During the last long-haul flight I was on, I re-watched ‘Apollo 13’ (the one with Tom Hanks as Jim Lovell). Perhaps not the best choice as I was hurtling through the sky at 500 mph in a tin-can myself, but there’s something to be said for the thrill. If you haven’t seen the film, it's based on real-life events and it’s gripping.
For context, here’s a quick summary of the plot:
April 13, 1970, 238,855 miles from Earth, an on-board explosion rips apart one oxygen tank and damages another. In space, Commander Jim Lovell, and back at Houston’s Mission Control, Flight Director Gene Kranz (played by Ed Harris), find themselves in a desperate battle against time to save the astronaut’s lives. They literally rip up their operations manuals to abort the planned moon landing, preserve the remaining power and oxygen, build a filter from scratch to reduce the poisonous build-up of carbon dioxide, and find a way to use the lunar module (designed for a 124 mile round-trip to the moon’s surface) to ‘lifeboat’ all three astronauts back to Earth.
An exposed wire, the result of tiny manufacturing and testing errors before flight, caused a short-circuit, which led to the explosion. On airplanes and rockets, these rare and tiny system errors can be catastrophic.
In your business, system errors are likely to show up in the form of work stoppages, excess scrap, poor customer service, excessive product returns, late deliveries, high levels of frustration among employees, poor financial results, and any other number of unwanted outcomes.
The lesson we can all draw from Apollo 13 is that one small flaw early in the process is likely to be multiplied by other small flaws in downstream systems. Minor, sometimes almost undetectable, flaws in your systems can and will create major problems for your end results.
This week I want to address the value of documenting your systems and show you how to get started. This is how an operations manual can save your business (and your life).
A well-designed business will always have an operations manual which has been intentionally designed and kept up-to-date. And the operations manual doesn’t have to be in a ringed binder. Nowadays, it’s just as likely to be managed through task management software like Asana. An operations manual for a well-designed business communicates four things:
- The owner is a systems engineer and the business was built from the ground up with a focus on control and attention to detail, not quick wins.
- There is a Business Development Process in place that includes Innovation, Quantification, and Orchestration.
- Having a Business Development Process means the entire company is continually involved in building systems. Employees go to work on the business as well as in it. In other words, they think systemically about the business, helping them build and document systems that work.
- The culture of the company is likely to have a high-level of internal communication with an emphasis on employee training and personal development.
A poorly-designed business may also have an operations manual. But it won’t be up-to-date and it’s probable that the company will be suffering financially. This is the system equivalent of garbage-in, garbage-out: A business full of action plans that don’t produce great business results are just a waste of time. Leadership is likely to be short-sighted without a clear vision and will possibly make ill-conceived attempts at micromanaging the day-to-day work. There are likely to be high levels of frustration for both the owner and the employees and a general culture of disengagement.
The difference between a well-designed business and a poorly-designed business is having an Operations Manual that lives within a larger Business Development Process.
It’s the same way of thinking about systems that allowed Jim Lovell and Gene Kranz to respond quickly in a crisis, rip up their operations manuals, and, from scratch, build new systems that would save the astronaut’s lives.
The Business Development Process is dynamic, simply because the world, moving as it does, will not tolerate a stationary object. The Business Development Process is that which enables you to preempt the world's changes. It hopefully precedes them, anticipates them, and, if not, at least is infinitely flexible in relationship to them. In short, Innovation, Quantification, and Orchestration are the backbone of every extraordinary business. They are the essence of your Business Development Process.—Michael Gerber, The E-Myth Revisited
The Business Development Process in Action
Building systems and the resulting Operations Manual is Innovation in Action. You’re using the system itself as a way to refine what is possible. It’s a legitimate use of trial and error because you're creating these systems with intention and refining them until they produce the results you want. Innovation isn’t just the invention of something new, it also includes creating new and improved ways of doing the things you already do—new and improved systems.
This is where the Transforming Frustrations process outlined in last week’s article comes into play. It’s a system that allows you to innovate, solving a current frustration in your business, both quantifying the impact of the current problem and anticipating the results your new system will give you. This is Quantification in Action. Measuring where you’ve come from and setting future goals. Any gap between current performance and the goal is where you need to refine your system for improvement.
The final part of your Business Development process is Orchestration in Action. Documenting your system and training your people so the result can be consistently repeated, time after time. This is what your customers want and here’s how it’s done:
- Specify the result and the name of the system
- Diagram the system
- Write system steps in clearly-stated benchmarks
- Assign accountabilities
- Determine the timing
- Identify required resources
- Determine how you will quantify the system
- Establish standards
- Document the system
This doesn’t need to be an entirely linear process. The following diagram gives you an idea of how to flow-chart the process.
Looking at the picture above, we can see that it doesn’t matter in which order you do the steps of 3. Describe Benchmarks, 4. Assign Accountabilities, and 5. Determine Timing, as long as they’re done after you follow 1. Specify Result and Name System and 2. Diagram System. These three steps—Describe Benchmarks, Assign Accountabilities, and Determine Timing— are independent of one another, but they are all dependent on 2. Diagram the System. This image shows you the flow in which you document your system and also shows that you can only 8. Establish Standards after you’ve 7. Determine Quantification Method (step eight is dependent on step seven). You can only document the system after everything else has been done.
Once you’ve documented the system the work of implementation begins. The act of carrying that system out of testing and revising until it accomplishes the desired result—that’s where the real working on your business happens.
And ultimately, your systems are only as good as your people. I work in a systems-driven business here at EMyth. How do I feel about the systems I use inside EMyth?
I admit I’m slightly older than most of my colleagues and as they like to remind me, I’m mildly technology-challenged. Even so, I use systems all day, every day. I know three things about the systems that are part of my life at EMyth:
- Like Jim Lovell and Gene Kranz, I believe in the mission. At EMyth that’s about helping business owners create a life and business they love leading.
- If my daily routine involves systems that don’t work, I have a responsibility to fix them.
- If the systems do work, they give me a framework within which I can do my best work, and in doing so they set me free. That’s personal growth.
What we've experienced in our work with small businesses is that, as the Business Development Process becomes an integral part of the business, it also becomes an integral part of communication between the participants. It becomes not only a way of thinking and a way of doing but a way of being as well. You might say that, while going to work on the business, people begin to realize that it is a powerful metaphor for going to work on their lives… —Michael Gerber, The E-Myth Revisited
Finally, let’s quickly review where we’ve got to in these articles so far:
- You’re the systems engineer in your business.
- Financial freedom starts by building systems that give you control first, and then growth.
- The Business Development Cycle of Innovation, Quantification, and Orchestration is how you build systems that work.
- Working on your business, not in your business, means addressing frustrations at the root cause, not at the symptom level. Thinking systemically will create a business with a healthy culture and strong foundations.
- The work involved in building an Operations Manual (or task management system) gives you the operational flexibility to cope with inevitable change. It can save your business.
If this article inspired you to think differently about systems in your business, let me know. I’ll reply directly to your comments and I look forward to hearing how you are getting on and the results you are seeing.
In the next article in this series, we’re covering the strategic design of systems and in our final article, I’ll give you a blueprint for doing it right the first-time.