An Interview with Watts Humphrey, Part 19: Starting at SEI

Like this article? We recommend

Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself

Learn More Buy

The SEI Director Was Fired

Humphrey: I had some friends -- dear friends -- who were at our wedding. My wife, Barbara, went to college with the lady, and they live in Pittsburgh, right downtown. So, I visited them when I was there with the SEI, the first visit. I got a letter from them. The letter had a clipping that John Manley had been fired from being the director of the SEI and that they were now looking for a director. Well, this is the guy I was supposed to have this special understanding with. All of a sudden, he was gone. So, my question was, “Do I have a job?” I had no idea. So anyway, the next day I got a telephone call from a fellow named Angel Jordan. I don’t know if you know who Angel is.

Booch: I don’t know.

Humphrey: He was provost at the university, [Carnegie] Mellon University. It’s a big job, as you know -- essentially running the university. But he called and said, “Watts, we know you were coming and you had agreed on a job with John, but we want you to come anyway.” I thought that was just marvelous.

Booch: Well, that was good to know because you’d already quit your previous job [at IBM].

Humphrey: Yes, and I had even had my retirement dinner, and everything was ready to go. It was a relief. So, I arrived and then they say John Manley was out. The problem they had was that what the SEI was doing, the Air Force didn’t want. They basically said, “This isn’t doing anything for us.” They didn’t like the programs we had. Nothing seemed to help them. They came out with a list of ten things that the SEI had to do. It was a directive.They fired the director. By the way, the technical people had also rebelled against him. So, he didn’t have a whole lot of support there. He had been ousted. I think he’s at University of Pittsburgh now. I was surprised. Remember I mentioned Jim Frame who worked for me at IBM?

Booch: Yes.

Humphrey: Well, Jim Frame had left IBM and gone to run programming at IT&T. John had worked for Jim Frame at IT&T. That was basically his programming background. So, I don’t think he knew a whole lot about it, but he certainly was a good talker, but he didn’t seem to have a vision for where the SEI was supposed to go. In any event, he was out. Larry Druffel was leading the search committee for the director of the institute. One of the questions to me was did I want to apply, and I said no and I thought that was kind of interesting, without a hesitation, but I didn’t want to run a lab. I wanted to do what I was going to do, and that’s what I said about being freed up. So, they were doing the search and I got involved in all of that.

The Software Acquisition Problem

Temporarily, I was assigned to work for Bill Sweet, who was one of the top guys in the SEI at that point. Bill was a sweet guy and a nice guy out of industry. He didn’t really have a whole lot of software background, but a very nice guy. He had a lot of contacts in industry and that sort of thing. One of the key things that the Air Force had really pushed us to do: they had ten items and the top one on their list was to come up with a way to help on the acquisition process for programming. They wanted us to work with Lincoln Laboratory, or rather with MITRE Corporation and the folks up at the systems division. So, that was their number one priority for us to do.

So in any event, I agreed. Bill Sweet and I were going to do this study. We went up to meet with the folks up at MITRE and met with a whole bunch of people up there, with the systems division people and everything else, and they told us about a study. I’m sure it was classified.

It was a study of 17 major software procurements from the systems division, and they had all been in trouble. They had all been late. Average delay of I think 75%, which means a four year contract would have been delivered in seven years. So, everybody was in serious trouble. And so, we were supposed to look at that as sort of a test set as to how you do it better.

I said, “Well, how did you pick the 17?” They said the 17 were all our large systems. I said that means you don’t have a selection problem. They said, “What do you mean?” I said, “Everybody’s failing. So, there’s no way you’re going to be able to pick a good one out of this crowd.” I said, “The problem is no one is doing it properly.” I’ll tell you, this looked just like what I wanted to do. And so I kind of got their attention. I said, “Perhaps the thing we ought to do is to look for a way to identify what are the characteristics of people who are doing good software work?”

We agreed and so that’s what we did. We sat down and we put together a whole list of how would the acquisition people identify vendors who were doing competent software work. We put together this list of 100-and-some questions, and that’s what we did. We basically had questions, and people wanted to put in stuff that they were using.

So, we were looking for things that distinguished between good and bad performance. I said, “If you don’t have any evidence that this practice is associated with good performance instead of poor performance, then we shouldn’t just drop in good ideas here. That’s not what we’re after. We’re after things that really will say these people are going to do competent work.” And I said, “There’s no evidence that I’m aware of that says using Ada instead of something else is going to give you good results.” They kind of grumbled and backed down.

But, that was a pretty tough test because no one really had much. Basically, the only real evidence we had is what I have seen and what I did with the OS 360, because I knew what practices helped because we had put them in place, and I knew what worked on quality because we had put it in place and we measured the difference. So fundamentally, with all of that stuff I had gone through over the years, I was able to apply it right there and it was marvelous. So, we put together a list of close to 100 questions and then we got to an issue next, and I was really struggling with this.

I remember I was sitting in the Atlanta airport. I was stuck coming back from somewhere. I had been on some trip and flights were canceled. The issue at the back of my mind -- and we had all been debating it -- was how do you actually take 60 or 80 or 100 answers to these questions and how do you rank people against it so you know who is better and who is worse. We didn’t have any idea how to do it at all.

The IBM Assessments

Well, let me back up a step because when I had been running the Software Quality and Process Group, my last job at IBM, I had gotten very interested in quality. I had heard about Quality College. What’s the name of the guy who wrote it? Quality is Free. I’m just looking for his book. Oh, yes. Here it is - Phil Crosby. Phil Crosby had been a quality manager at IT&T and he had put together this book on Quality is Free, and he had a maturity model -- five levels -- sort of went through how you were doing. I had actually gotten this, and I went to this very shortly after I took my job in Poughkeepsie in the quality and process job.  I think I mentioned to you that Art Anderson had talked about assessment.

Booch: Yes.

Humphrey: And so Ron Radice and I had gone to the Quality College, Crosby’s Quality College in Orlando -- it’s about a week -- and the guy had gone through how do you evaluate an organization in terms of quality attitude. You don’t look at specific quality practices; you look at attitudes. Did they believe in quality? Did they know what it was? Did they have a program in place? So, he had this kind of five levels. It was essentially an intuitive set of levels based on how people thought about quality and what they were doing about quality without talking about specific practices. Ron and I decided that we would do assessments of the software community using a five level framework, using Crosby’s maturity framework.

Ron Radice and Jack Harding both worked for me. I had them put together an assessment program, and they went out and put together the way we were going to do it. The first one we decided to do was in the San Jose lab. I remember going out there and meeting with the lab managers and the lab director, trying to talk them into doing this assessment. We were going to follow exactly the guidelines that Art had strongly recommended -- the assessment was not a report card that we were getting on them. It was a report card that they made to themselves. We didn’t publish it. We’d use it for guidance and that was it.

We went out there and talked to them, and they really didn’t want to have anything to do with it at the beginning. We spent all day with them. We talked to the lab director; it was fairly early, but he wouldn’t do anything until we convinced his staff. We kept saying we weren’t going to tell anybody. This was it. It was for you. We weren’t going to report on you. They finally bought it. So, we actually did an assessment and it had a marvelous effect. The people really were motivated by it. They focused on it. We did a bunch of assessments on a whole lot of labs just as we did at the San Jose one. They were quite excited about it. So, we went on and we did one in Poughkeepsie and in Hursley, England and Kingston.

I remember Kingston we did fairly quickly, but it was kind of a shock because we went back and did Kingston again about a year later. They wanted to see how they had done. We went back and did the second assessment. The problem was when you do an assessment, you can’t really assess everything. I mean, there’s no practical way you’re going to do it. So, we had a team of people in there for a week or two. It was actually a couple of weeks. It was a lot of work. We report back to the management. Present the results.

In the Kingston results, what you do typically is you go and select certain random projects, and you’d look at the selected projects to see what they’re doing and what’s going on. And so, we did the same. Of course, the next time we went back, we selected whatever their current projects were. It was a different number, and we got the results, and they had gotten worse. Kingston had put an enormous effort into improving things, and the assessment result came out that they were lower maturity than they had been before. It was an enormous downer. It was disaster. Fundamentally, it kind of killed the assessment program because really, it didn’t work. It didn’t connect to anything that they were doing at all and there was no way to really be objective about it. So, that was a bit of history I had learned.