Watts Humphrey headed the IBM development team that introduced the first software license, and he later served as its director of programming and vice president of technical development. He is a fellow of the Software Engineering Institute and the Association for Computing Machinery, as well as a recipient of The United States Patent and Trademark Office’s National Medal of Technology.

Accolades and accomplishments aside, he’s also made his share of mistakes, and from his decades of experiences, he learned hard lessons about how software projects should be managed, how to manage teams, his bosses and himself. Humphrey recounts those experiences in his recent book, “Reflections on Management,” which is the subject of his interview with SD Times.

SD Times: In your book, you discuss at length the impact that poor planning has on quality. How does a programming manager know whether they created a quality plan or not?
Watts Humphrey: A good plan must meet four requirements: It must be in sufficient detail to guide the work; it must accurately represent the costs and time required to do the work; it must be supported by sufficient facts and data to be convincing to senior management; and it must be owned by the development team and represent what all of the members are personally committed to accomplishing.

Since most plans are made by the managers and not the developers, they cannot meet requirements 1 and 4 and rarely meet requirements 2 and 3. These requirements can be met consistently when teams make their own plans. However, today’s software developers typically don’t know how to make plans and don’t believe that they should. They generally believe that planning is something that managers do. Changing these attitudes and skills is the key to good planning, and the Software Engineering Institute has developed the Team Software Process to guide developers and their management in doing this. I describe how the TSP does this and why this method is so effective in some of my books and papers.

You stated that blaming changes in requirements for failure is just an excuse for bad management. How can a programming manager avoid requirements creep, and how is the belief that changing requirements endanger projects an excuse?
Requirements creep can only be avoided by insisting that every requirements change, no matter how small, be supported with a plan to implement the change, and that management and the customer must agree on the extra time and resources required. Actually making plans for every small change, however, presents two problems.

First, few plans are detailed enough to permit this level of dynamic replanning. Then the costs for the added work are hard to determine and even harder to justify. The manager then typically loses the resource debate and ends up eating the added work.

The second problem is that, when developers are not truly committed to their plans, they will frequently agree to include “minor” changes that seem easy to implement and attractive functions without even telling the managers.

When teams make their own plans as described in the answer to question 1, these problems are typically resolved. The members know how much work they planned and can estimate what even small changes will involve. Then they are better able to recognize the costs of even minor changes and are unwilling to take on added work without some plan adjustment. Even when teams make their own plans, the manager must insist that no change is free and that the impact of every change must be estimated, planned and approved before it can be implemented.

You mentioned that not everyone shares the same level of commitment, and when someone is goofing off, the overall team spirit can suffer. How does a manager determine “equality of sacrifice” when team members may have different skills and abilities?
Sacrifice is not something that managers can demand without antagonizing and demotivating their teams. Since motivation is the single most important ingredient of successful teams, demanding sacrifice is  always a mistake. The key is to build the team’s motivation by having the members make and commit to their own plans.

The manager’s job is then to convince the team that the job is important and to make sure that the team does not get overcommitted. I have found that, when they make their own plans, motivated teams always overcommit themselves, and I have to convince them to be a bit more conservative in their planning and to recognize that there will be unexpected surprises.

The manager must then support the teams when they present their plan to higher management and to the customer. When managers support their teams in this way, and when the inevitable problems arise, the teams will make whatever personal sacrifices are needed to meet their team commitments. Then the manager’s job is to support, recognize and reward the team for a job well done.

Engineers may take it upon themselves to improve projects. Is there any best method to identify functional creep (additions to requirements beyond interpretations of requirements)?
Beyond the points I made in answer to question 2, this is a management problem. You have to be absolutely firm: No change is free!

On one of my military projects many years ago, the customer had a problem with testing facilities and wanted to delay delivery by six months. I told him we could do that, but I’d have to see what it would cost. He was pretty upset. “How,” he said, “could it cost money to delay the project?” I told him we would have to look at the plan and see.

It turned out to be quite expensive. The six-month-longer schedule meant we had to keep the team together for six months longer than planned. If I let any of the engineers go, I wouldn’t be able to get them back for testing. After some grumbling, the customer agreed.

Then, about six months later, he came back to see me. They had gotten additional money for the testing grounds at Fort Huachuca and could now put testing back on the original schedule, and he wanted to go back to the original plan. I told him that we could probably do that, but then I had to look at the plan. It turned out that the acceleration would actually cost more money.

My engineers had worked with his folks and come up with a number of added features that everybody wanted. If we kept these features, it would cost more money to accelerate the work, and if we dropped the features, it would take added effort to remove the extra features and reinstate the original design. While I got more money again, I never could have done it without a detailed plan.