In this chapter, I will emphasize the importance of decentralized control. I push you in this direction because most product development organizations are moving in the opposite direction, towards centralization.
This does not mean that 100 percent decentralization is the solution. The military skillfully
avoids the simplistic idea that they must choose between 100 percent centralized and 100 percent decentralized approaches. Instead, they focus on decentralized execution supported by centralized coordination.
Let us start by looking at a number of principles that should convince you why it is useful to combine the advantages of decentralization and centralization.
D1: The Second Perishability Principle: Decentralize control for problems and opportunities that age poorly.
Certain problems and opportunities are perishable. By this, I mean that they are best dealt with quickly. An example of a problem that ages poorly is a fire. It is best to put out fires quickly, when they are small, because small fires can turn into big fires.
In contrast, some other types of problems are inherently self-limiting. For example, if you invest
$1,000 in a bad stock, and it loses 90 percent of its value, you needn’t worry that this magnitude of loss will continue. Even if the stock continues its decline, you can lose no more than $100. Our control strategy should focus on reacting most quickly to problems that age poorly.
Opportunities may also be perishable. For example, in many markets, the first entrant sets the standard for the rest of the industry. IBM defined the standards for 8-inch and 51/4-inch floppy disks.
However, IBM was late to introduce their next standard, the 4-inch floppy disk. Instead, Sony and HP beat them by introducing the 31/2-inch floppy disk, and the 4-inch floppy disk has been forgotten.
How can we quickly solve problems that age poorly? How can we seize opportunities that are fleeting? We need to decentralize control. And decentralizing control does not simply mean decentralizing responsibility. We need to decentralize the authority to act, and pre-position sufficient resources to make this action meaningful.
Think of it like fighting fires. We put fire extinguishers where fires are likely to break out, and we train people to use them. People do not have to request permission to put out a fire, nor do they have to run to the corporate fire extinguisher storeroom to sign out a fire extinguisher.
D2: The Scale Principle: Centralize control for problems that are infrequent, large, or that have significant economies of scale.
Not all problems and opportunities are perishable. There is another class of problems and opportunities that truly benefit from large-scale responses. Big fires are best handled by fire trucks, not by individuals with garden hoses and fire extinguishers. When we encounter problems that require mass, we need a method to bring sufficient mass to bear. We do not park a tiny fire truck in front of every home. Instead, we centralize this resource by providing a few big fire trucks that we can move to the location of serious fires.
Of course, centralizing resources increases response time. How do we ensure that fire trucks can reach a rapidly growing fire quickly? We recognize that fire trucks have a high cost of delay, and we give them priority over other traffic. We would need many more fire trucks if they traveled our streets at the same speed as regular vehicles.
It is appropriate to use centralized resources in similar ways in product development. Rather than putting a regulatory affairs expert on every program, we centralize this resource. By pooling the variable demand of many projects, as explained in Principle F29, we can provide faster response
times to all projects. Moreover, we get the added benefit of consistency between projects.
Whenever we have infrequent but large excursions in demand, we use centralized resources.
This is even more attractive if these central resources have scale economies.
For example, purchasing agents have specialized expertise and vendor relationships. Managed properly, a centralized purchasing organization can outperform the same resources deployed to individual teams. Too often, it does not, because it is measured on the wrong criteria: purchasing efficiency instead of response time.
In contrast, frequent, small-excursion, low-variability demand, with limited scale economies, should be serviced with decentralized resources.
D3: The Principle of Layered Control: Adapt the control approach to emerging information about the problem.
What happens when you are not really sure whether the approach to a problem should be centralized or decentralized? There are two basic possible approaches, depending on your ability to judge the severity of the problem at the time of its arrival.
The first approach is triage. This approach is used in hospitals and for mass casualties. When medical resources are insufficient to treat everyone, we try to provide the maximum benefit to the maximum number of people. We do this by making tough sorting decisions at the intake point. Some of the wounded will die no matter what we do. They get no resources. Some of the wounded will live no matter what we do. They get no resources. Instead, scarce resources are concentrated on the third group of wounded, those for whom medical care determines whether they will survive. Triage works whenever we have sufficient information to make good judgments at the intake point.
We must use a different approach when we cannot judge the severity of a problem when it first arrives. Computer operating systems deal with such problems and provide us with useful methods.
In a computer operating system, we may not know which job will take the most time to run.
Under such conditions, we use the round-robin approach discussed in Principle F19. We allocate a quantum of time to each job. Any job that is not completed at the end of its quantum is put back into the work queue. This guarantees that short jobs will not be blocked by long jobs, even when we have no idea which job is shortest.
Sometimes operating systems divide jobs into priority classes and service the jobs in order of priority. However, this creates a risk that a job in a low-priority class may never get resources. How do we prevent this from happening? We automatically escalate the priority of a job when it has waited too long in queue.
We can use the same approach for problem solving. Problems that are not resolved within a certain time are moved to a higher level. This works because most small problems turn into medium-size problems on the way to becoming big problems. If we establish clear out-of-bounds conditions, we can quickly escalate problems that are too severe for decentralized resources. A good escalation process prevents us from elevating all problems to centralized resources. At the same time, it prevents important problems from getting stuck at low levels in the organization.
We can even combine triage and escalation, as shown in Figure 9-1. A quick triage can set priorities for most jobs. These jobs can be serviced in prioritized queues. Jobs that cannot be classified can start in the lowest-priority queue. If they remain in this queue too long, they can be escalated to a higher-priority queue.
D4: The Opportunistic Principle: Adjust the plan for unplanned obstacles and opportunities.
In Principle FF5, we made a distinction between static goals and dynamic goals. We focus on conformance when we have static goals. When we have dynamic goals, we continuously adapt. We try to make the best possible choices based on emerging information.
Attrition warfare emphasizes conformance, while maneuver warfare emphasizes adaptation. In fact, a classic military saying observes that, “No war plan survives the first shot of battle.”
The modern military does not create plans for the purpose of measuring conformance; they plan as a tool for maintaining alignment. The plan forms a baseline that synchronizes complex changes. If we decide to move up the invasion by 1 day, the thousands of activities required to make this happen, each of which may have different lead times, can all be quickly realigned.
Opportunism also adds enormous value in product development. As we progress, we may discover that a feature is valued by 10 times fewer customers and that it will require 10 times more effort to execute. A good process will recognize that this feature no longer makes economic sense.
Rather than battering down this obstacle, we will bypass it.
Similarly, we may discover a feature is easier to implement and more highly valued than we originally thought. In such circumstances, we should consider exceeding our original goal, even if it requires jettisoning other marginal requirements. It is quite difficult to do this in today’s conformance-oriented processes.
D5: The Principle of Virtual Centralization: Be able to quickly reorganize decentralized resources to create centralized power.
In some cases, it is not cost-effective to leave centralized resources idle, while waiting for infrequent
large demands. To avoid inefficiency, we often use these resources for background activities and mobilize them as needed to create the centralized power needed to deal with a big problem. If we do this quickly enough, we can get the combined benefits of having both centralized and decentralized resources.
For example, navy ships use this approach to fight fires, as discussed in Principle F28. Fires occur infrequently, but when they occur, they are very dangerous and must be fought quickly. It is not cost-effective to have specialized firefighters who do nothing when there is no fire to fight.
Instead, we train all sailors to fight fires, but these sailors do other jobs until a fire breaks out.
Then, they are formed into damage control parties, bringing substantial resources to bear on the fire.
This entire system is planned in advance. Equipment is located in damage control lockers, sailors are trained in firefighting schools, and they are constantly drilled on their responsibilities. We get the effect of a large, centralized resource without the cost.
Civilian firefighting organizations also create virtual centralized capacity. Fire departments in adjacent communities provide mutual support. This permits a community to cope with infrequent large fires without having a large fire department.
We can also use this approach in product development. Some development organizations use
“tiger teams” that are assembled from experienced and highly productive people. These teams are brought to bear when a program gets in unexpected and severe trouble. Yet, when there is no crisis, these team members do not sit idle; they work at their normal day jobs. Such resources can be brought to bear quite quickly if this is planned in advance.
D6: The Inefficiency Principle: The inefficiency of decentralization can cost less than the value of faster response time.
In many cases, we are willing to pay the price of inefficient, decentralized resources simply to provide responsiveness. We do this when response time is very valuable. For example, most people trained to do CPR will never use this skill. Why do we invest in training them? For response time.
The average response time of the Emergency Medical System is about 9 minutes, but brain damage occurs when a person has no blood flow for 4 to 6 minutes. Even when CPR does not restart the heart, it can provide enough blood flow to improve outcomes.
So don’t assume the goal of efficiency should be given higher priority than response time.
Instead, use your economic framework to make this choice.