As the profession of project management has developed, a common tension has remained between two basic views. Some professionals think projects are successful because of the personalities and abilities of the project managers, and others think projects can only be successful with rock solid processes and procedures. Which view is right?
Perhaps it is a natural outfall of meetings dominated by technically trained people that PMI tends to emphasize tools, processes, and procedures. Part of this emphasis probably comes from realizing that we can logically attack the improvement of processes in our projects, but we are less comfortable with assertions of natural leadership. Were we attending a meeting of the alumni of SEAL teams, the emphasis would probably be on the importance of leadership and teamwork, minimizing the processes.
Two of the high profile projects of last century in the United States were Hoover Dam and the Manhattan Project to produce the atomic bomb.
Hoover Dam was built with a fixed budget and on a shortened schedule under the direction of Frank Crowe. Building the first atomic bomb was judged by Niels Bohr to be virtually impossible. (Rhodes, 1986, p385) Yet General Leslie Groves directed the successful test of the first atomic bomb 35 months after he was assigned the project. Were Grove and Crowe supermen?
In an earlier time, nuclear power plants were built throughout the United States by means that emphasized processes to the exclusion of leadership. In most cases, the processes were so constraining that leadership was hardly possible. In retrospect, we have to ask: did these projects succeed through their application of processes?
In this paper I will attempt to explore this tension and give some guidance to today’s project managers about the balance between project leadership and process strength.
The subject has been of interest to me for many years. At an early point in my project management career, I was offered an assignment as Manager of Project Planning for a paper mill expansion. As I began this assignment, I commented to a friend that it was my goal to develop and apply project processes to managing the effort. My goal grew from my firm belief that there is a limit to the size of project that could be managed on the basis of the force of one individual’s personality.
In this project we took an initial forty-two month schedule and compressed it to twenty-two months, while maintaining the original budget. Less than two years elapsed from the authorization to proceed to our making sellable product. To support this we developed several tools and implemented key processes. A notable example was one used for tracking material and equipment, both promises and performance. We tracked more than 20,000 items of equipment and instrumentation coming from many nations. We developed and implemented contingency plans for vendor quality failures, dock strikes, and delivery of goods from manufacturing plants that did not yet exist when the order was placed.
In the years since, and in spite of a tremendous improvement in easily applied off-the-shelf tools, I have never seen this project function handled better. This success led to the salesman telling me, “This is the first time in my 25-year career that my company has delivered on the schedule we promised. Since I’m not aware of our having changed, I’d like to know what you did differently.”
Several of my colleagues on this project later commented that it was the best project experience of their careers. Still, when the project was over, I commented to the same friend that, “I still believe there is a limit to the size of project that can be run on the force of one man’s personality, but it is much higher than I thought.”
In recent years’ much has changed in our profession. The readily available tools have become much better. The willingness of organizations to endorse the use of formal procedures in project management has grown greatly. The presumption that intense projects are automatic absorbers of eighty-plus hour weeks has been reduced. Yet the tension between process and leadership continues to exist. Are successful projects the result of having the right project leaders or of having the right processes in place?
In a sense, the argument is similar to others in our society: Is math best taught as a reasoning exercise or as a series of intense drills? Is reading better taught as whole word recognition or based on phonics? Will increasing numbers of students “passing” NCLB standards indicate better teaching? Our society spends uncounted hours in fighting over such questions that are at best unanswerable. In all cases the answers come down to “it depends” or “it takes a mixture of both.”
To undertake this exploration we might hypothesize a graph of extreme tradeoffs. (Exhibits 1 & 2) We start in Exhibit 1 from the position that, if we have a superman project manager, we can compensate for weak, or nonexistent, processes. Exhibit 2 takes the opposite position that, with the right project processes, leadership on the project is a weak requirement.
A secondary concept is illustrated in Exhibit 3. Here we graph the cost of processes and leadership against the quality of those elements. This conceptual graph is intended to represent the cost relationship to quality in either processes or leadership. I will not attempt to prove an exact relationship but will assert that in my experience the relationship between cost and value is nonlinear. My idea is in general alignment with the Pareto principle with the following implications:
- We can achieve 80% of what we need for much less than 80% of the cost of the perfect process solution (or super leader).
- The cost relationship between a mediocre process (or player) and a solid one is not uniformly proportional to the value received.
- On the left side of the graph I suggest that good processes need not be more expensive than poor ones. Competent people are available at the approximately the same cost as incompetent ones. In a very real sense careful selection of people and processes need not add to our project costs. As Phil Crosby says: “Quality is Free” (Crosby, 1979).
- On the right side of the graph I suggest that superstars may well cost more than they are worth. “Getting the right people on the bus” does not mean that our project leader must be a “franchise player.” As Jim Collins puts it success does not come “From a genius with a thousand helpers.” (Collins, 2001, p41) Similarly, the pursuit of “perfect” processes can bankrupt the project without providing commensurate return.
In Exhibit 4 we represent a less extreme position that successful projects result from a mix of processes and leadership. Range C represents a set of feasible combinations resulting in possible solutions to the question of how much leadership, and what quality in processes, is required to bring about a successful project?
Range C represents an intermediate position where our plan to succeed is more realistically based on a mixture of leadership and process. As in Exhibit 3, the concave nature of the curves suggests nonlinear relationships. On the left the requirement for leadership falls faster than the quality of the processes rises. Improving our processes a little bit takes a significant burden off leadership. On the other end, less than perfect processes introduce a need for leadership at a lower rate of increase than the decline in process perfection.
Examining Exhibit 4 with the concepts of Exhibit 3 in mind, the suggestion is that less than perfect processes coupled with solid leadership are likely to yield a more cost effective result than perfect processes with weak leadership. The corollary on the left is that for our project management to be cost effective, we are better off with solid players and a decent play book than with prima donnas and total spontaneity.
In designing our approach to a project, we should seek a balance of leadership and processes that will yield a more optimal cost than answers near either extreme. By my theory, medium quality leadership and medium quality processes can bring more reliable success at a lower project cost than superman leadership or bulletproof processes, alone. This is not to suggest that we should design to the minimum combinations suggested by range C in Exhibit 4. We should aim for the greatest cost effectiveness obtainable by high quality leadership and great processes, but we shouldn’t trade off perfect leadership or processes for the inability to provide the other one.
Since strong leadership and solid processes cost very little more than lesser quality in either case, we will attempt to exceed the minimums suggested by range C. By this means we will increase the probability of success while compensating in advance for events on the project that test either our leaders or our processes.
In dealing with the issue of finding this balance point, let’s start with some basic concepts.
- Few projects exist where 100% dependence on leadership is the understood approach.
- Projects rarely succeed without good processes.
- Projects do not succeed without leadership and processes.
Dependence on Leadership
Innumerable projects can be cited where the quality of leadership had profound impact on the outcome of the project, but extrapolating that to justify it as the sole cause of success is unsupportable. I cannot cite a single successful project where I would say that leadership alone was the sole factor that led to project success. Those that have been cited to me fail the test of reality.
Frank Crowe was a marvelous leader for his day. While he was criticized by some for his treatment of labor, he also developed a fierce loyalty among many of his workmen. It was common for him to be found in the bottom of the canyon examining and solving problems at 2:00 a.m.. He personally invented some of the equipment used in the construction. However, the concrete at Hoover Dam was not poured by his leadership. The project might not have been two years early without his leadership, but he put in place the processes that drilled the tunnels and poured the concrete. (McBride, D. 1999 )
General Leslie Groves provided amazing leadership both in building the Pentagon and developing the atomic bomb. Still, he was not a one man show. He put in place people and processes that resulted in the success of those efforts.
Dependence on Processes
Faced with the argument that process is of paramount importance, we are also likely to come up short of real examples. It is easy to find examples where overemphasis on leadership was a factor in the project’s failure. Adjusting for that failure by excluding leadership as a success factor does not guarantee success.
Clearly, the load on leadership is lower if solid processes are in place. Still, over-reliance on process results in projects that go nowhere.
Nuclear power plants today provide a very economical source of electricity. While not without challenges, modern plants are reliable, and cost effective, and have proven safe. Yet the number of plants that were announced or started, and then cancelled, is almost equal to the number in use in the United States. The stories of these cancelled plants are individual, but they share a unifying theme: their process focus did not save them from becoming failed projects.
Adm. Hyman Rickover was known as a process man. His group in the naval atomic submarine group pioneered the PERT method of project monitoring. Without such processes, the atomic submarine would not have come into existence as quickly as it did. Yet Adm. Rickover had to continually provide leadership to take on the navy establishment to establish the use of his processes. The processes he invented would never have been applied to real world problems without his leadership.
Fredrick Taylor, Henry Gannt, and Frank Gilbreth were giants in process improvement. They are all remembered as best as process fanatics. Gilbreth was not above challenging workmen to brick laying contests and shedding his coat and tie to demonstrate his superior process. (Kanigel, 1997, p414) On one occasion he told a surgeon that “If you were laying brick for me you wouldn’t hold your job for ten minutes.” (Kanigel, 1997, p489) Still, Gilbreth, in particular is remembered for the practical side of his improvement strategies. How to apply the leadership to get his changes in process adopted by workmen cooperatively. This is a leadership function.
Successful Projects Need Both Leadership and Processes
So, my assertion is that both leadership and processes are necessary to bring about successful outcomes in projects. The question is never one or the other; it is about how to increase the contribution of less than perfect leadership and less than perfect processes to our project’s outcome.
Improving Project Processes and Leadership
Improving Project Leadership
Project leadership is about the project climate. The improvement of leadership is about establishing an intentional climate that encourages communication, initiative, and trust. The project leader who does not intentionally invest in establishing such a climate will accept by default a culture likely to be dysfunctional. As Peter Scholtes suggests calling default behaviors a project “ . . . culture often takes ordinary dysfunctional behavior elevates it into something ethereal.” (Scholtes, 1998 p178) It does not bring projects to successful conclusions.
To improve leadership on the project often means the investment in processes for the creation of a positive climate. Such processes include:
- Partnering sessions
- Intermixing of project participants for information sharing
- Individual coaching
Effective partnering sessions can do a great deal to establish a sharing environment where participants understand their place in the greater enterprise. Project relationships established by win-lose negotiation or oppressive contract terms cannot be overcome by a one-time effort. Problems are overcome by building trust. Trust requires continual communication.
One of the challenges of the Manhattan Project was shared communication. General Groves felt that compartmentalization was necessary to reduce security risks. The core scientific team, with the issue being championed by Leo Szilard, felt that intermixing of disciplines, problem teams, and family members would encourage the free flow of ideas necessary to tackle problems that they were encountering. (Rhodes, 1986, p503) There were no easy answers. The degree of freedom eventually allowed in information flow did lead to security compromises. It also led to the solution of problems that were at first considered intractable. Personally I think Groves initially got this one wrong. That was probably the easy road for him to take. Eventually he allowed a loosening of communication that was closer to what Szilard had sought.
Difficult personalities and underperforming individuals are no easier to deal within a project than in any other environment. The project leader must take a direct hand in dealing with such problem individuals. The ultimate sanction of removal from the project rarely needs to be applied, but when it is the last alternative, it needs to be done.
Improving Our Project Processes
Improving our project processes generally means applying leadership to selection and operation of those processes.
My dictum for project processes is that there should be:
- One plan
- One process
- One team
It takes leadership to accomplish this. Leadership applied to the insistence on quality processes, consistently applied. Leadership applied to the insistence on defining the state of the processes and not chasing will-o-wisps of future solutions to our problems through process instability brought by following dreams.
One plan means that individual components of the project team are not operating from differing plans for, or measures of, project outcomes. One of the most common failures of project leadership I have encountered is the tolerance for project sections operating from differing ideas of the project plan. The most detailed plan ever developed is useless if it exists as one of several opinions on the direction of the project.
Planning means more than scheduling, and so the context has to be broader than one Primavera schedule. Still, one schedule is often an improvement. It is my observation that there is, at most, one controlling schedule on a project. When the engineering functions of a project are operating from a different schedule than the construction personnel, the project is operating without a schedule. One schedule does not mean that there cannot be subsidiary schedules, but they must be coordinated.
One process means that the flow of information must be channeled to reliable sources. Leaders who tolerate cost accounting systems operating outside of the accounting function, or progress measurement inconsistent with the master plan, are accepting the defeat of the project processes.
In a classic example of operating multiple processes to the detriment of the project outcome consider the NASA program Mars Polar Lander. It is reported that the failure of the mission was attributable to different engineering groups independently using metric and English units. (Isbell, 1999)
One team is about the integration of all project participants into the breathing, living, project. It is easily said that this is in the nature of projects, a small group working together for a common purpose. It is much harder to accomplish in fact. Almost every time that I have proudly heard about the effective integration of the project team, I have discovered individuals or groups left behind. Often this appears to be the quality functions or safety. Sometimes it is the training development for plant operation.
A QA/QC technician recently expressed his experience to me this way: “On the first project when we were called in to make acceptance checks, it was a matter of pride for the supervisor to have us discover everything was in order. It was an embarrassment to them if this was not the case. On the second project the attitude was that we were being obstructionists if we couldn’t overlook the quality problems when asked to make acceptance checks on incomplete work.” This sorry situation was described based on two successive projects under a single project management team for construction of similar process units, in the same geography.
Ultimately, the successful application of our project processes depends on the climate created by the project leadership. If the leadership relies on the processes to be self operating, near-perfect processes will not save the project from itself. If the leadership climate allows the subversion of the processes, they quickly become pointless.
An example of the synergy between process and leadership can be found in the story of defective antifreeze put in Saturn automobiles during their manufacture. QA/QC processes operated effectively in the early identification of the problem and its cause. Leadership was required to implement a solution that was counter cultural in the GM organization. The organizational leaders decreed that every car that had been exposed to the faulty fluid would be destroyed. This was leadership working with process to do the right thing. The story stands as an outstanding example for project teams everywhere. (Aaker, 1996, p37)
In our projects, neither processes nor leaders can stand alone to bring project success. The tension over which is more important is misplaced. Any successful project requires a mixture of both. Our projects will most commonly be run by less than perfect project leaders using less than perfect project processes. Our success will come from making an effective team of that situation, not from emphasizing one of the other. Great project leaders acknowledge the need for process. Great process leaders acknowledge the need for acceptance of “good enough” recognizing that insistence on perfection is misplaced.
Effective project performing organizations will work in the short term with the project teams and processes they have for improvement in operation. In the longer team they will recognize that leadership can be fostered by the organizational climate in which projects are performed and that investment in improved processes can cascade over generations of projects. By so doing they will build the capability to bring projects to success.
Aaker, D. A., (1996) Building Strong Brands. New York, NY: The Free Press
Collins, J. (2001) Good to Great. New York, NY: HarperCollins Publishers
Crosby, P. B. (1979) Quality is Free: The Art of Making Quality Certain. New York, NY: McGraw-Hill
Isbell, D., Hardin, M., & Underwood, J. (1999) Mars Climate Orbiter Team Finds Likely Cause of Loss Retrieved on July 31, 2006 from http://mars.jpl.nasa.gov/msp98/news/mco990930.html
Kanigel, R. (1997) The One Best Way. New York, NY: Viking (Penguin Group)
McBride, D. (1999) Crowning Achievement. Las Vegas Review-Journal [Electronic Version]. Retrieved on July 31, 2006 from http://www.1st100.com/part1/crowe.html
Rhodes, R. (1986) The Making of the Atomic Bomb. New York, NY: Touchstone
Scholtes, P. R., (1998) The Leader’s Handbook A Guide to Inspiring Your People and Managing the Daily Workflow. New York, NY: McGraw-Hill