Back to Top
Interview with Alexander Laufer

Download PDF

By Don Cohen

Dr. Alexander Laufer is professor of civil engineering at the Technion (Israel Institute of Technology) and director of the Center for Project Leadership at Columbia University. His books include the recently published Breaking the Code of Project Management. He is also the former editor-in-chief of ASK. Don Cohen spoke with him at the College of Engineering at Columbia.

COHEN: How would you sum up the central idea of your new book?

LAUFER: The key is that projects must be led, not
just managed. We need both leadership and management, but right now the prevailing paradigm is that projects are managed—that planning and control can solve all the problems. My studies have shown me again and again that the best projects are first of all led and then managed, or led in order to be manageable.

COHEN: How do you define leadership?

LAUFER: Leadership is necessary to create change. Project leadership is primarily about challenging the status quo. Because of the dynamic environment they exist in, projects are plagued with many problems. Many of them are what Ronald Heifetz would call technical problems that one can solve with a set of rules, or with available technology. But more than a few are what he calls “adaptive problems”— problems that are not well-defined and cannot be solved with a set of rules.

The current repertoire of responses is inadequate. Solving adaptive problems requires learning—at times difficult learning—and often requires changing work patterns as well as other kinds of innovation. To meet these adaptive challenges, the project manager must adjust the plans and practices or sometimes even shape the project environment. And he or she has to do it with a group of people who usually don’t have much experience working together, who have different skills, functions, cultures, and interests.

Finding a solution to adaptive problems with a group doing a unique and innovative task in a dynamic environment by challenging the status quo requires leadership. The project leader doesn’t want to challenge the status quo every day. People are not used to adapting every day, so the leader needs to be selective. But in our dynamic environment, every once in a while it is necessary. Solving these adaptive problems renders the rest of the project manageable, and this is indeed what allows the leader to apply standard project management practices. The importance of both leadership and management to the success of the project is the theme of two Forums on Leadership being held this summer at NASA HQ in Washington, D.C., and at Columbia University in New York City.

I learned the hard way that the on-site practitioners knew better and did not rush to prepare detailed plans too soon, when information is still missing and changing.

COHEN: Can you give me an example of a project leader challenging the status quo?

LAUFER: There’s a story in Shared Voyage [written with Ed Hoffman and Todd Post]. When Terry Little from the U.S. Air Force was given a project because the previous project manager was released, the key requirement was to finish all the preparation needed to be able to assign the contract to two of the five contending contractors as soon as possible. Little told his team that they should be ready in six months. He explained later that he could have chosen seven or eight months, but he wanted them to work differently—not just harder or faster. He wanted them to learn to do things differently. He challenged the entire team to let go of the status quo. Another example: Joan Salute from NASA managed a project to study the effect of reentry on experimental materials. The air force wanted to restrict the use of the findings of her mission, but she said no, and eventually she prevailed. People in her community didn’t like it, but she said, “I own the mission. This is my work, and this is what I will do. I’m working for the science community.” She challenged the status quo.

COHEN: As you say, that’s not the kind of thing you can do every day.

LAUFER: Which brings us to something else that unfortunately is not well addressed in our literature: the need to exercise judgment. Judgment can be improved through experience. Better judgment in the context of adaptive problems is often improved by being exposed to a variety of challenging experiences, and by reflecting on these experiences while paying attention to the unique contexts surrounding them.

COHEN: Does the drive for efficiency get in the way of reflection?

LAUFER: This is the common perception. However, one must achieve both efficiency and effectiveness. In stable conditions and in the short run, efficiency should be stressed. As uncertainty increases and the time horizon becomes longer, other dimensions, like impact on the customer and business success, become more important. The need to find the right balance between the various dimensions requires reflection.

COHEN: Your interest in leadership, adaptation, and judgment is quite different from project theories that emphasize control.

LAUFER: Most of our current theories were developed primarily by engineers almost half a century ago and have not been updated significantly. In recent years, we are witnessing an earnest quest for a new paradigm, and many theoretical articles are being published on this subject. We are beginning to see experts from other disciplines—business, management, organizational behavior— becoming involved in research on projects. I believe that soon enough, especially once researchers focus more on empirical studies of actual projects and less on developing models based on the old paradigm, we will see some useful changes that will also stress the need for adaptive leadership.

COHEN: How did you arrive at your ideas about projects?

LAUFER: Most of my ideas are based on learning directly from practitioners, usually from the best of them, and these findings were always tested and refined by feedback received in my consulting work. This mode of research started through some disturbing observations early in my career as a researcher. I was a typical civil engineer. I spent seven years in the military working as a structural engineer and a project manager of construction projects. Then I came to Austin, to the University of Texas, to do my PhD in construction management. I taught for a couple of years at Texas A&M. When my wife and I went back to Israel, I went to work for a construction company, but I had caught the research bug, so I joined the Technion in Haifa but continued to teach and do research during the summers in the states.

Based on my construction experience and my teaching at Texas A&M, I found that something didn’t click. I didn’t understand, for example, why my graduate students who were applying various industrial engineering techniques to improve productivity on site would come at the end of the semester bragging about the detailed construction plans they created, something I thought should have been already prepared by the construction people themselves at the beginning of construction. I learned the hard way that the on-site practitioners knew better and did not rush to prepare detailed plans too soon, when information is still missing and changing. Similar incidents later on convinced me to start working closely with practitioners, and I quickly learned to reverse the question I used to ask. Instead of, “Why don’t practitioners use what researchers know?” I began to ask, “Why don’t researchers use what practitioners know?”

Later, I was invited to be a consultant for Procter and Gamble for three years. I came to share my new planning concepts, to change the mind-sets of project managers at P&G. But I found that it’s very difficult to do that. I also found that the best project managers there already applied my new concepts without always being able to explicitly describe them. I decided my life would be easier if I could capture their stories and share them with the rest of the community. We captured seventy stories of thirty-six project managers within Procter and Gamble, and in 1994 we published them in a book. The surprising thing is that these stories are still read and shared within P&G.

COHEN: Trying to convince people with stories is more effective than frameworks and theories?

LAUFER: Absolutely. Often you can try to influence and persuade people with an argument until you are blue in the face, but stories capture people’s attention. Stories can convey complex messages in an easily digestible form, making them easier to remember while also stimulating curiosity and inducing reflection. I learned later on, especially through my extensive collaborative work with Ed Hoffman, that people change their minds based on action and reflection, and stories are an excellent trigger for reflection.

COHEN: Over the years that you’ve observed projects, have you seen a shift in how they are carried out?

LAUFER: Yes, but not a sufficient one. People are much more results-oriented. They don’t necessarily use the right tools or theories, but I see a lot of pressure for deliverables. I also see a great deal of interest in trust and in the unique context of each project, but still not in a well organized fashion. Experienced people are aware of the limitations of planning tools; only the beginners are not. Unfortunately, for the moment they have nothing better. In software development, on the other hand, the agile movement is offering very innovative and practical approaches.

COHEN: What needs to be done to generate a sufficient shift in the way projects are done?

LAUFER: I believe there are a couple of things that should be done. Schools and universities should do empirical studies of real projects rather than just focus on theories and tools. They need to come up with paradigms that have to do more with practice and experience. We are all influenced by paradigms; a powerful article by Sumantra Ghoshal describes how bad theories kill good practices. I think this happens in project management as well, so we need better theories. Business schools in general, and especially in this country, do not have a project management function. The field of project management can be found in operations or organizational behavior or in management, but most business schools do not have a full-time faculty member focusing on project management. We also need executives to pay more attention to project management.

COHEN: In what ways?

LAUFER: In selecting and developing project managers, in fostering a learning environment and embracing a new culture. I think it will happen one way or another because the world is becoming even more volatile, unpredictable, and chaotic, and the competition is going to be even tougher. People will have to produce more innovative products faster and cheaper. They will have to get beyond simple planning and control. It’s just a question of how fast, and which country, industry, and organizations will gain a competitive advantage by being the first.

COHEN: Do you see people in projects thinking consciously about the knowledge they need?

LAUFER: Many people related to projects are keen to learn because they are aware that the context of each project is different, and they can enrich their own arsenal. I saw tremendous openness to learning at Procter and Gamble and NASA—people listening to case studies, analyses of projects, and stories because they realized that this is what they need. People craved coming to the two and a half days held twice a year [at Masters Forums] because they wanted to know how things were done at other centers and in the air force or navy. They felt hunger for this kind of knowledge—not so much general “lessons learned,” but knowledge about specific projects and their context as presented to them by their peers.

COHEN: Are you suggesting that this knowledge is different—maybe less easily definable—than typical lessons learned?

LAUFER: Lessons learned in science and engineering are important and can be easily generalized. But if you take a typical list of fifty project management lessons and attempt to apply them to your specific project, you may find that twenty-five of them contradict the other twenty-five. In management, including project management, most lessons are not universal. It all depends on the context, so you want to learn the lessons within their specific context and then adjust them to your own project context.

COHEN: Let’s talk a little about geographically distributed projects. Can people work successfully together virtually?

LAUFER: Don Margolies of NASA said, “Location, location, location.” Goddard and Johns Hopkins are twenty minutes apart. He said the fact that we could drive over there or they could come to us and meet face to face was gold. Many projects are done internationally and you cannot drag people all over the world, but meeting at the beginning of the project to establish trust and acquaintance is crucial. When you pick up the phone to talk to your good friend that you established trust with in the army, there is no need to be there. Some companies are very much aware of this. Early on, at the planning stage, the entire team of sixty or seventy people will be located at the client’s headquarters. When the project moves to the design stage, the entire team will be moved together to the designer’s location. They understand the significance of teamwork and trust, which is most naturally developed by being together.

In management, including project management, most lessons are not universal. It all depends on the context, so you want to learn the lessons within their specific context and then adjust them to your own project context.

COHEN: Many companies don’t want to spend the money to meet and think they can do everything virtually.

LAUFER: Nowadays, requirements are still shifting when projects start; the projects suffer from change and uncertainty throughout their life. We need to exchange information with the other party as soon as possible, as freely as possible, and as fully as possible. This happens only when trust is high. You cannot establish trust virtually. You can work virtually throughout the project once you establish it. But trust does not last forever; you have to maintain it by meeting periodically.

COHEN: John Seely Brown has described the purpose of those periodic meetings as “recalibrating.”

LAUFER: Indeed. In our current dynamic environment, projects suffer from a wide variety of changes; therefore, even a trusting team must “recalibrate” periodically to sustain teamwork.

COHEN: What do you see as NASA’s project strengths and weaknesses?

LAUFER: NASA has some of the best people. NASA has the advantage of having the coolest projects on Earth, which attracts excellent people. On the other hand, I’d say that while some centers are very well advanced and foster a culture of trust, some are not. In my opinion, the biggest hurdle for applying these ideas of leadership and adaptation is a non-trust culture. Trust and distrust are self-fulfilling prophecies. If you behave to people with distrust, suddenly you both are sure that this is the only way to behave.

COHEN: What does NASA need to do to meet the current challenges of its ambitious projects?

LAUFER: At NASA I would invest in social capital because people come here for thirty years, so the return is huge. I would also try to decouple large projects into smaller ones so if something happened I could still continue, absorbing uncertainty. I would also try as much as possible to think about how I can use the project learning for innovations applied to industry. I wouldn’t focus only on the long term. I would look for deliverables that could be produced in half a year or a year. I would almost force myself to come up with a list of innovations that can be delivered at the end of every year working together with private companies. I would force myself to look for small wins and not focus too much on something that may or may not be eventually pursued.

COHEN: At NASA and elsewhere there’s a tension—maybe a necessary tension—between standard procedures and flexibility.

LAUFER: I am a strong believer in the need for written processes and procedures. Even unique operations like projects share many regular, repetitive patterns of action. These written procedures prevent reinventing the wheel, save time and energy, and contribute significantly to the parties’ ability to maintain cooperation efficiently, even in the face of uncertainty. The procedure manuals in advanced organizations are often prepared by the most experienced practicing project managers in the company, not by staff people, and procedures are brief and simple, allowing for and even encouraging flexibility. Moreover, these manuals explicitly recognize that the procedures are not intended to cover all possible situations, but rather only the most common ones. In recent years, project managers at P&G, for example, have had the number of procedures markedly reduced from eighteen technical standards and thirty-two standard operating procedures to only four of each.

COHEN: Before we finish, would you sum up the elements of successful project management?

LAUFER: If I think about the new world of project management, I’d say it starts with ongoing learning. Such learning is the key to effective project planning when information is missing or constantly changing, as well as to reflection during and after the project. So learning is a constant theme. Second is judgment, which always must take into account the unique project context. Context is a key because, contrary to the old project management paradigm, there is no “one best way.” Number three: trust. There is no success in projects without trust. Number four is being action-oriented, focused on doing, on the deliverable. I like to quote the Persian proverb: “Thinking well is wise; planning well is wiser; doing well is wisest and best of all.” Number five, the riskiest one, is courage. It’s not the same courage as on the field of battle; you’re not going to die. But you may risk your esteem or your career. And you need the judgment to know when to challenge the status quo, while not risking the project just because you want to be heroic. Projects need leaders, not heroes.

About the Author

Share With Your Colleagues