|
|
 |
|
Modeling Organizational Change
© Esther Derby 1999-2002
This article originally appeared in STQE Nov/Dec 1999.
When you approach a problem in the way your work group functions, you're implementing an organizational change. By taking a critical look at your process, and using some theories from organizational design, you can fix the problem -- and change your organization to make quality more likely.
I'm writing for managers responsible for quality (QA, test or development group managers), so I'm going to assume you have one of those jobs. You may feel skeptical, because organizational change is something that happens to you, not something you do as part of your job. It's true, you probably don't have control over many of the elements that go into an organizational design, such as compensation or overall structure, but you will be involved in thousands of small-scale organizational changes in your career. That's why you can benefit from some of the theories and techniques used in large-scale organizational change.
Organizational change involves changing a complex system. This is true whether you are changing an entire company, or making adjustments within your project or work group. As a manager, you are changing the system every time you make a course correction within your span of control.
Systems, even small ones, are very complex. There are many variables, and the relationships among them are not simple: Any one variable may be influenced by a host of factors. And any action can affect more than one variable in the system. Your job in designing an organizational change is to figure out the interplay of factors and identify options for making a correction that will influence the system in the direction you want it to go.
Circular Causation
Let's look at an example that I've worked with in real life, and is probably familiar to you, too.
A software development organization has released an application with several major defects. The customers are unhappy, and have asked for a special release to fix the problems. Management agreed to do the "special," while still meeting the schedule for the next feature release.
Predictably enough, under the pressure of putting out a problem fix release in addition to the regular release, the testing staff cut some corners, and more defects went out with the next release.
If we think about this in terms of cause and effect, how does it look?
Request for special release leads to greater workload
leads to more pressure to deliver leads to corners cut in testing
leads to more defects released leads to requests for special releases.
Notice that the last effect is the same as the first effect. So instead of fixing the problem (customers are unhappy because of the number of defects), the choice to put out a special release has perpetuated the problem. This is circular causation. It can be hard to figure out where in the circle to make a correction.
In project work we tend to think in terms of simple cause and effect: the build is three weeks behind schedule, therefore testing will begin three weeks behind schedule. But circular causation is much more common, especially in complex systems. It's hard to see these circular causation loops. This is where it really helps to have a model of the system. A model of the system helps you see the complexity, and it also lets you play out several options before you commit to a particular action.
Determining Corrective Action
The easiest kind of model to develop is a simple diagram of effects. To model a system, you need to have some idea of
measurable events within the system. The measurements don’t have to be exact …. but they do have to be observable evidence of the events in the system.
Figure 1 shows a simple model of the system operating in the organization that is releasing too many defects with its product. The clouds represent effects you can observe in the system. The arrows indicate that as one effect increases, so does the one the arrow points to. As the workload gets bigger, pressure on the testing staff increases, and so on.
Figure 1. The current state: The customer is dissatisfied with the number of defects in the current release and requests a special release (in addition to the the already scheduled feature release) to correct problems. The work load goes up, which puts more pressure on the testing staff. The testing staff reacts to the pressure by cutting corners, which leads to more defects released...which leads to another request for a special "bug fix" release.
It’s easy to see the loop here. Now that the circular causality is clear, how can the manager design an intervention that will allow her to stabilize the system and make some changes that will bring the defect rate down?
First look for something to "do more of." This is the simplest organizational intervention. You can't always find this kind of lever, but it's worth looking for. It's clear that in this case, we don't want increase any of these effects.
If you fail to find a natural lever, start by generating several options for things you can do to reduce some of the effects you want to diminish. . If you can only come up with one option, you really don’t have a choice. So lets try to come up with at least three (you can probably come up with lots more). They don’t have to be perfect options, they just have to be options. In fact, looking for the "right" correction is a common mistake, and often keeps managers from taking "good enough" action to correct a problem early.
So what are some options?
- Add more testers
- Require overtime for the testing staff
- Implement a change management process that examines trade-offs and allows management to look at priorities and negotiate.
Option 1: Add More Testers.
Adding resources or mandating overtime are common interventions for all sorts of problems. Option three, changing the process to manage the workload, is common in some organizations, and unknown in others.
How will each of these interventions impact the existing system?
Suppose you can hire testers who are fully productive first week on the job. By dividing up the test cases among all the testers, you can reduce the workload for each tester, thereby reducing pressure, and stop the cycle of introducing more defects with the fix release.
Sounds good. But even if the new testers are up to speed on the first day, adding staff means more effort to coordinate tasks and communication, which adds to the workload. Figure 2 shows the impact of adding additional testers who don't have any learning curve. The testers will have to absorb the additional effort of coordination and communication, which will cancel out the planned benefit of reducing the number of test cases each tester is responsible for.
Figure 2. Management responds to the request for a special release by adding more testers. If the new testers are able to contribute immediately, and they don't require time from the experienced testers for coaching and to answer questions, the work load on each tester will be reduced (the black dot indicates that as one effect goes up, the other goes down, and vise versa). There will be another effect of adding more testers: additional effort to coordinate the work. The additional effort will most likely cancel out the benefits of each tester having responsibility for fewer test cases.
It's more likely that you won't find testers who can be fully productive without some coaching and support from experienced staff. So the experienced testers will have to spend some of their time orienting the new testers and answering their questions, which increases both their workload and the amount of pressure they experience.
Figure 3 show how the system looks with the addition of new testers who will need information and coaching from existing staff. This follows the conventional wisdom that adding staff late in a project actually reduces progress.
Figure 3. Management responds to the request for a special release by adding more testers. The new testers need to ask questions and get coaching from the experienced testers in order to be productive. In addition to the increased effort to coordinate work, experienced staff need to spend tie with the new testers, reducing the amount of time they can spend on their own tasks. This outcome is the most likely, unless management actively works to manage the impact of adding staff.
While beefing up the testing staff may be an excellent long-term strategy, in the near-term, it will increase the stress on the system and perpetuate the problem. You may still choose this option, but will now need to take some additional steps to keep the system from spinning out of control.
Option 2: Required Overtime.
Required overtime is common in our industry. We've all been on projects where 50 - 60 hour weeks are assumed during a crunch. Most people can put up with it for a short period of time and continue to function, although less effectively. Many people tolerate overtime for a very long time if they have stock options or some other financial interest in the company. The intention of overtime is to allocate more time to tasks and therefore reduce cutting corners. The reality is that efficiency goes down quickly and the intended benefits are seldom realized.
What happens when overtime continues for an extended period of time and morale starts to go down? As morale goes down, testers become de-motivated -- and more corners get cut. Testers may even start to leave, increasing the workload
and pressure for those who remain (Figure 4).
Figure 4. Management responds to the request for a special release by instituting required overtime to meet the current scheduled feature release and accommodate the special release. This leads to a drop in morale AND more pressure on the testers. The drop in morale causes more corners to be cut because testers begin to feel the situation is hopeless...which leads to...
If you add required overtime for the developers, they may start introducing more errors as they attempt to correct the defects found in testing. Which leads to more defects à more requests for special releases à greater workload….
Again, we've added complexity to the system, while keeping the problem going, and probably making it worse.
Option 3: Implement Change Management.
The third option is adding a change management process to help management negotiate to defer features, slip schedules and prioritize what will be fixed to keep the workload level. Figure 5 shows how change management will effect the system.
Figure 5. Management responds to the request for a special release by implementing a change management process. Management negotiates with marketing to defer features or slip the ship date for the scheduled release. This maintains the current workload, which keeps the system from spinning out of control and buys some time to address underlying quality problems. The shaded square indicates a management action with choice.
This correction doesn't solve all the problems, but will probably keep the system from totally breaking down. It will give you some breathing room to address some of the other causes that are at the root of the quality problem.
Risk Consciousness
Now that you have an option in mind, it's time to temper you optimism. So let's think of what could go wrong. If you can’t think of at least three things that could go wrong, you’re in for a bad surprise. You can't think of everything that could go wrong, and you certainly can’t prevent them all from happening. By thinking through the down-side, you may find weakness in your idea, or you may be able to develop contingencies. Either way, your change will have a better chance of succeeding. There's a technical term for this activity: "risk management."
Assuming you chose to put a change management process in place, what could go wrong?
- Customers refuse to negotiate either on priorities or schedules.
- Senior management agrees to implement a change management process, but then backs down under pressure from customers.
- The product is so full of defects that customers scrap it before you get a chance to bring things under control.
- Customers call programmers directly and influence them to add fixes or features that have been deferred or listed as low priority during the change management negotiation, leaving testers with the choice of testing the changes (increased workload) or letting them ship untested (more defects).
Based on this list, you can come up with a back-up plan, pay extra attention to getting buy-in from senior management, or choose a different correction.
At this point, you are ready to try your change. Keep your diagram of effects and track the results of your change. There are bound to be things that you did not consider. Your best defense is to model the system again, and choose the
smallest correction that will achieve the results you want. Each time you will be come better at observing and tempering your action to the system.
It's often tempting to take a dramatic action to correct a problem, especially if customers or senior management are pressing for quick results. But major action can lead to major re-action in a system. The re-action seldom takes you in a direction you want to go, and may make the situation much worse. By practicing this technique you can become better at reading the system dynamics and choosing the smallest possible correction to get things back on track.
What if senior management demands big action? You still have choices. Model them, build contingencies and track your results. Just remember that acting decisively doesn’t necessarily mean making a big correction.
Sources:
Dorner, Dietrich. The Logic of Failure: Recognizing and Avoiding Error in Complex
Situations. Reading, Mass: 1996.
The Logic of Failure examines a series of experiments on how people make decisions and take action in complex situations. The results throw light on the way people approach problems and how it can lead to disaster, step by small step.
Hanna, David P. Designing Organizations for High Performance. Reading, Mass: Addison -Wesley, 1988.
Provides an overview basic components of organizational design, and provides strategies for implementing change in large organizations.
Shmaltz, David. "Why?" Compass Vol. 3, No. 1, Spring 1999.
A short article that explains different types of causation and how they can effect the way managers think about projects.
Weinberg, Gerald M. Quality Software Management, Volume 1, Systems
Thinking. New York: Dorset House, 1992.
This book is packed with useful ways to think about quality, problems and software organizations. It introduces the cybernetic model of systems, and provides lots of examples and detail about the type of "diagram of effects" model discussed in this article.
|
