In the early 1990s I designed and started teaching a project management course for 3^rd and 4^th year civil engineering students at the University of Minnesota. I had been teaching an engineering systems course that was problem-driven and made use of project teams and used a similar approach in the project management course. I also started teaching project management and teamwork courses for graduate students in professional master’s programs, especially at the University of Minnesota’s Technological Leadership Institute; and participants in short courses for government agencies, such as the Minnesota Department of Transportation (Mn/DOT), and private companies.

When McGraw-Hill invited me in 1997 to write a book on project management and teamwork for their BEST series, I thought, What a terrific idea! Real world engineering problems require teamwork to be solved. Involving first-year engineering students in teamwork and project management as soon as possible would help them prepare for engineering practice. I immediately embraced the idea and started working on a book for them.

Along with colleagues and undergraduate student teaching assistants I had taught a introductory engineering course for first-year students at the University of Minnesota for more than 20 years. It evolved into a course titled How to Model It: Building Models to Solve Engineering Problems, which I have taught with colleagues and undergraduate student teaching assistants. We also wrote a book to accompany the course—How to Model it: Problem Solving for the Computer Age (Starfield, Smith, and Bleloch, 1990, 1994). Since the course made extensive use of project teams, I knew that a book on project management and teamwork was needed.

Teamwork and projects are at the heart of the approach I use in teaching students at all levels, including participants in faculty development workshops. I’ve learned that it isn’t easy for students to work effectively in project teams or for faculty to organize and manage them, but the potential for extraordinary work from teams makes it worth the effort. Also, projects and teamwork are a central part of engineering work in the world outside the classroom.

The book went through two iterations prior to the 4^th Edition. Though the first edition, Project Management and Teamwork, was designed for first-year students, we found that other students used it, especially those in senior-level capstone design courses. So the 2^nd edition, retitled Teamwork and Project Management, was redesigned to be accessible to first-year students, but also be applicable for upper-division students who hadn’t had an opportunity to focus on teamwork and project management skills in earlier courses and programs, and for students in graduate and professional programs. The 3^rd edition was primarily an update to the 2^nd and also started the collaboration with P.K. Imbrie. The Sidebar Reflection below summarizes P.K.’s connection to the 3^rd edition.

A number of years ago I attended a workshop on cooperative learning given by Prof. Smith (yes the same Prof. Smith that is the principal author of this book). At that time, I strongly believed “the lecture” was the quintessential way to promote student learning and I saw no value (from a leaning perspective) in using student teams. After his workshop I came to realize the most important thing we do as a faculty member is help students learn how to learn—or, another way of saying it, we need to prepare them for the idea of lifelong learning. What I discovered is through a traditional lecture class, we teach them (our students) how to be stenographers and to memorize whatever it is we teach. However, in the active, cooperative classroom, students actually have to learn how to learn, because they have to learn how to communicate their ideas to other individuals while they're in a team environment.

So you might be asking yourself, what does this have to do with “teaming?” What I have found is whether you are in the classroom, working on homework, or completing a term-long project, moving from being individualistic learners to partner learners and moving from a textbook, faculty-centered learning style to "my peers and everybody else can be equal contributors in this" can provide a phenomenal leaning experience. However, it requires you learn how to be an effective member team. To be an effective member of a team (or an informal learning group) one must learn how to: work interdependently, specify goals, develop a sense of cohesiveness, and communicate (and, if you are on a formal team, one needs clearly defined roles and rules of accountability – norms). The teaming chapters of this book will help you understand what we have found to be important and will hopefully make your teaming experience more enjoyable.

P.K. Imbrie

Since the engineering method involves progressive refinement, that is, taking what we know at the present (labeled state of the art, sota₂₀₁₂ ) and identifying opportunities for improvement, the changes in this edition continue to reflect a focused emphasis on preparing engineering students for professional practice. In the spirit of advancing the state of the art, I’ve made major changes to several chapters and have updated the entire book.

The 4^th edition represents a major redesign and includes an expanded number of collaborators. There are new chapters by Constance Kampf, Russell Korte, Robert MacNeal, Curt McNamara, Senay Purzer & Nicholas D. Fila, and Cliff Whitcomb & Leslie Whitcomb; and reflections and other contributions by Eric Berkowitz, Shannon Ciston, P.K. Imbrie, Kathryn Jablokow, David Johnson, Shawn Jordan, Billy Koen, Holly Matusovich, Tamara Moore, Matthew Ohland, David Radcliffe, Anthony Starfield, Ruth Streveler, and Khairiyah Mohd Yusof. I am confident these new chapters and larger collection of reflections will strengthen the book considerably.

Chapter 1, which is an introduction and overview, was extensively revised to reflect the changing landscape of teamwork and project management. Chapter 2 is new and provides a framework for project management based on the clarity of the goal as well as the clarity of the process. The framing is based on March’s (1991) work on exploration versus exploitation and also draws on Wysocki’s (2012) Effective Project Management: Traditional, agile, extreme. Chapters 3 and 4, the teamwork chapters, were updated and expanded. Chapters 5, 6, 7 and 8, are new and contributed by Cliff Whitcomb & Leslie Whitcomb, Russell Korte, Senay Purzer & Nicholas Fila, and Robert MacNeal, respectively. Each of these chapter represents cutting edge ideas in teamwork and project management. Chapters 9, 10 and 11, on project management basics, were updated. Chapter 12, on project monitoring and evaluation, was updated to include team functioning and detailed material on team and project charters. Chapter 12, on communication and documentation, was extensively revised by Constance Kampf. Chapters 14 and 16 were updated to include some of the latest technology, as well as speculations on the future of teamwork and project management. Chapter 15, contributed by Curt McNamara, provides an introduction to complex adaptive systems in the teamwork and project management arena. I continue to provide my reflections, have added many new reflective essays by others, and encourage you to reflect on your experience and learning and add your stories to dialogues you engage in.

Overall, my goals for readers of Teamwork and Project Management are the following:

• To improve your understand of the dynamics of team development and interpersonal problem solving.

• To identify strategies for accelerating the development of true team effectiveness.

• To help you frame the project and team and identify and use an appropriate project management approach

• To understand the critical dimensions of project scope, time, and cost management.

• To understand critical technical competencies in project management.

• To explore a variety of “best practices” including anticipating, preventing, and overcoming barriers to project success.

As you engage with this book, be sure to continually reflect on what you’re learning and how you can apply what you are learning to the projects and teams you work on each day, in classes, on the job, and in social, professional, and community organizations. An important key to success in projects and teams is to routinely work at a “meta level.” That means you are simultaneously thinking about the task and how well the team is working. Talk with others about how the projects and teams you’re involved with are going, share successes and insights, and work together to identify and solve team problems. The personal story in the accompanying box describes some of the questions I’ve grappled with and how I got interested in this project. I encourage you to develop your own stories as you work your way through this book.

One of the messages of the story in the sidebar about engineering problem solving is the importance of checking a variety of resources to help formulate and solve the problems you encounter. Another message is that, although engineers spend some of their time working alone, engineering is not individual, isolated work. Collaborative problem solving and teamwork are central to engineering. Engineers must learn to solve problems by themselves, of course, but they must also learn to work collaboratively to effectively solve the other 95 percent of the problems they will face as professional engineers. There may be a tendency to think that this 95 percent—this asking questions and searching other sources for the solution—is either trivial or else unrelated to engineering. However, working with others to formulate and solve problems and accomplish joint tasks is critical to success in engineering.

Engineering Problem Solving

I have been involved in engineering, as a student and as a professional, for over 40 years. Frequently I have grappled with the questions, What is the engineering method? Is it applied science? Is it design? As a professor I have struggled with the question, What should my students learn and how should they learn it? These concerns prompted me to address the question, What is the nature of engineering expertise and how can it be developed effectively?

A study conducted by one of my colleagues (Johnson, 1982) provides valuable insight into the activities of engineers. My colleague was hired to collect protocol from engineering experts while they solved difficult problems. Working with a team of professors, he developed a set of difficult and interesting problems, which he took to chief engineers in large companies. In case after case the following scenario was repeated.

The engineer would read the problem and say, “This is an interesting problem.”

My colleague would ask, “How would you solve it?”

The engineer would say, “I’d check with the engineers on the floor to see if any of them had solved it.”

In response, my colleague would say, “Suppose that didn’t work.”

“I’d assign the problem to one of my engineers to check the literature to see if a solution was available in the literature.”

“Suppose that didn’t work,” retorted my colleague.

“Well, then I’d call my friends in other companies to see if any of them had solved it.”

Again my colleague would say, “Suppose that didn’t work.”

“Then I’d call some vendors to see if any of them had a solution.”

My colleague, growing impatient at not hearing a solution, would say, “Suppose that didn’t work.”

At some stage in this interchange, the engineer would say, “Well, gee, I guess I’d have to solve it myself.”

To which my colleague would reply, “What percentage of the problems you encounter fall into this category?”

Engineer after engineer replied, “About five percent”!

Acknowledgments

Many people deserve credit for guidance in this project. Former students with whom I’ve taught and worked on project management for many years, provided enormous insight into the process of what will work for students and were a source of constant support and encouragement. My heartfelt thanks to my many mentors, and especially to David Johnson, Billy Koen, and Tony Starfield for generously sharing their insights and enthusiasm and permitting me to stand on the shoulders of these giants. Billy Koen has been an inspiration to me since we first met in the early 80s. His wonderful ideas show up in several places in the book. Anthony M. Starfield, co-creator of the first-year course, How to Model It, and co-author of the book by the same title encouraged me to use the questioning format of the How to Model It book to engage the reader. David and Roger Johnson (whose cooperative learning model provides the theoretical basis for this book) generously provided their great ideas and steadfast support.

I thank the hundreds of students who learned from and with me in project management courses for their patience, perseverance, wonderful suggestions and ideas, and interest and enthusiasm in project management and teamwork.

The team at McGraw-Hill, beginning with the initial editors, Holly Stark and Eric Munson and Byron Gottfried, Consulting Editor provided guidance throughout. Editors for the second edition, Kelly Lowery and John Griffin, encouraged extensive redesign and the title change from Project Management and Teamwork to Teamwork and Project Management. Bill Stenquist, editor for the 3^rd and 4^th editions is delightful and demanding to work with. His support for my vision for the future of the book made it possible to increase the length by 30% and include six new chapters.

A special note of thanks to my daughters, Riawa Thomas-Smith and Sharla Stremski, who helped with the editing and graphics; and to my wonderful wife, Lila M. Arduser Smith, for her patience and unwavering support.

Comments and Suggestions

Please send your comments and suggestions to me at ksmith@umn.edu.

References

Johnson, P. E. 1982. Personal communication.

March, James G. 1991. Exploration and Exploitation in Organizational Learning. Organization Science, 2 (1), 71-87.

Project Management Institute. 2008. A guide to the project management body of knowledge, Fourth Edition (PMBOK). Upper Darby, PA: Project Management Institute (http://www.pmi.org).

Starfield, Anthony M., Karl A. Smith, and Andrew L. Bleloch. 1990. How to model it: Problem solving for the computer age. New York: McGraw-Hill.

Starfield, Anthony M., Karl A. Smith, and Andrew L. Bleloch. 1994. How to model it: Problem solving for the computer age. Edina, MN: Interaction Book (updated and sofware added).

Wysocki, Robert K. 2012. Effective Project Management: Traditional, agile, extreme, Sixth Edition. New York: Wiley.