The Critical Path
n making the change from the Structural Engineering Department, I had wanted to be doing computer work. I had wanted to write programs and develop computer systems. That really was the attraction for me. And now here I was, the head of this “computer” department. I now had my own small office and several people worked for me. But there was a problem: there was seemingly no computer work to do.
The small department I now headed was known as the Planning and Scheduling Department. They were the computer department only in the sense that this scheduling function that they performed was the only one in the company that actually used a computer. I had only the vaguest idea of just what the fundamental thing was that they did. I was to find out, but I wasn’t much interested in it in when I did. However it was a condition of me taking over that I would also run this so-called Planning and Scheduling department. And it was here that I was to learn all of the several meanings of the phrase “the critical path”. Some of them turned out to be critical in ways I had not expected.
From a career perspective, hierarchically, I had moved up a notch, maybe two. I now headed a sub-department within a rather large department, the Project Management Department. It was arguably the most important department in the company. And I had a new boss. His name was Chuck Strowe. He was, I believe, titled the Director of Engineering.
Fundamentally, the company was divided into two parts, one was Engineering, the other Construction. Strowe was in charge of all of Engineering and he had several hundred people working for him. He was a firebrand, a heavyset, middle-aged, light complexioned man with thinning, straight, white hair, always neatly combed. He was a man whose face turned bright red when he became vexed, which occurred easily and often. He was in charge of all the project engineers, at least one of whom managed each project; a large project might require several project engineers. He controlled all the other engineering departments as well.
He was feared by all for his explosive nature. Perhaps a short fuse was a useful quality in the position he fulfilled; were project engineers in the military they would be Captains and Majors, and perhaps a Colonel or two. They were the shakers and the movers who made things happen and timidity would have been rewarded by failure. Strowe was, in this analogy, perhaps a Brigadier General and toughness was probably a prerequisite. Calm, worldly—though in some ways surprisingly unsophisticated. He could be genial one minute and then, for no reason apparent to me, a raging, intimidating bully that could make his subordinates, even the most stalwart of them, quiver. He certainly made me nervous.
Mr. Strowe had a very large, carpeted, corner office with an elegant wooden desk and a large leather chair. Perquisites of office, or their lack, were everywhere evident in this strongly hierarchic company. In one corner of this bright office, where the two large floor-to-ceiling windows came together at right angles, one had a rather grand view of the city; I think it was from the 27th floor. Just in that corner he had an elegant glass cabinet that he had acquired in Japan. Oriental in design, it was framed in thin, delicate wood with a glossy, black enameled surface, and in that cabinet was an exquisitely dressed Japanese doll, a representation of a kabuki actress I believe.
Strowe had worked for Blaw-Knox for many years. Just after World War Two he had been stationed in Japan taking part in building some sort of rubber processing plant. He was proud that he spoke a few words of Japanese. Stamp collecting was his hobby and, through his travels and his dedication to the task, he apparently had quite an extensive collection; it was said by others to be worth a considerable sum. He seemed to me a rather strange mix; part uncultured, Midwest farm boy, and part the worldly traveler. He had through those travels acquired a patina of sophistication of which he had become extravagantly proud. Strangely, one on one, he was quite pleasant to chat with, but one had always to follow his lead, taking care to be the passive actor; he saw center stage as his natural position.
Though I was in the Project Management Department now, I was not a project manager. Project Managers, or Project Engineers aspiring to be managers, are in charge of projects, their technical aspects, their financial aspects, customer relations and the political aspects that seem always to accompany these elements. Their main job: keep the ball rolling; crack the whip.
Instead I seemed to have become the head of a project management support group, one that had apparently been developed to keep the project managers and engineering managers honest. I reported directly to Mr. Strowe. In a manner of speaking, I was the official tattletale of the whole shebang, and even of the construction department: Mr. Strowe had a direct line to the president of the company and was, in turn, his snitch. None of this was spiteful; in fact it was embedded in the standards of the company. As with the writers of the United States Constitution, it was understood by the company that, human nature being what it was, checks and balances were required. I was, in effect, an auditor, but of time (scheduling), not of money. Mr. Strowe was used to people lying to him or at the very least putting the best face on a fraught situation.
My group developed plans and schedules for each big project. The notion was that this would provide an independent estimate of where the project ought to be, timewise, which could then be compared with where we actually were. At the beginning of the project we prepared a detailed schedule of future tasks that had to be performed in order to complete the project, on time. Then, actual progress was periodically compared to that plan. There was another complete department, unaffiliated with Engineering: The Cost Control Department, which reported directly to the head of Accounting for the company, in effect doing a similar auditing job with respect to money.
I have come to understand that there are several reasons why nearly all projects—to this day—are late and over-budget. The most important of these is that in the Engineering and Construction business each project is unique and the opportunities to incrementally improve, model over model, as one might advance, say, the design of a washing machine, or an automobile, over the years, does not exist to any great extent in this business. And that is because the conditions that surround each project, both physical and political, as well as its geographical location is unique. The second, and perhaps more important, reason is that the people developing the estimates of cost, and the time it will take to complete the project, are invariably optimistic; if they weren’t, they probably would not have been hired for the job in the first place. Engineering and Construction—as in the military—is an endeavor for optimists.
The Critical Path Method is a technique for planning projects step by step. Projects are by definition one-off efforts, each with a distinct starting point and ending point. Consider the design and construction of a building, a refinery, a submarine, a computer program, or a particular sort of spacecraft, as opposed to, for example, a continuous process such as bottling Coca-Cola, or the rolling of steel beams. These latter undertakings, “manufacturing” jobs, are intended to go on pretty much continuously until something breaks down; no “end” is foreseen, or desired.
For Engineering and Construction projects, for software, and for other development projects as well, a project plan is usually developed from a theoretical—even if unknown—point in time when the project is to start, then a set of tasks are defined in such a way that, after all are completed, one will, if fortunate, arrive at an end point, and then the project will be finished. A project has a start date and a projected finish date. In the network diagram here—a trivially simple one—node 10 is the start date and node 50 is the finish date. This sort of diagram is how projects were scheduled some decades back. There are newer and more efficient methods of diagramming in use today.
For large projects—larger, say, than preparing thanksgiving dinner—the project schedule is defined as a network of tasks which are connected together in a logical order: one has to put in the foundation, say, before one can erect the superstructure, put up the superstructure before one can erect the wall siding and the roofing, and so forth. All of these tasks, and the ways in which they relate to each other, are then fed into the computer and the computer software calculates how long the project will take by summing up all the many paths through this network. The longest one is termed the critical path, the one that tells you when the project will be completely finished. This is by no means the only path of significance, it is simply the longest one. In the diagram above there are actually two equally critical paths: 10-30-40-50 equals seven months; and 10-20-50, which also equals seven months. The diagram shows a plan; there is as yet no progress. But, as progress is made during the execution of the project, the critical path can change as activities finish earlier or, more likely, later than planned for.
For some complex projects thousands of steps might be planned out and linked together logically in a manner such that, during the execution of the project, as things change, the computer software will run through the network again and again, showing the effects of that slippage on all the other affected “downstream” activities, those that depend upon it. This will show how much later—or, rarely, how much earlier—the project will finish than had originally been planned on. Some projects may, after all, take several years, conceivably decades, to complete and it is difficult early in the project to determine just how changes that have had to be made in those first months or years, will change that date, far in the future, when the project as a whole will be finished.
This methodology was initially developed by the Dow Chemical Company. Later, the first “popular” computer program that was routinely used for this work was developed by IBM. And this was the software that was being used when I first took over the department. It was very awkward to use because printed reports had to be designed, and then written in Assembler Language, so one had to know this arcane language in order to effectively use the program. For this purpose there was a fellow in my department whose name was Gerhardt Hopf.
Gerhardt enjoyed working in this low level computer language that today is rarely used except for special purposes where efficiency is paramount. He enjoyed it because he liked coding. During World War II he had been in the German Army—or maybe it was the Luftwaffe—as a radio operator. He seemed fascinated by codes of all sorts, not just computer code—they didn’t have computer codes during the war, coding then was a subterfuge used to transmit plans and orders and intelligence confidentially, and one of the main efforts of the British and the Americans was to “crack” these codes. Gerhardt once told me this synopsis of his military career:
He had been stationed in Sicily when the Americans invaded. Under this onslaught, the Germans and Italians retreated hastily to the mainland of Italy. He said the Germans had nothing but contempt for the Italian soldier, then allied with Germany. He said the Italians, by that time in the war, had little interest in fighting and ran unless constrained. The Germans were to shoot them in their backs if they ran, and did so, he said. After that retreat Gerhardt had been shipped by train to the Eastern Front to help in fighting the Russians. But there he was captured and put to work in a mine where he spent the rest of the war. It was not easy, he said; the Russians had less than no use for the Germans; they were lucky to be fed at all, and worked like slaves. When the war was over—he was somewhere in Ukraine at that time—the Russians just said, “Go home.” So small bands of German soldiers began the walk back to Germany from the East. They had no food but somehow they had obtained weapons. Starving, he said that they would dig up potatoes in a farmer’s field to eat and, if the farmer came out to complain, they just shot him. I believed him—one had only to look at him carefully and it became clear; he was not inclined to exaggeration, nor hubris.
Gerhardt also told me another story in a wryly humorous fashion. He warned me, half-jokingly, that he always carried a few special punched cards with him and that if he was ever laid-off he would zip over to our card reader, read them through, and our complete computer system would be wiped out. I think he was joking.
As I began to learn how the IBM planning system worked, I liked it less and less. First of all it was completely dependent upon Gerhardt—no one else on my staff could do programming in assembler language. But beyond that the system seemed, in subtle ways, to encourage planners to use thousands of activities. The computer could handle all these tasks quite easily. The problem was that humans had to digest its voluminous output and try to make sense of it in such a way that trends could be spotted and corrective action recommended. It was more than people could grasp. As a consequence, the plan for what was only a medium sized project quickly became huge and almost uncontrollable. But more importantly, the system was fundamentally flawed in that the people who actually had to do the work that was being scheduled had little or no input into the plan. This had traditionally been the planners job—so how could the engineers and constructors themselves be held responsible? If some planner had decided that something ought to take 10 days and the engineer took 20 days to do it, the engineer could simply say, “Well, I didn’t say it would take 10 days!”
The process was so awkward and essentially cosmetic that was then used only rarely, for big projects when we wanted to impress the customer with our advanced computer technology—it was advanced, I imagine, for those days, which I suppose now to be sometime in the early 1970s.
When I was in structural engineering I had used STRUDL, the structural design program, so I was aware that there was another of MIT’s Integrated Civil Engineering Systems called Project I. This program was intended for project planning and scheduling. It was similar to the IBM program we had been using, but slicker. And, as with STRUDL, it had been developed by graduate students. One of them, a fellow named Bob Daniels, had worked on this program at MIT. Developed by students, it was pretty buggy, even more than was STRUDL. So, when Daniels left school he began to improve it on his own—the school version was in the public domain. Thus he developed a commercial product that he named Project2.
The program worked very much like STRUDL in the way that information about the project could be entered easily in what was then known as “free-format”—until this format became available all information had to be punched precisely into just the right punched card columns, the source of many errors. With the MIT programs this was no longer a requirement; the computer software figured it out.
I got in touch with Daniels and he said his version was already on the McAuto computer system in St. Louis that we were using then, and that he would send me a contract. He didn’t sell his program he charged a fee for its usage—the more you used it, the bigger the fee. It was expensive. But it had many benefits. Instead of using Activity on Arrow diagrams (as shown above) it used a different and simpler method. Activities were the primary entities. And they could have properties themselves besides simply a duration: which department did it belong to? How critical was it? What physical part of the project did it have to do with? These trivial sounding things permitted the printing of reports of just certain activities, and made analysis of the project a great deal simpler. And there were several types of relationships a available to connect activities; this had the benefit that fewer activities could be used, yet the modeling of the tasks themselves was better. This gave us a lot more freedom. And, importantly, we no longer needed assembler language programming.
I convinced Mr. Strowe to use Project2. It was a relatively easy sell because most of our big contracts were at this time cost-plus; we just passed the cost on to our customer—with a markup. The second part of the problem was harder to solve: how to get the people doing the work to take responsibility for the schedule on themselves. The only way I could think of to do this was to get them to make their part of the schedule themselves. But they didn’t know anything about the scheduling program, and didn’t want to learn.
The answer to this problem was to develop small “standard” networks of activities for each department based on earlier work that had once been done at Blaw-Knox during a slow period. The various tasks that each department performs are done, with minor variations, over and over, project after project. So we could start with a model project and then simply make, with the engineer’s direction, minor modifications, adjustments, some additions and subtractions. Thus we tailored our standard network to specific projects, and we did it quickly.
In a round robin fashion, we would get each department’s representative—the guy that would actually be responsible for the work—to come into our office and review their part of each standard schedule with one of my planners, adjusting activity durations and the logic that connected activities to conform to the requirements of the actual project at hand. Thus it took less than an hour on average for all the work for a particular department to be modeled. Interdepartmental connections were built into the standard network; the Structural Department needed information from the Vessel Department before they could design their supporting beams, but that requirement had already been built into the standard network.
At the end of each session I had each engineer initial what had been decided upon by them for this particular project. Some of them didn’t like this of course, but in these cases I would calmly ask them whether they would like to make an appointment to see Mr. Strowe. They immediately pictured him turning red, and that was generally all that was required. Now, they were on the hook for what they had agreed to do. Well it wasn’t that simple, but that was the gist of it.
All of these changes to the process, taken together, had a bigger effect than anyone, including me, had expected. The understanding that each of the engineers had developed their part of the plan themselves gave them an incentive to make the plan come true, or to have a good reason why not. This had never before happened. And some engineers, the younger people especially, began to like the idea of assuming personal responsibility. This, in a curious way isolated the holdouts who then were moved to cooperate, if reluctantly, because their peers seemed to be doing so.
During the execution of the project we reviewed each plan monthly (a typical company project took a couple of years to complete) with each engineer and the construction manager for that project, and then we updated the schedule. The questions we asked: Did this activity start? If it had, when would it finish? The engineers and construction managers knew these things that were in progress intimately. Then we ran all these changes through the computer program again, and it would project the overall affect of all the progress—or its lack—for the project as a whole, including the many activities that were scheduled for far in the future.
If the end-date of the project, or one of its main logical paths, slipped—a frequent occurrence—then we could pretty easily analyze why, get the right people together, and figure out what would have to happen to get the plan back on schedule: Did they need more people? Did they need information that they otherwise couldn’t get? Was equipment being delivered on time? We could often make things like this happen because we had unfettered access to all the chief engineers and purchasing agents. Arms could be twisted; we could make things happen that a mere engineer often could not. And we always had the end of the project, which would otherwise slip, as a hammer: “if you can’t make this happen then the project will be late and all hell will break loose, blah, blah, blah… ”
Then I began to publish each month, in pretty forthright language, a brief written executive summary of the project as a whole, for people who didn’t want to get into the detail. I tried to keep it to one or two pages. This was my first venture into writing. Management liked this, and so did our customers, who now, for the first time, we tried to involve actively in the design and the execution of the project. We began to schedule customer activities—work they had to perform or, more likely, information that they had to provide us. Many delays of projects are actually the fault of the client or others for whom they are responsible, and this process made their transgressions as obvious as ours. This reverberated up their chain of command and often made things happen that would otherwise not have.
All of this seemed a big improvement to the company’s management over what had gone before, which had been more like eye candy. And customers were impressed with the amount of attention and control that we seemed to exhibit over their projects. This ended up working so well that we were called upon to do it on every project of any size. I was told to hire more schedulers. This was my first experience at internal entrepreneurialism.
I was not used to this sort of work, work in which I would have to: facilitate people working together; do a fair amount of politicking; and talk to groups of 10 or 20 people. I’d never done this before and it made be uncomfortable at first. Then I got used to it, though I still didn’t like it much. Fundamentally, I still wanted to develop software. Yet all I seemed to be doing was sitting around tables talking with people. Eventually, the thought crept in on me that I was learning quite a lot about how engineering and construction was done by talking to all these knowledgeable people, over and above my knowledge of my former field: structural engineering.
One day I was called into Strowe’s office and he complained about all the trouble they were having getting material delivered to the various job sites. There was a small department that did expediting of equipment and inspection of complicated or unique equipment that was being fabricated all around the country. Some mechanical equipment and pressure vessels were very special: large, expensive and complicated. Sometimes it was necessary to ship them to the jobsite in special, police-escorted convoys along major roads or waterways, so that these extra wide elements of the plant could be transported.
This department would send people around the country to periodically inspect the fabrication of major equipment to make sure that it would be delivered on time. Their recordkeeping, to the extent that they did it, wasn’t the best, and worse, they considered it private. Yet we needed that information to plug into the project schedule because this stuff had a big effect on the project. We weren’t getting this information, nor was anyone else that was working on the project.
I told Mr. Strowe that we could probably work something out to make this information more visible, but that nobody would like it. He said to me, characteristically turning red just thinking about someone not doing what he had said to do, “If they don’t like it, tell them to come and see me!” So we did. And nobody wanted to see him. I had the perfect club.
Finally I was developing software. We called this new system the Material Status System or MSS for short. It kept track of all the hundreds of elements purchased for a project, from simple commodities such as pipe, siding, electrical cables of various types to all the pumps and tanks and heat exchangers and vessels that were required. We published a weekly report showing the status of all this procurement for each project to each of the projects’ group leaders, the information coming—if reluctantly—from various sources. We added a piece of information to the system we developed that related each piece of equipment—and there might be hundreds—to a particular activity in the schedule. That way we could print out the equipment dates by activity and easily update the schedule ourselves without even talking to the expeditors. This was a very simple system compared to the software used for performing engineering and I was surprised at how impressed people were with what seemed to me to be such a trivial thing. I learned that it is not always the technically difficult things that are most valuable.
The effort of developing the system involved digging information out of people about how they did their work. The software was nothing really. There was an aspect to my new job that I had not expected, and that was that I had to be able to understand how people did their work. Over time, I began to realize that what I was doing was called Systems Analysis, a profession I had years ago seen advertised in the help wanted sections of a Chicago newspaper, but at that time I had no idea what it actually was. It sounded rather exotic. Now I guessed that I was one.
I had mixed feelings about all of this, partly because it seemed so technically trivial, and partly because I seemed to have become an adjunct of the Big Man in the Corner who could Turn Red. I sat in his office many times while he bawled-out some project manager that he thought had screwed up, or may have screwed up, a project manager that for me, as a draftsman only a short while ago, had been one of my big bosses. The big man turned so red and yelled so loud that the poor fellow almost cried, while I cringed in the corner of the his big office, an unwilling witness. But the big man liked me. And I came to think the reason was this: He didn’t have a degree either. He had started at the company as a draftsman too, yet he had the second or third biggest job in a company of several hundred people. I wondered whether this might be precisely why he seemed so thoroughly to enjoy his master-slave Kabuki role. Certainly he knew I had no degree either. So I suppose that was a part of why he seemed to like me and to want me present at these little stage plays. I think he was trying to teach me, but I was an unwilling pupil for this brand of almost sadistic disciplinarianism.
Each project required hundreds of drawings. Only the various departments that had made them knew how many were completed, how many in progress, and how many were still to be started—and sometimes even they didn’t know. Yet the completion of individual drawings is one of the most reliable ways of measuring Engineering completion. Each group had a way of keeping track of this—sort of. So, based on the success of the Material Status System, I proposed a Drawing Status System that would be common across all departments. Of course no one making the drawings cared much for this idea; no one likes outsiders to know just what they’re doing, especially when they are under pressure. But I had the big man in the corner that could turn red. We called this system DSS.
I had been impressed with the way that McAuto had so sped their work up by having girls on roller skates load tapes into tape drives, so I tried something similar with these two new systems. Though we eschewed the skates which would have made quite a ruckus in our office, I had a few boys and girls, well just young people generally, working for me. So, each afternoon at four I routinely sent some of them around to each department to drop off a form for the group leader of each project. It listed only the equipment and drawings that they were then working on—usually just one page, very simple. The next day we picked up yesterday’s form which it been updated by the engineers in the meantime. So we kept up with their work on a day-to-day basis, limiting carefully just what they had to look at so as not to bog them down with paperwork.
Again, there was resistance, but many of the people involved—more than I had expected—seemed to get to like the idea, and all these men liked a girl coming around to chat them up for a minute or two at about 4:00 in the afternoon. This system helped us update the project schedule in the same way that the Material Status System was doing. That made the process of scheduling even less onerous for the engineers themselves, improving their dispositions considerably.
Mr. Strowe seemed rather pleased with the systems we had put in place. Blaw-Knox had always been what I would now call “systems-oriented”, in comparison to similar companies of its size, and now he himself, with the help of a few graphics people, put together a rather impressive brochure—for those days anyway—that highlighted all the benefits that the company could bring to its customers. Key among them were those we had developed over the last couple years. Over that time my initial little group of only a few people had grown to about 30 people and, more importantly, the management systems were no longer cosmetic, they had become tightly embedded in the operations of the company. This told me something that I had not really understood well before, and my interests correspondingly shifted away from the simple development of software and toward the understanding of systems, and of how they could change organizations.
We were given a rather large new space to accommodate all the people that I seem to have acquired, some from within the company and some new people from outside. Unusually, I was told that I could arrange the space as I pleased. Before, space design had been done by a special department. Rather than chop my space up into individual offices, as was even then traditional in the company, I decided to turn it mainly into one large open area with a half dozen or so quite large round tables, each separated only by low bookshelves—we had mountains of information about each project, instruction books for software, and more besides.
Around each of these quite large tables I put two “stations” about 180°apart. Each consisted of a desk and a chair; rotate your chair one way and you were facing your desk, working personally; rotate it the other way and you were seated at the round conference table. At one of these two stations was a project-planner and at the other a person whom we had come to call a scheduling technician—usually a girl. In this fashion the planner could call in appropriate people from the various engineering and construction groups and seat them at the “conference” table for quick planning sessions.
We taught the planners how to ask the right questions so that the individual standard subnets of each department could quickly be tailored to a specific new project. Meanwhile, and unobtrusively, the scheduling technician was listening as the planner asked the questions: “Do you have to do this activity for this job?” “How long will it take?” “I see that sometimes you need such-and-such from this other department; do you need it for this project?” We developed a routine and a set of questions so that this process went very quickly. And as this interview was underway, the technician, listening silently, keyed the data into a computer terminal. This way, when the interview was done all the data had been entered as well. Then the project plan could be processed quickly through the computer and, after review by the planner, published.
One of our engineers’ main gripes had always been that “planning the job takes longer than doing the job,… ” a pretty standard obfuscation. But now many of them began to see—there are always a few hard cases—that it could be done rather quickly and, further, that they didn’t have to plan out their own dates as they had had to previously. They had never liked doing that. No one likes to commit to something that they cannot control, such as getting information they need from another department on-time. With our system all those interconnections were taken care of automatically by the overall logic of the network itself which connected each department’s activities to the others.
On a typical day our new, open-planning area was a hubbub of activity: small planning conferences with different engineering groups; network updates going on; information being gathered and summarized from our daily MSS/DSS system; schedules being processed through the computer terminal, (which was in a separate room because the line printer and the card reader were noisy). New programming was going on as well—I had had to hire a few programmers.
Our area gradually became a showcase and was always included on the tour when potential customers were being shown around, as though to say to them, “see how much we care about finishing your project on time.” This is always one of the main considerations for a customer, because every day that a new chemical plant was not running cost them a great deal of money, and the engineering and construction industry, as a whole, had become infamous for finishing things late.
But, in fact, I was now on a more critical path than I knew…