3
Rational Management

In Chapter 1, I described the three principles of software management: recognizing that you are in the software business, making quality the first priority, and using motivated and disciplined people to do the work. Then, in Chapter 2, we reviewed five of the principal causes of project failure: unrealistic schedules, inappropriate staffing, disruptive requirements changes, poor-quality work, and believing in magic. Now, in this chapter, we discuss solutions to these problems. As H. L. Mencken once said, “For every complex problem, there is a simple answer, and it’s wrong.” While there is no single solution to software’s multiple problems, there is an effective strategy. It concerns management style and the techniques for enlisting your people in attacking the problems of your business. I call this style rational management. The principle of rational management is that your people are loyal and thinking professionals who would like to support you in addressing the organization’s problems.

Facing Facts

When faced with a software problem, many executives behave irrationally. As we saw in Chapter 1, the Ashton Tate CEO knew that he had to ship Dbase IV in November, so that’s what he told his management team. Not surprisingly, they said they could do it. However, any rational examination of the situation would have shown that, by just continuing to test and fix defects, they didn’t have a chance. So what would a rational manager do instead?

When you are in an impossible situation, gather the available facts, assess these facts to understand the problems, and then rationally address these problems. After all, if the situation looks truly impossible, it probably is; then pushing ahead and hoping for a miracle will only make matters worse. Rational management means making plans, following these plans, and fixing problems before they get out of control. It requires that you trust your people, be honest with your customers, and insist on professional work. The stories in this chapter give examples of how this rational approach can help you to resolve issues and to take advantage of business opportunities. While rational management isn’t easy, it does work.

Cutting Cycle Time

Cycle time is rarely defined precisely, yet most organizations consider it their most important competitive yardstick. Cycle time refers to the time from project inception to the first product offering to customers. If you don’t measure cycle time, you cannot manage it, and if you don’t manage cycle time, it almost certainly won’t improve. The following story shows how many organizations manage cycle time.

I was in India for a conference and took the opportunity to visit the Bangalore laboratory of a company I was working with. My first meeting was with the laboratory director. He explained that corporate headquarters had established this laboratory as a test bed for improved software methods. He also explained that the CEO had just challenged all the product groups to improve cycle time by ten times in ten years. This number seemed so extraordinary that I asked the lab director for more details. He assured me that the CEO was serious and that they really were trying to shorten the typical two-year project to a two-and-a-half-month job.

I spent the next three days meeting with project leaders and engineers. I held several informal 90-minute sessions with groups of about 10 to 15 engineers each. After a few opening comments, I would ask each engineer to explain his or her job and to discuss any important issues or problems. In three days of meetings, not one engineer mentioned cycle time. While management was clearly concerned about the cycle-time goal, nobody was doing anything about it. I concluded that the managers had no idea how to achieve the goal, so they did not know what to tell the engineers. Not surprisingly, the goal was ignored and cycle time was not improved. Today, one of that company’s biggest problems is its inability to bring new products to market as quickly as its competitors. Instead of cycle time improving by ten times, it actually got worse.

Aggressive goals can be useful, but they are useful only if they lead to productive action. That usually requires that people change their behavior. This, in turn, requires an improvement plan that focuses on achievable goals and on the actions needed to achieve them. While a ten-times cycle-time improvement in ten years may not be achievable, the same goal could have been broken into ten annual improvements of 25% each. A one-year goal to improve cycle time by 25% would probably seem reasonable. It might even be achievable, as long as the goal was measured and tracked and the work was supported by a detailed improvement plan.

The first element of rational management is a direct outgrowth of the principles of software management. To get motivated and disciplined people, you need aggressive goals and you need to support these goals with specific programs and plans to achieve them. Most important, reduce any long-term goals to short-term actions with checkpoints and measures. Then measure these goals and use the measures to track and manage the work.

You’re Ruining the Business

IBM had just fired the director of programming. The senior vice president had called a meeting with the senior programming management team. He was so mad that he was pounding the table. The company had announced a complete new line of computers a year and a half before. IBM was now delivering the hardware, but the OS/360 programming support had slipped three times. The problem for the business was that customers were delaying their computer orders until they had believable dates for the software. The VP ended his tirade by telling us we were ruining the business. Then he demanded that we give him a schedule in two weeks. No one said a word. Everybody in the room looked at me.

I had just been named director of programming, and I knew that two weeks was insane. I had nearly 4,000 programmers in 15 laboratories and 7 countries. Most of them were working on the OS/360 system. This was a major corporate crisis, but I knew that any schedule guess would almost certainly be wrong. If I made up a date and missed it, my credibility would be gone; then I, too, would be out of a job. I told the VP that I could give him a date that day if he insisted but we’d probably have another date tomorrow. If he wanted a responsible date, we would have to make a plan. That would take 60 days. The VP looked around the room. One by one, he asked all the managers what they thought. They all agreed that it would take 60 days. In the end, he agreed to the 60 days.

When executives tell me they are in a crisis and don’t have time to do the job properly, I tell them that when they are really in a crisis, they cannot afford to panic. A crisis is no time to wing it. Since the time wasted to recover from mistakes would only make things worse, you must do the job in the very best way you can. You must make complete plans and review these plans to ensure that they are realistic and sound. After all, if your job depends on meeting the plan, you had better have a good plan. By facing the facts, we did solve the OS/360 problem. While we delayed the schedules, this team produced a plan everyone understood and believed in, and they did it in the promised 60 days. What is more, they did not miss a single date for the next two and a half years.

The second element of rational management is planning. This again connects to our principles for managing software. For truly motivated people, you need aggressive goals and plans, but your people must also believe in the plans and be committed to meet them. So the second element of rational management is to insist on plans, and insist that these plans be made by the people who will do the work. Then review the plans to make sure they are complete, they are based on data, and you are willing to bet your job on meeting the planned dates. Finally, make sure all of the people involved are committed to meeting these plans. If they say they can’t meet your date, believe them. The chances of your getting an earlier schedule are nil. By negotiating the plan with the people who will do the work, you give them a stake in the job and you ensure that they are all committed to meeting that schedule.

Getting the Facts

Crises are common in software, and they commonly cause panic. Whether the problem is with hardware or software, a good rule to follow in a crisis is this: get the facts. A search for facts is a great way to avoid panic. Ask questions and demand answers. If you don’t get good answers, the engineers probably don’t know them. But, by asking some questions, you can almost always find some useful data. Be persistent and continue to probe. When you obtain all of the available facts, then you can devise the fastest and most effective way to solve the problem. The next story provides a good example of how facts and data can help a business.

Frank was president of a small company that made communications switching equipment. The company’s profit margin was eroding, and customer complaints were increasing. Warranty and field support costs were way over budget, and most of the engineers were fixing customer problems instead of developing new products. The company had shipped its newest product three years before and, although it worked well, the users kept finding problems. As they added new users, these users found even more problems.

Frank wanted my advice. When I asked for details, however, he didn’t have any facts. To understand the problem, I told him that we had to know how many defects had been found, how these defects were distributed among the system’s modules (or parts), and what it cost to fix each defect. Without these data, there was no way to make a logical decision on how to address his problems.

Neither Frank nor his managers thought anyone had the data we needed. However, we soon found a maintenance engineer who did. He had gathered data from defect reports and we were able to piece together the needed information. Figure 3.1 shows what we found. The company had repaired a total of 686 defects in the first three years of customer use. The system had 1,643 modules, but 81% of them had been defect-free. All of the defects had been found in only 19% of the modules, and only 4% of the modules accounted for 48% of the defects.

These data showed that nearly half of the company’s maintenance costs were due to only 4% of the system’s modules. With this information, it took the engineers only five months to clean up the 72 defective modules. This cut maintenance costs in half. By the end of the year, the company’s profit margin was back where it belonged.

Figure 3.1 Percentage of Modules with Defects

The third element of rational management is to use facts and data. This again connects to the principles of software management. With motivated and disciplined teams, your people will know how and why to gather data, and they will consistently measure their work and report the results. By objectively using the team’s facts and data, you demonstrate trust in your people and a willingness to listen to their problems, plans, and ideas.

Once you have engineers who do quality work and who have the discipline to consistently do such work, you can set realistic and aggressive goals, make sound decisions, and precisely track the work. Often, as the next story shows, a little data can help to resolve problems before they impact the business.

The Flight-Test Deadline

When Bret launched his project in October, he knew that the U.S. Air Force needed the completed system by the end of December in the following year. This was a major avionics upgrade to support a critical January flight test, only 15 months hence. Since Bret’s team was using the Team Software Process (TSP), the engineers had detailed plans that showed them what to do each week.

After the first six weeks of work, the team’s weekly progress reports showed that they were falling behind. As illustrated in Figure 3.2, their earned-value (EV)^* projection showed that they were slipping schedule by about 8% a week. While this might seem like a small problem, it was enough to miss the December delivery by over a month. Bret waited until after the Thanksgiving and Christmas holidays, but then he asked the entire team to go on overtime.

* Earned value measures a team’s progress against its plan. Each task’s planned value (PV) equals that task’s planned percentage of the total job. When that task is completed, the project earns that value (EV). By projecting EV progress, teams can accurately predict when they will finish.

Figure 3.2 Earned-Value Projection

By working six-day weeks for the next three months, the team caught up. Thereafter, Bret and the team reviewed progress every week. If some engineers fell behind in one week, they had to make up the shortfall the next week or go on overtime. Because the engineers could precisely track progress, they finished the project slightly ahead of schedule, with only a little additional overtime.

The fourth element of rational management is to use facts and data to anticipate and correct problems before they become disasters. An 8% correction is only about three hours a week, but if you wait a year, it grows to a full month. Schedules slip a day at a time, and if your project measures cannot detect a one-day slip, you cannot anticipate problems early enough to prevent them—you must wait until the problem is big enough to notice with the measures that you have. Then it will probably be too late to fix it, at least not without considerable pain.

The Essence of Rational Management

Figure 3.3 shows the four elements of rational management. Although I have already discussed each individual element, they are all related and are all required for an effective management style.

First, in setting product or operational goals, examine current performance and devise goals to meet business objectives. Then translate these long-term objectives into short-term goals that motivate action.

Second, require plans to meet the short-term goals. Goals drive plans and the people who will do the work must make these plans. Then have the engineers defend their plans and show you that they are complete and sufficiently detailed to guide the work. If a plan does not meet your goals, negotiate that plan to arrive at one that will meet your business needs and that the engineers will commit to meet. To work this way, the engineers must know how to make plans and they must be required to do so.

Figure 3.3 Rational Management

Third, measure and track the plans and monitor the discipline with which the work is done. Once you have a plan, you have a benchmark for measuring performance. To have any chance of meeting their commitments, however, the engineers must follow their plans, measure their work, and regularly report on their progress. This requires that they be trained in disciplined practices and that they measure and track their work and manage the quality of the products they product. Then, of course, they must consistently follow these practices in doing the work.

Finally, continually monitor business performance. If you see problems, follow a rational management style to address those problems. When the work is planned, measured, and tracked, you can regularly monitor business performance. You will have a precise and timely picture of business status, and you can anticipate problems and take timely action to correct these problems before they impact business performance.

Summary and Conclusions

With a rational management style, you have precise data on the organization and can make sound and timely decisions. There are four elements to rational management:

1. Set aggressive long-term goals, but break these goals into realistic and measurable short-term goals.

2. Require detailed and complete plans, review these plans, and then negotiate the commitments with the people who will do the work.

3. Insist on facts and data, and use these facts and data to run the business.

4. Monitor the work, and use current data to anticipate and resolve future problems.