Monday, October 13, 2014

The Flies and the Bees: Tailoring Project Processes to Project Context


Peter Drucker argued that since the study of management began in the 1930s, several assumptions regarding the realities of management must be unlearned. One of these assumptions is that: “there is (or there must be) ONE right way to manage people.” Drucker further noted: “In no other area are the basic traditional assumptions held as firmly—though mostly subconsciously—as in respect to people and their management.” More importantly, “In no other area are they so totally at odds with reality and so totally counterproductive.”[i]
The following experiment demonstrates one possible “counterproductive” consequence of clinging to the “one best way” when at odds with reality:    

If you place in a bottle half a dozen bees and the same number of flies, and lay the bottle horizontally, with its base (the closed end) to the window, you will find that the bees will persist, till they die of exhaustion or hunger, in their endeavor to discover an opening through the glass; while the flies, in less than two minutes, will all have sallied forth through the neck on the opposite side.…  It is the bees’ love of light, it is their very intelligence, that is their undoing in this experiment. They evidently imagine that the issue from every prison must be where the light shines clearest; and they act in accordance, and persist in too-logical action. To bees, glass is a supernatural mystery.… And, the greater their intelligence, the more inadmissible, more incomprehensible, will the strange obstacle appear. Whereas the featherbrained flies, careless of logic… flutter wildly hither and thither, and meeting here the good fortune that often waits on the simple… necessarily end up by discovering the friendly opening that restores their liberty to them. [ii]

Indeed, the “featherbrained” team that employs a random search (like the flies) may perform better in a dynamic environment than the “too-systematic team,” which completely lacks sensitivity to variations in project context (like the bees). The challenge is to transform the “too-systematic team” and render it context-sensitive, that is, a team which applies expediently proven principles, practices, and processes as general instructions that must be tailored to each unique context of the project (e.g., project size, stability of objectives, speed, task complexity, organizational culture, extent of top management support, and team members’ experience and skills).

Following is a brief example of how the different contexts of two information technology projects affect the working culture and work processes. The first project involves the development of control software for an airplane. The proper behavior in this case is highly technical. FAA regulations must be followed. Anything you do — or don’t do — would be evidence in a lawsuit 20 years from now. The development staff shares an engineering culture that values caution, precision, repeatability, and double-checking everyone’s work. In contrast, the development of a word processor that is to be used over the web requires a different approach. “Correct behavior” is whatever woos a vast and inarticulate audience of Microsoft Word users over to your software. There are no regulatory requirements that matter (other than those governing public stock offerings). Time to market matters — 20 months from now, it will all be over, for good or ill.[iii]
Unfortunately, the prevailing project management paradigm still advocates context-free processes and practices, rather than tailoring them to the unique context of the project.  Thus, the emphasis in most projects is still placed on the “standard” or the “common” rather than on the “unique.” Melgrati and Damiani eloquently make this point: “Project management ideology is paradoxical because it focuses on repetitive aspects and ‘marginalizes’ the uniqueness and originality that should instead characterize the project.”[iv]


[i] P.F. Drucker. 1999. Management Challenges for the 21st Century. New York, NY: Harper Collins, 9, 16.  
[ii] T. Peters and R.H. Waterman. 1982. In Search of Excellence: Lessons from America’s Best-Run Companies. New York, NY: Harper & Row, 108.
[iii]  The Seven Basic Principles of the Context-Driven School. 2007. Retrieved September 1, 2014, from http://www.context-driven-testing.com/
[iv]  A. Melgrati and M. Damiani. 2002. Rethinking the Project Management Framework: New Epistemology, New Insights. Proceedings of PMI Research Conference, Seattle: 371-80. A. Laufer. 2009. Breaking the Code of Project Management. New York, NY: Palgrave Macmillan, 97-100.

Tuesday, September 9, 2014

Improvisations: The Read-Aloud Team and the Official Sniffer



By Alexander Laufer and Jeffrey Russell 
In the previous blog we focused on project planning, demonstrating how a well-known planning tool can be used effectively and ineffectively to maintain project progress. However, at times planning tools have nothing to offer and improvisation is required. Brian Muirhead, who was responsible for the development and launch of NASA’s Mars Pathfinder flight system, argues that, “Everybody understands the need for a plan… But in a world of Faster, Better, Cheaper, improvising should be seen as an inseparable part of planning, the other half of a complete process. In the fast-paced, rapidly changing world in which we now live and do business, the ability to improvise has risen to the top of the priority list of managerial skills.”1
Following are two examples of improvisations introduced in the midst of projects. The first story is told by Kenneth Szalai from NASA, who served as the chief engineer and software manager for the first digital fly-by-wire aircraft:
A systems engineer called and told me that the preflight self-test had failed…. While troubleshooting, I froze and my heart sank. The problem was far worse than some self-test tolerance setting. I discovered that a half-dozen instructions did not match the program listing!… the flight computer had contaminated instructions. We did not have the means to automatically check the computer memory against the accurate printed listing… I laughed to myself and thought: How long would it take to manually check the computer memory dump against the listing? Let’s see, there are 25,000 memory locations, if we had five teams of engineers, and they could read aloud and verify one memory location every 10 seconds, five teams could verify 30 memory locations in a minute. That would take about 14 hours.… We finished by Friday afternoon, and did not find any other errors. I guess sometimes pioneering work needs solutions rather than elegance.… We flew on Wednesday, as Carl had asked." 2
Facing enormous time pressure, Kenneth came up with a spontaneous improvisation that provided a simple, albeit inelegant, solution to the problem.
In the next case, Leslie Shepherd shares a story about a renovation project for the U.S. Federal Government. Because the buildings were occupied, the project manager was required to work around the tenants and the existing site conditions, and to do it quickly. 
The roof of a fully occupied office building was being renovated, which required covering it with roofing tar. The fumes from the tar were being pulled in by the building’s fresh air intakes, making it impossible to work. The building manager could have shut down the air intake system for a few hours at a time, but not for the entire day. After considering his options, the building manager decided to take a non-traditional approach to solving the problem. 
My solution may not have been elegant, but it was effective. We hired someone to stand on the roof next to the air intakes and sniff for tar fumes. The building manager trained the new worker how to turn the air intake fans on and off. He started work the very next day, turning the fans on or off depending on his olfactory reflexes. That was his only job and the additional salary for this “Official Sniffer” was far less than the lost hours resulting from interrupted work that had to be covered by the tenants. The building manager received no more complaints about the tar fumes for the entire duration of the roofing project.3
Leslie, like Kenneth in the first story, was under great time pressure. His improvisation is characterized by spontaneity and creativity, demonstrating that high-tech is neither the only nor always the best way to solve a problem. In today’s dynamic environment, where living order often dominates, organizations and individuals should enhance their willingness to forgo planning in favor of acting in real time.4
Improvisation is a fundamental organizational skill that allows you to work creatively and quickly in today’s ever-changing world. As the noted author Isaac Asimov has noted, “To succeed, planning alone is insufficient. One must improvise as well.”
        1.      Muirhead, B. and Simon, W. 1999. High Velocity Leadership: The Mars Pathfinder Approach to Faster, Better, Cheaper. New York, NY: Harper Business, 193.

2.      Szalai, K. Fly Safe, But Fly, 2004. NASA Ask Magazine 19, (August): 12-15. http://appel.nasa.gov/ask/about/overview/index.html

3.      Shepherd, L.L. Simple Solutions Surpass Sophistication, 2000. In A. Laufer and E.J. Hoffman, Project Management Success Stories, 82-5. New York, NY: John Wiley & Sons.

4.      Weick, K. E. 1998. Introductory essay—Improvisation as a mindset for organizational analysis. Organization Science, 9(5), 543-555.

Thursday, August 14, 2014

PERT: Micromanagement vs. Engaging Management



By Alexander Laufer and Jeffrey Russell 

In the previous blog entry we learned about a well-known and successful project where PERT (Program Evaluation and Review Technique) served as a key tool, not to manage the project, but rather to manage the external world. In our current blog we present two examples where PERT was used to manage projects, yet in two fundamentally different ways.

Micromanagement: Scheduling the Donuts1

Following is a story from Brian Rutledge who served as the project Financial Manager in the U.S. Air Force. He describes one episode that took place under the first project manager of JASSM (Joint Air-to-Surface Standoff Missile):

“The project manager demanded that we keep meticulous schedules of our daily activities. He wanted to know what I was doing every day down to the smallest detail. This applied to all of the leads on the program.

I was responsible for putting together the affordability portion of the Request for Proposal, and it was one other person and I working with five companies. To prepare a schedule as it pertained to five companies on a daily basis was a terrible burden. I was spending more time documenting my activities than doing my actual work.

This came to a head one Friday at a 6 P.M. meeting. Someone put up his schedule on the overhead. The next week we were going to have an Industry Day, where the companies would all send representatives to Eglin Air Force Base. The schedule on the overhead included a line that said, ‘Drive to the bakery, pick up donuts.’ The deputy project manager commented that this was exactly what he wanted to see in our schedules.

It may have been because it was a Friday night—the end of a long week—and I was beat; but when I heard him say this I stood up and declared that it was the most ridiculous thing I had ever heard. ‘If you want me to write down when I go to get donuts,’ I said, ‘I’ll never get to the finish line.’

Yes, you need a schedule, but you also need to be reasonable. It was no surprise that the project manager was unable to make meaningful progress and was replaced several months later.”



Engaging Management: Placing the Chart on the Side of a Large Container2

The following story is from Ray Morgan, who was the Vice President of AeroVironment Design Development Center, and the project manager of Pathfinder, a solar-powered airplane.

“From the standpoint of communicating the overall picture of what needs to be done, when and why, to the project team and our customers, the PERT chart is extremely helpful.

We put our chart on the side of a large container right in the hangar, next to the flight test crew and the airplane. When posted, it is a valuable, graphic depiction of the work plan, interdependencies, milestones, and people on the critical path (as well as which ones may need help). It also allows the team to mark it up interactively, adding tasks that come up and checking-off tasks as they are completed. We usually incorporate these changes into a computer model and reprint it once or twice a week during flight tests.

The chart is much more than window dressing, as we often refer back to it in team meetings to help redefine the importance of a current task and to see how it fit into ‘the big picture.’ This becomes a critical tool for the team. Enthusiasm for accomplishing the next goal is reborn each time we view the graphics on our wall.”

In the first example, the PERT was used to micromanage and control the team while in the second example it was used to engage and empower it. These two stories call our attention to the fact that the impact of the same tool may be completely different and will be determined by the purpose and the process of using it.



  1. Laufer, A., Post, T., & Hoffman, E. J. (2005). Shared voyage: Learning and unlearning from remarkable projects, The NASA History Series, Washington, DC, page 87.


  1. Laufer, A., Post, T., & Hoffman, E. J. (2005). Shared voyage: Learning and unlearning from remarkable projects, The NASA History Series, Washington, DC, page 160.

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.