When you approach a process problem in the way your workgroup 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 just 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.
Let's look at an example that I've worked with in real life, one that 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 has 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 has cut some corners and more defects go out with the next release.
If we think about this in terms of cause and effect, how does it look?
Request for special release-->greater workload-->more pressure to deliver-->corners cut in testing-->more defects released-->requests for special releases.
Notice that the last effect is the same as the first effect. So instead of fixing the problem (customers' unhappiness over the number of defects), the choice to put out a special release has perpetuated the problem. This is circular causation. And 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-and this is where it really helps to have a model of the system. A model helps you see the system's complexity, and it also lets you play out several options before you commit to a particular action.
Determining the 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 in the organization that was 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.
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 to increase any of these effects.
If you fail to find a natural lever, generate several options for things you can do to reduce some of the negative effects. If you can only come up with one option, you really don't have a choice. So let's 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, often keeping managers from taking "good enough" action to correct a problem early.
So what are some options?
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 their 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 breaking 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 will be needed to coordinate tasks and communication, which adds to the workload. Figure 2 shows the impact of adding additional testers who don't require 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.
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 shows how the system looks with the addition of new testers who will need information and coaching from existing staff. This follows the traditional wisdom that adding staff late in a project actually reduces progress.
While beefing up the testing staff may be an excellent long-term strategy, in the short term it will increase the stress on the system and perpetuate the problem. You may still choose this option, but you will need to take some additional steps to keep the system from spinning out of control.
Required overtime is common in our industry. We've all been on projects where fifty- to sixty-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 (see Figure 4).
If you add required overtime for the developers, they may start introducing more errors as they attempt to correct the defects found in testing. That leads to more defects, which generates more requests for special releases, which creates a greater workload, and so on.
Again, we've added complexity to the system, while keeping the problem going-and probably making it worse.
The third option is adding a change management process to help Management negotiate to defer features, slip schedules, and prioritize what will be fixed-so that the workload is maintained at a level that won't jeopardize quality. Figure 5 shows how change management will affect the system.
This correction doesn't solve all the problems, but it 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.
Now that you have an option in mind, it's time to temper your 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. But by thinking through the downside, you may find weaknesses 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?
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 become 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 modeling 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.