Systems Archetype: Shifting the Burden

Description

Shifting the Burden is one of the more common systems archetypes. The problem occurs when a short term fix is applied without regards for possible side effects. The short term fix seems to work, but over time the side effects escalate. In many cases, the capability to apply a long term solution atrophy over time, making it very hard to correct the problem.

Example

A classic Shifting the Burden example in software development is when management tries to apply a brute force solution, like increasing the manpower of a project, or forcing developers to work an excessive amount of overtime, to compensate for low productivity, or poor planning.

The diagram above describes a situation where a project has productivity problems. In other words, it won't make the deadline. The obvious, but often flawed, solution is to add more people to the project.

Most projects measure progress in terms of hours worked. Unless you live on Mars, you are almost certainly familiar with the basic idea: if a job has been estimated to take 100 hours, and someone has worked on it for 80 hours, then there are 20 hours of work left to do. However, this simplistic notion of progress fails to take several important factors into account: the original estimate may be wrong; statistical fluctuations (see The Variance Trap) may reduce the productivity rate; time lost to task switching will be mistakenly counted as "progress"; developers may have to spend time on non-productive tasks, which will also be counted as progress, etc.

The upshot is, management often has no idea what happens to productivity when they increase manpower. Even worse, because the number of hours spent per week does go up when more people is added, and management assumes there is a direct relationship between number of workers and productivity rate, it is very hard for them to notice any side effects. All seems to be well.

Under the surface there may be a witches brew of problems. The first thing that happens when more people are added to a project is that productivity goes down. Think of it like this: the first day on the job, a developer will not be very productive. She will need help though, setting up the development environment, being shown around, taught administrative routines, etc. Someone else, usually several someones, will have to spend time helping her to settle in. Therefore, the net productivity of the project is reduced on the first day. Over time the new developer will learn the ropes, and will gradually become more productive. This does take time though. If the system under development is complex, or just messy, there may be several months, maybe a year, before the new developer is up to speed. Until then, the project will not get the productivity increase the management hoped for.

If too many developers have been added at once, there may be major coordination problems. What should all the new people do? The system under development may not have an infrastructure that allows very many people to work on it efficiently. Management usually finds ways to keep everyone busy anyway, in the interest of "cost efficiency". The result is predictable: the software becomes incredibly messy. Consequently, changes become very hard to implement, and the defect count skyrockets. Even if there was an initial improvement in productivity, it is not sustainable.

Early Warning Symptoms

In software development, an early warning symptom is when developers begin to complain of poor quality, high complexity, or that the software "isn't object oriented" (assuming it is supposed to be). Most developers won't complain. They don't care two figs worth whether the software is a mess, as long as they get paid every month. I'm sad to say, they often do not even know the difference between high and low quality code. The people who will complain are the nerds, the people for whom software development is an all-consuming interest. (You know, the oddballs management often wish they hadn't hired in the first place.)

In general, a situation where workers begin to worry, and management can't understand why, is a sign of Shifting the Burden.

Management Principle

Focus on fundamental solutions! The only reason ever to use a short term solution is to gain time necessary for implementing a fundamental solution.

Of course, the trick is to be able to distinguish fundamental and short term solutions from each other. This can be difficult, but effective tools for doing that, such as the TOC Thinking Tools, do exist. All management has to do is learn to use them, and apply them. (There are no miracle cures, of course. However, I do believe that effects have causes. Therefore, using methods for reasoning about cause and effect is very useful.)

Another thing management can do is to just listen. Keep ears and minds open. Very often there are people in the organization who will recognize a false fix for what it is, and who are able to predict the long term effects very accurately.

The problem is accerbated by measuring the wrong thing, as we in the software development business are especially prone to do. Measuring the wrong thing blinds us to what is really going on, and makes it hard to take effective action. Most managers, project managers, middle management, and upper management, focus on measuring effort (hours worked, lines of code, task completion time, etc.). Measuring effort does not work, because there is no direct cause-effect relationship between effort and productivity, only a correlation. (The correlation isn't quite what most managers believe. The Critical Chain theory of business process management shows that a system yielding a high return on investment by necessity has parts that work at less than full capacity. Conversely, a system where the parts all work at full capacity, is never yielding optimal return on investment.)

I have seen several cases where management did not understand that something was wrong until years after the symptoms first occurred. Even worse, because the measurements where wrong, it was very hard for them to see what to fix.

On the other hand, productivity can be measured directly, so it is a good thing to measure. There is a direct relationship between Work-In-Process (WIP, or Inventory) and return on investment, (the ROI equation), so that is also a good thing to measure. Know those things, and you will know what really happens in a project.