Monday, March 23, 2015

The Impact of Project Collaboration



This month’s blog is adapted from a recent article entitled “What Successful Project Managers Do” published in the March 2015 issue of the MIT Sloan Management Review. In addition to Alex Laufer and Jeff Russell, the other co-authors are Edward J. Hoffman, NASA's Chief Knowledge Officer, and Scott W. Cameron, Global Project Management Technology Process Owner at Procter & Gamble.  

In the article we demonstrated that the first role assumed by successful project managers in a variety of industries is to develop project collaboration. In today’s blog we present four examples that highlight the paramount impact of project collaboration.

Example A, The Power of Trust

NASA project manager Tim Flores looked at three projects at the Jet Propulsion Laboratory (JPL): the Pathfinder, Climate Orbiter, and Polar Lander. Although all three projects had the same guiding principles, similar scope, and shared elements (including some team members), the Pathfinder was a success while the other two failed.

Flores thought he’d find that the Pathfinder project stood out from the others in things like resources, constraints, and personnel. To some extent this was true, but what he found to be the primary difference was the level of collaboration. The Pathfinder team developed trusting relationships within an open culture. They felt free to make decisions without fearing severe punishment for mistakes. The other two project teams never developed such a high level of trust.

Example B, The Power of Openness

NASA’s Wide-Field Infrared Explorer (WIRE) mission studied how galaxies formed and evolved. They used a telescope so delicate it was sealed inside a solid hydrogen cryostat. Shortly after launch, the cryostat’s cover ejected prematurely and the Explorer craft tumbled wildly through space. The entire mission failed.

Jim Watzin, project manager at NASA and a team member at the WIRE project, commented on the official NASA after-action report: “WIRE failed because people could not or would not communicate well with each other….Individuals simply were uncomfortable allowing others to see their work.” He added: “The real lesson of this loss is that any team member that does not participate as a true team player should be excused (from the project).”

Example C, The Power of Partnership

Allen, a payload manager in NASA’s Advanced Composition Explorer (ACE) project, developed trust between his team and 20 groups of instrument-developers using a three-stage plan. First, he picked team members who could operate in a university environment—they knew when to bend or even break the rules. Second, he permanently moved his team into a university environment, realizing it would provide a more open, flexible culture than the home-base environment. Third, he came up with an uncommon process for interacting with the scientist groups.

Allen anticipated that it would be difficult to get the scientists to regard his team as partners. Having dealt with NASA before, the scientists tended to believe Allen and his people would demand tons of paperwork and that things be done “just so.” Many of the scientists weren’t even sure they should share with Allen’s team the problems they were encountering.

Because Allen’s team had to review instrument development, he believed the best way to do this was to focus on building trust and convincing the scientists his team was there to help them problem-solve. So Allen and his team went to each university and stayed on-site for an extended period of time, spending days and nights working with the scientists, helping them solve their problems. They were there not as controllers but as partners.

Example D, The Power of Interdependence

Procter & Gamble (P&G) launched a large construction project at one of its European plants. Karl, the contractor’s project manager, had no interest in team-building efforts and kept brushing them off. Pierre, the P&G project manager, finally found an opportunity to change Karl’s attitude. Three months into construction, the contractor (Karl’s group) accidentally placed the foundations off the mark, pouring about 600 lineal feet of foundation concrete in the wrong place.

Pierre recognized the volatile and disruptive nature of the mistake. He could have ordered Karl to fix the mistake by tearing down the foundations and starting over, but he realized that would have damaged the contractor’s reputation and ego. He understood that the best plans evolve in waves as the project unfolds and more information becomes available and reliable. He thus chose a different approach. Pierre took several days to meet and negotiate with users and designers, modified the interior plant layout, and minimized the damage without tearing down the foundations and starting over.

While the mistake resulted in costly changes, Karl’s reputation was preserved and the project wasn’t delayed. Eventually Karl came around to embrace Pierre’s team approach—namely, “If they fail, we fail.” Realizing they are all interdependent led to the development of a collaborative relationship.  Developing mutual interdependence and mutual responsibility for project results is key to project success.

Tuesday, February 17, 2015

The Payoff: Working With Trust



Last month’s blog was entitled The Cost of Working Without Trust. This month we share a story1 which stands in marked contrast. It is from Jerry Madden, a successful NASA project manager:
It’s easier to sell a project if you can show it is based on a previous successful project. People feel safer with the tried and true. When we introduced the ISEE* project, we told NASA headquarters that we would build the spacecraft exactly like the IMP-H**. The structure would be the same and we would keep the same basic electronics as far as possible. Because I believed it could be done, I issued this edict to everyone in the project and even appointed one of the best mechanical engineers to be in charge of the structure.
A short while into the project, he showed up at my office and said, “When are you going to get down off your high horse and let us design a structure for ISEE that can fly. IMP-H just will not work.” I was taken aback. This meant taking a risk rather than going down the same road of a successful project. Had he been someone else, I would have asked to have him assigned to a different project. How could I trust someone to carry out directives in a project in which I totally believed?
However, I trusted him explicitly because I had worked with him for a long time. This was an opportunity to change direction, based on solid judgment. I swallowed my pride, looked at him squarely in the face and said, “If that is the way you truly feel, now is about as good a time as any. Will it still have 16 sides and will it look the same on the outside?”
He said that it would, but it will be larger and will bear almost no resemblance on the inside. I said, “Fine. I will inform Headquarters that we will have to mod [modify] the structure and make additional changes to the internal systems.” Fortunately, the project was set up as a highly flexible organization with competent and experienced management and was made the change to the new concept with very little static. In the end, the successful ISEE spacecraft from a distance looked the same as IMP-H but internally, both in electronics and structure, there was no resemblance. You have to know when to eat your own words and enjoy the taste.
Practically the same sort of thing occurred with my counterpart in ESA who was building the ISEE-B spacecraft that was mated to the ISEE-A for launch. In the selling of the program their project manager had accepted too stringent requirements on the spacecraft partially to fit within the IMP-H. The ESA method of management was slightly different from ours so when they got to the execution phase, they brought in a new manager known for his competency and integrity, whose perspective was not jaded and who was able to see the project elements in a fresh light. He took one look at the system and like my mechanical engineer, had only one thing to say, “This is rubbish!” Here too, the future of this important project now hung on the opinion of one man.
Fortunately, my counterpart did not have to eat his own words but only those of his predecessor, who had determined the spacecraft concept design. My counterpart was straightforward and honest and recognized the value of flexibility, which helped to make the program change workable. As a true leader, he was able to affect the sharp change to the concept. Our two teams immediately formed one team to get the job done because we recognized not only the competence of our colleagues but also their integrity.
A key lesson from this story is some of the most important decisions, made by people in a rigorous and “thing-based” profession (engineering), and some of the most sophisticated technological artifacts, are often made and accepted based on two human concepts: intuition and trust. Soft is hard.
1 Source:  Madden, J. (2000). In A. Laufer & E. J. Hoffman, Project management success stories: Lessons of project leaders (pp. 104-105). New York, NY: Wiley.
*ISEE means International Sun-Earth Explorer, one of NASA’s Explorers spacecrafts.
**IMP means Interplanetary Monitoring Platform; IMP-H was one in a series of such spacecrafts.

Thursday, January 15, 2015

The Cost of Working Without Trust



photo in public domain

This month’s story, the first of a two-part series about working with and without trust, is about a manufacturing plant in a well-known consumer goods corporation.
     Three years ago we began a “grass-roots” plan to expand production capacity for a successful product. The project started in a wheat field and was to end two years later with a multi-million dollar plant. Unfortunately, the eventual plant cost became a troublesome issue in an otherwise successful project.
Management blind to the facts  
     To begin with, upper management believed the project should cost $40 million, a figure based solely on their own experience and not on the facts. Management declared the conceptual study’s estimate of $55 million to be unacceptable because it had already agreed to staff and develop a conceptual study based on their $40 million figure. They questioned the cost engineer's credibility, even though he was quite experienced and used proven methods to develop the estimate. There were even discussions that the scope and estimate were “gold-plated” and that we really wouldn’t build the plant like that. After reducing the project scope to appease management (reduced building size, eliminated some non-process scope, etc.), a compromise estimate of $50 million was accepted for the project's appropriation.
     Immediately after appropriation, the eliminated scope was returned to the project because the scope reduction decisions had been based on cost criteria alone, with no consideration for the actual needs of the project. For example, reducing the building size meant a key piece of production machinery would no longer fit, so the building had to be returned to its original dimensions. Despite valid scope additions such as this, management refused to approve changes. They said, “You already have $10 million more than you need. We're not going to give you any more fat!”
Given management’s attitude, the project team maintained very little cost consciousness. Since management was ignoring valid cost estimating and trending data, the team didn't bother with cost control and the cost situation soon became disruptive. The project team knew they were exceeding the appropriated amount, but since management refused to listen to the team's concerns, cost control became a big joke.
     So the scope grew while the cost predictions remained the same. When the project team completed definition and design, a second estimate was published at $58 million.  When construction took over, the estimated cost of the plant increased to $64 million (the amount the contractors originally estimated for the project). Even the most dedicated effort of a competent project team cannot deliver a successful project without the trust and support of upper management. Trust is a two-way street:  the trust of senior managers in the project team facilitates the trust of the team in the senior leadership.
     At project close, the project team had done an excellent job of building a $64-million plant. The start-up was on time and one of the best in the company. The only criterion the project failed to meet was cost, due to management's stubborn arrogance and unbending devotion to its own target cost. Unreasonable pressure from management to pursue unrealistic objectives does not ensure the achievement of those objectives.
     When it comes to organizational performance it is a balancing act to challenge people to achieve high performance. Set the bar too low and it only calls for minimal effort to reach. However, if the bar is set too high, with unrealistic objectives, failure is the assured outcome. And what was upper management’s response to the outcome in this story? The contractors were hung.
Part 2 of this two-part series will be published next month, with a story about working with trust.

Wednesday, December 17, 2014

Pragmatism Does Not Mean Being Unprincipled



In the last blog we stressed the importance of judgment for successful project management. Robert Goehle, from the US Department of Energy (DOE), had to resort to judgment when attempting to adhere to one of the key principles of project management: Strive to meet the customer’s needs!1
Good project managers understand that it is important to involve the customer in the project deeply. Involvement can mean many things, but generally requires the project manager to listen to and be responsive to the customer’s needs.
Listening and responsiveness do not mean always accepting the customer’s point of view. Following are two examples in which customers were deeply involved in the projects, but the extent to which their initial demands were met differed considerably.
A Research Facility with Only One Line In
One project entailed the design and building of a facility for ecological research and was operated by a local university (the customer) at a site operated by the DOE. The facility would house a veterinary-type clinic for observation, surgery and autopsy of small animals. As most of the researchers using the facility would have offices elsewhere, the customer required only a single telephone line for the entire facility.
The DOE site manager decided that the facility must comply with DOE standards, and this included multiple phone lines, fiber optics, computer capability, and a fire notification system. These applied to all new facilities constructed no matter what their functions.
The customer was furious when informed of this because these requirements were going to add substantial cost to the project, and the customer had a limited budget. At that point the customer proposed doing away with all the communication lines to the facility, settling for a cellular phone. The DOE site manager still found this idea unacceptable; all facilities located on site must be on the site system.
It was a delicate situation for the DOE project manager, whose job was to provide oversight of the project and serve as the go-between for the customer and the DOE site manager. Despite the site manager’s requirements, the project manager was convinced that the customer was right. Under these unique circumstances, the Project Manager believed the DOE standard was inappropriate. The site manager, however, was adamant about his requirements. Thus, the Project Manager decided to take the case to DOE headquarters and argue on behalf of the customer.
In this case, a waiver was granted. The facility was constructed with a single phone line, and the project was completed within budget.
A Testing Facility for Multiple Customers
In the second project, led by the same Project Manager, the mission was to design and build a facility to test products for five different customers. The new facility was to provide environmental test chambers that could quickly raise and lower temperatures. Each customer had completely different temperature requirements for the products to be tested. This meant that the facility had to provide multiple ovens or additional environmental chambers to satisfy all the different requirements. The result was that the total estimated cost of the facility was much higher than the approved budget.
The Project Manager approached the customers separately and tried to get them to relax their requirements so that the project would be able to meet its budget. The customers listened to him, but were clear that they could not compromise on their requirements. While the Project Manager wanted to satisfy his customers, he realized that unless he found a way to get them to relax their requirements they would all wind up with nothing. Therefore, he decided to approach them one more time to ask them to relax their requirements, but this time he approached them as a group.
Each customer was provided with the temperature ranges required by the other four. They all were requested to adjust their requirements to the next closest set of requirements. At first, there was resistance to changing anything. Each customer felt that the requirements could not be changed. But once they realized that unless they collaborated, none of them would get anything, they worked together to streamline their requirements so the project could succeed. By combining requirements, they reduced by half the number of ovens and environmental test chambers. In the case of special needs, small units would be purchased at a greatly reduced cost. Since fewer units were needed, the size of the facility was likewise reduced.
In both examples the project manager fully engaged and worked with the customers and met budget constraints. However, in the first case he was willing to confront authorities to meet the customer’s requirements, while in the second case he confronted the customers and convinced them to modify their requirements.
These two examples demonstrate that when it comes to meeting customer needs, context and customer engagement are key. John Russell, former vice president of Harley-Davidson Europe, put it this way: “The more you engage with customers the clearer things become and the easier it is to determine what you should be doing.”
In his book Six Action Shoes, Edward de Bono relates pragmatism to context-sensitivity. “Some people condemn pragmatism because they believe that pragmatism seems to be a way of acting without principles. Pragmatism does not mean being unprincipled: it means the pragmatic use of principles. Pragmatism is when you do what can be done to achieve an objective and put as much emphasis on practicality as on principles… Pragmatism means being sensitive to the situation...”2
1 Laufer, A. & Hoffman, E. J. (2000). Project management success stories: Lessons of project leaders. New York, NY: Wiley, 149-151
2 de Bono, E. (1991). Six action shoes. New York, NY: Harper Business, 67-8.