Ron: The kinds of things that we're after are: How did you get into project management work? What projects did you work on? What tools did you use? And who were some of the key people that made substantial contributions that you worked with? Finally, reflecting on those experiences, what were some of the key strengths and the weaknesses of the PERT techniques? What would you have done differently? That's the thrust of what we will discuss. Please start off and we can ask questions as we go along.
THE EARLY DAYS
Bob: Early on, I remember that we at MITRE and ESD heard that the Navy had a management tool that was supposed to be pretty good and why don't we go and take a look at it to see if it was something we could use in the Air Force, primarily at ESD. So we trouped off to Washington and were given a tour of the Polaris Special Projects Office. The Navy showed us their version of PERT, how to get estimates, prepare networks, enter data in the computer, update things and so on. Somebody explained that PERT was not all that helpful to project management, as the hands-on managers already knew their plans, schedules and problems. Where PERT was exceptionally valuable was in presenting program information to Congress in support of program funding. The PERT output charts tended to show that the managers are on top of all the details and that the need for further funding is real and reasonable.
Chuck: I got into PERT for Martin because we were about to bid on the Typhoon system for the Navy. Since it was a Navy system, and since PERT was very big in the Navy, I was sent by Martin to an AMA Meeting at Saranac Lake to hear from Will Frazar and others what PERT was. I thought that one of the great things about PERT was that it forced one to think through the inter-dependencies.
Before we get too far, we weren't as dumb as people think in the pre-PERT days. Most people don't realize that when Gantt devised the Gantt Chart he meant to show interdependencies. For example, his charts would show little arrows which would indicate the flow of engineering data from, say, engineering to production engineering.
Ron: Gantt was actually the name of the individual?
Chuck: Yes, there is a genuine Gantt. He was still active in the ‘70s in Washington.
Ron This is the first time I've heard that Gantt charts have been used to show the dependencies.
Chuck: Well, he was certainly trying to show activities on a time scale, and he was also trying to show dependencies. In addition, I think anybody who has ever worked in production recognizes that there is a “goes-into” structure; namely, components go into subassemblies, subassemblies go into the assemblies and, so forth. Production planning was based on this. It doesn't seem to me that the idea of activity dependency is anything startlingly new.
At Martin we ran into a funny problem with PERT. In the old days, (1950s) when scheduling at Martin, we planners would always try to get our internal milestones well ahead of the contract milestones. When the Government wanted to see the pertinent PERT, we then had to show them the work plan keyed to contract milestones. And it was hard to try to figure out how to correlate internal schedules, contract schedules and the PERT network. You would have liked to have gotten everything scheduled and done a month or two ahead of time, but you didn't want to show the Government a PERT that did this.
Ron: One of the things that I had heard on the early work of PERT on the Polaris program was its value in controlling subcontractors. At that time, the early 1960s, I joined General Electric where they took the PERT technique and turned it inside out. Instead of a control tool, per se, they used it as a planning tool from the bottom up, to establish the baseline that you could then use to control to. That may have been one of the better, or the more important, contributions that General Electric gave to the use of the technique starting about 1960. It was used mainly for the planning process to establish a base line. Thus, PERT was a great device for improving communication among all participants on a project. You start with a blank sheet of paper and you lay out your plan; you try to get the participants to put all their cards out on the table. As opposed to just taking a schedule and working back—PERT helped open up honesty and professionalism in the planning process. Would you agree? What did you see?
Bob: Well, in my experience actually drawing networks and trying to identify dependencies and constraints, one has to make several passes backwards and forwards through the network before you get the network where you want it. PERT is most valuable in the planning stage and less valuable in the control stage. PERT/COST can be murderous in the control stage.
Chuck: I think there is a basic problem with PERT or any other schedule technique. What do you do if you are a contractor and the Government imposes what may be an unrealistic schedule on you? If you want to win the contract, you propose that you'll meet that unrealistic schedule. You can, of course, indicate a certain amount of risk to the Government by doing an analysis like PERT.
It seemed to me, that in the old (pre-PERT) days, we would all sit down in a scheduling meeting and we would all get mad at each other. And if everybody left the meeting equally annoyed, we knew we had a good meeting because that meant that everybody was hurting more or less equally. The problem of using PERT in this area was that if everybody was happy with PERT, you had to be careful that the new PERT schedule didn't come anywhere close to the contract requirement.
Let's get back to the early days. When I came here, I worked for Bob and we were trying to develop a PERT network for the Cheyenne Mountain Complex. We both worked for Norm Waks and Gene Lundberg. We had a gigantic network that went down the wall of one room and across the floor and up the other wall. As I was standing in my stocking feet, in walks MITRE'S President to look at the network. Looking in disbelief at both me, standing therein my stocking feet, and at the gigantic network, he mumbled something like “If that's PERT, I don't like it.”
PLANNING VERSUS CONTROL
Ron: Chuck, you mentioned an issue which I think is important. You imply you don't know whether Air Force and Air Force contractors are planning any better today than they were 20-30 years ago; and to some extent they may not even be doing as well. On the other side, they certainly now have PERT/CPM software programs which are somewhat better, I would think. And the hardware is there, and microcomputers are there, and minicomputers are there. I wonder whether that's a topic we ought to explore a bit.
Chuck: My perception is that adequate capability is there in the hardware and software to process PERT, but the plans may not be there. I think that part of the problem on usability is that we don't have anything like the master planning group that I came out of headed by my Martin boss, Ed Soist-man. I don't think industry has master planners who understand all interrelationships or activities. If you had been at it for five years or so on a project, you got a pretty good feel of engineering milestones, and the tooling and manufacturing and procurement ones, as well. I don't see these people in industry anymore; I see a lot of accountants in industry, but I don't see planners.
I think, also in retrospect, we were dealing with comparatively simple systems, at least when I was with Martin. We had problems, I remember, on Pershing. We had fairly hilarious problems when the jet vanes kept ablating too fast. So, you used another compound in the jet vanes, ran it under the exhaust and saw whether the vanes melted. Eventually one didn't melt, and off you went. But this was comparatively simple.
I remember when I was working the Martin central planning chart room that our General Manager could go out and look at the missiles at the several test stations. One could see whether a given Pershing was in test station A,B,C, or whatever. You would go out every morning and look to see where all the hardware was. You could see it. Then you would come in and see whether the status charts had been updated that morning, because we had an essentially real-time system. We were more real-time then, without computers, than we are now with computers. A supervisor could check on whether the milestones which showed on the charts were being met because you could eyeball it.
There is no way that anybody can eyeball software status. I'm looking at contractor now that will take credit for software coded, and rightly so, since they think that it works. However, when they get all the software hooked together, they find that they can't meet key requirements, such as the timing requirements on the displays. So they have to go back and redo it. At this point they have already taken credit for all the earned value. They can't get anymore earned value, but they still have to redo the software again. And maybe yet again. So you find yourself watching the latest revised estimate increase, not the budgeted cost of work performed. Then you eventually re-baseline…and go through the cycle again.
Ron: The CPM process was good and worked as of the early to mid ‘6os. The computer programs were adequate, but they weren't that sophisticated. They were not updated as the hardware and software got better. Many of the companies were spending more effort on their hardware and software packages than on the actual planning process. And I don't know whether that whole problem has turned around even today. What have you folks seen on that? Where is the emphasis? How has it evolved?
Chuck: In general, from what I have seen, the C/SCSC system is working in the sense of documentation and data. I went through the equivalent of subsequent application review a couple of weeks ago. The hardware works, the software works, but there are some problems in areas like choice of algorithms. For example, the usage of proportional algorithms where you take a credit automatically for awhile. Also the “end of the month” is not a good end point for taking full credit for accomplishment. A milestone is a better, much better, end point. “Twenty percent complete” is not a milestone. A milestone is something you can touch or look at or see test results on. In other words, I think the systems are working okay. The contractor systems can run fine with milestones in areas like parts fabrication. On things of that nature, they're very good. There are very good, discrete milestones for the machine shop stuff. They get kind of flaky in some of the software areas. So, again, I think the systems are working fine. But again, I think that there are problems in doing the basic planning. Bob, as you pointed out to me one time. when we started out, the missiles were just logically outgrowths of aircraft to the point where the Titans had a keel line on them. They were flying boats, they just happened to be round. Now as for software, give the process a few more years, and maybe things like Ada will be able to help. Maybe some of the “software factories” that people talk about are a step toward that direction. Again, I have the feeling that we need better planning. It seems to me that the process is becoming incredibly complex.
THE TEST APPLICATIONS
Bob: But let's go back to early days when PERT was being evaluated and developed for use in the three services.
This effort left a lot to be desired. The Navy, with support from Booz-Allen, developed, installed and used PERT on the Polaris program (and probably others as well). Development of PERT/COST was started by the Navy at the time the Air Force appeared on the scene. Not wishing to be second to the Navy, the Air Force developed PEP, a variation on PERT and simultaneously began to work on their version of PERT/COST. The rivalry engaged the attention of DoD personnel concerned with the subject. The consequence was a DoD decision to have three prototype PERT/COST applications-one Army, one Navy, one Air Force. The three applications would be evaluated and the best one selected for standard use throughout DoD. The Air Force used the TFX program; the Navy used the Mark 48 Torpedo program; and I think the Army used it on its LANCE program. I believe these programs were selected because they had previously been selected to use the then new Definition Phase.
Ron: The Air Force TFX program had General Dynamics as prime contractor. At General Electric we had the attack radar subcontract on the TFX. I think, as I said before, General Electric was one of the first to use PERT/COST at a subcontract level and to wrestle with the problem of subsystem/system interface.
Bob: There was a big implementation effort on programs already started. So since all three services were struggling to implement PERT/COST on major programs, the competition was still on. Eventually, the services got their PERT/COST systems installed, and we at MITRE had the job of preparing evaluation criteria. Before any significant amount of experience was obtained and before the evaluation methodology had even been nailed down, DoD issued a directive which said, generally, “PERT cost is a great success. Hereafter, all acquisition programs (of a certain size) will use it.”
Ron: What year was this, Bob, do you recall?
Bob: It must have been around 1963-1965.
So then a lot of other people got in the act because System Command (AFSC) Headquarters decreed that, unless otherwise directed, Air Force program managers will use PERT/COST on their programs. And someone had the wisdom to direct that you (the program manager) will use PERT/COST unless you can justify not using it. Then the challenge was to get it waived on your program. A rationale evolved; you don't know what you are getting into, you don't have the people who do; and staff support personnel are not available. So, PERT/COST was universal on a case-by-case basis. Years later, probably in the 1970s, the DoD retracted the mandatory use of PERT/COST and said that its use was now optional.
This earlier policy led to the writing of all those Air Force standard PERT documents for the Air Force Systems Command. PERT and PERT/COST are tools for project management. They provide useful information for planning, scheduling and monitoring of milestones. Some people used to think that PERT was an innovative management tool that provided all the information needed for project management. It does not. It cannot. Specification and specification maintenance are all matters which input data to PERT, not vice versa. Some persons didn't know the whole big puzzle and picked up only this piece; they may have been overly impressed with the detail possible from the network graphics.
Also, you have to look at PERT in the middle of the changing environment of defense systems acquisition and the project management for such organizations.
CONFLICTING REQUIREMENTS
Chuck: You're bringing up something very vital; namely, that PERT may be used as an internal planning tool, or as a recording device, or as a government management tool. As a government management tool it is very much a creature of cost plus contracting. I have a feeling that the reason that we are not red hot on PERT these days is that it has been a time for procurement people to do their thing. Program control in the Government has tended to be more of a finding thing.
Some funny things happened. I remember one program where PERT stopped coming. I drafted a letter demanding it be resumed, with an equitable adjustment for months missed. The procurement people said, “Well, didn't you know that the contractor put in a value engineering change six months ago and after we processed it, we eliminated PERT? To cut down on Government paper work.”
Ron: Tell me if I am correct in saying this, but it looks as if the technique that started out as being a good planning and, to a certain extent, control tool was misused and maybe ill-used until some people thought it was an appendage that really wasn't buying much, and they cut it out.
Chuck: Looking back over the past thirty years, I remember MacNamara. I can remember in those days we would get a new “ism” every year. It would be design-to-cost, or it would be warranties or something else. I can remember reading an article from that era saying “…this finally takes care of warranties.” That was 20 years ago and now we're back with warranties again. And it doesn't seem to me that they even stuck with any of these techniques long enough to see whether they work, how they work, or how they should be gradually improved. It seemed like we just went hopping from one gimmick to another. It wasn't the fault of the practitioners, but it could be viewed as the fault of the political appointees who were trying to make an impact in a two-year period when they were in office. It's just a fact of life. Otherwise one is nothing but a front man.
Bob: It was interesting to observe how all these exogenous forces interact on the process.
CONTRACT IMPLICATIONS
Ron: In today's environment, many of the contractors are losing money due to some of the procurement techniques. It makes them wonder whether fixed priced contracts or the fixed price incentive contracts (the way they're structured) are weighted against them. One wonders whether eventually that whole process will swing the other way and some of the planning and control systems will come back.
Bob: I have a personal bias which says that the Government should use CPFF or fixed price incentive contracting for design and development and use fixed price for production. That gives you flexibility when system design is going on. Use of CPFF contracting may cost more than fixed price contracting, but it can be cheaper in the long run. Especially it if reduces production costs. In any event, a better system will usually be achieved because you have a contractor with a much better working climate and more willing to take redirection from the Government. You don't have to renegotiate a contract every time you want to redirect activities and it's just a much better way of doing things. Unfortunately, Congress and others in the recent past thought that CPFF-type contracting was giving away the store. And I don't share that view at all. Very, very recently we seem to be changing back.
At about any point in time, there are a lot of clear inconsistencies between the regulations and other guidance applicable to any given system acquisition. MITRE once proposed to do an in-depth analysis of all directive and guidance material applicable to a certain medium-sized ESD system acquisition. The program manager responded, “No, don't change a thing, I like it inconsistent, that gives me some room to maneuver.”
Chuck: I guess my feeling on C/SCSC is that it has become very bureaucratic. People look at BCWS, BCWP, ACWP, LRE, etc. Then they run all the computations utilizing ten formulas and compile great numeric tables. This way they don't have to indicate a problem, but if one comes up later on, they can say, “It was in the data.” Also, you find people who never have looked at the schedules. They just run off mathematics. Even in teaching C/SCSC these days, they don't talk much about “Format Five, ” which is for your explanation. I don't think most people realize that they can go to the contractor's plant and see the whole trail of comments on slippages that are available there.
TECHNIQUES VERSUS PEOPLE
Bob: I'd like to switch the conversation a little bit to talk about techniques versus people. If MITRE's President were sitting in this room at the moment, he would probably say something like, “The real way to get a project in on schedule and on budget is to assign very good people to the project. And let them use whatever techniques they want to use. That way you get something reasonable, or if the plans are totally unreasonable, that part would surface also. But I'm not going to worry too much about whether we have so many bits or bytes on a management control system. ” I talked to a Navy Captain once about a relatively small project, probably 25 to 35 million dollars, and I asked him if he used any of these advanced management techniques and he said, “Hell, no. I got three good guys on the project with me, and we stay on the phone 24 hours a day talking to people about the project. What do we need PERT for?”
Chuck: Well, I remember being at a meeting one time when the Air Force SPO staff for program control reported that according to their PERT predictions from the prior week we had missed a beneficial occupancy date. And the SPO director turned and said, “Did you ever think of using the telephone and calling those guys up?” I think this is the same thing you were saying.
Ron: Maybe that chap with the three people could have gotten by with one or two if he had a system that integrated across the interfaces.
Chuck: I don't know, I guess you and I (Bob) are of the school that says that you don't rely on anything that's coming in by electronic transfer of data. You have to look the guy in the eye. You've got to see whether he is sweating when he tells you that he's going to make the date.
Ron: In one way industry takes advantage of the personal contract. They make the project manager give a monthly or a quarterly presentation to “top corporate management” using these tools as the basis. In that way, the PM has a better data base, one over which there is more control, to support decisions. It's really more of a decision support system. Maybe that's the best we can hope that it evolves to. As decisions get more and more complex, and they are with the bigger projects, the PM has an adequately sophisticated, and indeed a more sophisticated decision support system to use. If additional backup is needed, the PM knows where to go.
Chuck: I'll be the devil's advocate. The PM has a procurement person there and a subcontracts person there and, in fact, if either one doesn't produce they are fired. If the engineering person doesn't produce, that person is fired. Anyone who doesn't produce, will be fired.
Bob: I can remember we at General Dynamics had monthly progress meetings, For each major program we had a control room, the kind Chuck used to work in. The B-58 program had a project management center probably six times as big as this office. All around the walls were summary data charts for each of the 12 or so subsystems, e.g., propulsion, navigation, flight control, landing gear, etc.—twelve or fifteen parts of the air frame. Maintaining this data was not done by just anybody. Very good people worked on and maintained it on pretty much a 24-hour per day basis. I find it hard to believe that PERT could give the company manager a better handle than they already had.
Chuck: I think that in industry, as I know it, the chief management tool was to have everybody sign the schedule.
I think that we're all saying that networking on PERT techniques are useful as a planning tool. We don't disagree with that at all.
Bob: Let me share an experience with you. At the Ballistic Systems Division in the early 1960s there was an officer who was responsible for a work group reviewing planning documents. One day he called ESD and said, “Hey, we have a nifty little management tool. If you people have enough time to listen, we'll tell you about the new management system we developed.” We said, “Sure.” So he told us that the “system” was developed to help the principal Air Force officer responsible for one or more Minuteman missiles. If he has any problem he cannot handle in the field, he calls straight into the command section of the BSD to report the problem. Whereupon the BSD Commander assigns a senior BSD Colonel to that problem. The Colonel has three days to get out there, find out what the problem is, get back, and make a recommendation as to what to do about it. And they solved problems that way.
Ron: I think the three of us have agreed that PERT is fine in terms of a planning tool; reporting and control maybe less so. I guess a lot depends on how it's used. Have you seen instances of proper use as a control tool…reporting and control tool? Maybe design or program change control is a key thrust here.
Chuck: That's a very good point.
Bob: Along that same line, some engineering directors still think that planning is where you put guys that have failed elsewhere in the organization. If you're labeled too heavily as a planning expert, it can be the end of your career.
THE REALITY OF PM TODAY
Ron: While we could reminisce and talk for days on this subject, our tape is winding down. Lets try and summarize a few points.
The Project Management Institute has been instrumental in recognizing planning as a profession. It gets back to the people. One of the most important things is to get a team of good people. You've got to get knowledgeable and interested people to put the plan together. And another issue is the hardware and software: while it's better, and it's certainly better than it has been in terms of memory capacity, and it can produce prettier network charts, but this isn't the constraining factor. It can't do the job. Each organization probably has to have their expert that knows the latest and the best hardware and software, but you don't want to spend too much of your resources in that area per se; you want to spend it having planning people that can do the work and get the reasonable plan on the table. Is that a reasonable summary of what we discussed? Want to add to it?
Bob: Well, one of the prime benefits of PERT as I have used it over the years has really been to minimize surprises. In other words, you want to get the story out, the accurate story as early as you can. What you do with the story once you have it and whether the bureaucracy will buy it or suppress it, or all of the above, that's a separate issue. All it can do is get the most reasonable story out early and minimize surprises and also lay out your alternatives which you can neatly do with PERT/CPM, and it's value added to the project, the program.
There is a myth which says a program manager is given sufficient resources and authority to accomplish the program. In fact, this is seldom true. The PM is subject to a variety of outside pressures to change this, do that, or do something. Some of these are directed upon him and some of these are highly recommended but not directed. And so the PM is stuck between a rock and a hard place. By becoming a program manager, the commitment was made to bring System XYZ in, on budget and on schedule. Left to the PM's own devices and double the budget, it could probably be done. But the PM is never given such freedom. Congress pulses DoD, DoD pulses the Air Force, Air Force pulses the program manager requiring changes in system design, schedules, budgets, etc. This area has nothing directly to do with PERT, but it is part of the environment that PERT must function within. The program manager who planned on the basis of the resources needed, in fact, doesn't have them and may be told to do things that were not contemplated initially. You simply say, “Yes, sir,” salute smartly and walk off.
That opens up a whole new area; modern project management encompasses a heck of a lot more than just planning and control techniques such as PERT or CPM. You have people problems, organization problems, quality problems, change and configuration problems. You name it. we've got these kinds of issues.
Ron: It sounds like those are good topics for another session. Bob and Chuck, I want to thank you on behalf of PMI for sharing your remembrances of the “early days” of PERT/CPM, and how 30 years of changes, good and bad, have affected implementation considerations.
Charles S. Enright received his AB and MA degrees from Harvard. Joining Martin-Orlando in 1957, be became Planning Manager of Central Planning and Advanced Design. He joined MITRE in 1962 and was a member of the working group that created the 375 series of AFSC Manuals. Joining Peat Marwick in 1967, be was responsible as Principal for support to the founding of DSMC. He subsequently served various administrations in the Office of the Secretary of Interior, being awarded a medal by Secretary Andrus for his services to natural resource management. Returning to MITRE in 1979, he provides consulting support to acquisition projects.
Robert L Hamilton, now retired from the MITRE Coloration, obtained his BA from Yale University in 1948, and his LL.B. from Harvard Law School in 1951.
After practicing law with a leading Boston firm, Hamilton served as a Teaching Fellow at Harvard Law School and simultaneously as a Research Associate at MIT. From 1955 to 1960, Hamilton served as a contracts representative and supervisor for General Dynamics Corporation.
During the 1960s, 1970s, and 1980s, Hamilton was a Department Head at MITRE. He helped MITRE and ESD implement the PERT and other project management tools.
Ronald M. Lehrer earned a BS degree in Aero-Engineering from Rensselaer Polytechnic Institute. He is with Systematic Management Services, Inc. He has over 30 years of professional experience in program and project management. He was one of the early implementors of PERT/CPM techniques at General Electric Co. in the 1960-63 period. He contributed to the development of and taught the American Management Association PERT/CPM course.
Mr. Lehrer has been a member of PMI since 1979. He was the Mass Bay Chapter vice president and is currently on the Board of Directors. He was also Assistant Project Manager for the annual PMI Seminar/Symposium in 1981 held in Boston.