Tuesday, July 1, 2014

The Flawed Foundation of PERT


By Alexander Laufer and Jeffrey Russell 

One of the most well-known building blocks of project management is the PERT (program evaluation and review technique) method.1 In his comprehensive review of the development of project management, Morris reports:  “Polaris developed a management control procedure [in 1957], PERT; this, together with CPM, was the progenitor of the management systems which over the next 20 years were to become (almost too) synonymous with project management.”2

What evidence was provided about the effectiveness of this scheduling methodology to ensure that it would become almost a household word when discussing project management?  This is how Morris describes the publicity of PERT: “Admiral Raborn and the SPO [Special Projects Office of the U.S. Navy] public relations machinery began publicizing PERT, hailing it as ‘the first management tool of the nuclear and computer age.’  So effective was the publicity that when the first Polaris missile was launched in 1960, press coverage of PERT was almost as great as the coverage of the launch itself.  By 1962, the U.S. Government had issued 139 different documents and reports on the technique.  By 1964, the bibliography on PERT comprised nearly 1000 books and articles…. There is, however, considerable evidence that the method was deliberately oversold, with the aim of keeping Congressional and other external critics at arm’s length.  Raborn used PERT as a tool to control his external environment.”3

One of the sources that Morris used for his analysis was a detailed study of the development of the Polaris system conducted by Harvey Sapolsky.  Here are some of the surprising results of this study, as reported by Sapolsky: “In interviews with contractor executives reviewing their experience with the original PERT system, not one of them said he had used the data generated by that system… Instead, many thought it was the SPO technical officers and engineers who actually had used the PERT system data.  The technical officers and engineers, in turn, denied ever using PERT data… they thought it was the program evaluators… who made use of the PERT system… Persons who held positions in Plans and Programs, however,… never used the system; rather they thought that it was… the plant representatives who worked with the PERT reports.  The plant representatives were similar in their response: ‘No, it must have been someone else.’” 4

Sapolsky concludes by “putting the myth in perspective”:  “An alchemous combination of whirling computers, brightly colored charts, and fast talking public relations officers gave the Special Projects Office a truly effective management system.  It mattered not whether the parts of the system functioned or even existed.  It mattered only that certain people for a certain period of time believed that they did…. The Special Projects Office won the battles for funds and priority.  Its program was protected from the bureaucratic interferences of the comptrollers and the auditors.”5 Polaris was a success, but what really stood behind its success?  Davies and Hobday highlight the real practices that contributed to the Polaris’s success: “PERT was not actually used to build the system…. Instead Polaris’s success was the result of inspired leadership, good management and a shared spirit of commitment… PERT… was a deeply flawed management tool…. used primarily to impress visitors… and to build up a myth of management effectiveness. ”6

Stout addresses the wider and long-lasting implications of disseminating the myth, the rational method, while at the same time ignoring the real soft practices that led to Polaris’s success: “What is retained is not an understanding of the actual practices, but the magic and symbolism of ‘the system.’… The assumed effectiveness of PERT was not based on an evaluation of its role in Polaris; rather it was a matter of inference.  The inference took the symbolic form: Polaris was a success; PERT was used; therefore, PERT was at least partially responsible for the success.  Even if the second claim was true, and it is not, the inference is still questionable.  But it is on this that PERT has achieved its popularity.”7

Our questions:

  • To what extent do you think that the quick popularization of PERT can be attributed also to the prevailing assumption that one can (and should) impose “geometric order” even early in the life of the project?
  • Are you sure that the current popular project management methods and tools are supported by better evidence than the ones that were used to support the effectiveness of the PERT method?8



       1.      This blog is an excerpt from: A. Laufer, Breaking the Code of Project Management, New York, NY: Palgrave, 2009, 5-6. 

2.      P.W.G. Morris. 1994. The Management of Projects. London, UK: Thomas Telford Services, 25.  Program Evaluation and Review Technique (PERT) is an event-oriented network analysis technique used to estimate program duration when there is uncertainty in the individual duration estimates. Critical Path Method (CPM) is a network analysis technique used to predict project duration by analyzing which sequence of activities (which path) has the least amount of scheduling flexibility.  

3.      P.W.G. Morris. 1994. The Management of Projects. London, UK: Thomas Telford Services, 30-1.

4.      H.M. Sapolsky. 1972. The Polaris System Development. Cambridge, MA: Harvard University Press, 123-24.

5.      H.M. Sapolsky. 1972. The Polaris System Development. Cambridge, MA: Harvard University Press, 129.

6.      A. Davies and M. Hobday. 2005. The Business of Projects: Managing Innovation in Complex Products and Systems. Cambridge, UK: Cambridge University Press, 151-52.

7.      R. Stout Jr. 1980. Management or Control?: The Organizational Challenge. Bloomington, IN: Indiana University Press, 25-6. 

8.     An article on the same subject, stressing the need for more elaborate case studies like Sapolsky’s research, was published in 2012 by M. Engwall:  PERT, Polaris, and the realities of project execution. International Journal of Managing Projects in Business 5.4, 595-616.

Friday, June 6, 2014

Saving Lives: Expecting Problems or Burying Them


By Alexander Laufer and Jeff Russell
In our current blog we will use metaphors from hospital life to highlight two different approaches for dealing with problems. The first is a story told by Terry Little:

Life in the E.R.1

Contrary to what my wife would say, I don't watch much television. I do, however, regularly watch one show on the Learning Channel—the reality series Trauma: Life in the E.R.

While watching the last episode, I recognized parallels between what was going on in the emergency room, with its host of accident and gunshot wound victims, and what goes on in successful project management.

First, there was a sense of urgency, but not haste. As an ambulance or helicopter brought in patients, the physicians, nurses and technicians did some quick planning, anticipating the likely condition and needs of the patient. They moved to get the necessary tools and equipment in place before the patient arrived.

Once the victim appeared, there was no wasted motion. With time as the chief resource, no one did anything that didn't directly address the ultimate objective—saving the victim. The medical team shared a clear set of priorities: deal with life threatening issues first, possible long-term consequences second and ignore everything else.

Each person in the room had an active role. No one was in the emergency room as an observer or overseer. Someone was clearly in charge, but typically no one waited to be told what to do. Interestingly enough, no one ever seemed paralyzed by fear of doing the wrong thing. Through training and experience the entire team operated in harmony. When there wasn't enough information to make a decision about a course of treatment, the staff moved quickly to get more information using x-rays, magnetic resonance imaging and similar diagnostics. People spent little time debating or pondering what to do next. They decided on what to do and got on with it.

Sometimes the unexpected happened and a situation that seemed to be in control suddenly went out-of-control. In those cases, there was no hand wringing or fault finding—just a measured, adapted response to the new situation. Sometimes there were mistakes; mostly they were acts of omission rather than commission. There was concern and open discussion about the mistakes, but learning was the chief consequence.

I also noted that there was a general acceptance that not everything affecting the patient was totally within the control of those in the emergency room. The staff spent their time dealing with what was in their control and not complaining about what wasn't.

The second lifesaving story is an abridged version of a bizarre episode taken from the novel Doctors,2 as it appeared in Breaking the Code of Project Management.3

It was to be a routine removal of a gallbladder. However, some problems were anticipated since the patient, Mr. A, had a somewhat complex medical history and was allergic to almost everything one could imagine.

It was my first week as an intern on Surgery. I was eager and proud to be in the operating room with the chief surgeon, Dr. Aubrey, and the anesthesiologist, Dr. Nagy, who were considered to be the top specialists in their fields.

Everything seemed to be going smoothly until Dr. Nagy started reporting some problems. From then on, it seems that things deteriorated faster than lightning. One moment the blood pressure was dropping and the next, the ECG was going crazy. In spite of all their emergency procedures, within a few minutes the ECG was flat and Dr. Nagy pronounced the patient dead.

Suddenly there was silence. No one dared speak until Dr. Aubrey decided on a course of action. He ordered Dr. Nagy to continue aerating the lungs. I wondered what was going on. After all, the poor man was dead! Then, with growing disbelief, I watched as Dr. Aubrey took over from his assistant and carefully started suturing and closing the opening. When the last suture was in place, Dr. Aubrey quietly ordered, “Take him to the recovery room. I’ll be there in a few moments.”

I was stunned. Only after I recovered my speech did I dare ask Dr. Aubrey’s assistant why they continued pumping air into the dead man’s lungs. He seemed to think the answer was obvious: “That way, Mr. A will be pronounced dead after the operation by somebody in the recovery room. This explains why no patient of Dr. Aubrey’s ever dies on his operating table….”

The intern in the Doctors story explained that another reason for Dr. Aubrey’s aberrant practice was to avoid the massive paperwork required by the hospital and the insurance companies. Thus, in addition to maintaining his perfect operating record, the surgeon was able to pass a time-consuming bureaucratic job on to the recovery room staff.

The two lifesaving cases were affected by their unique contexts and the operating assumptions of their relevant leaders. In the ER series the assumption was that they operated in a “living order” environment, thus problems were expected and were addressed swiftly which was followed by an effort to learn from them. On the other hand, in Doctors, the environment was assumed to be in “geometric order”: major problems were not expected, and if unfortunately did occur they were quickly buried.
1Life in the E.R. appears in an article that was written by Terry Little and published in the NASA Magazine, Academy Sharing Knowledge, under the title: “Project Management: The Television Show.”  http://appel.nasa.gov/2003/06/01/project-management-the-television-show/
Terry Little served as a project manager in the US Air Force where he was regarded as one of the most successful project managers. He then served as the executive director of the Missile Defense Agency, the senior civilian in an organization of approximately 8,000 employees. Earlier, he was the first director of the Air Force Acquisition Center of Excellence. Currently, Terry is a member of a research team at the Consortium for Project Leadership at the University of Wisconsin. 
2E. Segal. 1988. Doctors.  New York, NY: Bantam Books, 303-6.
3A. Laufer. 1999. Breaking the Code of Project Management. New York, NY: Palgrave, 189-190.

Wednesday, May 14, 2014

The Evolution from “Geometric Order” to “Living Order”: Four Metaphors



By Alex Laufer and Jeff Russell

“He (or she) is the light of my life.” While you may have heard this before, you know that the person described is not generating real, physical light. You understand that this is an example of a metaphor; in this case, used to describe someone who is special; valuable; memorable.

Metaphors are used constantly in literature and in everyday conversation. According to the Macmillan Advanced Learner’s Dictionary, a metaphor is “a word or phrase that means one thing and is used for referring to another thing in order to emphasize their similar qualities.

Why use metaphors? Metaphors often provide a compact vision of a phenomenon without the need to spell out all the details. They enable people to designate characteristics that are unnamable and direct attention to a certain interpretation of situations. Metaphors may also help create a new interpretation of experiences by asking the reader to see one thing in terms of something else.  

Following are four metaphors that were developed by Alex and his colleagues from Procter & Gamble (P&G), following a three-year consulting engagement. They used the metaphors to describe the evolution of project management models throughout the years, as the challenges faced by project managers evolved.

Coordination & Scheduling

One can identify four distinct generations of project management models. The first model noted as scheduling (see the table below) can be traced to the birth of the modern notion of project management during the 1950s and early 1960s when CPM and PERT techniques emerged. The model focuses on the coordination of sequential and parallel activities, just as seen with major airlines and flight scheduling problems. The scheduling model became an effective approach for managing simple projects which are devoid of high uncertainty.

Integration & Teamwork

A different approach evolved in the 1970s when organizations were faced with managing complex projects, consisting of many dissimilar, highly interdependent components, and requiring cooperation between individuals from different disciplines. The challenge here was to ensure integration and teamwork between participants. In this project management model, the project manager was expected to orchestrate the manifold, complex operations much like a conductor of a symphony orchestra.

The above two models fit squarely in a world of certainty, and can therefore function well in an environment dominated by “geometric order.”

Decision Making & Reducing Uncertainty

However, by the 1980s it became apparent that most projects suffer from changes and uncertainty throughout their lives. Thus, the third dominant project management model focused on reducing uncertainty and making stable decisions. The main tools employed to achieve this purpose were much like those used when exploring an unknown country. These included searching for as much relevant information as possible before and during the decision process, and selectively building in redundancy to buffer the unforeseen.

Integrating Tasks & People

In the 1990s, however, as time to market became the driving factor, a new project management model emerged, namely simultaneity. Effective project managers appeared to be working disjointedly, in paradoxically opposite directions. In reality their aim was to integrate tasks and people widely separated in space and time, in hierarchy and methods, in orientation and philosophy. Goals and means were not resolved sequentially and separately but rather simultaneously and interactively. Thus the simultaneous manager operated like the director of a three-ring circus, continuously switching acts based on audience response.

The last two models address a world of uncertainty, addressing the needs of an environment dominated by “living order”. 

In our next blog we will present a more up to date metaphor for projects operating in a “living order” environment.

Evolution of Models of Project Management

Central
Concept
Era
of
Model
Dominant
Project
Characteristics
Main
Thrust
Metaphor
Scheduling
1960s
Simple,
Certain
Coordination
Scheduling
regional airline flights
Teamwork
1970s
Complex,
Certain
Cooperation
between
participants
Conducting a
symphony
orchestra
Reducing
Uncertainty
1980s
Complex,
Uncertain
Making
stable
decisions
Exploring
an unknown
country
Simultaneity
1990s
Complex,
Uncertain,
Quick
Orchestrating
contending
demands
Directing a three-ring circus
continuously
switching acts
based on
audience response


Reference
Laufer, A., Denker, G., and Shenhar, A.J., “Simultaneous Management:  The Key to Excellence in Capital Projects,” International Journal of Project Management, 14(4), 1996, 189-199.

Monday, April 14, 2014

"First, Define the Problem" - Why Do Experienced Project Managers Not Follow This Rule?


By Alex Laufer and Jeff Russell

The rationale for setting project objectives is obvious: without proper objectives (translated into technical requirements) the project team might try to do the task right without doing the right task. The example from Alice in Wonderland articulates it succinctly: “If you don’t know where you’re going, any road will get you there.”

Indeed, the negative implications of poorly defined requirements have been discussed in the literature. To avoid these negatives, the common recommendation is to develop the complete set of requirements prior to embarking on the means for accomplishing them. However, the following story, told by Dr. Michelle Collins from NASA, suggests that some project managers do not accept this recommendation.

At a meeting of NASA Project Managers, the group was involved in an exercise on requirements. She narrates:

“You are given a project to develop the software for an Automatic Teller Machine (ATM). Write four requirements… The group was a mix of senior and junior Project Managers (PMs). We broke into pairs to come up with the four requirements for the ATM, and then we regrouped to discuss our findings. Several of the pairs consisted of one senior PM and one junior PM…All three senior PMs gave requirements that were extremely brief and general; the junior PMs offered lengthy and fairly explicit requirements.”

            An example of a pair of responses follows.

Senior Project Managers

Junior Project Managers

Functionality  
Provide money in the form of $20s with no fee and warn Home Office of empty condition at least one hour in advance of becoming empty.

Reliability
With minimal annual maintenance, the ATM does not break down.

Security  
The ATM communicates with the Home Office continuously including a video feed.

User-friendly
The ATM accepts at least 10 major credit cards and operates in 6 major languages with complete instructions provided where a withdrawal transaction, including printing the receipt, occurs in less than 60 seconds.


Prior to discussing the intriguing question of why the veteran project managers exhibited caution and refused to elaborate the requirements, we will share results of three relevant studies. In the first study, 39 experienced project managers at 11 large US corporations (e.g., AT&T, DuPont, Exxon, General Motors, IBM, and Procter & Gamble), were interviewed by the first author. Each interview lasted about a half-day, and it focused only on one project which was studied in great detail. The results showed that these project managers did not adhere to the rule “Define the problem, then solve it,” or, “Objectives first, means second.” Rather, in almost all the 39 projects the requirements specification process was not an isolated activity, and it was not completed before searching for alternatives began.

In the second study, of 211 R&D projects, it was found that the extent to which the project’s business and technical goals were well-defined at the time of initiation was not significantly related to the project’s eventual success or failure. However, late in the life of the project the relationship was statistically significant. Business and technical goals for successful projects became better defined over the life of the project than did the goals for unsuccessful projects.

The third study, of 308 decision processes in West Germany, also demonstrated that the goal formation process was not completed before the beginning of the problem-solving activity. This study provided the rationale behind this behavior:  namely, the insight into possible solutions influences the decision-makers’ ideas of what they really wanted.

Indeed, a similar rationale was provided by Professor James March of Stanford University, a well-known authority on organizations and decision-making who concluded that: “The argument that goal development and choice are independent behaviorally seems clearly false. It seems to me perfectly obvious that a description that assumes that goals come first and action comes later is frequently radically wrong. Human choice behavior is as much a process for discovering goals as for acting on them.”

Now we are better equipped to reflect on the opening story regarding the level of detail in the requirements given for an ATM machine by the two groups of project managers. It seems that the experienced project managers knew that because the scenario was posed early, at the beginning of the conceptual phase of their task, it was advisable to first quickly examine the means rather than immediately attempt to formulate the requirements in great detail. Specifically, they wanted to examine the means to learn better what they really want and if they can afford it. To use the terminology presented in our first blog post, they realized that they are still in the living order phase. The inexperienced project managers, on the other hand, wrongly assumed that they are already in the geometric order phase.

In future blog posts we will present specific practices used by successful project managers to identify and facilitate the appropriate pace of moving from living order to geometric order, so that they can finalize the formulation of stable project requirements, as early as possible, but not too early.

SOURCES:
  • Collins’ story: “Lessons from NASA Project Managers,” Michelle Collins. 2001.  Ask Magazine 3 (June): 26-9.
  • First study: “Letting Go of Once and for All,” Alexander Laufer. 2003. Ask Magazine 13 (August): 40.
  • Second study: N.R. Baker, S.G. Green, and A.S. Bean. 1986. Why R&D Projects Succeed or Fail. Research Management 29, 6 (November-December): 29-34.
  • Third study: J. Hauschildt. 1986. Goals and Problem-Solving in Innovative Decisions. In Empirical Research on Organizational Decision-Making, eds. E. Witte and H.J. Zimmermann, 3-19. North-Holland: Elsevier.
  • J.G. March. 1976. The Technology of Foolishness. In Ambiguity and Choice in Organizations, eds. J.G. March and J.P.Olsen,69-81. Bergen: Universitetsforlaget.