Teamwork & Project Management

Teamwork and
Project Management
Karl A. Smith
University of Minnesota
December, 2002
McGraw-Hill’s BEST Series
Basic Engineering Series and Tools
DRAFT for Review and Comment

Please Do Not Copy or Distribute
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chapter One: Teamwork and Project Management In Engineering . . . . . . . . . . . . . . . . . . . . . . 11

What is Engineering? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Engineering Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Teamwork and Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Systems Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Reflection: Project Management and Teamwork in Engineering . . . . . . . . . . . . . . . . . . . . . 26
Chapter Two: Teamwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Definition of a Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Types of Learning Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Groups and Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Importance of Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Reflection: On Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Characteristics of Effective Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Reflection: Interdependence and Teamwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Chapter Three: Teamwork Skills and Problem Solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Importance of Task and Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Organization -- Group Norms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Decision Making . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Conflict Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Teamwork Challenges and Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Reflection: Teamwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Chapter Four: Project Management Principles and Practices . . . . . . . . . . . . . . . . . . . . . . . . . . 87

What is a Project? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Keys to Project Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Project Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Reflection: Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Chapter Five: Project Manager’s Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Changes in the Workplace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Changes in Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Skills Necessary for Effective Project Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Critical Success Factors and Their Importance for System Implementation . . . . . . . . . . . . 118
Project Manager's Role Over the Project Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Reflection: Professor as Project Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Chapter Six: Project Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Critical Path Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Project Resource and Cost Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
The Role of Computer-Based Project Management Software . . . . . . . . . . . . . . . . . . . . . . . 144
Reflection: Avoiding Analysis Paralysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Chapter Seven: Project Monitoring and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Monitoring Team Effectiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Team Talk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Project Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Building Quality Into Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Reflection: Paying Attention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Chapter Eight: Project Management Documentation and Communications . . . . . . . . . . . . . . 174

Project Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Project Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Reflection: Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Chapter Nine: Project Management Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Personal Data Assistants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Project Management Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Project Management and the World Wide Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Chapter Ten: Where to Go From Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Closing Reflection: On Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Teamwork and Project Management 4 Karl A. Smith
Preface
When McGraw-Hill invited me to write a module on project management and teamwork for
their BEST series I thought What a terrific idea! I had been teaching project management and
teamwork courses for seniors in engineering; graduate students in professional masters programs
especially at the University of Minnesota’s Center for the Development of Technological
Leadership; and participants in short courses in the University of Minnesota Executive
Development Program, governmental agencies, and private companies. It would not have
occurred to me to write a book for first-year students. I immediately embraced the idea and
started work.
I’ve been teaching a course for first year students at the University of Minnesota for more
than 20 years. It has evolved into a course titled How to Model It: Building Models to Solve
Engineering Problems, which I have been teaching with colleagues and undergraduate student
teaching assistants for the past 10 years. We also wrote a book to accompany the course -- How
to Model it: Problem solving for the computer age (Starfield, Smith & Bleloch, 1994). Since
this course makes extensive use of project teams I know that a book on project management and
teamwork is needed.
Teamwork and projects are at the heart of the approach I use in teaching students at all
levels, including faculty 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 first part of the book summarizes the context of engineering and stresses the importance
of teamwork. The middle part focuses on the nature of projects and the project managers’ role.
The last part emphasizes the particulars on scheduling, monitoring, and documentation. Overall,
my goals for readers of Project Management and Teamwork are the following:
! To understand the dynamics of team development and interpersonal problem solving.
! To identify strategies for accelerating the development of true team effectiveness.
! To understand the critical dimensions of project scope, time and cost management.
! To understanding 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 it 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”. “Going meta” means reflecting individually and
talking with others about how the projects and teams you’re involved with are going, sharing
successes and insights, and working together to identify and solve team problems. Working at
the meta-level also means that you are simultaneously thinking about the task and how well the
team is working. The personal story (sidebar) 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 box 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.
[sidebar] Personal Story
I have been involved in engineering, as a student and as a professional, for over thirty years.
Frequently I have grappled with the question, 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 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 problem 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. Michael B. Mahler, a graduate
student in civil engineering at the University of Minnesota who I’ve taught with and worked
with on project management for many years, provided enormous insight into the process of what
will work for students and was a source of constant support and encouragement. Robert C.
Johns co-taught the project management course with me a Minnesota and provided lots of good
ideas. 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. The five manuscript reviewers provided terrific assistance. Holly
Stark and Eric Munson, McGraw-Hill; and Byron Gottfried, Consulting Editor, initiated the idea
and provided guidance throughout. A special note of thanks to my daughters, Riawa and Sharla
Smith, who helped with the editing and graphics.
A special acknowledgment to Michigan State University, which provided me with a
wonderful place to work on this project during my sabbatical leave. Another goes to David and
Roger Johnson (whose cooperative learning model provides the theoretical basis for this book)
for their great ideas, generosity, and steadfast support.
Most of all 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.
Comments and Suggestions
Please send your comments and suggestions to “Karl A. Smith” <[email protected]>.
Preface to the Second Edition
Welcome to the second edition of Project Management and Teamwork. Many things have
changed since I wrote the first edition in 1998-99. Teamwork has gotten increased emphasis
from ABET and from employers, the World has gotten smaller and our sense of interdependence
has greatly increased, the importance of professional responsibility and ethics has magnified,
projects are becoming much more common. Because teamwork and projects are prevalent in
engineering in business, industry and government, they are also becoming common in
engineering classes. In addition to the importance of teamwork in the profession, teams are used
in classes because students working in well-structured teams learn more, remember it longer, and
develop superior problem-solving skills compared with students working individually. All these
changes increase the importance of learning (and practicing) the concepts, principles, and
heuristics in this book.
My civil engineering project management course is overflowing with students from across
the Institute of Technology at the University of Minnesota. They apparently are voting with their
feet, recognizing the importance of teamwork and project management skills. I really appreciate
their enthusiasm. The teaching team has grown considerably and now includes several graduate
students. The current teaching team includes Brandon Pierce, Connie Kampf, and Lori
Engstrom. and they have been wonderful in helping revise the course, and therefore, have had
lots of influence on this book. Two adjunct faculty, Tim Eiler and Randy Carlson, will start
teaching the course this year and I suspect the next iteration of this book will include lots of their
ideas.
The reviewers and editors made many wonderful suggestions for improving the book, many
of which I've incorporated in this edition. The most notable is probably the title change from
Project Management and Teamwork to Teamwork and Project Management, which was
suggested by Kelly Lowery and John Griffin.
Project Management and Teamwork was designed for first-year students, but was used by
other students, especially those in senior-level capstone design courses. Teamwork and Project
Management is still designed to be accessible by first-year students, but will be applicable for
upper division students who haven't had an opportunity to focus on Teamwork and Project
Management skills in earlier courses and programs.
Chapter One, the introduction and overview, was extensively revised. Chapters Two and
Three, the teamwork chapters were updated and expanded. Chapters Four and Five on project
management basics were rearranged and new material on Scoping Projects was added, based on
new developments and the importance of planning. The errors were corrected in Chapter Six, but
it wasn't changed much otherwise. The remainder of the book was updated.
Tom Peters wrote in his book The Project 50, "In the new economy, all work is project
work". My intention is that this book will help prepare you to work in the new economy. Good
teamwork and project work to you!
References
Johnson, P.E. 1982. Personal communication.
Peters, Tom. 1999. The project 50: Fifty ways to transform every “task” into a project that
matters. New York: Knopf.
Starfield, Anthony M., Smith Karl A., and Bleloch, Andrew L. 1994. How to model it: Problem
solving for the computer age. Edina, MN: Interaction Book Company.
Chapter One: Teamwork and Project Management In Engineering
Teamwork and Project Management is designed to help you prepare for professional practice
in the new economy. Teamwork has gotten increased emphasis from employers, the World has
gotten smaller and our sense of interdependence has greatly increased, the importance of
professional responsibility and ethics has magnified, and projects (and project-type
organizations) are becoming much more common. All these changes highlight the importance of
learning (and practicing) the concepts, principles, and heuristics in this book.
According to Thomas Friedman (2000) "the world is ten years old." Friedman's central
notion is GLOBALIZATION, that is, "the inexorable integration of markets, nation-states, and
technologies to a degree never witnessed before -- in a way that is enabling individuals,
corporations and nation-states to reach around the world farther, faster, deeper and cheaper than
ever before, and in a way that is enabling the world to reach into individuals, corporations and
nation-states farther, faster, deeper, and cheaper than ever before (p. 9)."
This is the world in which you’ll be working. It is very different from the world I started
working in as an engineer in 1969, but it is the world I try to cope with every semester with
undergraduate students in Civil Engineering and graduate students in three professional Masters
programs in which I teach – Management of Technology, Manufacturing Systems Engineering,
and Infrastructure Systems Engineering. The engineering graduates in these one-day-per week
two-year programs are working full-time and most of the participants work globally.
The essence of the globalization economy (according to James Surowiecki, Slate) is the
notion that: "Innovation replaces tradition. The present -- or perhaps the future -- replaces the
past." The importance of innovation and creativity in engineering is one of the features added to
this edition.
As we start this journey together here are some suggestions that I think will help you get the
most from this book. The essence of the suggestions are ACTIVITY, REFLECTION, and
COLLABORATION. First, I encourage you to engage in the activities, especially the exercises
in the book as they will help connect you with the material and its real-world applications.
Second, periodically throughout the book, I’ll ask you to stop and reflect. I encourage you to
take advantage of the opportunity. My goal is to give you a chance to describe what you already
know and to get you to think. Then when you read what I have to say about the topic you’ll have
a basis for comparing and contrasting. Finally, I encourage you to collaborate with others.
Working together is the norm in projects. Working together to learn the material in this book will
make it easier and, very likely, you’ll remember it longer.
My goal for this chapter is to create a context for teamwork and project management in
engineering. Let’s start my exploring the nature of engineering. Before you read ahead for
various answers to the question “What is engineering?” Please complete the following reflection.
What is Engineering?
Reflection: What is engineering and what does it mean to learn to engineer in school? What is
your experience with engineering? Did you learn about engineering in high school? Do you
have a brother or sister, mother or father, or other family relative or friend who is an engineer?
Take a minute to reflect on your where you learned about engineering and what your impressions
of engineering are. What did you come up with?
Since there are few high school courses in engineering, it is relatively difficult for first-year
students to have gained much exposure to engineering. Yet we are surrounded by engineering
accomplishments; they are so ubiquitous that we don't notice most of them. One of the foremost
thinkers and writers on engineering, mechanical engineering professor, Billy Koen, is noted for
asking four probing questions of his audiences (Koen, 1984). Koen’s first three questions are
explored at the beginning of the chapter, and his forth at the end. The first question is:
1. Can you name one thing in the room in which you are sitting (excluding yourself, of
course) that was not developed, produced, or delivered by an engineer?
Koen finds that the question is usually greeted with bewildered silence. I have posed Koen’s
questions to hundreds of first-year students, and they come up with some great suggestions: the
air (but how does it get into the room?), dirt (trapped in peoples shoes), electromagnetic
radiation (but the lights generate much more than the background). Almost every thing that we
encounter was developed, produced, or delivered by an engineer or engineers.
Koen’s second question is:
2. Can you name a profession that is affecting your life more incisively than is engineering?
Again, students name several professions but on reflection note that if it were not for
engineering, politicians would have a difficult time spreading their ideas; medical doctors,
without their tools, would be severely limited in what they could do; lawyers wouldn’t have
much to read; and so forth. Things such as telephones, computers, airplanes, and skyscrapers –
which have an enormous effect on our lives -- are all products of engineering.
Koen’s third question is:
3. Since engineering is evidently very important, can you now define the engineering
method for solving a problem?
Many students respond with a puzzled look as if I am asking an unfair question. They note that
they have a ready response to the question “What is the scientific method?” Students list things
like “applied science,” “problem solving,” “trial and error,” etc., but almost no one (over the
fifteen or so years that I’ve been asking this question) says “design.”
If you were to ask practicing engineers the question “What is the engineering method”? they
would likely respond “Engineering is design!” A group of national engineering leaders stated
that:
Design in a major sense is the essence of engineering; it begins with the identification of
a need and ends with a product or system in the hands of a user. It is primarily concerned
with synthesis rather than the analysis which is central to engineering science. Design,
above all else, distinguishes engineering from science (Hancock, 1986).
We’ll explore the concept of engineering design next – and save Koen’s fourth and final
question for the end of the chapter. In closing this section, I offer my favorite definition of an
engineer – an engineer is a jack of all trades and a master of some.
Engineering Design
If design is the essence of engineering, the next question is “what is design”? What comes to
mind when you consider the term “design.” Do you think of product design (such as
automobiles), architectural design, set and costume design (as in theater), or interface design (as
in computer)? Take a moment to collect your thoughts on design.
The Accreditation Board for Engineering and Technology (ABET), the group that accredits
engineering programs, defined engineering design as “the process of devising a system,
component or process to meet a desired need.”
Researchers who carefully observe the engineering design process are increasingly noting
that it is quite different from the formal process typically described. For example, Eugene
Ferguson (1992) writes:
Those who observe the process of engineering design find that it is not a totally formal
affair, and that drawings and specifications come into existence as a result of a social
process. The various members of a design group can be expected to have divergent
views of the most desirable ways to accomplish the design they are working on. As
Louis Bucciarelli (1994), an engineering professor who has observed engineering
designers at work, points out, informal negotiations, discussions, laughter, gossip, and
banter among members of a design group often have a leavening effect on its outcome.
Recent work on engineering design indicates that design is a more social process than we once
thought. Larry Leifer (Stanford Center for Design Research) claims that engineering design is "a
social process that identifies a need, defines a problem, and specifies a plan that enables others to
manufacture the solutions." Leifer's research shows that design is fundamentally a social
activity. He describes practices such as "negotiating understanding," "conserving ambiguity,"
"tailoring engineering communications for recipients," and " manipulating mundane
representations."
If design is the heart of engineering and

“Design team failure is usually due to failed
design is a social process, then it follows that team dynamics” Larry Leifer, Director,
Stanford Center for Design Research
project management and teamwork are
essential to engineering. Many problems with engineering result from poor team dynamics and
inadequate project management.
A lot has been written about engineering and engineering design. Some, such as Adams,
1991; Hapgood, 1992; Ferguson, 1992, can give students considerable insight into engineering.
One of the most interesting insights into engineering design is the ABC News Nightline show
documenting the design process at the product design firm IDEO (The Deep Dive, 1999). David
Kelly, IDEO’s ? challenges the viewer to “look around, the only things not designed by humans
are in nature.” Five steps are key to IDEO’s expertise in the innovative design practice:
1. Understand the market/client/technology/constraints
2. Observe real people in real situations
3. Visualize new-to-the-world concepts and ultimate customers
4. Evaluate and refine prototypes
5. Implement new concept for commercialization
I hope you have an opportunity to view this video/DVD. Students who I’ve shown it to exclaim
– “I want to work at a place like that!”.
Now that we’ve explored engineering, and I’ve tried to deepen your understanding of the
role of design, I turn to the role of teamwork and project management in engineering.
Teamwork and Engineering
How important is teamwork in the "I will pay more for the ability to deal with people
than any other ability under the sun."
practice of engineering? Take a moment and --John D. Rockefeller
reflect on your experiences and conversations "If you can't operate as a team player, no matter how
valuable you've been, you really don't belong at GE"
(1993)
on the importance and role of teamwork in --John F. Welch
CEO, General Electric
engineering practice?
The quotes from Rockefeller and Welch stress the importance of teamwork from a corporate
Chief Executive Officer (CEO) perspective, but what about the importance for engineering
graduates?
Teamwork and project management are central to engineering. Learning how to organize
and manage projects, and to participate effectively in project teams, will not only serve you well
in engineering school, where there are lots of group projects, but will also be critical to your
success as a professional engineer. The Boeing Company uses the following checklist when
considering new employees.
Employer’s Checklist — Boeing Company
U A good grasp of these engineering fundamentals:
Mathematics (including statistics)
Physical and life sciences
Information technology
U A good understanding of the design and manufacturing process (i.e., an understanding of
engineering)
U A basic understanding of the context in which engineering is practiced, including:
Economics and business practice
History
The environment
Customer and societal needs
U A multidisciplinary systems perspective
U Good communication skills
Written
Verbal
Graphic
Listening
U High ethical standards
U An ability to think critically and creatively as well as independently and cooperatively
U Flexibility--an ability and the self-confidence to adapt to rapid/major change
U Curiosity and a lifelong desire to learn
U A profound understanding of the importance of teamwork
ASEE Prism, December 1996, p. 11.
The Boeing Company checklist has been undergoing updates and refinements and the following
were added (or revised extensively) in a list titled “Desired attributes of a global engineer”:
U An awareness of the boundaries of one’s knowledge, along with an appreciation for other
areas of knowledge and their interrelatedness
with one’s own expertise

What Employers Want
U An awareness and strong appreciation • Learning to Learn

• Listening and Oral Communication
for other cultures and their diversity, • Competence in Reading, Writing, and
Computation
• Adaptability: Creative Thinking and
their distinctiveness, and their inherent Problem Solving
• Personal Management: Self-Esteem,
value Goal Setting/Motivation, and
Personal/Career Development
• Group Effectiveness: Interpersonal
U A strong commitment to teamwork, Skills, Negotiation, and Teamwork
• Organizational Effectiveness and
including extensive experience with and Leadership
understanding of team dynamics Workplace basics: The skills employers want.

1988. American Society for Training and
Development and U.S. Department of Labor.
U An ability to impart knowledge to
others.
The emphasis on teamwork is not entirely new as shown in the 1988 report Workplace
basics.
The importance of teamwork in business and industry is also embedded in the concepts of
concurrent (or simultaneous) engineering and total quality management. The following quote
elaborates on this point:
In concurrent engineering (CE), the key ingredient is teamwork. People from many
departments collaborate over the life of a product--from idea to obsolescence--to ensure
that it reflects customers' needs and desires. . .Since the very start of CE, product
development must involve all parts of an organization, effective teamwork depends
upon sharing ideas and goals beyond immediate assignments and departmental
loyalties. Such behavior is not typically taught in the engineering schools of U.S.
colleges and universities. For CE to succeed, teamwork and sharing must be valued just
as highly as the traditional attributes of technical competence and creativity, and they
must be rewarded by making them an integral part of the engineer's performance
evaluation (Shina, 1991).
The increased emphasis on teamwork in engineering classes is due, in part to the emphasis
by employers, but is also due to engineering education research on active and cooperative
learning, and the emphasis of the Accreditation Board for Engineering and Technology (ABET).
To maintain ABET accreditation, engineering departments must demonstrate that all of their
graduates have the following eleven general skills and abilities:
a. an ability to apply knowledge of mathematics, science, and engineering
b. an ability to design and conduct experiments, as well as to analyze and interpret data
c. an ability to design a system, component, or process to meet desired needs
d. an ability to function on multi-disciplinary teams
e. an ability to identify, formulate, and solve engineering problems
f. an understanding of professional and ethical responsibility
g. an ability to communicate effectively
h. the broad education necessary to understand the impact of engineering solutions in a global
and societal context
i. a recognition of the need for, and an ability to engage in life-long learning
j. a knowledge of contemporary issues
k. an ability to use the techniques, skills, and modern engineering tools necessary for
engineering practice.
As you no doubt have recognized there
is a confluence of pressures emphasizing Top Three Main Engineering Work Activities

(Burton, Parker & LeBold, 1998)
teamwork in engineering education and Engineering Total Civil/Architectural

• Design – 36% 1. Management – 45%
practice. We do, of course, need to leave • Computer 2. Design – 39%
applications – 31% 3. Computer
• Management – 29% applications – 20%
room for the “maverick”, but most, if not all,
Burton, L., Parker, L, & LeBold, W. 1998. U.S. engineering career trends.
engineering graduates need to develop skills ASEE Prism, 7(9), 18-21.
for working cooperatively with others, as
indicated by the Top Three Engineering
Work Activities.
The full list of work activity reported by engineers as shown in the Table 1.1. Note that 66%
mentioned design and 49% mentioned management.

Rank Order of Work Activities, 1993
(Burton, Parker & LeBold, 1996)

Activity Percent Mentioning
1. Design 66%
2. Computer Applications 58%
3. Management 49%
4. Development 47%
5. Accounting, etc. 42%
6. Applied Research 39%
7. Quality or Productivity 33%
8. Employee Relations 23%
9. Sales 20%
10. Basic Research 15%
11. Production 14%
12. Professional Services 10%
13. Other Work Activities 8%
14. Teaching 8%
Fundamental Tools for the Next Generation of Engineers and Project Managers
I’ve stressed the importance of teamwork for engineering education and practice, but that’s
not all. If engineers are going to become “The Master Integrators” as emphasized by Joe
Bordona (?), there are three additional tools that are fundamental:
• Systems/systems thinking/systems engineering
• Models
• Quality (I defer this to Chapter 7)

Systems Approach
In addition to teamwork, another idea emphasized not only in employer checklists like
Boeing’s but also in the new accreditation criteria for the Accreditation Board for Engineering
and Technology is that of systems and the systems approach.
A system is a whole that cannot be divided up into independent parts (Ackoff, 1994).
Systems are made up of sets of components that work together for a specified overall objective.
The systems approach is simply a way of thinking about total systems and their components.
Five basic considerations that must be kept in mind when thinking about the meaning of a
system: (1) the total system’s objectives and, more specifically, the performance measures of the
whole system; (2) the system's environment: the fixed constraints; (3) the resources of the
system; (4) the components of the system, their activities, goals, and measures of performance;
and (5) the management of the system (Churchman, 1968).
Systems thinking is a discipline for seeing wholes. It is a framework for seeing
interrelationships rather than things, for seeing patterns of change rather than static "snapshots."
It is a set of principles and a set of specific tools and techniques (Senge, 1990). An implication
of the systems approach is the importance of getting everybody involved to improve whole
systems (Weisbord, 1987). The systems approach is commonly operationalized through learning
organizations.
The Art & Practice of the Learning Organization
Peter Senge (In Ray & Rinzler, 1993)
1. Building Shared Vision. The idea of building shared vision stresses that you never quite
finish it--it's an ongoing process.
2. Personal Mastery. Learning organizations must be fully committed to the development of

each individual's personal mastery--each individual's capacity to create their life the way
they truly want.
3. Mental Models. Our vision of current reality has everything to do with the third discipline--
mental models--because what we really have in our lives is constructions, internal pictures
that we continually use of interpret and make sense out of the world.
4. Team Learning. Individual learning, no matter how wonderful it is or how great it makes us
feel, if fundamentally irrelevant to organizations, because virtually all important decisions
occur in groups. The learning unit of organizations are "teams," groups of people who need
one another to act.
5. Systems Thinking. The last discipline, the one that ties them all together, is systems
thinking.
As in many project management books, a systems theme, and will be one of the integrating
themes in this book. The idea of systems, along with that of the learning organization, has
important contributions to make not only to your study of project management but many other
things you will be studying in engineering. Here, for example, are eight principles for learning
from Xerox (Jordon, 1997):
1. Learning is fundamentally social.
2. Cracking the whip stifles learning.
3. Learning needs an environment that supports it.
4. Learning crosses hierarchical bounds.
5. Self-directed learning fuels the fire.
6. Learning by doing is more powerful than memorizing.

7. Failure to learn is often the fault of the system, not the people.
8. Sometimes the best learning is unlearning.
The above list from Xerox indicates that the ideas in this book are not only important for your
project work but also for your day-to-day work in engineering school.
Model and Modeling
Modeling in its broadest sense is the cost-effective use of something in place of something
else for some cognitive purpose (Rothenberg, 1989). A model represents reality for the given
purpose; the model is an abstraction of reality, however, in the sense that it cannot represent all
aspects of reality. Models are characterized by three essential attributes: (1) Reference: It is of
something (its referent); (2) Purpose: It has an intended cognitive purpose with respect to its
referent; (3) Cost-effectiveness: It is more cost-effective to use the model for this purpose than to
use the referent itself.
A problem that I often give to help students learn about these attributes of modeling
involves determining the maximum number of Ping-Pong balls that could fit in the room they’re
sitting in. First I give them about 20 seconds and ask each person to guess. Next I ask them to
work in groups for about 5-10 minutes to develop not only a numerical estimate but also a
description of the method they use. At this stage students typically model the room as a
rectangular box and the ball as a cube. They then determine the number by dividing the volume
of the room by the volume of a ball. I ask them what they would do if I gave them the rest of the
class period to work on the problem. Sooner or later a student says “Who cares how many Ping-
Pong balls could fit in the room!” I thank that student and report that we can now stop. In any
problem that involves modeling, the purpose must be specified. Without knowing the purpose,
we don’t know how good an answer is needed or how to use the model. In fact, the 20 second
answer might be good enough.
An essential aspect of modeling is the use of heuristics (Starfield, Smith and Bleloch, 1994),
which may be generally defined as methods or strategies that aid in discovery or problem
solving. Although difficult to define, heuristics are relatively easy to identify using the
characteristics listed by Koen (1984, 1985, 2002): (1) Heuristics do not guarantee a solution;
(2) Two heuristics may contradict or give different answers to the same question and still be
useful; (3) Heuristics permit the solving of unsolvable problems or reduce the search time to a
satisfactory solution; (4) The heuristic depends on the immediate context instead of absolute
truth as a standard of validity.
Thus, a heuristic is anything that provides a plausible aid or direction in the solution of a
problem but is in the final analysis unjustified, incapable of justification, and fallible. It is used
to guide, to discover, and to reveal. Heuristics are also a key part of the Koen's definition of the
engineering method: The engineering method is the use of heuristics to cause the best change in
a poorly understood situation within the available resources (p. 70). Typical engineering
heuristics include: (1) Rules of thumb and orders of magnitude; (2) Factors of safety; (3)
Heuristics that determine the engineer's attitude toward his or her work; (4) Heuristics that
engineers use to keep risk within acceptable bounds; and (5) Rules of thumb that are important in
resource allocation.
Models and heuristics will constitute a major part of this book. The Critical Path Method
(CPM) is a procedure for modeling complex projects with interdependent activities. Visual
representations include Gantt charts and network diagrams. My goal is for you to develop skills
and confidence to organize, manage, be a participant, and lead project teams. This goal is
consistent with current thinking about the purpose of engineering schools. Deming associate and
engineering educator, Myron Tribus summarized the purpose of engineering schools as follows
(1996):
The purpose of a School of Engineering is to teach students to create value through the
design of high quality products and systems of production, and services, and to organize
and lead people in the continuous improvement of these designs.
Notice that in Tribus' statement, management is considered an integral part of engineering. He
also elaborates on the importance of group work for learning to engineer:
The main tool for teaching wisdom and character is the group project. Experiences with
group activities, in which the members of the groups are required to exhibit honesty,
integrity, perseverance, creativity and cooperation, provide the basis for critical review
by both students and teachers. Teachers will need to learn to function more as coaches
and resources and less as givers of knowledge.
Reflection: Project Management and Teamwork in Engineering
As I finished writing this book, I was reminded of a book I read almost 20 years ago –
Excellence in Engineering – by W.H. Roadstrum (1978). I was unable to locate my copy (I
probably loaned it out) but did find the second edition, Being Successful as an Engineer
(Roadstrum, 1988). In this edition, Roadstrum remarks “Engineering is almost completely
divorced from this concept of routine and continuous. Engineering work is project work” (p. 7).
Engineering is project work! This is the essence of Roadstrum’s book. The first two chapters,
“What Engineering Is” and “The Engineer,” cover ground similar to the material given in this
chapter, but from a perspective about 15 years ago. Roadstrum then addresses “The Project and
the Project Team” and “”Project Control” in Chapters 3 and 4. Although I had not looked at
Roadstrum’s book for several years, I was struck by the overlap between his book and mine.
Being Successful as an Engineer addresses a broad range of topics, including problem
solving, laboratory work, design, research and development, manufacturing and quality control,
systems, proposal work, human relations, and creativity. Roadstrum writes, “Design is the heart
of the engineering process – its most characteristic activity.” Furthermore, he states “If you and
I are going to understand engineering, we’ll have to understand design.” (p. 97).
Roadstrum elaborates on the role of the project engineer, with the following statement:
Every engineer looks forward to the time when he can have a project of his own. A
project engineer has the best job in the business. He has ultimate responsibility for the
work as a whole. He is the real architect of the project solution. Even more than his
colleagues, he looks at the job as a whole from the beginning. He watches carefully to
make all details come together into a timely, economical, fresh, and effective meeting
of the need (p166).
Roadstrum’s book and ideas no doubt influenced my decision to develop skills and expertise in
project management, however, the specific reference lay dormant until now. I hope my book
will influence your experience and practice of project management in engineering.
As a final note, recall the discussion at the beginning of the chapter of Professor Billy
Koen’s probing questions. Koen’s fourth question in case you’re interested is “Lacking a ready
answer [to the third question – What is the engineering method?], can you then name a nationally
known engineer who is wise, well-read, and recognized as a scholar in the field of engineering –
one t to whom I can turn to find out what engineering really is”? To whom would you turn?
Difficult, isn’t it? No other profession lacks knowledgeable, clearly recognized spokespersons. I
sincerely hope that you’ll help provide the leadership to make engineering better known.
Questions
1. What is engineering? How does engineering differ from science? What role does design
play in engineering?
2. What is a model? Why are models useful in project management and in engineering?
3. What is a system? Why are many project management books organized around a systems
approach?
Exercises
1. Summarize your course work and experiences with engineering and design. What are some
of the key things you’ve learned about engineers and engineering? Do you have relatives or
friends who are project managers or engineers? If so, talk with them.
2. Why should you, as a first year engineering student, be interested in project management
and teamwork? Take a minute and reflect. Jot down at least three reasons why a first year
engineering student should be interested in project management and teamwork. What did
you come up with? Did you say, for instance, that project management and teamwork are
integral to engineering professional practice?
3. Inventory your good experiences with projects and teamwork. Have you had experience
with a team that had extraordinary accomplishments? If so, describe the situation,
especially the characteristics of the team and project that led to extraordinary success. What
were some of the characteristics— “a sense of urgency”?, “a project too complex or timeline
too short for one person to complete”?, or “need for synergistic interaction”?
References
Ackoff, Russell L. 1994. The democratic corporation: A radical prescription for recreating
corporate America and rediscovering success. Oxford: Oxford University Press.

Adams, James L. 1991. Flying buttresses, entropy, and o-rings: The world of an engineer.
Cambridge, MA: Harvard University Press.
Bucciarelli, Louis. 1994. Designing engineers. Cambridge, MA: MIT Press.
Burton, Lawrence, Parker, Linda, and LeBold, William K. U.S. engineering career trends. ASEE
Prism, 7(9), 18-21.
Chapman, William L.;Bahill, A. Terry and Wymore, A. Wayne. 1992. Engineering Modeling
and Design. Boca Raton, FL: CRC Press.
Churchman, C. West. 1968. The systems approach. New York: Laurel.
Ferguson, Eugene S. 1992. Engineering and the minds eye. Cambridge, MA: MIT Press.
Hapgood, Fred. 1992. Up the infinite corridor: MIT and the technical imagination. Reading,
MA: Addison-Wesley.
Jordon, Brigitte. 1996. 8 principles for learning. Fast Company, Issue 5, October/November,
116.
Koen, B.V. 1984. Toward a definition of the engineering method. Engineering Education, 75,
151-155.
Koen, Billy V. 1985. Definition of the engineering method. Washington: American Society for
Engineering Education.
Koen, Billy V. 2002. Discussion of the method. Oxford: Oxford University Press.
Leifer, Larry. 1997. NTU Faculty Forum reference on design in groups–Design failure is due to
team dynamics failure.
Papalambros, Panos Y. and Wilde, Douglass J. 1988. Principles of optimal design: Modeling
and computation. Cambridge, England: Cambridge University Press.
Ray, Michael & Rinzler, Alan. (Eds). 1993. The new paradigm in business: Emerging
strategies for leadership and organizational change. Los Angeles: Tarcher/Perigee.
Roadstrum, W.H. 1988. Being successful as an engineer. San Jose: Engineering Press.
Rothenberg, James. 1989. "The nature of modeling," Artificial intelligence, simulation &
modeling, ed. L.E. Widman, K.A. Loparo and N.R. Nielsen (New York: Wiley).
Senge, Peter. 1990. The fifth discipline: The art and practice of the learning organization.
New York: Doubleday.
Shina, S.G. 1991. "New rules for world-class companies," Special Report on Concurrent
Engineering, ed. A. Rosenblatt & G.F. Watson, IEEE Spectrum, 28 (7), 22-37.
Starfield, Anthony M.; Smith, Karl A. and Bleloch, Andrew L. 1994. How to model it: Problem
solving for the computer age. Edina, MN: Burgess.
Tribus, Myron. 1996. "Total quality management in schools of business and engineering,” In
Harry V. Roberts (Ed.), Academic initiatives in total quality for higher education, 17-40.
Milwaukee: ASQC Quality Press.
Weisbord, Marvin R. 1987. Productive workplaces: Organizing and managing for dignity,
meaning, and community. San Francisco: Jossey-Bass.

Chapter Two: Teamwork
Reflection: Think about a really effective

"Everyone has to work together; if we can't get
team that you’ve been a member of, a team everybody working toward common goals, nothing is
going to happen."
that accomplished extraordinary things and --Harold K. Sperlich
Former President, Chrysler Corporation
perhaps was even a great place to be. Start
Coming together is a beginning;
by thinking about teams in an academic, Keeping together is progress;
Working together is success.
professional, or work setting. If no examples --Henry Ford
come to mind, then think about social or
community-based teams. If again you don’t conjure up an example, then think about sports
teams. Finally, if you don’t come up with a scenario from any of these contexts, then simply
imagine yourself as a member of a really effective team. OK, got a picture of the team in mind?
As you recall (or imagine) this highly effective team experience, try to extract the specific
characteristics of the team. What was it about the team that made it so effective? Please make a
list.
Look over the list you made in the above Reflection. Did you preface your list with “it
depends”? The characteristics of an effective team depend, of course, on the purpose of the
team. In large measure they depend on the team’s task goals (those concerning what the team is
to do) and maintenance goals (those concerning how the team functions). Michael Schrage
(1991) states emphatically:
[P]eople must understand that real value in the sciences, the arts, commerce, and,
indeed one’s personal and professional lives, come largely from the process of
collaboration. What’s more, the quality and quantity of meaningful collaboration often
depend upon the tools used to create it (p. 27). . . Collaboration is a purposive
Project Management and Teamwork 32 Karl A. Smith
relationship. At the heart of collaboration is a desire or need to: solve a problem,
create, or discover something.
Let’s assume that it’s a team that has both task and maintenance goals, since most effective
teams have a job to do (a report to write, project to complete, presentation to give, etc.) but also a
goal of getting better at working with one another.
I’ve used the Reflection above with hundreds of faculty and students in workshop and
classroom settings. Here is a typical list of the characteristics of effective teams:
good participation common goal
respect sense of purpose
careful listening good meeting facilitation
leadership empowered members
constructively managed conflict members take responsibility
fun, liked to be there effective decision making
My goal for this chapter is to help you get a sense of the essential characteristics of teams
that perform at a high level by drawing on your experience (as I have tried to do above) and start
connecting you with some of the rapidly expanding literature in this area. I remind you of the
importance of maintaining a team climate that embraces and celebrates diversity. I summarize
some of the classic work on stages of team development. Finally, I aim to familiarize you with
emerging notions, such as “Communities of Practice,” “Network Quotient,” and “Emotional
Intelligence.”
Definition of a Team
Katzenbach and Smith (1993) studied teams that performed at a variety of levels and came
up with four categories: Pseudo Teams that perform below the level of the average member.
Potential Teams that don’t quite get going but struggle along at or slightly above the level of the
average member. Real Teams that perform quite well, and High-Performing Teams that perform
at an extraordinary level. Katzenbach and Smith then looked for common characteristics of real
teams and high-performing teams. All real teams had the following characteristics: a small
number of people with complementary skills who are committed to a common purpose,
performance goals, and approach for which they hold
themselves mutually accountable. High-performing teams
met all the conditions of real teams, and in addition, had
members who were deeply committed to one another’s
personal growth and success.
Reflection: Now think about the teams that are being used
in your engineering classes. Think about your most
successful/effective team project experience. What were
the characteristics of the team? What were the conditions? Figure 2.1Group Performance
Are they similar to your most effective teams? Describe the team development process.
Types of Learning Teams
There is nothing magical about teamwork in engineering classes. For example, some types
of learning teams increase the quality of classroom life and facilitate student learning. Other
types of teams hinder student learning and create disharmony and dissatisfaction with classroom
life. To use teamwork effectively, you must know what is and what is not an effective team.
There are many types of teams that can be used in classrooms. Formal cooperative learning
groups is just one of them, although they are becoming quite common (Johnson, Johnson &
Smith, 1998b). When you choose to use (or are asked or required to use) instructional groups,
you must ask yourself “What type of group or team am I involved in”? The following checklist
and accompanying Figure 2.1 may be helpful in answering that question.
1. Pseudo-Learning Group: Students are assigned to work together but they have no interest
in doing so. They believe they will be evaluated by being ranked from the highest performer to
the lowest performer. While on the surface students talk to each other, under the surface they are
competing. They see each other as rivals who must be defeated, block or interfere with each
other's learning, hide information from each other, attempt to mislead and confuse each other,
and distrust each other. Students would achieve more if they were working alone.
2. Traditional Classroom Learning Group: Students are assigned to work together and
accept that they must do so. Assignments are structured, however, so that very little joint work
is required. Students believe that they will be evaluated and rewarded as individuals, not as
members of the group. They interact primarily to clarify how assignments are to be done. They
seek each other's information, but have no motivation to teach what they know to their
groupmates. Helping and sharing is minimized. Some students loaf, seeking a free ride on the
efforts of their more conscientious groupmates. The conscientious members feel exploited and
do less. The result is that the sum of the whole is more than the potential of some of the
members, but the more hard working and conscientious students would perform higher if they
worked alone.
3. Cooperative Learning Groups: Students are assigned to work together and, given the
complexity of the task and the necessity for diverse perspectives, they are relieved to do so.
They know that their success depends on the efforts of all group members. The group format is
clearly defined. First, the group goal of maximizing all members' learning provides a
compelling common purpose that motivates members to roll up their sleeves and accomplish
something beyond their individual achievements. Second, group members hold themselves and
each other accountable for doing high quality work to achieve their mutual goals. Third, group
members work face-to-face to produce joint work-products. They do real work together.
Students promote each other's success through helping, sharing, assisting, explaining, and
encouraging. They provide both academic and personal support based on a commitment to and
caring about each other. Fourth, group members are taught teamwork skills and are expected to
use them to coordinate their efforts and achieve their goals. Both task and teambuilding skills
are emphasized. All members share responsibility for providing leadership. Finally, groups
analyze how effectively they are achieving their goals and how well members are working
together. There is an emphasis on continual improvement of the quality of learning and
teamwork processes. A recent “students guide to success in active learning” is available in the
book Striving for Excellence in College (Browne & Keeley, 1997).
4. High-Performance Cooperative Learning Group: This is a group that meets all the
criteria for being a cooperative learning group and outperforms all reasonable expectations,
given its membership. What differentiates the high-performance group from the cooperative
learning group is the level of commitment members have to each other and the group's success.
Jennifer Futernick, who is part of a high-performing, rapid response team at McKinsey &
Company, calls the emotional binding of her teammates together a form of love (Katzenbach &
Smith, 1993). Ken Hoepner of the Burlington Northern Intermodal Transport Team (also
described in Katzenbach & Smith, 1993) stated: "Not only did we trust each other, not only did
we respect each other, but we gave a damn about the rest of the people on this team. If we saw
somebody vulnerable, we were there to help." Members' mutual concern for each other's
personal growth enables high-performance cooperative groups to perform far above
expectations, and also to have lots of fun. The bad news about extraordinarily high-performance
cooperative learning groups is that they are rare. Most groups never achieve this level of
development.
Groups and Teams
I’ve been using the term “team” in reference to projects and “group”in reference to learning.
Many folks, including me, use these two terms interchangeably and I will continue to do so
throughout this book. The traditional literature focuses on groups, while recently some have
been making distinctions between groups and teams. For example, Katzenbach and Smith
(1993) summarize the major differences between working groups and teams in Table 2.1:
Table 2.1
Not All Groups Are Teams: How to Tell the Difference
Working Group Team
Strong, clearly focused leader Shared leadership roles

Individual accountability Individual and mutual accountability
The group's purpose is the same as the Specific team purpose that the team itself
broader organizational mission delivers

Individual work-products Collective work-products
Runs efficient meetings Encourages open-ended discussion and
active problem-solving meetings

Measures its effectiveness indirectly by its Measures performance directly by assessing
influence on others collective work-products

Discusses, decides, and delegates Discusses, decides, and does real work
together
Are there any surprises in this list from your perspective? Many students emphasize the
importance of a strong leader, but Katzenback and Smith indicate that “real” teams have shared
leadership roles. Also notice that the literature on “high-performance” teams indicates that they
are composed of members with complementary skills, that is, they’re diverse.
Importance of Diversity
Often we must work with people who are different from us or difficult to work with but
whose skills, talents, expertise, experience, etc. are essential to the project. It may seen
impossible at times, but look at the example of Phil Jackson (former head coach of the Chicago
Bulls basketball team). Can you imagine more a more diverse group than one made up of
Dennis Rodman, Michael Jordon, and Scottie Pippin). Phil Jackson is an “expert at managing
diversity”. Diversity has many faces, including preferred learning style – visual, auditory,
kinesthetic; background and experience; ethnic and cultural heritage; and sex, gender, and sexual
orientation. The evidence from effective groups is that diversity is important, that is, the better
the group represents the broader community, the more likely it is to make significant, creative,
and desired contributions. Participating in and managing diverse groups is not always easy,
since diverse groups usually bring a diversity of ideas and priorities. Here are some
considerations that may help you learn to manage diverse groups more effectively (Cabanis,
1997; Cherbeneau, Jeanne. 1997):
1. Learning skills for working with all kinds of people
4. Stress that effective teams are diverse
5. Stress the importance of requirements
6. Emphasize performance
7. Developing perspective taking skills
8. Respect and appreciation for alternative perspectives, etc.
Chicago Bulls’ head coach Phil Jackson advocates that “Good teams become great ones
when the members trust each other enough to surrender the ‘me’ for the ‘we’.” His recent book
Sacred hoops: Spiritual lessons of a hardwood warrior Phil Jackson and Hugh Delehanty
(1995) offer terrific advice on organizing and managing extraordinarily high performing teams.
Reflection: On Diversity
One of the greatest challenges I faced as co-coordinator of the Bush Faculty Development
Program for Excellence and Diversity in Teaching at the University of Minnesota was helping
science, mathematics, and engineering colleagues recognize the importance of the discrepancy
between the rapidly growing diversity of the population and the lack of diversity among the
student body. My most memorable exposure to these issues was the September 1997 conference
held at Penn State “Best Practices in Diversity: Exploring Practical Applications for the 21st
Century.” It was a real eye-opener for me to see and hear so many people deeply engaged in
“making the great diversity of our nation work for the future” (from Graham Spanier’s welcome
letter). The conference was particularly memorable because it came at the beginning of my
sabbatic leave at Michigan State University and since they had so many students, faculty, staff,
and administrators participating in the conference they chartered a bus and we rode with one
another from Lansing to State College and back.
Let’s start by exploring the question, “Why bother”? Why should we be concerned about the
diversity dimension of students’ team experiences?
First, there is little attention paid and little willingness to recognize that not all students are
the same. University of Minnesota Astronomy professor Larry Rudnick once said “I used to
think all students learn exactly the same way I do; perhaps a little slower.” It seems that many
faculty feel this way not only about learning styles but about many other things as well –
outlook, cultural or ethnic background, experience, motivation, expectations, and sexual
orientation. Not only is this “sameness” approach simpler and easier, it’s also safer. If faculty
only have to design one instructional system, a “one size fits all,” and probably the one they
experienced as a student, then it’s familiar and manageable. If faculty acknowledge that learners
are different then they must face lots of unknowns, and more work. The consequence for
students is that if faculty don’t provide opportunities for a diversity of experiences in the
classroom, then students are less likely to build skills about others and knowledge for working in
teams with diverse membership.
The consequences of ignoring differences are enormous. For example, students from some
cultures (some Native Americans and Asians, for example) are reluctant to correct others or to
make them look bad in front of their peers. Students face this in situations like the individual
test followed by a group test format where individual students get a higher score but don’t
contradict the group during the group exam portion. When asked a typical response is “In my
culture it’s unacceptable to correct someone else.” One group dealt with this by always having
the Asian-American student go first during the group exam portion. Furthermore, ignoring
differences makes many people feel unwelcome, which we address in the next section.
Second, the demographics of the United States are changing very rapidly and undergraduate
engineering enrollments don’t reflect the broader diversity. Often people don’t choose to be in
situations where they don’t see some of themselves mirrored.
William. A. Wulf (1998), President of the National Academy of Engineering, stressed this
point in “Diversity in Engineering.” He opened the article with the following:
Every time an engineering problem is approached with a pale, male design team, it may
be difficult to find the best solution, understand the design options, or know how to
evaluate the constraints.
Wulf also made a case for the connection between diversity and creativity, as indicated by the
following:
Collective diversity, or diversity of the group – the kind of diversity that people usually
talk about – is just as essential to good engineering as individual diversity. At a
fundamental level, men, women, ethnic minorities, racial minorities, and people with
handicaps, experience the world differently. Those differences in experience are the
“gene pool” from which creativity springs.
If people don’t see themselves represented then it’s hard for them to be interested in the
designs, products and services created by engineers. Furthermore, engineering is going to be
deprived of marvelous talents.
Finally, it’s the law of the land. At least three times (Brown vs. Board of Education, Title
IX, PL 94-142) the United States Supreme Court and Congress have re-emphasized that all
citizens have equal rights and opportunities. Essentially these three decisions and laws stress
that all individuals, regardless of differences, have a right to access to the broader peer group!
Characteristics of Effective Teams
The research on highly effective teams both in the classroom (Johnson, Johnson & Smith,
1991, 1998a, 1998b) and in the workplace (Bennis & Biederman, 1997; Hargrove, 1998;
Katzenbach & Smith, 1993; Schrage, 1991, 1996) reveals a short list of characteristics:
1. Positive Interdependence, such as common goal or single product
2. Individual and group accountability, that is, each person taking responsibility for his or her
work and the overall work of the group.
3. Promotive interaction, usually face-to-face, where each member does real work.
4. Teamwork skills where each member has and practices effective communication (especially
careful listening), decision making, problem solving, conflict management, and leadership.
5. Group processing where the group periodically reflects on how well the group is working,
celebrates the things that are going well and problem solves the things that aren’t.
Teams have become commonplace in engineering practice and are making inroads in
engineering education. There is an immense literature on teams and teamwork, ranging from
very practical guides — The Team Handbook

Building Team Performance
and The Team Memory Jogger — to (Katzenbach & Smith, 1994)
conceptual and theoretical treatises — • Establish urgency and direction

• Select members based on skill and
Joining Together: Group Theory and Group potential, not personalities
• Pay attention to first meeting and
Skills and Groups that work (and those that actions
• Set clear rules of behavior
doesn’t): Creating conditions for effective • Set some immediate performance-
oriented tasks and goals
teamwork. Check out one of these to • Challenge the group regularly with
fresh information
broaden and deepen your understanding of • Spend lots of time together
• Exploit the power of positive
teamwork. Four books were highlighted in feedback, recognition, and reward
this chapter — Shared Minds: The New
Technologies of Collaboration, The Wisdom of Teams: Creating the High-Performance
Organization, and Organizing Genius: The Secrets of Creative Collaboration, and Mastering the
art of creative collaboration. These four books focus on extraordinary teams — teams that
perform at unusually high levels where members experience accomplishments through
synergistic interaction that they rarely experience in other settings. They provide lots of
examples and insights into high performance teams.
Stages of Team Development
Teams often progress through a series of stages. One of the most common “sequential-stage
theories” was formulated by Bruce W. Tuckman (Tuckman, 1965, Tuckman & Jensen, 1977).
He noted that teams develop through five sequential stages, which he labeled forming, storming,
norming, performing, and adjourning. Members get to know one another and start to learn to
work together in the forming stage. Differences and conflict appears during the storming stage
and much of the team’s focus is on managing conflict. The team works together to accomplish
the goals during the performing stage. The group dissolves during the adjourning stage.
An alternative to stage theory was developed by Robert Bales (1965), where he noted that
an equilibrium has to exist between the team’s task orientation and it’s relationship or team
maintenance orientation. Teams oscillate between a focus on achieving their goals and
maintaining good working relationships (more the emotional dimension).
Both these perspectives are valuable for understanding team development. Teams move
through stages while dealing with issues that emerge. Further information on team development
is available in The Team Developer (McGourty & DeMeuse, 2001, Joining Together (Johnson &
Johnson, 1991), The Team Handbook (Scholtes, , Joiner& Streibel 1996).
Emerging Ideas
Other exciting development in area of teamwork is the emergence of communities of
practice, emotional intelligence and network quotient. Communities of practice are essential in
many companies (Boeing, Daimler Chrysler, ?, for example) for managing and developing
knowledge. Here’s a definition:
“Communities of practice are groups of people who share a concern, a set of problems,
or a passion about a topic, and who deepen their knowledge and expertise in this area
by interacting on an ongoing basis” (Wenger, McDermott & Snyder, 2002).
Emotional intelligence is another emerging idea that is being heralded for it’s importance for
team and project success. Daniel Goleman (1998) defines emotional intelligence as “the capacity
for recognizing our own feelings and those of others, for motivating ourselves, and for managing
emotions well in ourselves and in our relationships.” A related idea is that of NQ or network
quotient.
Tom Boyle of British Telecom calls this the age of interdependence; he speaks of the
importance of people’s NQ, or network quotient – their capacity to form connections with one
another, which, Boyle argues is now more important than IQ, the measure of individual
intelligence (Cohen & Prusak, 2001).
The emerging ideas summarized above indicate that teamwork, project management and
knowledge management are dynamic areas where there is a lot of innovation. So, stay posted and
stay alert.
Effective teamwork is not easy to accomplish. Engineering professor Douglas J. Wilde said
“It’s the soft stuff that’s hard, the hard stuff is easy.” Larry Leifer, Director or the Stanford
Center for Design Research, reports “Design team failure is usually due to failed team
dynamics.” However if you work at it, continue to study and learn about effective teamwork,
and attend to the skills and strategies needed for effective teamwork described in the next
chapter, you will very likely have many positive team experiences (and save yourself a lot of
grief!).
Reflection: Interdependence and Teamwork
I’ve been a student of interdependence and teamwork ever since I took a course on the
social psychology of education in about 1974. Prior to that I had predominantly thought of
learning and work for that matter as an individual endeavor. The instructor, Dennis Falk, one of
David Johnson’s graduate students, had us working together, cooperatively; and he emphasized
positive interdependence. I had an epiphany! I thought “This is the way I worked as an
engineer.” “Why isn’t the classroom organized in this way?” Numerous resources are available
to help faculty organize and manage learning teams, especially those developed by the
Foundation Coalition Active/Cooperative Learning project (www.foundationcoalition.org) and

this resource is intended to help students learn how to work together.
I’ve often wondered, “Why did this occur in Minnesota?” I haven’t discovered that yet, but
think it may be due to the Lakota presence in Minnesota. One of the cornerstones of Lakota
culture is the phrase used in all their ceremonies – mitakuye oyasin (“we are all related”)
(Marshall, 2001). According to Medearis and White Hat (1995), the connection between
mitakuye oyasin and education is “Education is an art of process, participation, and making
connection. Learning is a growth and life process; and life and Nature are always relationships in
process”
References
Bales, Robert F. 1965. The equilibrium problem in small groups. In A. Hare, E. Borgatta, & R.
Bales (Eds.), Small groups: Studies in social interaction. New York: Alfred A. Knopf.
Bennis, Warren & Biederman, Patricia. 1997. Organizing genius: The secrets of the creative
organization. Reading, MA: Addison-Wesley.
Brassand, Michael. 1995. The team memory jogger: A pocket guide for team members.
Madison, WI: GOAL/QPC and Joiner Associates.
Brown, M. Neil and Keeley, Stuart. 1997. Striving for excellence in college. Upper Saddle
River, NJ: Prentice-Hall.
Cabanis, Jeannette. 1997. Diversity: This means you. PM Network, 11(10), 29-33.
Cherbeneau, Jeanne. 1997. Hearing every voice: How to maximize the value of diversity on
project teams. PM Network, 11(10), 34-36.
Cohen, Don & Prusak, Laurence. 2001. In good company: How social capital makes
organizations work. Cambridge, MA: Harvard Business School Press.
Covey, Stephan R. 1989. The seven habits of highly effective people. New York: Simon &
Schuster.
Goleman, Daniel. 1998. Working with emotional intelligence. NY: Bantam.
Hackman, J.R. 1990. Groups that work (and those that don't): Creating conditions for effective
teamwork. San Francisco: Jossey-Bass.
Hargrove, Robert. 1998. Mastering the art of creative collaboration. New York: McGraw-Hill.
Jackson. Phil and Delehanty, Hugh. 1995. Sacred hoops: Spiritual lessons of a hardwood
warrior. Hyperion.
Johnson, David W., Johnson, Roger T. and Smith, Karl A. 1991. Cooperative learning:
Increasing college faculty instructional productivity, Washington: ASHE-ERIC Reports on
Higher Education.
Johnson, David W., Johnson, Roger T. and Smith, Karl A. 1998a. Active learning:
Cooperation in the college classroom. (2nd Ed). Edina, MN: Interaction Book Company.
Johnson, David W., Johnson, Roger T. and Smith, Karl A. 1998b. Maximizing instruction
through cooperative learning. ASEE Prism, 7(6), 24-29.
Johnson, David W., & Johnson, Frank P. 1991. Joining together: Group theory and group
skills, 4th ed. Englewood Cliffs, NJ: Prentice-Hall.
Katzenbach, Jon & Smith, Douglas. 1993. The wisdom of teams: Creating the high-
performance organization. Cambridge, MA: Harvard Business School Press.
McGourty, Jack & DeMeuse, Kenneth P. 2001 The Team Developer: An assessment and skill
building program. New York: Wiley.
Marshall, Joseph M. III. 2001. The Lakota way: Stories and lessons for living. New York:
Penguin.
Medearis, Cheryl and White Hat, Sr., Albert. 1995. Mitakuye oyasin. Collaboration for the
Advancement of College Teaching and Learning Faculty Development Conference.
Scholtes, Peter R., Joiner, Brian L. & and Streibel, Barbara J. 1996. The team handbook.
Madison, WI: Joiner Associates.
Schrage, Michael. 1995. No more teams! Mastering the dynamics of creative
collaboration..New York: Doubleday.
Schrage, Michael. 1991. Shared minds. New York: Random House.
Wulf, William A. 1998. Diversity in Engineering. The Bridge, 28 (4).
Tuckman, Bruce. 1965. Development sequence in small groups. Psychological Bulletin, 63, 384-
399.
Tuckman, Bruce & Jensen, M. 1977. Stages of small group development revisited. Groups and
Organizational Studies, 2, 419-427.
Wenger, Etienne, McDermott, Richard, and Snyder, William. 2002. Cultivating Communities of
Practice. Cambridge, MA: Harvard Business School Press.
Questions
1. What are the characteristics of effective teams? How do you help promote them?
2. Where and how have teamwork skills been taught or emphasized to you? In school?, social
groups?, professional groups?, your family? Describe two or three instances where
teamwork skills were emphasized.
3. How is increasing ethnic diversity effecting project teams? What are some strategies for
effectively participating on and managing diverse teams?
4. Students often remark “but groups in school are different from groups in the workplace.”
The remark is delivered as a reason for not using groups in school. Is it a valid excuse?
Summarize the major differences between groups in school and groups in the workplace.
How are these differences beneficial, harmful, to the work of the group? What are some
things that you can do to improve the school groups? [The most important ways I can think
of to improve school groups is to provide training in effective group work (such as this book
tries to provide), and to make sure grading practices are consistent with grouping practices,
that is, to ensure that group members are truly interdependent and that students are not being
graded on a curve.]
EXERCISES
1. Check out a reference on teams that have performed at extraordinary levels. Some of the
books I listed (Hargrove, Bennis & Biederman, Schrage, etc.) have terrific stories of stellar
teams. You may want to check the library or do a search of the literature electronically.
Summarize the features of these “extraordinary” teams. How do they compare with the list
provided in this chapter? Remember, this is a dynamic area of research with lots of new
books and articles appearing each year!
2. Look for opportunities to participate in a superb team. Make a plan for participating in a
high-performance team.
3. Note the diversity of teams in school and in the workplace and note strategies for
recognizing, valuing, and celebrating diversity.

Chapter Three: Teamwork Skills and Problem Solving
Reflection: Have you been a member of a team that got the job done (wrote the report, finished
the project, completed the laboratory assignment) but ended up with the members hating one
another so intensely they never wanted to see each other again? Most students have, and they
find it very frustrating. Similarly, have you been a member of a team whose members really
enjoyed one another’s company and had a great time socially, but in the end hadn’t finished the
project? Again, most students have been a member of this type of group and find it also a
frustrating experience. Take a moment to recall your experiences with these two extremes of
teamwork.
Importance of Task and Relationship
As noted in Chapter 2, to be most "I will pay more for the ability to deal with people
than any other ability under the sun."
effective, groups need to do two things very --John D. Rockefeller
well: accomplish the task and get better at "If you can't operate as a team player, no matter how
valuable you've been, you really don't belong at GE"
(1993)
working with one another. Both of these --John F. Welch
CEO, General Electric
require leadership – not just from a single
person acting as the leader but from every member contributing to the leadership of the group.
This chapter focuses on teamwork skills using a “distributed actions approach” to leadership.
Distributed actions are specific behaviors that group members engage in to help the group
accomplish its task or to improve working relationships. Napier and Gershenfield (1973)
summarize many of these behaviors (Table 3.1). Note the date–1973– which indicates that
effective group work is not a new concept.

Table 3.1 Group Task and Maintenance Roles
Group Task Roles Group Maintenance Roles

Initiating Encouraging
Seeking Information Expressing Feelings
Giving Information Harmonizing
Seeking Opinions Compromising
Giving Opinions Facilitating Communications
Clarifying Setting Standards or Goals
Elaborating Testing Agreement
Summarizing Following
To realize the benefits of a team culture requires a change in management behavior, as
shown in Table 3.2. If the behaviors listed on the right-hand-side of Table 3.2 are not common in
the groups you participate in, read on.

Table 3.2 Management behavior change needed for team culture
FROM TO
Directing Guiding
Competing Collaborating
Relying on Rules Focus on the Process
Using Organizational Hierarchy Using a Network
Consistency/Sameness Diversity/Flexibility
Secrecy Openness/Sharing
Passive Risk Taking
Isolated Decisions Involvement of Others
People as Costs People as Assets
Results Thinking Process Thinking
Source: McNeill, Bellamy and Foster, 1995
Organization -- Group Norms
A common way to promote more constructive and productive teamwork is to have the teams
create a set of guidelines for the group, sometimes called group norms. Take a minute and list
some things (attitudes, behaviors, and so on) that you have found or think that would help a
group be more effective. Then compare your list with the following two lists, both of which are
from McNeill, Bellamy and Foster, 1995 The first was adapted from the Boeing Airplane Group
Team Member Training Manual and the second is from Ford Motor Company.
Text Box
Code of Cooperation
1. EVERY member is responsible for the team’s progress and success.
2. Attend all team meetings and be on time.

3. Come prepared.
4. Carry out assignments on schedule.
5. Listen to and show respect for the contributions of other members; be an active listener.
6. CONSTRUCTIVELY criticize ideas, not persons.
7. Resolve conflicts constructively,
8. Pay attention, avoid disruptive behavior.
9. Avoid disruptive side conversations.
10. Only one person speaks at a time.
11. Everyone participates, no one dominates.
12. Be succinct, avoid long anecdotes and examples.
13. No rank in the room.
14. Respect those not present.
15. Ask questions when you do not understand.
16. Attend to your personal comfort needs at any time but minimize team disruption.
17. HAVE FUN!!
18. ?
Ten Commandments: An Affective Code of Cooperation
• Help each other be right, not wrong.
• Look for ways to make new ideas work, not for reasons they won’t.
• If in doubt, check it out! Don’t make negative assumptions about each other.
• Help each other win, and take pride in each other’s victories.
• Speak positively about each other and about your organization at every opportunity.
• Maintain a positive mental attitude no matter what the circumstances.
• Act with initiative and courage, as if it all depends on you.
• Do everything with enthusiasm; it’s contagious.
• Whatever you want; give it away.
• Don’t lose faith.
• Have fun!
Team norms are not only common in business and industry, but they are also important in
academic and research settings. The following list was developed by Randy Pausch’s for use in a
course he taught at Carnegie Mellon University (Pausch, 2002). Pausch’s web site also contains
a set of slides that summarize his terrific, and radical ideas on time and project management –
http://wonderland.hcii.cs.cmu.edu/randy.htm.
Tips for Working Successfully in a Group
By Randy Pausch, for the Building Virtual Worlds course at Carnegie Mellon, Spring 1998
Meet people properly. It all starts with the introduction. Then, exchange contact information,
and make sure you know how to pronounce everyone’s names. Exchange phone #s, and find out
what hours are acceptable to call during.
Find things you have in common. You can almost always find something in common with
another person, and starting from that baseline, it’s much easier to then address issues where you
have differences. This is why cities like professional sports teams, which are socially
galvanizing forces that cut across boundaries of race and wealth. If nothing else, you probably
have in common things like the weather.
Make meeting conditions good. Have a large surface to write on, make sure the room is quiet
and warm enough, and that there aren’t lots of distractions. Make sure no one is hungry, cold, or
tired. Meet over a meal if you can; food softens a meeting. That’s why they “do lunch” in
Hollywood.
Let everyone talk. Even if you think what they’re saying is stupid. Cutting someone off is
rude, and not worth whatever small time gain you might make. Don’t finish someone’s
sentences for him or her; they can do it for themselves. And remember: talking louder or faster
doesn’t make your idea any better.
Check your egos at the door. When you discuss ideas, immediately label them and write them
down. The labels should be descriptive of the idea, not the originator: “the troll bridge story,”
not “Jane’s story.”
Praise each other. Find something nice to say, even if it’s a stretch. Even the worst of ideas
has a silver lining inside it, if you just look hard enough. Focus on the good, praise it, and then
raise any objections or concerns you have about the rest of it.
Put it in writing. Always write down who is responsible for what, by when. Be concrete.
Arrange meetings by email, and establish accountability. Never assume that someone’s
roommate will deliver a phone message. Also, remember that “politics is when you have more
than 2 people” – with that in mind, always CC (carbon copy) any piece of email within the
group, or to me, to all members of the group. This rule should never be violated; don’t try to
guess what your group mates might or might not want to hear about.
Be open and honest. Talk with your group members if there’s a problem, and talk with me if
you think you need help. The whole point of this course is that it’s tough to work across
cultures. If we all go into it knowing that’s an issue, we should be comfortable discussing
problems when they arise -- after all, that’s what this course is really about. Be forgiving when
people make mistakes, but don’t be afraid to raise the issues when they come up,
Avoid conflict at all costs. When stress occurs and tempers flare, take a short break. Clear your
heads, apologize, and take another stab at it. Apologize for upsetting your peers, even if you
think someone else was primarily at fault; the goal is to work together, not start a legal battle
over whose transgressions were worse. It takes two to have an argument, so be the peacemaker.
Phrase alternatives as questions. Instead of “I think we should do A, not B,” try “What if we
did A, instead of B?” That allows people to offer comments, rather than defend one choice.
Team Charter
Having an agreed-upon, abided by code
• Team name, membership, and roles
of cooperation such as the ones listed above will
• Team Mission Statement
• Anticipated results (goals)
help groups get started toward working
• Specific tactical objectives
• Ground rules/Guiding principles for
effectively. However, if group members
team participation
• Shared expectations/aspirations
haven’t developed the requisite communication, trust, loyalty, organization, leadership, decision-
making procedures, and conflict management skills, then the group will very likely struggle or at
least not perform up to its potential. One way a team can develop such a code is to create a team
charter – a sample format for a team charter is given in the sidebar. Also see Exercise Three
which is a group ground rules planning form.
Team charters are typically created during a team meeting early in the project life cycle.
Involvement of all team members in creating the charter helps build commitment of each to the
project and to other members. A set of guidelines such as those listed above often help the team
through this process.
Let’s start to look more deeply into the mystery of teamwork skills, starting with a summary
of our work on teamwork skills in learning groups.
Teamwork Skills
What are these teamwork skills and how does one learn them? This is an area we’re researched
in our study of active and cooperative learning. We identified the following categories of skills –
Forming, Functioning, Formulating and Fermenting – and have suggestions for mastering them.
Cooperative Teamwork Skills
Forming Skills – Initial Management Skills
• Move Into Groups Quietly
• Stay With the Group
• Use Quiet Voices
• Take Turns
• Use Names, Look at Speaker
• No “Put-Downs”
Functioning Skills – Group Management Skills
• Share Ideas and Opinions
• Ask for Facts and Reasoning
• Give Direction to the Group’s Work (state assignment purpose, provide time limits, offer
procedures)
• Encourage Everyone to Participate
• Ask for Help or Clarification
• Express Support and Acceptance
• Offer to Explain or Clarify
• Paraphrase Other’s Contributions
• Energize the Group
• Describe Feelings When Appropriate
Formulating Skills – Formal Methods for Processing Materials
• Summarize Out Loud Completely
• Seek Accuracy by Correcting/Adding to Summaries
• Help the Group Find Clever Ways to Remember
• Check Understanding by Demanding Vocalization
• Ask Others to Plan for Telling/Teaching Out Loud
Fermenting Skills – Stimulate Cognitive Conflict and Reasoning
• Criticize Ideas Without Criticizing People
• Differentiate Ideas and Reasoning of Members
• Integrate Ideas into Single Positions
• Ask for Justification on Conclusions

• Extend Answers
• Probe by Asking In-depth Questions
• Generate Further Answers
• Test Reality by Checking the Group’s Work
Learning Cooperative Teamwork Skills
1. Observe and reflect to see the need to learn the skill.
2. Learn how to do it (T-chart – what does it look like, what does it sound like).
3. Practice the skill daily.
4. Reflect on, process, and refine use.
5. Persevere until skill is automatic
These cooperative teamwork skills are essential for productive and successful teamwork and
they must be learned and practiced with the same seriousness that other engineering skills are
learned.
Communication
Effective communication – listening, presenting, persuading, etc. – is at the heart of
effective teamwork. The task and maintenance roles listed above all involve oral
communication. Here are the listening skills emphasized in Arizona State University’s ECE100:
• Stop talking
• Engage in one conversation at a time
• Empathize with the person speaking
• Ask questions
• Don’t interrupt
• Show interest
• Concentrate on what is being said
• Don’t jump to conclusions
• Control your anger
• React to ideas, not to the speaker
• Listen for what is not said, ask questions
• Share the responsibility for communication
Three listening techniques they recommend include:
Critical Listening
• Separate fact from opinion
Sympathetic listening
• Don’t talk - listen
• Don’t give advice - listen
• Don’t judge - listen
Creative listening
• Exercise an open mind
• Supplement your ideas with another person’s ideas and vice versa.
You may be wondering why so much emphasis on listening. The typical professional spends
about half of his or her business hours listening and project managers may spend an even higher
proportion of their time listening. Most people, however, are not 100 percent efficient in their
listening. Typical listening efficiencies are only 25 percent (Taylor, 1998). The first list provides
suggestions to help the listener truly hear what is being said and the second highlights that
different situations call for different types of listening.
Reflection: Take a moment to think about the listening skills and each of these listening
techniques. Do you listen in all three ways? Which are you best at? Which do you need to
work on?
Did you notice the similarity among these listening skills and the cooperative teamwork skills in
the previous section? The ECE 101 faculty developed a list and presented it to the students as
“guidelines (read rules) for effective conversations.” Each situation requires it’s own set of
guidelines and the examples I’m providing are intended to give you ideas so you can develop
your own set of appropriate guidelines for each situation.
Leadership
A common notion is that leadership is a trait that some are born with. Another common
notion is that a person’s leadership ability depends on the situation. There is an enormous
literature on leadership and so I’ll only provide insights that I’ve found useful. I’ll also try to
guide you to more reading and resources on the topic.
Individual and Group Reflection: What does it mean to lead a team? What does it take? Take a
moment to reflect on the characteristics you admire most in a leader. Think of people you’ve
worked with or for. Jot down 8 to 10 of them. Compare with your team.
Leadership authors Kouzes and Posner (1987, 1993) have asked thousand of people to list
the characteristics of people they admire. Table 3.3 lists the most common responses from their
1987 and 1993 studies. Many students and workshop participants express surprise at the listing
of “honesty” as number one. They say it’s a given. Apparently honesty is not a given for many
leaders in business and industry. In 1993, Kouzes and Posner also asked the respondents to list
the most desirable characteristics of colleagues. Honest was number one again, with 82 percent
selecting it. Cooperative, dependable, and competent were second, third and forth with slightly
over 70 percent for each.

Table 3.3 Characteristics of Admired Leaders
1993 U.S. Percentage of 1987 U.S. Percentage of
People Selecting People Selecting
Characteristic
Honest 87 83
Forward-looking 71 62
Inspiring 68 58
Competent 58 67
Fair-minded 49 40
Supportive 46 32
Broad-minded 41 37
Intelligent 38 43
Straightforward 34 34
Courageous 33 27
Dependable 32 32
Cooperative 30 25
Imaginative 28 34
Caring 27 26
Mature 14 23
Determined 13 20
Ambitious 10 21
Loyal 10 21
Self-controlled 5 13
Independent 5 13
Kouzes and Posner found that when leaders do their best, they challenge, inspire, enable,
model, and encourage. They suggest five practices and ten behavioral commitments of
leadership.
Challenging the Process
1. Search for Opportunities
2. Experiment and Take Risks
Inspiring a Shared Vision
3. Envision the Future
4. Enlist Others
Enabling Others to Act
5. Foster Collaboration
6. Strengthen Others
Modeling the Way
7. Set the Example
8. Plan Small Wins
Encouraging the Heart
9. Recognize Individual Contribution
10. Celebrate Accomplishments
Peter Scholtes, author of the bestselling book, The Team Handbook, recently wrote The
Leader’s Handbook (Scholtes, 1998). He offers the following six New Competencies:
1. The ability to think in terms of systems and knowing how to lead systems.
2. The ability to understand the variability of work in planning and problem solving.
3. Understanding how we learn, develop, and improve; leading true learning and improvement.
4. Understanding people and why they behave as they do.
5. Understanding the interaction and interdependence between systems, variability, learning,

and human behavior; knowing how each affects the others.
6. Giving vision, meaning, direction, and focus to the organization.
Reflection: Take a moment to reflect on what you’ve learned thus far about the competencies
Scholtes emphasizes – systems, variability, learning and improvement, understanding people,
interdependence, and giving vision – and list as many connections both with your personal
experiences and with other sections of the book.
The latest breakthrough work on leadership is Jim Collins’ Level 5 Leadership (Collins,
2001a, 2001b). Collins and his research team studied companies who moved from good to great.
The central finding is that the leaders of these companies “build enduring greatness through a
paradoxical combination of personal humility plus professional will.” Collins’ revelation
reminds me of one of philosopher Walter Kaufmann’s cardinal virtues – the fusion of humility
and ambition (Kaufmann, 1973). I’ve tried to live by Kaufmann’s cardinal virtue of the fusion of
humility and ambition for the past 25 years. I find it interesting that Collins’ work has focused on
a similar fusion. There is something significant here and I suggest that you reflect on it.
In addition to group norms, communication and leadership, teamwork depends on effective
decision making and constructive conflict management, described in the next two sections.
Decision Making
Before proceeding to the decision-making and conflict resolution skills sections, I suggest
that you complete an exercise to provide a basis for continued discussion and learning. Common
exercises to assist in the development of teamwork skills, especially communication (sharing
knowledge and expertise), leadership, and decision making are the myriad of ranking tasks, such
as the survival (moon, winter, desert, ocean, etc.) tasks. Ranking tasks are common in groups
and organizations that must select among alternative designs, hire personnel, choose projects or
proposals for funding.
My favorite ranking task for helping groups focus on communication, leadership, decision
making, and conflict resolution is “They’ll Never Take Us Alive.” This exercise, which includes
both individual and group decision making, is included at the end of this chapter. Do it now.
Group reflection I: How did your group make the decision? Did you average your individual
rankings? Vote? Did you discuss your individual high and low rankings and then work from
both ends toward the middle? Did you try to reach consensus? Were you convinced by group
members who seem to have “expert” knowledge? Did you start with the number of fatalities for
one of the activities and work from there?
Group refection II: How well did your group work? What went well? What things could you do
even better next time?
The method a group uses to make a decision depends on many factors, including how
important the decision is, how much time you have, etc. It is important to have a good repertoire
of decision making strategies and to use the one that is most appropriate for the situation.
Several methods have been described in the literature for making decisions. One of my
favorites is from Johnson & Johnson (1991). The authors list seven methods for making
decisions:
1. Decision by authority without discussion. The leader makes all the decisions without
consulting the group. It is efficient but does not build team member commitment to the
decision.
2. Expert member. Group decision is made by letting the most expert member decide for the
group. The difficulty is often deciding who has the most expertise, especially when those
with power or status in the group overestimate their expertise.
3. Average of members' opinions. Group decision based on average of individual group
members’ opinions.
4. Decision by authority after discussion. Group in which designated leader makes decision
after discussion with the group. Effectiveness often depends on the listening skills of the
leader.
5. Minority control. Two or more members who constitute less than 50 percent of the group
often makes decisions by (a) acting as a executive committee or (b) special problem solving
sub group.
6. Majority control. Decision by
a majority vote is the method
used by the U.S. Congress.
Discussion occurs only until at
least 51 percent of the
members decide on a course of
action.
7. Consensus. Consensus is
Figure 3.1 Decision Type and Quality
probably the most effective
method of group decision making, but it also may take the most time. A lesser degree of
consensus is often accepted where everyone has had their say and will commit to the
decision, but they may not completely, agree with the decision.
Johnson & Johnson, F. (1991) note that the quality of the decision and the time needed vary
as a function of the level of involvement of the people involved in the decision-making method
as shown in Figure 3.1.
They also list the following characteristics of effective decisions:
1. The resources of the group members are well used.
2. Time is well used.
3. The decision is correct, or of high quality.
4. The decision is put into effect fully by all the necessary members' commitment.
5. The problem-solving ability of the group is enhanced.
Group Reflection: How well did your group do on each of these five characteristics of effective
decisions?
Typically novice decision-making groups don’t take full advantages of the skills and talents
of their members, and they often struggle to get started. Some report a series of stages in team
development – Forming, Storming, Norming, Performing – and offer suggestions for working
through each stage (Scholtes, Joiner, and Streibel, 1996). Also, if you ask a group to invest time
and effort in making a decision it is very important that the decision or recommendation of the
group be implemented (or very good rationale provided for why it wasn’t implemented). There
are few things more frustrating than to be asked to spend lots of time and effort on work that
goes nowhere.
Some of the latest and most interesting work on decision making comes from David Gavin
Two Approaches to Decision Making

Garvin & Roberto, 2001. Harvard Business Review, 79(8), 108-116.
Advocacy Inquiry
Concept of decision A contest Collaborative problem

making solving
Purpose of discussion Persuasion and lobbying Testing and evaluation
Participants’ role Spokespeople Critical thinkers
Pattern of behavior Strive to persuade others Present balanced arguments

Defend your position Remain open to alternatives
Downplay weaknesses Accept constructive criticism
Minority views Discouraged or Cultivated and valued
dismissed
Outcome Winners and losers Collective ownership
and Michael Roberto (2001). They propose that we view decision making as an inquiry process
rather than as an advocacy process where the concept of decision making is collaborative
problem solving rather than a contest. Key differences between an advocacy approach and an
inquiry approach as shown in Figure ?. Their inquiry approach to decision making is remarkably
similar to a constructive academic controversy approach we devised to help students learn about
reaching decisions in controversial situations (Johnson, Johnson and Smith, 2000).
Approaching, framing, and working through decisions in this manner would result, I think, in far
more enlightened and constructive decisions.
Russo and Shoemaker (2002) describe an interesting and straightforward four-step decision-
making process:
1. Framing or deciding what you are going to decide-and not decide;

2. Gathering intelligence-real intelligence, and not just information that will support your
internal biases;
3. Coming to conclusions-determining how your company acts on the intelligence it gathers,
and;
4. Learning from experience.
Russo and Shoemaker’s approach helps to demystify the process of decision making. Their
guidance through each of the steps provides insight into the process and highlight key concepts.
They also provide case studies and worksheets to help the reader apply the approach to their own
decision-making situations.
Decision making and providing information so that others can make decisions is one of the
most important and frequent activities of practicing engineers.
Conflict Management
Conflict is a routine aspect of every

The work life of a project manager is a life of
conflict. Although conflict is not necessarily
project manager’s job. Conflict is a situation
bad, it is an issue that has to be resolved by
the project manager. Without excellent
in which an action of one person prevents,
negotiation skills, the project manager has
little chance for success.
obstructs, or interferes with the actions of
Taylor, J. 1998. A survival guide for project
another person (Deutsch, ?). On complex
managers. AMACON.
projects and tasks, highly talented and
motivated people routinely disagree about the best ways to accomplish tasks and especially
about how to deal with trade-offs among priorities. A conflict often is a moment of truth, since it
can follow either a constructive or a destructive path.

Individual Reflection: Write the word conflict in the center of a blank piece of paper and draw a
circle around it. Quickly jot down all the words and phrases you associate with the word conflict
by arranging them around your circle.
Review your list of associations and categorize them as positive, negative, or neutral. Count
the total number of positive, negative and neutral associations, and calculate the percentage that
are positive. Did you have more than 90% positive?
Less than 5 percent of the people I’ve worked with in classes and workshops have more than
90 percent positive associations. The majority of people I‘ve worked with have less than 50
percent positive associations. Many have less than 10 percent positive.
The predominance of negative associations with conflict is one of the reasons conflict
management is so difficult for project managers. Many people prefer to avoid conflict or
suppress it when it does arise. They become fearful, anxious, angry, or frustrated; consequently,
the conflict takes a destructive path.
My goal for this section is to help you develop a set of skills and procedures for guiding
conflict along a more constructive path. I’d like to begin by asking you to complete a
questionnaire to assess how you typically act in conflict situations. The “How I Act in Conflict”
questionnaire is included as Exercise 2 at the end of this chapter. Take a few minutes to
complete and score the questionnaire. Try to use professional conflicts and not personal
conflicts as your point of reference.
Set the questionnaire aside for a few minutes and read Exercise 3, the Ralph Springer case
study. Work through the, completing the ranking form at the end.
Group activity: Share and discuss each
member’s results from Exercise 2.
Discuss each of the possible ways to
resolve the conflict.
Then compare your individual
responses from Exercise 2 to your
rankings in Exercise 3. Note that each of
the alternatives listed in Exercise 3
represents one of the strategies listed on

Figure3.2 Blake & Mouton Conflict Model
the scoring form in Exercise 2. Match the
alternatives to the strategies they represent. Discuss similarities and differences in the order each
group member would have used the strategies and the relative effectiveness of each.
The five conflict strategies shown in Exercise 2 – withdrawal, forcing, smoothing,
compromise, and confrontation – were formulated into a model for analyzing approaches to
conflict to Blake and Mouton (1964). The authors used two axes to represent the conflict
strategies: (1) The importance of the goal and (2) and importance of the task. The placement of
each of the five strategies according to this framework is show in Figure 3.2.
The five strategies are described as follows:
Conflict Strategies
1. Withdrawal - Neither the goal nor the relationship are important - you withdraw
from the interaction.

2. Forcing - The task is important but not the relationship - use all your
energy to get the task done.
3. Smoothing - The relationship is more important than the task. You want to be
liked and accepted.
4. Compromise - Both task and relationship are important but there is a lack of time
- you both gain and lose something.
5. Confrontation - Task and relationship are equally important. You define the conflict
as a problem-solving situation and resolve through negotiation.
Each of these strategies is appropriate under certain conditions. For example, if neither the
goal nor the relationship is important to you, then often the best thing to do is withdraw. If the
relationship is extremely important and the task is not so important (at the time), then smoothing
is appropriate. In many conflict situations, both the task and the relationship are important. In
these situations, confronting and negotiating often leads to the best outcomes.
A confrontation is the direct expression of one opponent’s view of the conflict, and his or
her feelings about it, and an invitation to the other opponent to do the same.
Guidelines for Confrontation
1. Do not "hit-and-run": confront only when there is time to jointly define the conflict and
schedule a negotiating session.
2. Openly communicate one's feelings about and perceptions of the issues involved in the
conflict, and try to do so in minimally threatening ways.
3. Accurately and fully comprehend opponent's views of the feelings about the conflict.
Negotiation is a conflict resolution process by which people who want to come to an
agreement, but disagree about the way to resolve, try to work out a settlement.
Steps in Negotiating a Conflict
1. Confront the opposition.
2. Define the conflict mutually.
3. Communicate feelings and positions.
4. Communicate cooperative intentions.
5. Take the other person's perspective.
6. Coordinate the motivation to negotiate.
7. Reach an agreement that is satisfactory to both sides.
Constructively resolving conflicts through a confrontation - negotiation process takes time
and practice to perfect, but it’s worth it. Conflicts that do not get resolved at a personal level
must be resolved at more time-consuming and costly levels – third-party mediation, arbitration,
and; if all else fails, litigation.
Finally, here are my favorite heuristics for dealing with conflicts in long-term personal and
professional relationships:
1. Do not withdraw from or ignore the conflict.
2. Do not engage in "win-lose" negotiations.
3. Assess for smoothing.
4. Compromise when time is short.
5. Confront to begin problem-solving negotiations.
6. Use your sense of humor.
Remember that heuristics are reasonable, plausible but not guaranteed. I suggest that you
develop your own set of heuristics for dealing with conflict as well as for the other skills needed
for effective teamwork. Some of my former students who now work as project manager
emphasize during classroom visits that they spend a lot of time resolving conflicts – over
meeting specifications, schedules, delivery dates, interpersonal problems among team members –
and that most conflicts are dealt with informally.
Teamwork Challenges and Problems
Reflection: What are some of the most common challenges problems you’ve had working in
teams? Please reflect for a moment. Make a list. Has a professor ever had you do this in your
teams? If so, it’s a clear indication that the professor understands the importance of group
processing for identifying and solving problems. What’s on your list?
The challenges and problems you listed in the above reflection may have included the following:
* members who don’t show up for meetings * lack of clear agenda, or hidden agendas
or who don’t show up prepared * sub-groups excluding or ganging up on
* members who dominate the conversation one or more members
* members who don’t participate in the * ineffective or inappropriate decisions and
conversation decision-making processes
* time wasted by off-task talk * suppression of conflict or unpleasant flare-
* members who want to do the entire project ups among group members
because they don’t trust others * members not doing their fair share of the
* group meeting scheduling difficulties work
* no clear focus or goal * lack of commitment to the group’s work
by some members
The problems listed above are commonly encountered by students (and professionals)
working in teams and groups. If they are not addressed they can turn the group experience into a
Pseudo group, as described in Chapter 2, where the group does worse than individuals working
alone. If they are addressed in a problem-solving manner, then the group is likely to perform at
much higher levels (and the members will have a much more positive experience).
The following process is widely used to address group problems:
Step 1: Identifying challenges, difficulties and barriers to effective group work
Develop a List of Challenges, Barriers and Problems
! Reflect individually for a moment and start a list of challenges, barriers, or problems facing
the group. Share the individual lists and create a joint list that includes at least one item from
each group member
! Do Not Solve (yet)
! Be Realistic and Specific
! Work Cooperatively
! If more than one group is involved, list challenges, barriers, and problems for all groups on
an overhead projector or flip chart.
Step 2: Addressing Barriers, Challenges, and Problems
1. Have each group or (if only one group is involved) each member select one item from the
joint list.
2. Clarify: Make sure you have a common understanding of what the item means or represents.
3. Create three possible actions that will solve, resolve or eliminate the problem, challenge, or
barrier
4. Prioritize the possible solutions: Plan A, Plan B, Plan C.

5. Focus on what will work; be positive and constructive
6. Implement the solutions; report back; celebrate and spread the ones that are effective
Caveat: During implementation of group work expect some challenges, barriers and problems.
Doing so will help you recognize a roadblock when it appears. When it does appear, apply the
appropriate parts of Step 2.
With one or more colleagues, develop three or more solutions. Implement one, evaluate,
replan, and retry
The problem identification, problem formulation, and problem solving format described
above does not guarantee that your teamwork experiences will be free of troubles. But, having a
format for getting problems out on the table and then dealing with them in a problem-solving
manner usually reduces the frustration and interference of group problems.
Reflection: Teamwork
I’ve tried to address many of the highlights of effective teamwork and team problem
solving, and have barely scratched the surface. Hundreds of books and articles have been
written on effective teamwork and I’ve listed a few of my favorites in the reference section
(Fisher, Rayner & Belgard, 1995; Goldberg, 1995; Hackman, 1990; Katzenbach & Smith, 1993).
As I mentioned earlier, the most widely used teamwork books is Scholtes, Joiner, & Streibel’s
(1996) The team handbook.
References
Blake, R.R., & Mouton, J.S. 1964. The managerial grid. Houston: Gulf Publishing Company.
Collins, Jim. 2001a. Level 5 leadership: The triumph of humility and fierce resolve. Harvard
Business Review. January, 67-76.
Collins, Jim. 2001b. Good to great: Why some companies make the leap. . . and others don’t.
New York: Harper Business.
Fisher, Kimball; Rayner, Steven; & Belgard, William. 1995. Tips for teams: A ready reference
for solving common team problems. New York: McGraw-Hill.
Garvin & Roberto, 2001. What you don’t know about making decisions. Harvard Business
Review, 79(8), 108-116.
Goldberg, David E. 1995. Life skills and leadership for engineers. New York: McGraw-Hill.
Hackman, J.R. 1990. Groups that work (and those that don't): Creating conditions for effective
teamwork. San Francisco: Jossey-Bass.
Johnson, David W. & Johnson, Frank. 1991. Joining together: Group theory and group skills.
Upper Saddle, NJ: Prentice-Hall.
Johnson, David W. & Johnson, Roger T. 1991. Teaching students to be peacemakers. Edina,
MN: Interaction Book Company.
Katzenbach, Jon R. & Smith, Douglas K. 1993. The wisdom of teams: Creating the high-
performance organization. Cambridge, MA: Harvard Business School Press.
Katzenbach, Jon R. and Smith, Douglas K. 1993. The discipline of teams. Harvard Business
Review, 71(2), 111-120.
Kaufmann, Walter. 1973. Without guilt and justice: From decidophobia to autonomy. New
York: Peter H. Wyden.
Kouzes, J.M. & Posner, B.Z. 1987. The leadership challenge: How to get extraordinary things
done in organizations. San Francisco: Jossey-Bass.
Kouzes, J.M. & Posner, B.Z.. 1993. Credibility: How leaders gain and lose it, why people
demand it. San Francisco: Jossey-Bass.
McNeill, Barry; Bellamy, Lynn; and Foster, Sallie 1995. Introduction to engineering design.
Tempe, Arizona: Arizona State University.
Napier, Rodney W., & Gershenfeld, Matti K. 1973. Groups: Theory and experience. Boston:
Houghton Mifflin.
Pausch, Randy. 2002. Tips for working successfully in a group.
http://wonderland.hcii.cs.cmu.edu/Randy/teams.htm (Accessed 1/4/03).
Russo, J. Edward and Shoemaker, Paul J.H. 2002. Winning decisions. NY: Currency Doubleday.
Scholtes, Peter R. 1998. The leader’s handbook: Making things happen, getting things done.
New York: McGraw-Hill.
Scholtes, Peter R., Joiner, Brian L. & and Streibel, Barbara J. 1996. The team handbook. (2nd
Ed.) Madison, WI: Joiner Associates.
Schrage, Michael. 1991. Shared minds. New York: Random House.
Schrage, Michael. 1995. No more teams! Mastering the dynamics of creative collaboration.
New York: Doubleday.
Taylor, James. 1999. A survival guide for project managers. New York: AMACOM.
Questions
1. What other skills do you feel are essential for successful groups? How about trust and
loyalty, for example? I briefly dealt with trust and loyalty under the organization section,
but you may want to emphasize them more. Check the references, Joining together, for
example for more. What other teamwork skills would you like to follow up on?
2. What are some of the strategies for developing a developing a good set of working
conditions in a group?
3. What are your reactions to the list of “Characteristics of effective leaders”? Were you
surprised by the high ranking of honesty?

4. Why is conflict central to effective teamwork and project work? What are some strategies
for effectively managing conflict?
5. Keep a log of problems you’ve faced in working on project teams. How do the problems
change over the life of the group?
6. The next time a problem occurs in a group, try the problem-solving process outlined in the
chapter.
EXERCISES
Exercise One: Risk Ranking – They’ll Never Take Us Alive!!

The New They'll Never Take Us Alive!!
Below, in alphabetical order, are listed the top fifteen causes of death in the United States in
19971. The data are based on an annual review of death certificates. Your task is to rank them in
decreasing order of number of deaths caused each year. Place the number 1 next to the one that
causes the most deaths, the number 2 by the next, and so forth.
Product or Activity Ranking Number of Fatalities

Accidents
Alzheimer's disease
Blood poisoning
Cancer
Diabetes
Hardening of arteries
Heart disease
HIV and AIDS
Homicide
Kidney disease
Liver disease
Lung disease
Pneumonia and influenza
Stroke
Suicide
To Group Members: TASKS
1. Individually determine the ranking.
1
Sources: Office of the Surgeon General; National Center for Health Statistics.
2. Determine one ranking for the group.
3. Every group member must be able to explain the rationale for the group's ranking.
4. When your group finishes (each member has signed), (a) record your estimated number of
fatalities in the U.S. for each, and then (b) compare your ranking with that of another group.
[Note: List of rankings and annual fatalities is available from Karl Smith ([email protected])]
Exercise Two: How I Act in Conflict
HOW I ACT IN CONFLICT
The proverbs listed in the accompanying table can be thought of as descriptions of some of the
different strategies for resolving conflicts. Proverbs state conventional wisdom, and the ones
listed here reflect traditional wisdom for resolving conflicts. Read each carefully. Using the
scale provided, indicate how typical each proverb is of your actions in a conflict. Then score
your responses on the chart at the end of the exercise. The higher the total score in each conflict
strategy, the more frequently you tend to use that strategy. The lower the total score for each
conflict strategy, the less frequently you tend to use that strategy. Rank the five conflict
strategies from the one you use the most to the one you use the least. This will give you an
indication of how use see your own conflict strategy.
5 = very typical of the way I act in a conflict
4 = frequently typical of the way I act in a conflict
3 = sometimes typical of the way I act in a conflict
2 = seldom typical of the way I act in a conflict
1 = never typical of the way I act in a conflict
____ 1. It is easier to refrain than to retreat from a quarrel.

____ 2. If you cannot make a person think as you do, make him or her do as you think.
____ 3. Soft words win hard hearts.
____ 4. You scratch my back, I’ll scratch yours.
____ 5. Come now and let us reason together.
____ 6. When two quarrel, the person who keeps silent first is the most praisworthy.
____ 7. Might overcomes right.
____ 8. Smooth words make smooth ways.
____ 9. Better half a loaf than no bread at all.
____ 10. Truth lies in knowledge, not in majority opinion.
____ 11. He who fights and runs away lives to fight another day.
____ 12. He hath conquered well that hath made his enemies flee.
____ 13. Kill your enemies with kindness.
____ 14. A fair exchange brings no quarrel.
____ 15. No person has the final answer but every person has a piece to contribute.
____ 16. Stay away from people who disagree with you.
____ 17. Fields are won by those who believe in winning.
____ 18. Kind words are worth much and cost little.
____ 19. Tit for tat is fair play.
____ 20. Only the person who is willing to give his or her monopoly on truth can ever profit
from the truths that others hold.
____ 21. Avoid quarrelsome people as they will only make your life miserable.
____ 22. A person who will not flee will make others flee.
____ 23. Soft words ensure harmony.

____ 24. One gift for another makes good friends.
____ 25. Bring your conflicts into the open and face them directly; only then will the best
solution be discovered.
____ 26. The best way of handing conflicts is to avoid them.
____ 27. Put your foot down where you mean to stand.
____ 28. Gentleness will triumph over anger.
____ 29. Getting part of what you want is better than not getting anything at all.
____ 30. Frankness, honesty, and trust will move mountains.
____ 31. There is nothing so important that you have to fight for it.
____ 32. There are two kinds of people in the world, the winners and the losers.
____ 33. When one hits you with a stone, hit him or her with a piece of cotton.
____ 34. When both people give in half-way, a fair settlement is achieved.
____ 35. By digging and digging, the truth is discovered.
Scoring: How I Act in Conflict
Withdrawal Forcing Smoothing Compromise Confrontation

1 2 3 4 5
6 7 8 9 10
11 12 13 14 15
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31 32 33 34 35
Total Total Total Total Total
The higher the total score in each conflict strategy the more frequently you tend to use that
strategy. The lower the total score for each conflict strategy, the less frequently you tend to use
that strategy.
Case Study – Ralph Springer
The following case gives you a chance to apply the Blake and Mouton conflict model to a
hypothetical situation. Read the case carefully and then label each of the possible actions from
Most to Least Effective and from Most to Least Likely.
You have been working as a project manager in a large company for some time. You are
friends with most of the other project managers and, you think, respected by all of them. A
couple of months earlier, Ralph Springer was hired as a supervisor. He is getting to know the
other project managers and you. One of the project managers in the company who is a friend,
confided in you that Ralph has been saying rather nasty things about your looks, the way you
dress, and your personal character. For some reason you do not understand, Ralph has taken a
dislike to you. He seems to be trying to get other project managers to dislike you also. From
what you hear there is nothing too nasty for him to say about you. Your are worried that some
people might be influenced by him and that some of your co-project managers are also beginning
to talk about you behind your back. You are terribly upset and angry at Ralph. Since you have a
good job record and are quite skilled in project management, it would be rather easy to get
another job.
Rank each of the following five courses of action from 1, most effective (likely) to 5 least
effective (likely). Use each number only once. Be realistic.
Effective Likely
_____ _____ I lay it on the line. I tell Ralph I am fed up with the gossip. I tell him that
he’d better stop talking about me behind my back, because I won’t stand
for it. Whether he likes it or not, he is going to keep his mouth shut about
me or else he’ll regret it.
_____ _____ I try to bargain with him. I tell him that if he will stop gossiping abut me I
will help him get started and include him in the things other project
managers and I do together. I tell him that others are angry about the
gossiping and that it is in his best interest to stop. I try to persuade him to
stop gossiping in return for something I can do.
_____ _____ I try to avoid Ralph. I am silent whenever we are together. I show a lack
of interest whenever we speak, look over his shoulder and get away as
soon as possible. I want nothing to do with him for now. I try to cool
down and ignore the whole thing. I intend to avoid him completely if
possible.
_____ _____ I call attention to the conflict between us. I describe how I see his actions
and how it makes me feel. I try to begin a discussion in which we can
look for a way for him to stop making me the target of his conversation
and a way to deal with my anger. I try to see things from his viewpoint
and seek a solution that will suit us both. I ask him how he feels about my
giving him this feedback and what his point of view is.
_____ _____ I bite my tongue and keep my feelings to myself. I hop he will find out
that the behavior is wrong without my saying anything. I try to be extra
nice and show him that he’s off base. I hide my anger. If I tried to tell
him how I feel, it would only make things worse.
Exercise Three: Group Contract Example
Group Ground Rules Contract Form

(Adapted from a form developed by Dr. Deborah Allen, University of Delaware)
Project groups are an effective aid to learning, but to work best they require that all groups
members clearly understand their responsibilities to one another. These project group ground
rules describe the general responsibilities of every member to the group. You can adopt
additional ground rules if your group believes they are needed. Your signature on this contract
form signifies your commitment to adhere to these rules and expectations.
All group members agree to:

1. Come to class and team meetings on time.
2. Come to class and team meetings with assignments and other necessary preparations
done.
Additional ground rules:

1.
2.
If a member of the project team repeatedly fails to meet these ground rules, other members of the
group are expected to take the following actions:
Step 1: (fill in this step with your group)
If not resolved:
Step 2: Bring the issue to the attention of the teaching team.
If not resolved:
Step 3: Meet as a group with the teaching team.
The teaching team reserves the right to make the final decisions to resolve difficulties that arise
within the groups. Before this becomes necessary, the team should try to find a fair and
equitable solution to the problem.
Member’s Signatures: Group Number:______________
1.____________________________ 2.____________________________
3.____________________________
4.____________________________
Chapter Four: Project Management Principles and Practices
This chapter discusses what a project is, introduces project scoping strategies, and
explains why projects and project management are receiving a lot of attention right now. The
number of books and articles on project management is growing almost exponentially.
Something is happening here! Perhaps it is due in part to observations like those in a Project
Management Institute survey, which indicated that only a fraction of technology projects in the
United States finish on time. The percentages are startling: Close to half of the projects started
were never finished, and 30 percent were completed but took at least twice as long as expected;
some took 5 times as long. Only 10 percent of the projects were finished on time.
The situation has changed a lot since the development of scheduling tools and strategies
such as CPM (Critical Path Method) and PERT (Program Evaluation and Review Technique) in
the 1950s. Laufer, Denker, and Shenhar (1993) have outlined the evolution in the nature of
project management. A summary of the changes is shown in Table 4.1. Laufer, et.al, emphasize
that projects have become more complex and the time to accomplish them shorter; thus requiring
simultaneous management.
Table 4.1 Evolution of Models of Project Management
Central Era of Dominant Project Main Thrust Metaphor Means

Concept Model Characteristics
Scheduling 1960s Simple, Coordinating Scheduling regional Information

(Control) Certain activities flights in an airline technology,
Planning
specialists
Teamwork 1970s Complex, Cooperation Conducting a Process

(Integration) Certain between symphony orchestra facilitation,
participants Definition or
roles
Reducing 1980s Complex, Making stable Exploring an unknown Search for

Uncertainty Uncertain decisions country information,
(Flexibility) Selective
redundancy
Simultaneity 1990s Complex, Orchestrating Directing a three-ring Experience,

(Dynamism) Uncertain, contending circus with continuous responsiveness
Quick demands program modification and
based on live audience adaptability
feedback
Reflection: Take a moment to reflect on the current nature of project from your experience.
Think about the project and project management environment you will enter when you graduate
(especially if you’re close to graduation). Try to complete the categories in Table 4.1 – central
concept, dominant project characteristics, main thrust, metaphor, and means.
I ask students in many of my project management classes to complete this reflection
exercise. I know if difficult to predict the future (to paraphrase Yogi Berra and Nils Bohr), but
thinking about the kind of project management future we want is important, too. As Alan Kay
said, “The best way to predict the future is to invent it.” Here’s what a couple recent groups
came up with:
Central Concept -- Virtual, non-linear Central Concept -- Global projects

Dominant Project Characteristics -- Dominant Project Characteristics -- Cross-
Leverage chaos time, cross-geography
Main Thrust -- Melding innovation Main Thrust -- Parallelism
Metaphor -- Adhocracy Metaphor -- Concurrent engineering on
Means -- Open-ended management steroids
Means -- Electronic Sharing
Ed Yourdon claims in his latest book Death march projects (Addison-Wesley, 1997) that
many projects must be completed in half the time, with half the budget, or with half the resources
initially planned, hence the title “death march projects.” Yourdon also claims that it is possible,
almost exciting at times, to be a part of this type of project.
Reflection: Think about your involvement with projects both in school and in other aspects of
your life. Have you been involved in more and more projects in school? Think about some of
these projects. What are the distinguishing features of the projects you’ve been involved with?
For example, did you have to make a presentation or write a report? Did you have to give a
performance, as in the production of a dramatic event such as a play? Have you participated in a
science fair project or a design project? Please take a few minutes to reflect on changes in your
involvement in projects and make a list of the distinguishing features of these projects.
What’s on your list? Does it include items such as “common, overriding purpose and
established goals”; “temporary” (i.e., clear beginning and end); “one-time activity”; “requires
coordinating many interrelated activities”; and “involves several people”?
What is a Project?
A dictionary of project management terms defines a project as follows (Cleland &

Kerzner, 1985):
[A project is] a combination of human and nonhuman resources pulled together in
a temporary organization to achieve a specified purpose.
Project is defined by Snead and Wycoff (1997) as “a nonroutine series of tasks directed
toward a goal.” In their helpful guide they claim that “success depends on the ability to
effectively complete projects.”
A textbook (Nicholas, 1990) that I have used in my project management classes lists the
following features of projects:
! Definable purpose with established goals
! Cost, schedule, and performance requirements
! Multiple resources across organizational lines
! One-time activity
! Element of risk
! Temporary activity
! Process of phases/project life cycle
Based on this definition and list of features you can see that projects are quite different
from the on-going, day-to-day work that most of us do. Each project is unique, is temporary, has
an element of risk, and has a definable purpose with established goals. Three features of projects
that I’d like to explore further are (1) exploration versus exploitation projects, (2) cost, schedule,
and performance requirements; and (3) project phases or life cycle.
Exploration versus Exploitation Projects

A common tension I’ve encountered working with students on project management
topics and issues is between (1) doing old things better and (2) doing new things. Civil
engineering construction project often involves improving the effectiveness and efficiency of
current practices; whereas, mechanical engineering product design projects emphasize
developing new ideas. James March’s (1991) distinction between exploration and exploitation
activities, summarized in Table 4.2, provides some guidance to the differences.
Table 4.2. Exploiting Old Ways versus Exploring New Ways
Exploiting Old Ways: Organizing for Exploring New Ways: Organizing for
Routine Work Innovative Work
Drive our variance Enhance variance
See old things in old ways See old things in new ways
Replicate the past Break from the past
Goal: Make money now Goal: Make money later
Keys to Project Success
Traditionally, project success has been measured
according to three criteria: cost, time, and performance.
Although students in classes often negotiate time (especially
due dates) and performance requirements, there is often less
flexibility in professional life. For example, the due dates
for submitting research proposals to funding agencies are
rigid. One must get the proposal in before the deadline or
wait until next year (and hope the agency still is making Figure 4.1 Project Success:
Quadruple Constraint
grants in that particular area). In many large construction projects there are significant
incentives for finishing on-time, and major penalties for finishing late. Some projects have been
terminated when there were cost overruns; note the tragic demise of the Superconducting
Supercollider (the multibillion dollar particle accelerator in Texas that was terminated by the
U.S. Congress).
Subsequent chapters of this book we will explore how cost, time, and performance are
operationalized; that is, how they are put into practice. Briefly, cost is operationalized by
budgets; time by schedules; and performance by specifications.
Cost, time, and performance. Is this it? Is this all that we need to attend to for successful
projects? Many project management experts are discussing a forth aspect of project success --
client acceptance. Pinto and Kharbanda (1995) for example, advocate that there is a quadruple
constraint on project success, which of course, increases the challenge of completing projects
successfully. See Figure 4.1.
The most common way that client acceptance is operationalized is by involving the client
throughout the project. One of the most famous examples of this is Boeing’s 777 project, in
which customers were involved early on and throughout the project. These customer airlines
had a significant influence on how the 777 was designed and built. Boeing’s vision was to build
a high quality aircraft in an environment of no secrecy and no rivalry. These new values were
clarified in the following three statements (cited in Snead & Wycoff, 1997):
1. Use a style of management unheard of in the industry: working together while building
trust, honesty, and integrity.
2. In the past, people were afraid to state a problem because of the practice of killing the
messenger. We will instead celebrate our problems and get them out into the open so we
can work on them.
3. We must come with no limitations in our mind. We must have a shared thought, vision,
appreciation, and understanding of what we are going to accomplish together.
Boeing’s long-range goals for this airplane helped create the environment described
about:
• Design, develop, and produce a plane safer and more reliable than any other plane in
aviation history that is state-of-the-art and service-ready on delivery, to be called the 777.
• Design, develop, and produce a program to empower a massive team of people to
implement the “working together” philosophy while creating the 777.
Phil Condit, Boeing’s CEO said “The task for us at Boeing is to provide a massive
change in thinking throughout the company – this is a cultural shift, and it isn’t easy! Boeing
experienced many positive changes (and outcomes) during this process. The 777 was delivered
on time and was under budget. Most significantly, however, it positively changed the
“management-teamwork” paradigm from a hierarchical relationship to a lateral relationship.
If you’d like to explore Boeing’s 777 project in more detail, the book 21st Century Jet by
Karl Sabbagh and the six-part PBS video series provide rich insight into the process. Also, Jim
Lewis’ (2000) book Working together is based the twelve guiding principles of project
management that Alan Mulally’s used in the Boeing 777 project.
Project Life Cycle
Reflection: Please reconsider the projects that came to mind during the first reflection activity at
the beginning of this chapter. Did each project seem to go through a series of stages? If so, how
would you characterize them? Think about how the activities and work on the project changed
from beginning to end. Jot down your reflections.

The prevailing view of the project life cycle is that projects go through distinct phases,
such as:
1. Conceiving and defining the project
2. Planning the project
3. Implementing the plan
4. Completing and evaluating the project
5. Operate and maintain project
A typical construction project has the following seven phases (Kerzner, 1998):
1. Planning, data gathering, and procedures
2. Studies and basic engineering
3. Major review
4. Detail engineering
5. Detail engineering/construction overlap
6. Construction
7. Testing and commissioning
Some people, perhaps in moments of frustration, have described the phases in a more cynical
way:
1. Wild Enthusiasm
2. Disillusionment
3. Total Confusion
4. Search for the Guilty
5. Punishment of the Innocent

6. Praise and Honors for the Nonparticipants
These faculty could often be avoided if project managers think about resource
distribution over the project life cycle.
I usually use an hands-on building exercise to help students experience project
management throughout the life cycle. I give teams an in-class project of building a simply-
supported newprint beam that will support a concentrated load of 250 grams in the center of at
least a 65 centimeter span. The students find it very challenging but most succeed as shown in
the three images from a summer class with high school students.
As you examine these three paper beam design
images, think about important heuristics for
managing a successful paper beam design project.
Reflection: Consider the paper beam project and first four phases of the project life cycle
described above (conceiving, planning, implementing, and completing) and sketch how you
think resources (people, money, etc) are distributed throughout the life of a project. What did
you come up with? Continually increasing resources? Increasing then decreasing? Why did
you draw the shape you did?
A typical distribution of resources (people,
materials, etc.) is shown in Figure 4.2
Project managers must also consider
how their ability to make changes and the cost
of those changes vary over the project life

Figure 4.2 Resource distribution over the
cycle. Figure 4.3 shows the relationship project life cycle
between these two factors. Consider the essential message in Figure 4.3. Since you have
considerably more flexibility early in a project
and it’s cheaper to make changes, don’t skimp
on planning during the early stages! Though
this essential message probably makes a lot of
sense, it’s one that is hard to implement.
Because of the extraordinary eagerness of
many project managers and project team

Figure 4.3 Ability to change & cost to make
members to “get going,” careful and thorough changes over the project life cycle
planning is often neglected. This essential message could also be described as a project
management heuristic.. (See Chapter 1 for elaboration on the meaning of heuristics and their
importance in engineering.) Examples of project management heuristics that students typically
synthesize from the simply-supported beam building exercise are:
1. Allocate resources to the weak link. Students who recognize that the beam usually fails at
the point were the load is applied and at the ends, and apply reinforcement (their one file
folder label) to these areas are more likely to succeed.

2. Freeze the design. At some stage in the project (when about 75% of the time or resources
are used up) the design must be frozen. Students who individually strive to create
successful prototypes without comparing designs with one another or discussing strategy
often fail to create a working design as a group – they are still working individually when
time called.
3. Periodically discuss the process and ask meta-level questions, e.g., What are we doing?
Why are we doing it? How does it help? Students who reflect out loud with one another
during the design process produce better designs more quickly than those who don’t.
Heuristics are essential for successful project management, since every project is unique and
requires it’s own approach. A superb collection of modeling heuristics (that are highly relevant
for project management) was presented by Ravindran, Phillips, and Solberg (1987):
1. Do not build a complicated model when a simple one will suffice.
2. Beware of molding the problem to fit the technique.
3. The deduction phase of modeling must be conducted rigorously.
4. Models should be validated prior to implementation.
5. A model should never be taken too literally.
6. A model should neither be pressed to do, nor criticized for failing to do,
that for which it was never intended.
7. Beware of overselling a model.
8. Some of the primary benefits of modeling are associated with the process
of developing the model.
9. A model cannot be any better than the information that goes into it.
10. Models cannot replace decision makers.

The heuristics given in both of the above lists are important when thinking about the
project life cycle and will become crucially important when we look at the use of project
scheduling models later in the book.
Project Planning
Projects typically start with at Statement of Work (SOW) provided by the client. The
statement of work is a narrative description of the work required for the project. In engineering
classes, the statement of work is provided by the faculty member.
Project planning starts in response to the Statement of Work. This process can be very
detailed, as in Mantel, Meredith, Shafer, and Sutton’s (2001) project master plan, which has the
following elements:
Overview
brief description of project
deliverables
milestones
expected profitability and competitive impact
intended for senior management
Objectives
detailed description of project’s deliverables
project mission statement
General Approach
technical and managerial approaches
relationship to other projects
deviations from standard practices
Contractual Aspects
agreements with clients and third parties
reporting requirements
technical specifications
project review dates
Schedules
outline of all schedules and milestones
Resource Requirements
estimated project expenses
overhead and fixed charges
Personnel
special skill requirements

necessary training
legal requirements
Evaluation Methods
evaluation procedures and standards
procedures for monitoring, collecting, and storing data on project performance
Potential Problems
list of likely potential problems
Another common format for project scoping is the project charter, and in this area there
has been a radical change. I’ve asked participants in workshops (I’ve taught a project
management workshop for the Carlson School of Management’s Executive Development Center
for more than 10 years, and teach project management courses in Executive Master’s Programs
for engineers) how they go about scoping project. Five years ago no one mentioned project
charters, but in the past 2-3 years almost every participant has experience with sophisticated
project scoping systems. Also, they treat them as intellectual property and are reluctant to share
them!
Martin and Tate (1997) describe the following elements in a typical project charter:
1. Write an Overview of the Project Scope

2. Determine the Team’s Boundaries for Creating the Deliverables
3. Define the Customer’s Criteria for Acceptance
4. Determine the Required Reviews and Approvals
5. Establish Risk Limits
6. Select the Project Leader and Team Members
7. Set Deadlines for Delivery of the Final Deliverables
8. Set Limits on Staffing & Spending
9. Create a List of Required Reports
10. Identify Organizational Constraints & Project Priorities.
The next level of detail in the planning process is the development of a Work Breakdown
Structure (WBS). A WBS is “a deliverable-oriented grouping of project elements which
organizes and defines the total scope of a project” (Duncan, 1996). There are typically three to
six levels in WBSs, such as program, project, task, and subtask. Developing a work breakdown
structure is important for scoping a project, i.e., determining the specific tasks that have to be
completed, choosing appropriate groupings for these activities, and setting precedence and
interdependence (what has to follow what and what can be going on at the same time).
A simple approach for creating a WBS is to (1) gather project team, (2) provide team
members with pad of sticky-notes, (3) ask team members to write down all the tasks they can
think of, and (4) have each team member place sticky-notes on chart paper and (5) work together
to re-arrange them. I’ve used the following Post-It Note Project Planning exercise in my classes
and workshop:
Statement of Work (SOW) – Office Remodeling
Activities Needed to Complete Office Remodeling
1. One activity per Post-It note, include name, description and estimated duration (Initial each
Post-It).
2. Arrange Post-Its on chart paper
3. Work together to rearrange Post-Its
4. Draw arrows to indicate precedence
The following images are typical of what the groups come up with:
These two parts of project planning –
Project Charter and Work Breakdown Structure – are often neglected in traditional project
management textbooks and classes, perhaps due to the eagerness to get to the “nitty gritty” of
project scheduling by critical path analysis. However, carefully considering these two initial
aspects of project scoping are important parts of not skimping on planning.
Reflection: Project Management
Project management is a relatively new profession and is growing at a remarkable rate.
Fortune magazine called project management “Career Number 1" for the 1990s. When I was in
engineering school is the late 60s project management courses weren’t offered and since I now
teach several project management courses, I’ve had to learn it by experience and research.
Several of the books I’ve found useful and have used as texts in my courses are listed in the
references – Culp & Smith, 1992; Eisner, 1997; Frame, 1994, 1995; Grady, 1992; Graham &
Englund, 1997; Kerzner, 1998; Lewis, 1993, 1995, 1998;Lientz & Rea, 1995; Meredith &
Mantel, 1994; Nicholas, 1990; Pinto & Kharbanda, 1995; Snead & Wycoff, 1997). Since project
management is an emerging field and is changing quite rapidly, I encourage you to continue
honing your skills and competencies.
References
Cleland, D.I. and Kerzner, H. 1985. A project management dictionary of terms. New York:
Van Nostrand Reinhold.
Culp, G., & Smith, A. 1992. Managing people (including yourself) for project success. New
York: Van Nostrand Reinhold.
Eisner, H. 1997. Essentials of project management and systems engineering management. New
York: Wiley.
Frame, J. D. 1994. The new project management. San Francisco: Jossey-Bass.
Frame, J. D. 1995. Managing projects in organizations. San Francisco: Jossey-Bass
Grady, Robert B. 1992. Practical software metrics for project management and process
improvement. Englewood Cliffs, NJ: Prentice-Hall.
Graham, Robert J., & Englund, Randall L. 1997. Creating an environment for successful
projects. San Francisco: Jossey-Bass.
Kerzner, H. 1998. Project management: A systems approach to planning, scheduling, and
controlling, 6th ed. New York: Van Nostrand Reinhold.
Kharbanda, O.P. & Pinto, J.K. 1996. What made Gertie gallop? Learning from project
failures. New York: Van Nostrand Reinhold.
Laufer, A., Denker, G.R., and Shenhar, A.J. 1993. Simultaneous management: The key to
excellence in capital projects. Unpublished manuscript.
Lewis, James P. 1993. The project manger’s desk reference: A comprehensive guide to project
planning, scheduling, evaluation, control & systems. New York: Probus.
Lewis, James P. 1995. Project planning, scheduling, & control: A hands-on guide to bringging
projects in on time and on budget. New York: Probus.
Lewis, James P. 1995. Fundamentals of project management. New York: AMACOM.
Lewis, James P. 1998. Mastering project management: Applying advanced concepts of systems
thinking, control and evaluation, resource allocation. New York: McGraw-Hill.
Lewis, James P. 2000. Working together: 12 principles for achieving excellence in managing
projects, teams, and organizations. New York: McGraw-Hill.
Lientz, Bennet & Rea, Kathryn. 1995. Project management for the 21st century. San Diego:
Academic Press.
March, James G. 1991. Exploration and exploitation in organizational learning. Organizational
Science, 2, 71-87
Martin, P. & Tate, K. 1997. Project Management Memory Jogger. GOAL/QPC.
Meredith, J.R. & Mantel, S.J. 1994. Project management: A managerial approach. New York:
Wiley.
Nicholas, J.M. 1990. Managing business & engineering projects: Concepts and
implementation. Englewood Cliffs, NJ: Prentice-Hall.
Pinto, J.K. & Kharbanda, O.P. 1995. Successful project managers: Leading your team to
success. New York: Van Nostrand Reinhold.
Duncan, William R. 1996. A guide to the project management body of knowledge. Project
Management Institute.
Ravindran, A., Phillips, D.T., & Solberg, J.J. 1987. Operations research: Principles and
practice. New York: Wiley.
Sabbagh, Karl. 1997. 21st -Century Jet : The Making and Marketing of the Boeing 777. New
York: Scribner.
Snead, G.L. & Wycoff, J. 1997. To do, doing, done! A creative approach to managing projects
& effectively finishing what matters most. New York: Fireside.
Yourdon, E. 1997. Death march projects. Reading, MA: Addison-Wesley.
Questions
1. What is a project? What are the key characteristics of projects? How does project
management differ from management in general?
2. What are the three cardinal conditions of project success?
3. What has been your experience in completing projects “on time, under budget, within
specifications, and acceptable to the client”? What is your “batting average”? Is it better
than the 10% figure cited by the Project Management Institute survey?
4. How does your distribution of effort vary over the life of projects that you’ve worked on?
Do you start strong and taper off? Or do you start slowly and build? Sketch out a graph
that has effort on the ordinate (y) and time on the abscissa (x) for a typical project. Is
your effort curve consistent with the “bell shaped” curve described earlier in the chapter?
Is it different? Does most of your effort go in to the last few hours before the project is
due? If much of your effort is applied in the closing hours of the project, perhaps you
are “freezing the design” too late. How does your enthusiasm vary over the project life
cycle?
5. Start developing a list of your own “project management heuristics.” There are several
books of “rules of thumb,” which are one type of heuristic. One of my favorites is by
Grady (1992). See references.

Project Planning Exercises
Now that you’ve had an opportunity to think about projects, project management, project life
cycles, and project scoping; I’d like you to try applying what you’ve learned.
Suppose you have two tickets to a fabulous concert and are planning a special dinner for
two prior to the concert. Your menu consists of a very special soup and baked chicken entree.
The soup must be boiled for 35 minutes and you should allow 15 minutes to serve and consume
it. The chicken dish requires a fair amount of preparation: you have to boil the rice for 30
minutes, brown the chicken in the frying pan for fifteen minutes, and place the rice and chicken
in a baking dish in the oven for 15 minutes. It takes 5 minutes to prepare a sauce in the frying
pan and 15 minutes to boil the peas. (You only have two pots and one frying pan). You have
bought a good red wine, allow 5 minutes to uncork it (very carefully) and let it stand for 30
minutes before serving it. You plan to allow 25 minutes to serve and eat the entree and wine.
How quickly can you prepare and consume the meal? What representation (model) did
your group use to determine the time? How did you keep track of which activities had to follow
other and which could be going on at the same time?
Playground Project Planning
Student professional organizations (American Society of Civil Engineering, ASCE) are often
involved in community service projects, such as the following school playground construction
project. Assume the role of project team member and that the following activities must be
accomplished to build a playground:

Activity Estimated Duration ( Quarter Days)

Construct playground pads and slides 1
Construct playground walls 2
Design Playground 3
Drill foundation holes 1
Excavate site 1
Place sand 1
Place support frame 2
Procure cement 5
Procure playground materials 7
Procure tools 1
Wash playground 1
You have been assigned by the project manager to complete the following tasks:
Deliverables:
1. Develop a brief Statement of Work or project mission statement
2. Complete a Work Breakdown Structure
3. Create a Critical Path Schedule
General Project Scoping
Select a project (or sub- project) from your workplace or experience, and assume the following
roles and prepare the appropriate documents.
Project Deliverables
1. Assume the role of client: Develop a Statement of Work (SOW) or Project Mission
Statement. Write the SOW as the client directing the engineer-consultant-contractor to
perform prescribed project details and requirements.
2. Assume the role of Engineer/Consultant/Contractor: Create a Project Charter using the
Project Management Memory Jogger format (outlined above), the Lewis Institute
charterform (www.lewisinstitute.com -- charterform.pdf), or a form from your experience or

workplace.
3. Complete a Work Breakdown Structure (WBS) for the project.
4. Create a Precedence Network and Gantt Chart and determine the Critical Path (using the
Critical Path Method (CPM)).
5. Write a one page executive summary of the project.

Chapter Five: Project Manager’s Role
Project management is undergoing enormous changes, as Table 4.1 in indicated, and thus
the role of the project manager is changing. Before we explore the changes that are occurring in
project management, let’s explore broader changes that are occurring in business, industry,
government, and education.
Individual and Group Reflection: Think about changes that have occurred in the workplace (or
school if that is your principal area of experience) in the past five years. Make a list of some of
the most notable changes and compare it with other team members’ lists.
Students in my project management classes who do the above Reflection come up with
lots of changes they’re noticing – communications technology, computers, global marketplace,
emphasis on quality, shortened time frames, and changing role and importance of knowledge
workers.
Changes in the Workplace
Changes in the workplace have been studied and summarized by numerous authors,
including Byrne (1992) and Byrne (2000). Changes occurring in how engineers work in
business and industry, summarized in the following table, have serious implications for how we
prepare engineering graduates for working in the 21st century.

Table 5.1
What a Difference a Century Can Make: Contrasting Views of the Corporation
Characteristic 20th Century 21st Century

Organization The Pyramid The Web or Network
Focus Internal External
Style Structured Flexible
Source of Strength Stability Change
Structure Self-sufficiency Interdependencies
Resources Atoms – physical assets Bits – information
Operations Vertical integration Virtual integration
Products Mass production Mass customization
Reach Domestic Global
Financials Quarterly Real-time
Inventories Months Hours
Strategy Top-down Bottom-up
Leadership Dogmatic Inspirational
Workers Employees Employees and free agents
Job expectations Security Personal growth
Motivation To compete To build
Improvements Incremental Revolutionary
Quality Affordable best No compromise
Source: Byrne, 2000.
The changes that are occurring in business and industry suggest that we should consider
changes in engineering education to prepare our graduates to function effectively in the "new
paradigm" companies. The "Made in America" study (Dertouzos, Lester & Solow, 1989)
recommended the following changes for MIT:
1. Broaden its educational approach in the sciences, in technology, and in the humanities
and should educate students to be more sensitive to productivity, to practical problems, to
teamwork, and to the cultures, institutions, and business practices of other countries.
2. Create a new cadre of students and faculty characterized by (1) interest in, and
knowledge of, real problems and their societal, economic, and political context; (2) an
ability to function effectively as members of a team creating new products, processes,
and systems; (3) an ability to operate effectively beyond the confines of a single
discipline; and (4) an integration of a deep understanding of science and technology with
practical knowledge, a hands-on orientation, and experimental skills and insight.
3. Revise subjects to include team projects, practical problems, and exposure to
international cultures. Encourage student teaching to instill a stronger appreciation of
lifelong learning and the teaching of others. Reinstitute a foreign-language requirement
in the undergraduate admissions process.
Although progress has been made in the past 12 years, due in large part to the
Accreditation Board for Engineering and Technology (ABET) emphasis on graduates’ skills and
abilities, the changes Dertouzos, Lester and Solow called for in 1989 are extremely important.
Changes in engineering education were described in a paper in the Frontiers in Education
Conference Proceedings (Smith & Waller, 1997) and summarized in Table 5.3. If you’re
interested in learning more about new paradigms for engineering education, you may view the
paper on the World Wide Web at the ASEE/IEEE Frontiers in Education page.
Table 5.3
Comparison of Old and New Paradigms for College Teaching
Old Paradigm New Paradigm
Knowledge Transferred from Faculty to Students Jointly Constructed by Students and Faculty
Students Passive Vessel to be Filled by Faculty's Active Constructor, Discoverer, Transformer of
Knowledge Knowledge
Mode of Learning Memorizing Relating
Faculty Purpose Classify and Sort Students Develop Students' Competencies and Talents
Student Goals Complete Requirements, Achieve Grow, Focus on Continual Lifelong Learning
Certification within a Discipline within a Broader System

Relationships Impersonal Relationship Among Students Personal Transaction Among Students and
and Between Faculty and Students Between Faculty and Students

Context Competitive/Individualistic Cooperative Learning in Classroom and
Cooperative Teams Among Faculty

Climate Conformity/Cultural Uniformity Diversity and Personal Esteem/ Cultural
Diversity and Commonality

Power Faculty Holds and Exercises Power, Students are Empowered; Power is Shared
Authority, and Control Among Students and Between Students and
Faculty
Assessment Norm-Referenced (i.e., Graded "On the Criterion-Referenced; Typically Performances
Curve"); Typically Multiple Choice Items; and Portfolios; Continual Assessment of
Student rating of instruction at end of course Instruction

Ways of Knowing Logico-Scientific Narrative
Epistemology Reductionist; Facts and Memorization Constructivist; Inquiry and Invention
Technology Use Drill and Practice; Textbook Substitute; Problem Solving, Communication,
Chalk and Talk Substitute Collaboration, Information Access, Expression

Teaching Any Expert can Teach Teaching is Complex and Requires Considerable
Assumption Training
The premier issue of an exciting new engineering magazine, Today’s Engineer, proposes
that we are at the dawning of a new age of engineering – the crossroads for a changing
professional model (Gaynor, 1998). The editor, Gaynor, claims that this new model makes three
demands on us: that we transcend traditional boundaries, that we think strategically, and that we
develop a business perspective. Gaynor also tells us that technical competence is an absolute
requirement, but by itself is no longer sufficient. It must be integrated with: breadth of vision,
flexibility, customer focus, and business orientation.
Changes like those outlined by Dertouzos and his colleagues, as well as Gaynor’s bold
changes, are enormously difficult to implement in a direct, linear manner. The nature of change
is described by Katzenbach and Smith (1993) by a "whitewater raft ride" metaphor. The authors
also list behavioral changes that are demanded by change.
Major change, by its nature, is intentionally disruptive and largely
unprogrammable. In comparing the management of major versus normal change,
one top executive said, "It used to be like I-75. You'd lay it out from Toledo to
Tampa. Now it's more like a whitewater raft ride. You try to get the right people
in the raft and do the best you can to steer it. But you never know what's just
around the bend."
Katzenbach and Smith suggest several behavioral changes in the table below that will help us
make the necessary changes.

Table 5.2 Behavioral Changes Demanded by Performance in the 1990s and Beyond
FROM TO
Individual accountability Mutual support, joint accountability, and
trust-based relationships in addition to
individual accountability
Dividing those who think and decide from Expecting everyone to think, work, and do
those who work and do
Building functional excellence through each Encouraging people to play multiple roles
person executing a narrow set of tasks ever and work together interchangeably on
more efficiently continuous improvement
Relying on managerial control Getting people to buy into meaningful
purpose, to help shape direction, and to learn
A fair day's pay for a fair day's work Aspiring to personal growth that expands as
well as exploits each person's capabilities
Peter Drucker, who has written more articles for the Harvard Business Review than
anyone else, recently described the changing views of the “manager” concept. Drucker stresses
the idea of the “knowledge worker” and, consistent with this concepts, focuses on skills and
strategies for “managing the knowledge worker.” In the 1920s, a manager was seen as one who
was responsible for the work of subordinates; in the 1950s, a manager was one who was
responsible for the performance of people; and in the 1990s (and beyond?), a manager is one is
responsible for the application and performance of knowledge.
Individual Reflection: How are you feeling about all these impending changes? A bit
overwhelmed, no doubt. Are you seeing changes in your educational experience? Is your
college education on the cutting edge of modern practice? What do you think about the state of
your education? Discuss with your group.

Lots of people have noted, often with a sense of frustration, that the classroom is one of
the few settings that would be recognizable to someone working in the setting 100 years ago.
Few, if any, other settings – transportation, hospitals, factories – would be recognizable to
someone who worked in them 100 years ago. Perhaps the classroom is a “place that time forgot
and that the decades can’t improve” (to paraphrase Garrison Keillor from Prairie Home
Companion), but I think there is room for improvement.
Changes in Project Management
Since so many changes are occurring in the workplace – including downsizing,
rightsizing, and attending to the customer – is there any question that change is also occurring in
project management? Management guru, Tom Peters, makes bold claims about the importance of
project management in the following statement: “Those organizations that take project
management seriously as a discipline, as a way of life, are likely to make it into the 21st century.
Those that do not are likely to find themselves in good company with dinosaurs.” (p. 128).
Peters (1991), an engineering graduate who wrote a masters thesis on PERT charts, has also
made the following statements in an article “From eight commandments for project managers:
• “Tomorrow’s corporation is a ‘collection of project’.”
• “Everyone needs to learn to work in teams with multiple independent experts--each will
be dependent upon all the others voluntarily giving their best.”
• “The new lead actor/boss--the Project Manager--must learn to command and coach; that
is, to deal with paradox.”
Tom Peters recent work is on the WOW project (Peters, 1999). He writes in Fast Company
(Peters, 1999): “In the new economy, all work is project work. And you are your projects!
Here’s how to make them go WOW!”. (p. ?).
In the area of project management, several authors have summarized the most notable
changes. Pinto and Kharbanda (1995) refer to our age as “The Age of Project Management.”
Key features of this age are:
1. Shortened market windows and product life cycles.
2. Rapid development of third world and closed economies.
3. Increasingly complex and technical products.
4. Heightened international competition.
5. The environment of organizational resource scarcity.
Lientz and Rea (1995) list several trends that affect projects:
TRENDS
Global Competition Empowerment
Rapid Technological Change Focus on Quality and Continuous
Product Obsolescence Improvement
Organizational Downsizing Measurement
Business Reengineering Interorganizational Systems
Furthermore, Lientz and Rea remind us that projects are set in time. They are also set in the
context of organization, a legal system, a political system, a technology structure, an economic
system, and a social system. How do these environmental factors affect projects? How should a
project manager and project respond? Outside factors impact the project, and the project must
respond to the resulting challenges.
If I haven’t I convinced you that there are many changes occurring in the business world
and that the emergence of project management is one of them, try the following reflection.
Individual Reflection: What does it take to be a good project manager? Take a few minutes to
think about the skills and competencies (and perhaps the attitudes) needed for effective project
management. Make a list. Compare your list with those of other students.
Do you know any project managers? Do you have relatives or friends who do project
work? Try to find someone you can interview to help you get your bearings on project
management. (See the interview exercise at the end of this chapter.) Then revise your list.
Skills Necessary for Effective Project Managers
Barry Posner (1987) conducted a survey of project managers, asking them “what is takes
to be a good project manager.” He got the following results:
1. Communications (84% of the 4. Leadership Skills (68%)

respondents listed it) 1. Sets Example
1. Listening 2. Energetic
2. Persuading 3. Vision (big picture)
2. Organizational skills (75%) 4. Delegates
1. Planning 5. Positive
2. Goal-setting 5. Coping Skills (59%)
3. Analyzing 1. Flexibility
3. Team Building Skills (72%) 2. Creativity
1. Empathy 3. Patience
2. Motivation 4. Persistence
3. Esprit de Corps 6. Technological Skills (46%)
1. Experience
2. Project Knowledge
Several authors have surveyed project managers and conducted extensive literature
searches to learn about essential project management skills. Pinto and Kharbanda (1995) list the
following skills necessary for effective project managers:
• Planning: work breakdown, project scheduling, knowledge of project management
software, budgeting and costing.
• Organizing: team building, establishing team structure and reporting assignments,
defining team policies, rules and protocols
• Leading: motivation, conflict management, interpersonal skills, appreciation of team
members' strengths and weaknesses, reward systems.
• Controlling: project review techniques, meeting skills, project close-out techniques.
Lientz and Rea (1996) provide the following list of keys to success as a project manager:
! Communicate regularly in person with key team members
! Keep management informed
! Keep informed on all aspects of the project
! Delegate tasks to team members
! Listen to input from team members
! Be able to take criticism
! Respond to and/or act on suggestions for improvement
! Develop contingency plans
! Address problems
! Make decisions
! Learn from past experience
! Run an effective meeting
! Set up and manage the project file

! Use project management tools to generate reports
! Understand trade-offs involving schedule and budget
! Have a sense of humor
Individual Reflection: How do these lists compare with yours? Was there lots of overlap?
Were there categories of items that were on your list but not on these, and vice versa?
Research by Jeffrey Pinto (1986) sought to quantify some of these factors by correlating
them with their importance for system implementation. “System implementation” may be
interpreted as a successful project outcome.
[Text Box]
Critical Success Factors and Their Importance for System Implementation
(Listed in decreasing order of correlation)
1. Project mission. Initial clearly defined goals and general directions.
2. Top management support. Willingness of top management to provide the necessary
resources and authority/power for implementation success.
3. Schedule plans. A detailed specification of the individual action steps for system
implementation.
4. Client consultation. Communication, consultation, and active listening to all parties
impacted by the proposed project.
5. Personnel. Recruitment, selection, and training of the necessary personnel for the
implantation project team.

6. Technical tasks. Availability of the required technology and expertise to accomplish the
specific technical action steps to bring the project on-line.
7. Client acceptance. The act of "selling" final product to its ultimate intended users.
8. Monitoring and feedback. Timely provision of comprehensive control information at
each stage in the implementation process.
9. Communication. The provision of an appropriate network and necessary data to all key
actors in the project implementation process.
10. Troubleshooting. Ability to handle unexpected crises and deviations from plan.
How does one implement all of these characteristics of effective project managers?
There are so many. One way is to employ a common modeling strategy called salami tactics
where a complex problem is broken into smaller, more manageable parts (Starfield, Smith &
Bleloch, 1994). The “slices” that I’ll use are the phases in a typical project life cycle -- planning,
organizing, staffing, directing, and controlling.
Project Manager's Role Over the Project Life Cycle
Planning
During the planning stage, you as the project manager must establish project objectives and
performance requirements must be established. Remember to involve key participants in the
process (since, according to an old rule of thumb, involvement builds commitment). Establish
well-defined milestones with deadlines. Try to anticipate problems and build in contingencies to
allow for them. Carefully outline responsibilities, schedules, and budgets.
Organizing
The first step in organizing is to develop a work breakdown structure that divides the project into
units of work. If the project is large and complex, then the next step is to create a project
organization chart that shows the structure and relationships of key project members. Finally,
schedules, budgets, and responsibilities must be clearly and thoroughly defined.
Staffing
The major portion of most project successes depends on the people involved with the project.
You must define work requirements and, to the extent possible, seek appropriate input when
selecting team members. Be sure to orient team members to the big picture of the project. Seek
each team member’s input to define and agree upon scope, budget, and schedule (Remember,
involvement builds commitment, and usually a better product). Set specific performance
expectations with each team member.
Directing
The day-to-day directing of projects involves coordinating project components, investigating
potential problems as soon as they arise, and researching and allocating necessary resources. Be
sure to remember to display a positive can-do attitude, and to be available to team members.
Recognize team members’ good work and guide necessary improvement.
Controlling
Keeping the project on course with respect to schedule, budget and performance specifications
requires paying attention to detail. Some things that usually help are:
1. Communicate regularly with team members
2. Measure project performance by maintaining a record of planned and completed work
3. Chart planned and completed milestones

4. Chart monthly project costs
5. Document agreements, meetings, telephone conversations
This summary of the project manager’s role over the project life cycle is intended to
provide guidance and is not intended to be followed linearly or exhaustively. Each project is
unique and requires it’s own approach; however, appropriately following the suggestions for
each stage of the project outlined above are like to improve project success.
Conclusion
Enormous changes are occurring in the way work and learning are done. You are
probably experiencing some of these changes in your classes as you are asked to work on
projects in groups and formulate and solve open-ended problems. If you’re working at an
engineering job you are surely experiencing some of these changes.
I’ve tried to provide a perspective on changes that are occurring both in the classroom
and in the workplace. One of the most influential references on change is Stephen Covey’s
Seven habits of highly effective people (Covey, 1989) which has sold millions of copies. Covey
lists these habits as follows:
1. Be Pro-Active: Take the initiative and the responsibility to make things happen.
2. Begin With an End in Mind: Start with a clear destination to understand where you are
now, where you're going, and what you value most.
3. Put First Things First: Manage yourself. Organize and execute around priorities.
4. Think Win/Win: See life as a cooperative, not a competitive arena where success is not
achieved at the expense or exclusion of the success of others.
5. Seek First to Understand: Understand then be understood to build the skills of

empathic listening that inspires openness and trust.
6. Synergize: Apply the principles of cooperative creativity and value differences.
7. Renewal: Preserving and enhancing your greatest asset, yourself, by renewing the
physical, spiritual, mental and social/emotional dimensions of your nature.
Countless students in my classes have said “Covey’s book changed my life!” Stephen
Covey had an early influence on my professional work. I attended a management development
program he conducted in Moab, Utah in 1969-70 as a part of my first full-time engineering job.
The roles of project managers in engineering school and in the workplace are complex and
varied. Covey’s list provides a good set of heuristics to guide project managers. Another classic
that you may want to read is Frederick P. Brooks’ The mythical man-month. If Brooks’ book
about software project management intrigues you, then you may want to check out Steve
McConnell’s Software project survival guide. More and more engineers are involved in
software development and these two books will help you manage it.
Reflection: Professor as Project Manager
I tend to think of each course I teach as a project, and in terms of beginnings and endings,
and resource loading during the semester, each course clearly has project characteristics. I think
about the goals and outcomes, that is, what I want students to know and be able to do at the end
of the course; what evidence I’ll gather through monitoring and assessment to document that
students have learned; and finally I design the instructional aspects of the course. Mainly I try to
orchestrate variety during the class sessions so I don’t get bored and to provide help for students
who learn myriad ways. This past semester, Fall 2002, two students wrote a paper on the project
management aspects of the course. I was hesitant to read it, but as I delved in, found from their
perspective that I had succeeded in treating the course as a project. The paper by Luke Heaton
and Greg Williams, An Analysis of Project Management CE 4101W as a Project is available on
my web site – www.ce.umn.edu/~smith.
References
Brooks, Jr., Frederick P. 1995. The mythical man-month: Essays on software engineering -
Anniversary edition. Reading, MA: Addison-Wesley.
Byrne, J.A. 1992. Paradigms for postmodern managers. Business Week, Special Issue on
Reinventing America, 62-63.
Byrne, John. 2000. Management by web. The 21st Century Corporation. Business Week,
August 28, p. 87.
Covey, Stephen R. 1989. The 7 habits of highly effective people. New York: Simon &
Schuster.
Gaynor, G. H. 1998. The dawning of a new age: Crossroads of the engineering profession.
Today’s Engineer, 1(1), 19-22.
Lientz, Bennet & Rea, Kathryn. 1995. Project management for the 21st Century. San Diego:
Academic Press.
McConnell, Steve. 1998. Software survival guide: How to ensure your first important project
isn’t your last. Redmond, Washington: Microsoft Press.
Oberlender, G.D. 1993. Project management for engineering and construction. New York:
McGraw-Hill.
Drucker, Peter F. 1993. Post-capitalist society. New York: Harper Business.

Peters, Thomas J. 1987. Thriving on chaos: Handbook for a management revolution. New
York: Knopf.
Peters, Thomas J. 1991. Managing projects takes a special kind of leadership. Seattle Post-
Intelligence, 4/29/1991, p. 64.
Peters, Thomas J. 1999. The WOW project: In the new economy, all work is project work. Fast
Company, 24, 116-128.
Pinto, J.K. 1986. Project implementation: A determination of its critical success factors,
moderators, and their relative importance across stages in the project life cycle. Unpublished
Ph.D. dissertation. Pittsburgh, PA: University of Pittsburgh.
Pinto, J.K. & Kharbanda, O.P. 1995. Successful project managers: Leading your team to
success. New York: Van Nostrand Reinhold.
Posner, Barry. 1987. Characteristics of Effective Project Managers. Project Management
Journal.
Smith, Karl A. and Waller, Alisha A. 1997. New paradigms for engineering education.
Pittsburgh, PA: ASEE/IEEE Frontiers in Education Conference Proceedings. Adapted from
Smith, K.A. & Waller A.A. 1997. After word: New paradigms for college teaching. In
Campbell, W.E. & Smith, K.A. (Eds.). 1995. New paradigms for college teaching. Edina, MN:
Interaction.
Starfield, A.M., Smith, K.A., & Bleloch, A.L. 1994. How to model it: Problem solving for the
computer age. Edina: Burgess.
Questions
1. What changes have you noted in the workplace or school? Has your school undergone a
schedule change recently, e.g., quarters to semesters? How do the changes you’ve noted
compare with those listed in the chapter?
2. This chapter emphasized the changing nature of the workplace and of engineering work,
and the needed project manager skills, based on past (and sometimes current) practice.
What do you anticipate project manager skills will be in the future? What do the futurists
-- John Naisbitt, Watts Walker, Esther Dyson, etc -- have to say about this?
3. What skills are essential for effective project managers? How can they be enhanced and
developed?
4. What does the literature report as “Keys to project success”? How does this list compare
with your experience?
5. This chapter organized the project manager’s role around the life cycle. Are there other
ways that come to mind for organizing the project manager’s role? What are they? What
are their advantages and disadvantages?
Exercise
Interview a project manager, or someone who is involved with project work. Potential interview
questions developed by students in my project management classes are listed below. This
exercise will not only give you a chance to find out more about project management in practice
(and refine your list of essential skills, competencies, and attitudes), but also may help you
decide if it is a career path you’d like to pursue.
Questions asked of project managers in different fields:
1. What is the main thrill or interesting reason for being a project manager?
2. Describe a typical work schedule during the week, including number of hours.
3. What directed you to become a project manager? Why not stay in engineering or some
other form of business management?
4. Project manager’s role as a team leader and a team member -- discuss instances.
5. Discuss the realm and responsibilities of the project manager.
6. What personal characteristics are your best ally during the job’s activities?
7. What skills have you had to develop or refine since becoming a project manager?
8. What personal goals striving for: personally and professionally?
9. What are the things that slow you down?
10. What are a few of the frustrations of the job?
11. Project manager’s professional credibility and its value.
12. How does the company you work for consider the project manager and the
responsibilities/opportunities?
13. Describe any battles to complete tasks in the most economical manner and still maintain
quality or integrity.
14. How important is the project schedule and what purposes does it serve?
15. Discuss extent of interaction with project owner(s) or client(s).
16. Level of involvement with contract negotiations.
17. Discuss interaction with other professionals, e.g., engineer or architect.
18. Methods to monitor adequate communication between project owner, architect, client,
etc. and the jobsite crew.
19. Accounting practices for project budget and regular reviews.
20. Is financial compensation commensurate with the work? Other benefits?

Chapter Six: Project Scheduling
Project scheduling is one of the central yet often overrated aspect of project management.
For some the feeling is “OK, we’ve got a schedule; we’re done.” Getting a schedule is just one
important step in the process of project management. The real work begins when circumstances
cause delays and pressures mount to revise the schedule.
Individual Reflection: Think about how you typically schedule complex projects, such as
completing a major report for a class. Do you make a list of things to do? An outline? Do you
draw a concept map? Or do you just start writing? Do you develop a timeline?
In this chapter, we’ll work our way through the details of the scheduling process. We’ll
learn the basics of the critical path algorithm and experience first hand the ideas of forward pass,
backward pass, critical path, and float. As you develop an understanding of these concepts and
procedures, you will gain insight into managing projects with complex schedules. I first
encountered these concepts as an undergraduate engineering student in about 1964. The critical
path method was presented in an engineering systems class as a network algorithm. The
approach was purely mechanical; no reference was made to it’s potential usefulness in
scheduling projects.
Let’s revisit the meal planning exercise from Chapter Four (p. ?). Take a look at what
you did for this exercise. If you didn’t do it yet, go back and think about how you would tackle
this task. We’ll use this exercise as the project example throughout this chapter.
Reflection: What representation (model) did your group use to determine the time? How did you
keep track of which activities had to follow each other and which could be going on at the same
time? How did you go about determining the total time the meal preparation and eating would
take? Did you make a list? A timeline? Or did you approach the problem in some other way?
Work Breakdown Structure
A common approach for scoping a project such as this is to prepare a Work Breakdown
Structure (WBS), as described in Chapter 4. The WBS can be presented as a list or a
organization-type chart. A one-level
WBS would be “Prepare the meal,”but this wouldn’t be too helpful in figuring out what had to
be done. A two-level WBS would include:
Preparation
Boil soup
Boil rice
Boil peas
Brown chicken
Prepare sauce
Bake chicken, rice & sauce
Open Wine & let breathe
Eating
Eat soup
Eat entree
This two-level WBS provides more guidance
as to what needs to be done but it still leave a
lot up to the chef (which is OK in many

Figure 6.1 Post-It note Precedence Network
cases). A more elaborate approach to preparing a WBS is to use “Post-It” notes to sort out the
sequences. There are several possible sequences for the activities for this WBS, depending on
how you interpret the “proper order” of preparing this meal. One possible WBS showing
precedence relationships (technically this is now a precedence network) is show in Figure 6.1.
In this WBS only the activity names and the resource (Pot 1, etc.) that the activity uses
are listed. Notice that I’ve made decisions about placing the sauce on the entree before putting it
the oven, and having the wine with the entree rather than with the soup. You may have chosen a
different sequence, perhaps to have the wine with the soup or to place the sauce on entree after it
is served. Later we’ll explore how these choices affect the schedule.
Reflection: Have you used the WBS the idea for scoping projects? If not, are there places in
your personal and professional life where you can immediately apply the WBS idea? How about
engineering course or design projects you’re working on? If you want more practice, try the
office remodeling project example at the end of the chapter.
Critical Path Method
Now that we have a precedence network for the meal planning project, how do we
determine the minimum time to complete it? To do this, we go through Figure 6.1, number each
node and list the time it takes (see Figure 6.2). Examine the precedence network in Figure 6.2 to
determine the minimum time to complete the project. Sum the individual activity durations along
each path, for example, path 1+5+10 is 35+15+25=75 min. Which path is longest?
Provided that the number of activities is not too large, problems of this type can often be
solved by hand. By sketching the relationships between the individual tasks, and taking into
account the amount of time each requires
for completion, we can determine the total
amount of time needed to get the whole
process completed.
When the number of tasks gets large
– say, over 20 – then it’s quite challenging
to keep track of everything by hand. A
simple and systematic way of doing this is

Figure 6.2 Precedence Network
provided by the critical path method (CPM). This method represents the flow of tasks in the
form of a network. To use it we simply have to know the duration of each of the activities, and
the predecessors of each – that is, the set of activities that must have terminated before an
activity can begin.
Forward Pass -- Early Start (ES) and Early Finish (EF)
The first step in the procedure is to run through the network from beginning to end
and mark the earliest time that each
activity can start; the Early Start (ES)
time. In Figure 6.3, this is time is in the
upper left-hand corner of each activity.
This is clearly obtained by adding the
earliest start of its latest starting
predecessor to that predecessor's duration.
When two or more activities must be

Figure 6.3 CPM-Forward Pass - Early Times
completed before the next one can start (such as Boil Rice and Bake Chicken and Prepare Sauce
before Bake Entree), then the maximum must be used. The Early Finish (EF) time is determined
by summing the Early Start (ES) and the Duration (see Figure 6.3).
Backward Pass -- Late Start (LS) and Late Finish (LF)
Similarly, a backward pass is
made, establishing the latest possible
starting time (Late Start, LS) that an
activity can have, which is the latest
start of the earliest starting successor,
less the duration of the activity under
consideration (see Figure 6.4). The
result is the Late Finish (LF) time.

Figure 6.4 CPM-Backward Pass - Late Times
Critical Path
Activities for which the earliest and latest times turn out to be equal are called critical. That is,
they cannot be delayed without delaying the duration of the entire project. The path that these
activities lie on in the network is known as the critical path. The remaining non-critical
activities have some float (sometimes referred to as slack) and can have their durations increased
by some amount before they would become critical and delay the total duration.
Floats
The amount by which termination of a non-critical activity can be delayed before it causes one of
its successors to be delayed is called the free float of that activity. Technically, the free float
(FF) is based on early start (ES) times and for any activity i is equal to the minimum early start
for activities following activity i minus the early start for i minus the duration (D) for i.
Algebraically, the free float (FF) is determined as follows:
FFi = (ESi + 1 )min - ESi - Di
The amount of slack an activity has before it would cause the path on which it lies to become
critical is called the total float. The total float of an activity is the minimum (out of all of the
paths on which it lies) of the sum of its free float and those of all activities ahead of it on the
path. Thus an activity is critical if its total float is zero. Technically, the total float (TF) is the
difference between the late times and the early times – late start minus early start or late finish
minus early finish. Algebraically, the total float (TF) for an activity i is determined as follows:
TF i = LSi − ESi = LFi − EFi

The numerical solution to the meal planning problem is given in Table 6.1.
Table 6.1 -- Meal Planning Exercise – Critical Path Method Results
ACT NAME DUR RES EARLY LATE FLOAT CUR CRIT

start PATH
ST FN ST FN TOT FREE
1 Boil Soup 35 1 0 35 0 35 0 0 0 YES
2 Boil Rice 30 1 0 30 5 35 5 0 0 NO
3 Brown 15 1 0 15 15 30 15 0 0 NO
Chicken
4 Open Wine 5 1 0 5 15 20 15 0 0 NO
5 Eat Soup 15 1 35 50 35 50 0 0 35 YES
6 Boil Peas 15 1 30 45 35 50 5 5 30 NO
7 Prep Sauce 5 1 15 20 30 35 35 15 10 NO
8 Wine 30 1 5 35 20 50 15 15 5 NO
Breathes
9 Bake Entree 15 1 30 45 35 50 5 5 30 NO
10 Eat Entree 25 1 50 75 50 75 0 0 50 YES
Another common model for representing scheduling projects is a time-scaled network, called a
Gantt chart, where the activities have been laid out on a time axis. The Table and Gantt chart
for the first 8 activities, shown in Figure 6.5 were prepared using the CritPath program which is
available for downloading from my website and is bundled with How to model it (Starfield,
Smith & Blelock, 1994) . The CritPath program is set up to only display eight activities at a
time. If you want to be able to scroll though the activities and change them, download the
CritPath program from my web site (www.ce.umn.edu/~smith) and play with it!
Figure 6.5
Gantt Chart
(Activities 1-8)
Figure 6.5
Gantt Chart
(Activities 3-
10)
If you are still having difficulty understanding the differences between free and total float
or are struggling with the Critical Path calculations, use the algorithm stepper in the CritPath
program. It will walk you through the process using a graphical representation (see Figure 6.6).
Figure 6.6 Critical Path Algorithm Stepper
Notice how there is no gap in the path that includes activities Open Wine (1), Eat Soup
(5), and Eat Entree (10)? That means, of course, that they are on the critical path. Also notice
how there is a gap after activities Wine Breathes (8), Prepare Sauce (7), Bake Entree (9) and Boil
Peas (6) which means they have free float in addition to having total float. The activities Brown
Chicken (3) and Open Wine (4) are followed by a gap farther down the path, but not by an
immediate gap; this means that they have total float but not free float.
Individual Reflection: Take a few minutes to think about the advantages and disadvantages of
the two representations of the meal planning project – precedence network (Figure 6.4) and
Gantt chart (Figure 6.5). What are the unique features of each? What specific features does each
represent? Where is each appropriate?
In the above Reflection, you may have concluded that both the precedence network and
the Gantt chart are essential for understanding complex projects and communicating project
information. The Gantt chart is a time-scaled network, since time is represented directly. It
gives a clear picture of the duration of events, but it doesn’t directly show the nature of the
interdependence, that is, what has to follow what. The precedence network, on the other hand,
clearly shows the interdependence – precedence and simultaneity, that is, what has to follow
what and what can be going on at the same time – but doesn’t directly show the time required for
each activity.
The CritPath program and most project scheduling software uses the precedence network
representation to do the critical path calculations. Many people find the Gantt chart most useful
for tracking project progress.
Critical Path Method Summary
In summary, the sequence of steps to apply the critical path method to project scheduling is as
follows:
1. Develop a Work Breakdown Structure (WBS).
2. Connect the activities in the WBS by arrows that indicate the precedence.
3. Perform the Critical Path Analysis calculations either by hand for a simple problem or
using computer software.
4. Create graphical representations – precedence network and Gantt chart – that suit your
purposes.
Bus Shelter Construction Example
Now that we’ve worked through the meal planning exercise is some detail, let try another
example. Consider the following construction project, outlined in Table 6.2. Note that the
precedence relationships are specified so you don’t have to create a work breakdown structure;
however, developing a precedence network is an important step. The resources column specifies
the number of people required for each task.
Table 6.2 – Bus Shelter Construction Example
Job Name Duration Resources Predecessor(s)
1 Shelter Slab 2 2 5
2 Shelter Walls 1 1 1
3 Shelter Roof 2 2 2,4
4 Roof Beam 3 2 2
5 Excavation 2 3
6 Curb and Gutter 2 3 5
7 Shelter Seat 1 2 4,6
8 Paint 1 1 7
9 Signwork 1 2 2,6
Determine the minimum time required to complete the bus shelter. Develop a
precedence network. Identify the critical path. Draw a Gantt chart for the project. Give it a try
before looking further. (A precedence network is sketched out in Figure 6.7).

Next, perform the critical
path analysis calculations. You
may do this by hand if you want
more practice, or you can use
CritPath or an commercial project
scheduling program. The Table

Figure 6.7 Precedence Network for Bus Shelter
and Gantt chart for the first 8
activities are show in Figure 6.8.
Look carefully at the Critical Path method results and the Gantt chart. Notice that there
Figure 6.8 Gantt Chart for Bus Shelter

is more than one critical path. The presence of multiple critical paths can be see on the
Algorithm Stepper, since all the paths through the network are displayed. Get the CritPath
software and try it. Table 6.3 shows the entire set of results for the Bus Shelter Construction
project.
Table 6.3 -- Bus Shelter Construction
Critical Path Method Results
ACT NAME DUR RES EARLY LATE FLOAT CUR CRIT

start PATH
ST FN ST FN TOT FREE
1 Shelter Slab 2 2 2 4 2 4 0 0 2 YES
2 Shelter 1 1 4 5 4 5 0 0 4 YES
Walls
3 Shelter Roof 2 2 8 10 8 10 0 0 8 YES
4 Roof Beam 3 2 5 8 5 8 0 0 5 YES
5 Excavation 2 3 0 2 0 2 0 0 0 YES
6 Curb and 2 3 2 4 6 8 4 1 2 NO
Gutter
7 Shelter Seat 1 2 8 9 8 9 0 0 8 YES
8 Paint 1 1 9 10 9 10 0 0 9 YES
9 Signwork 1 2 5 6 9 10 4 4 5 NO
Try developing and setting up your next project using the critical path method. Do the
calculations by hand a couple times to familiarize yourself with the forward pass and backward
pass of the algorithm. Then use Critpath or another commercial project scheduling program.
Project Resource and Cost Considerations
Resource Leveling
Critical activities, having no slack, cannot be extended or shifted without upsetting the
scheduled completion of the project. However, the slack afforded by noncritical activities can be
exploited to provide the best distribution of resources over the duration of the entire project. For
example it might be difficult or expensive to hire more than a certain number of programmers or
trades people at any one time. By shifting non-critical activities within their floats, it is possible
to spread the distribution of personnel more evenly over the span of the project. At other times it
may be beneficial to load the distribution in a certain way, for example if work over a holiday
period is to be minimized. Decisions of these kinds can be made only when the constraints (i.e.
earliest and latest start times) of the schedule has been determined. Look at what happens to the
Figure 6.9 Resource Histogram for Bus Shelter
Resource Histogram for the Bus Shelter project when you shift all activities are at their Early
Start times, Figure 6.9. What do you expect would happen if you shifted all activities to their
Figure 6-10 Resource Histogram – Latest Times
Late Start times? See Figure 6.10.
Compare Figures 6.9 and 6.10 to help decide what you think would be the best allocation
of resources. Notice that there is not too much that you can do to level the resources in this case,
which is sometimes the situation with real projects.
Cost Considerations
You may on some projects work through the critical path calculations and find that the
required project duration is greater than the time you have available Or, more commonly, if you
get behind during the project due to weather, late deliveries, work delays, and so on. In such
cases, you could, of course, go to your supervisor or professor and ask for an extension.
Alternatively, you could add resources (e.g., people, overtime) to activities on the critical path to
decrease their duration, thus decreasing the time for the entire project. Technically, this is know
as “crashing” a project. Why wouldn’t we add resources to non-critical activities? Let’s work
through the example shown in Table 6.3 to get a better sense of how this works.
Table 6.3 CPM/Cost Example
Task Precedence Normal Crash Time Normal Cost Incremental
Time Cost/Day
A - 8 4 800 300
B - 4 3 600 100
C B 2 1 1000 400
D A, C 3 2 300 200
Figure 6-11 shows the “normal” schedule duration. The “normal” schedule cost is just the sum
of the normal costs for the four activities – $2700.
As the project manager you would have to choose which activities along the critical path
to add resources to, in order to decrease their duration. What criteria would you use to choose
the activities? Would you crash activities early in the schedule first? The cost conscious project
manager would crash the activities that had the minimum cost per unit of time saved. Often
convenience, availability, and other factors must be considered.

Figure 6-11 Gantt Chart for Cost Example
Let’s look at what happens as we decrease the duration of activities on the critical path
for the example above (see Figure 6.11). The lowest cost choice is Activity D. By decreasing the
duration of Activity D from 3 to 2, the overall project duration decreases to 10 and the cost
increases to $2700 + $200 = $2900. Next we can add resources to Activity A to decrease it to 7.
The overall project duration becomes 9 and the cost increases to $3000. Adding more resources
to A to decrease it to 6 decreases the overall project duration to 8 and increases the cost to
$3300. The updated Gantt Chart is show in Figure 6-12. We can continue to decrease the
duration of the overall project but now we must add resources to more than one activity and
hence the cost increases at a higher rate.

Figure 6-12 Gantt Chart - All Paths Critical
As you add resources to critical activities and decrease the duration along the critical
path, eventually, more and more activities become critical.
Individual and Group Reflection: What are some good strategies for using the float over the life
of a project? Do you, for example, let things slide early on; thus using the float up early? Or do
you wait until later in the project to use the float? As a project manager, how do you recommend
that the float be utilized?
The Role of Computer-Based Project Management Software
It is not hard to see that if we were to add a few more activities, the problem would soon
become unmanageable by hand. Further, if changes have to be made either to the order in which
activities must occur, or in the time in which they can be completed, the entire process would
have to be repeated. The advantage of the critical path method is that it is indeed systematic. It
can be described as a formal set of instructions that can be followed by a computer. Alterations
in the data can be made repeatedly and the problem quickly solved, again by the machine. This
would enable us to obtain the benefit of what-if analysis, the process of making changes and
seeing effects of those changes immediately. Such analysis gives the user an intuitive feel for
the problem. The role of the computer will be addressed in more detail in Chapter 9.
Reflection: Avoiding Analysis Paralysis
I’ve learned that engineering students love the stuff in this chapter; it resonates with
them.. I’ve also seen students get so involved in the analysis that they forget what it is they’re
analyzing, and why they’re doing it. Don’t get me wrong, analysis is important; but in
engineering, analysis must be purposeful, that is it must be focused on developing understanding
so that a decision can be made. Also, it’s essential to decide how good is good enough (which is
a really tough decision when we know that if we spend more time and resources we’ll get a
better answer).
References
Starfield, A.M., Smith, K.A., & Bleloch, A.L. 1994. How to model it: Problem solving for the
computer age. Edina: Burgess (Includes disk with Critpath and WinExp).
Questions
1. What is a “Work Breakdown Structure (WBS)”? What is it important? What are some
of the types of WBSs?
2. What is the Critical Path Method (CPM)? What are Free and Total Float?
3. Explain the differences between resource leveling and crashing a project.
4. How have you typically managed complex projects in the past? How well did the
approach work? Not all projects merit taking the time to develop a schedule as they can
be managed by a list, or by using your day planner. Where could you apply the Critical
Path Method and how do you expect it might help?
5. How does the CritPath program compare with other software packages you’ve used?
With a spreadsheet, for example?
6. What are some of the advantages and disadvantages of relying on project scheduling
algorithms?
Exercises
1. Work Breakdown Structure Example
Office Remodeling Project
The following activities must be accomplished to complete an office remodeling project:
Activity Estimated Duration (Days)
Procure Paint 2
Procure New Carpet 5
Procure New Furniture 7
Remove Old Furniture 1
Remove Old Carpet 1
Scrub Walls 1
Paint Walls 2
Install New Carpet 1

Move in New Furniture 1
Part 1: Work Breakdown Structure (WBS)
1. Create a possible Work breakdown structure (WBS) for the remodeling project.
Part 2: Scheduling
1. When can the new furniture be moved in?
2. What is the minimum project duration?
3. Which activities do you have to play close attention to if you want to finish at the earliest
possible time?
2. Resource Leveling Example. Given the following set of project, determine the
smoothest distribution of resources. Assume resources are transferrable.
Task Duration Resources Predecessor

1 7 8
2 5 6
3 4 4 2
4 2 4 1, 3
5 3 6 2
6 1 6 5
3. Crashing Example. Given the following project determine the “normal” schedule cost.
Crash the project as far as possible. List the project duration and cost for each step along
the way.
Task Precedence Normal Crash Time Normal Cost Incremental
Time Cost/Day
A - 5 3 500 300
B A 4 2 600 100
C A 6 4 1000 400
D B, C 3 2 300 200
4. Scheduling Case Study
Develop a Work Breakdown Structure, Precedence Network, and Gantt chart for a project you’re
involved with. Complete the Critical Path Analysis calculations. Use these representations to
guide the project and to review progress.
5. A Minnesota Dream Project – Lakeside Cabin Cost Estimate
Imagine you’ve just inherited a lakeside lot in Northern Minnesota (beautiful in the
summer) that has an access road, electricity, water and sewage disposal, and a modest sum with
which to buy building materials. If you’re having trouble imagining yourself being so lucky,
consider the possibility that a friend or neighbor asked you for an estimate on how much it
would cost to build a cabin and for help in designing and building. Engineers are often expected
to know such things! How much would it cost for a modest, say 24' square cabin? How long
would it take you to build it?
The cabin cost estimate project is a favorite of students in my project management
classes. Since we haven’t done too much with cost estimating (it’s usually done in engineering
economics courses), I’ll provide a little guidance. I suggest you:
1. Guess! Take a wild guess at what it would cost for materials for a modest cabin.
2. Look up the per square foot costs for typical residential construction ($50-70/ft2) and
adjust it down for a modest cabin. Many students use $30/ft2 for a modest cabin.
3. Use a unit cost approach:
1. Develop a floor plan
2. Create a detailed list of materials with associated quantities
3. Find the cost of the materials in a local building center brochure (or cost manual)
4. Use a spreadsheet to list and calculate the total cost of the materials.
4. Compare the three cost estimates – Guess, Cost/ft2, and Unit cost.
Use the procedures outlined in this chapter to determine how long it would take you to
build it, that is, develop a WBS and a schedule using the Critical Path method.
Chapter Seven: Project Monitoring and Evaluation
Two important parts of project management are keeping on top of projects through
monitoring and conducting end-of-the-project review through evaluation. There are may ways to
keep informed, keep others informed, and coordinate projects. Informal one-on-one meetings, e-
mail, phone conversations are the most common. Other simple forms include FAX, voice
messages, and handwritten notes. Emerging forms of communication include net meetings,
instant messaging (WWW, PDA and phone), web-based project discussion systems, such as
eProject. More involved forms of information exchange are groupware (such as Lotus Notes),
enterprise systems (such as Microsoft Project 2002 server version), informal reports, formal
memos and meetings, and formal presentations. Each has advantages and disadvantages.
Reflection. What’s your experience with face-to-face, phone, fax, e-mail, and handwritten
communications? Under what conditions do you prefer each? What’s your experience with web-
based information exchange – net meeting, instant messaging, web discussion. How well do
these work for you?
Tom Peters (1989) popularized the idea of management by wandering around (MBWA),
which has become an important aspect of most project managers’ daily lives. Effective project
managers stay in touch. More recently, Peters (1999) has said that “all work is project work”
and that individuals are identified and recognized by their project work.
This chapter begins by discussing meetings and progresses through successively more
complex ways to monitor the work of projects and teams before finishing with strategies for
evaluating projects.
Meetings
Although meetings are a principal way of keeping up-to-date, they are also one of the banes of
project managers and many others. Dressler (1996) lists some of the major complaints people
have about meetings:
• Their purpose is unclear
• Participants are unprepared
• Key people are absent or missing
• The conversation veers off track
• Participants don’t discuss issues but instead dominate, argue, or take no part at all
• Decisions made during the meeting are not followed up
Individual Reflection: Think about some of your best (and worst) experiences in meetings. How
do the complaints listed above compare with your experiences in meetings? What additionals
challenges have you encountered? What conditions contribute to best and worst experiences?
What are some of the strategies you use or have seen used to counter the worst experiences?
Five guidelines from the book Meetings: Do’s, Don’ts, and Donuts can help alleviate
some of the most common problems (Lippincott, 1994):
1. State in a couple of sentences exactly what you want your meeting to accomplish.
2. If you think a meeting is the best way to accomplish this, then distribute an agenda to
participants at least two days in advance.
3. Set ground rules to maintain focus, respect, and order during the meeting.
4. Take responsibility for the meeting’s outcome.

5. If your meeting isn’t working, try other tools, such as brainstorming.
Using a meeting process, such as the one outlined in The Team Handbook (Scholtes,
Joiner, & Streibel, 1996) also can help. The authors describe the three-part process as follows:
Before
Plan:
Clarify meeting purpose and outcome
Identify meeting participants
Select methods to meet purpose
Develop and distribute agenda
Set up room
During
Start:
Check-in
Review agenda
Set or review ground rules
Clarify roles
Conduct:
Cover one item at a time
Manage discussions
Maintain focus and pace
Close:
Summarize decisions
Review action items
Solicit agenda items for next meeting
Review time and place for next meeting
Evaluate the meeting
Thank participants
After
Follow-up:
Distribute or post meeting notes promptly
File agendas, notes, and other documents
Do assignments.
The box, “How to Run a Meeting” also provides good advice for running effective
meetings. This advice is based on a popular training video in which the main character is
subjected to an inquisition for running a poor meeting.
Emerging ideas in this area seem to be virtual meetings. John Leeper, I.S. Director at
Ryan Construction, reported recently that

How to Run a Meeting
Ryan Construction is making extensive use (Adapted from “Meetings, Bloody Meetings” starring
John Cleese, 1993)
of Webex for meetings (Leeper, 2002).
Plan the Meeting
• Be clear on objectives of the meeting
Monitoring Team Effectiveness • Be clear WHY you need the meeting
• List the topics to be addressed
An important part of any team
Inform
• Make sure everyone knows exactly what is
meeting is taking time to reflection on how being discussed, why and what you want
from the discussion
well the team worked together. One common • Anticipate what people and information may
be needed and make sure they are there
methods for monitoring the effectiveness of
Prepare
• Prepare the logical sequence of items
group work is the plus/delta (+/Î) team • Allocate time on the basis of importance, not
its urgency
processing approach typically attributed to Structure and Control
• Put all evidence before interpretation and
Boeing. Near the end of the meeting the action
• Stop people from jumping back and going
team stops working on the task and spends a over old ground
Summarize and Recall

few minutes discussing how well they • Summarize all decisions and record them
with the name of the person responsible for
worked. The team makes a list that records any action
what when well on one side (+) and what
they could do even better on the other (Î). Other methods include individual reflection using
instruments such as Uhlfedler’s (1998) and then discusses each members’ observations.
[Text Box]
Figure 7.1 Sample Individual Reflection Instrument
For each trait, rate the team on a scale of 1 to 5:
1 = Not present (opposite trait present)
2 = Very poor (not much evidence of positive trait)

3 = Poor (some positive trait seen)
4 = Good (positive trait evident more than opposite trait)
5 = Very good (large amounts of evidence of positive trait)
Positive Trait Score Comments

Safety – how secure and
comfortable are you in the
team; especially around
speaking up?
Inclusion – how included to
you feel?
Free interaction – are team
members interactive freely?
Appropriate level of
interdependence
Cohesiveness – are you
working “as one”?
Trust
Conflict resolution
Influence – are you able to
influence the team?
Accomplishment
Growth
Source: Uhlfedler (1997)
More complex processing involves collecting data on individual participation in the team.
Several observation forms are available. The one I start students with in my project management
classes is shown in Figure 7.2. Any of the task and maintenance behaviors (from Chapter 3) may
be listed in the rows. Group members take turns observing the group and recording each
member’s participation. They then provide feedback about the team’s functioning during the
processing phase. A rule-of-thumb that I commonly use is “Keep the feedback specific,
descriptive, immediate, and POSITIVE.” I follow the recommendation to give negative
feedback only if the person requests it. If negative feedback is requested, person is usually
ready to hear it Only then will it be helpful. More rules-of-thumb for feedback include the
following (adapted from Scholtes, 1988):
[Text Box]
Guidelines for Constructive Feedback
! Acknowledge the need for feedback

! Give positive feedback (Only give negative feedback if the recipient asks for it)
! Understand the context
! Know when to give feedback
! Know how to give feedback
! Be descriptive
! Don't use labels
! Don't exaggerate
! Don't be judgmental
! Speak for yourself
! Talk first about yourself, not about the other person
! Phrase the issue as a statement, not a question
! Restrict your feedback to things you observed
! Help people hear and accept your compliments when giving positive feedback
OBSERVATION SHEET
Observation Names: Total
Category
Task
(Contributes Ideas)
Maintenance
(Encourages)
Total
Notes:
Observation Directions:
• Move your chair so you can see each member of the group clearly without interacting with them.
• Write the name of each person in the group at the top of one of the columns on the Observation Sheet.
• Watch each person systematically. As you see each person display one of the two behaviors specified
(contributes ideas or describes feelings) place a hatch mark below his/her name, in the box to the right of
the appropriate behavior.
• Task means anything that helps the group accomplish its task. For example, Contributes ideas means
giving an idea related to one of the questions on the worksheet and/or to something said by another group
member related to the task.
• Maintenance means anything that helps improve working relationships in the group. Encourages means
praising others ideas or inviting others to contribute.
• You may make some notations below the grid that may help you explain some scoring.
• When time is called, total the hatch marks in each column and across each row.
• When you give feedback to the group you will only give them the column totals and the row totals. Let
them see the sheet. DO NOT INTERPRET WHAT YOU SAW, OR WHAT THE TOTALS MIGHT
SUGGEST. You may be tempted to soften what you say. Don't allow this to happen. You are not
criticizing, you are only reporting what you saw, related to very specific behaviors.
• It is the job of the group to discuss what the totals might suggest about how they functioned as a group, and
to develop one or two sentences that capture this thought.
The idea of observing teams in action and trying to document their interactions and
effectiveness is not only used as a research approach (Bucciarelli, 1996; Cuff, 1991; Donnellon
1996; Minneman, 1991; Seely Brown and Duguid , 1991; Wenger and Snyder, 2000) but is also
common in business and industry. An industry approach that I’ve found very useful was
developed by Xerox and is included in their interactive skills workbook (Xerox Corporation,
1986). Their Interactive Skills Coding Worksheet is shown in Figure 7.3. The second part of the
figure provides definitions and examples of behavior categories in the worksheet..

Figure 7.3 Xerox -- Interactive Skills Coding Worksheet
Behavior Totals %
Initiating
Proposing
Building
Reacting
Supporting
Disagreeing
Defending/
Attacking
Clarifying
Testing
Understanding
Summarizing
Seeking
Information
Giving
Information
Totals
Process
Shutting Out
Bringing In
Table 7.3 Continued Xerox Interactive Skills Worksheet -- Definitions and Examples
Behavior Category Definition Examples

Proposing A behavior that puts forward a “Let’s deal with that one
new suggestion, proposal, or tomorrow”
course of action.
“I suggest we add more
resources to . . .”
Building A behavior that usually takes “. . .and your plan would be
the form of a proposal, but that even better if we added a second
actually extends or develops a reporting stage”
proposal made by another
person. “If I can take that further, we
could also use the system to
give us better cost control.”
Supporting A behavior that makes a “Yes, I go along with that.”
conscious and direct declaration
of agreement with or support for “Sounds OK to me.”
another person, or for their
concepts and opinions. “Fine.” “I accept that.”
Disagreeing A behavior that states a direct “No, I don’t agree with that.”
disagreement or which raises
obstacles and objections to “Your third point just isn’t
another person’s concepts or true.”
opinions. Disagreeing is about
issues. “What you’re suggesting won’t
work.”
Defending/ A behavior that attacks another “That’s stupid.”
Attacking person, either directly or by
defensiveness. Defending/ “. . .and your third point is
attacking usually involve value either stupid or an out-and-out
judgments and often contain lie.”
emotional overtones. They are
usually about people, not issues. “Don’t blame me, it’s not my
fault; it’s John’s responsibility.”
Testing A behavior that seeks to “Can I just check to be sure
Understanding establish whether or not an we’re talking about the same
earlier contribution has been thing here?”
understood. It differs from
seeing information in that it is “Can I take it that we all now
an attempt to ensure agreement agree on this?”
or consensus of some kind, and
refers to a prior question or
issue.
Summarizing A behavior that summarizes or “So far, we have agreed

restates, in a compact form, the (a) To divide responsibilities,
content of previous discussions (b) To meet weekly
or events. (c) To finish the draft proposal
by . . .”
Seeking A behavior that seeks facts, “What timeline did we agree
Information opinions, or clarification from to?”
another person.
“Can anyone tell me what page
that table is on?”
“Have you checked that

thoroughly?”
Giving A behavior that offers facts, “I remember a case like that last
Information opinions, or clarification to year.”
other people.
“There are at least three
alternatives.”
Bringing In* A behavior that invites views or “Dick, have you anything to say
opinions from a member of the on this one?”
group who is not actively
participating in the discussion. “Cheryl has been very quiet. I
wonder whether she has
anything she would like to say
here.”
Shutting Out* A behavior that excludes Jose: “What do you think,
another person or persons, or Bob?”
reduces their opportunity to
contribute. Interrupting is the Karl: “What I think is. . .”
most common form of shutting
out. (Karl is shutting out Bob)
*Characteristic of a process behavior.
The purpose of collecting data on team functioning by observing and other means is not
only to provide data for monitoring but also to help each member learn how to attend to how the
team is performing. Even if you don’t have an opportunity to systematically observe a team,
read the definitions and examples in Figure 7.3 and think about how you can expand your
repertoire of behaviors.
Team Talk Analysis
An even more sophisticated approach to processing the work of teams was developed by
Donnellon (1996) who claims (along with a growing chorus) that “Not all groups are teams.”
Although, as I mentioned in Chapter 2, the words group and team are often used
interchangeably, it is important to distinguish between the gathering of people into groups and
the purposeful formation of a team. A team, according to Donnellon, 1996, is “a group of people
who are necessary to accomplish a task that requires the continuous integration of the expertise
distributed among them” (p. 10).
Donnellon studied team talk and devised six dimensions along which to assess teams:
identification (with what group team members identify), interdependence (whether team member
fell independent from or interdependent with one another), power differentiation (ow much team
members use the differences in their organizational power), social distance (whether team
members feel close to or distant from one another socially), conflict management tactics
(whether members use the tactics of force or collaboration to manage their conflicts), and
negotiation process (whether the team uses a win-lose or a win-win process). Donnellon then
used these dimensions to differentiate between nominal teams and real teams, as shown in Table
7.1
Table 7.1 Nominal versus real teams
Nominal Team Real Team

Identification Functional group Team
Interdependence Independence Interdependence

Power differentiation High Low
Social distance Distant Close
Conflict management tactics Forcing, accommodating, Confronting, collaborating
avoiding
Negotiation process Win-lose Win-win
The dimensions shown in the table are consistent with the underlying conceptual
framework in this book – the importance of interdependence, low power differentiation, close
social distance (trusting relationships), constructive conflict management strategies, and win-win
dynamics . I encourage you to examine the groups and teams you’re in along these dimensions.
Donnellon’s team talk audit for assessing team dynamics is included in her book. Use this
instrument to attend to the team talk, reflect on what it tells you about the team, and then plan
how you will discuss the assessment with the team.
Donnellon described five types of teams based on the categorization in her six
dimensions. In Table 7.2, I’ve summarized some of the more direct paths. Think about where
your team fits.

Table 7.2 Team Talk Dimensions
Identification Inter- Power Social Negotiation Conflict Profile
dependence Differentiation Distance Management
Team High Low Close Win-Win Collaborative Collaborative
Team Moderate Low Close Win-Win Force-Avoid Mostly
Collaborative
Team Moderate High Close Emergent
Both High High Distant Win-Lose Force-Avoid Adversarial
Both Low High Distant Win-Lose Force-Avoid Adversarial
Function Low Low Distant Nominal
Function Low - High Distant Win-Lose Force-Avoid Doomed
Independence
Donnellon’s work indicates that there are very few paths to collaborative team profiles, a
conclusion borne out in the work by Katzenbach & Smith (1993), and Bennis & Beiderman
(1997), whose case studies note that very few teams perform at the highest levels. With these
dimensions in mind, carefully examine your group and team experiences and then explicitly
discuss the performance (functioning) of your team to help you decide (1) to leave if your team
is doomed, (2) refine the team if you’re in the middle, or (3) celebrate and continue performing if
you’re a collaborative team.
Using the monitoring and processing formats described above to systematically reflect on
the group’s performance on both the task and their work with one another by the processing
formats described above will help the group achieve it’s goals and help the members get better at
working with one another. Group processing takes time and commitment and is typically
difficult for highly motivated, task oriented individuals. A little bit of carefully structured time
spend on how the group is functioning can make an enormous difference in the group’s
effectiveness and quality of the working environment.
Peer Assessment
Peer assessment, a process of rating other team members, often anonymously, is
becoming more common in engineering teams. One of the best resources for peer assessment is
The team developer (McGourty and De Meuse, 2001). The authors use an anonymous computer-
based peer assessment system where each individual rates each of the other team members in
four team effectiveness dimensions – communication, decision making, collaboration, and self-
management – using a 1 to 5 scale. -point. Each member then has access to his or her self rating
as well as the overall average for the team. McGourty and De Meuse stress the importance of
using the information for development. They recommend that the individual and the team focus
on using the information to help them improve and solve problems.
Peer assessment has also been used in merit review (as in annual merit review, that is,
raises and promotions). The most common system is the 360-degree evaluations that were used
extensively at GE (Welch and Byrne, 2001). GE abandoned the 360s because “Like anything
driven by peer input, the system is capable of being ‘gamed’ over the long haul. People began
saying nice things about one another so they would all come out with good ratings” (p. ?). GE
currently uses 360s only in special situations. Peer assessment of team members is subject to the
same concern – everyone might be too nice and give others a high rating, which makes the
assessment of limited value for improvement. Effective development results from a climate for
improvement that may be facilitated by peer assessment, but it needs to be used with real care.
Project Evaluation
At the end of a project it is important, and often a requirement, to conduct an evaluation.
Typically a set of project evaluation questions guides this process. The following, generated by
Haynes (1989), is a typical set of questions:
1. How close to scheduled completion was the project actually completed?
2. How did we learn about scheduling that will help us on our next project?
3. How close to budget was final project cost?
4. What did we learn about budgeting that will help us on our next project?
5. Upon completion, did the project output meet client specifications without additional work?
6. If additional work was required, please describe:
7. What did we learn about writing specifications that will help us on our next project?
8. What did we learn about staffing that will help us on our next project?
9. What did we learn about monitoring performance that will help us on our next project?
10. What did we learn about taking corrective action that will help us on our next project?
11. What technological advances were made?
12. What tools and techniques were developed that will be useful on our next project?
13. What recommendations do we have for future research and development?
14. What lessons did we learn from our dealings with service organizations and outside
vendors?
15. If we had the opportunity to do the project over, what would we do differently?
Continual Evaluation
Evaluation doesn’t have to occur only at the end of the project; it is often initiated when a
project falls behind schedule or goes over budget. My recommendation is that evaluation be an
integral part of the project. How often have you been involved in group projects that got behind
schedule or use more resources that were initially allocated?
Individual Reflection: How have you dealt with projects that get behind schedule or require more
resources that were initially allocated? What are some of the strategies you’ve used? Take a few
minutes and reflect on dealing with delays and cost overruns.
There are lots of internal things you can do with your project team to address delays and
resource excesses. Sometimes it’s necessary to try to change external conditions to address
delays and overruns. Here’s a list of some things you can do:
1. Recover later in the project. If there are early delays or overruns, review the schedule and
budget for recovery later. This is a common strategy in many projects. How often have you
done extraordinary work at the last minute, especially the night before the project is due?
2. Reduce project scope. Consider eliminating nonessential elements or containing scope
creep. Engineers often find better ways of doing things during projects and are sometimes
perfectionists, so there is a tendency for the scope to creep.
3. Renegotiate. Discuss with the client the possibility of extending the deadline or increasing
the budget. How often have you asked a professor for an extension? This is a common
strategy, but sometimes there is not flexibility.
4. Add additional resources. Adding more resources -- people, computers, and so on -- to a
project (activities along the critical path as you learned in Chapter 6) can reduce the
duration. The increased costs must be traded off with the benefits of the reduced schedule.
5. Offer incentives or demand compliance. Sometimes by offering incentives (provided you
don’t endanger peoples’ lives or sacrifice performance specifications) you can get a project
back on track. Other times you may have to demand that people do what they said they
would do.
6. Be creative. If the delay is caused by resources that have not arrived, you may have to
accept substitutions, accept partial delivery, or seek alternative sources.
Building Quality Into Projects
Evaluation and continual improvement often becomes an ongoing part of projects and
company culture. Often this aspect of company or organizational culture is described as a
quality initiative. Table 7.3 provides a set of insightful contrasts about old and new thinking
about quality.
Table 7.4 -- Thinking About Quality
Old New
Competition motivates people to do better Cooperation helps people do more effective
work work
For every winner there's a loser Everyone can win
Please your boss Please your customer
Scapegoating pinpoints problems Improve the system
Focus improvements on individual processes Focus on the purpose of the overall system,
and how the processes can be improved to
serve it better
Find the cause and fix the problem First, acknowledge there is variation in all
things and people. See if the problem falls in
or outside the system
The job is complete if specifications have Continual improvement is an unending
been met journey
Inspection and measurement ensure quality A capable process, shared vision and aim,
good leadership and training are major factors
in creating quality
Risks and mistakes are bad Risks are necessary and some mistakes
inevitable when you practice continual
improvement
You can complete your education Everyone is a lifelong learner
Bosses command and control Bosses help workers learn and make
improvements
Bosses have to know everything The team with a good leader knows and can
do more
Short-term profits are best Significant achievement in a complex world
takes time
You don't have to be aware of your basic You must be conscious of your beliefs and
beliefs constantly examine and test them to see if
they continue to be true
Do it now Think first, then act
Source: Dobyns and Crawford-Mason. 1994.
Engineers are often required to help develop a quality initiative in their organization. Have
you been involved in a quality initiative in your work or school? Although there has been some
attention paid to quality in schools (see Langford & Cleary, 1995, for example), much of the
emphasis on quality has been in the workplace. Business and industry has taken the lead, as
indicated for example by Ford Motor’s Company’s motto “Quality is Job One.”
Some quality basics include a systems perspective, emphasis on the customer, and
understanding variation. Knowledge of sources of variation, especially ways of measuring and
documenting them; and strategies for reducing variability and maintaining consistent quality is
essential.
The current quality movement started with the work on W. Edwards Deming in the 1940s
and progressed through a series of initiatives – Continuous Quality Improvement (CQI), Total
Quality Management (TQM), and presently, Six Sigma. Each successive phase seems to provide
enhanced features for focusing on quality. The essential themes of Six Sigma are (Pande,
Neuman, and Cavanagh, 2000):
• A genuine focus on the customer

• Data- and fact-driven management
• Process focus, management and improvement, as an engine for growth and success
• Proactive management
• Boundaryless collaboration
• A drive for perfection, and yet a tolerance for failure
Another central feature of Six Sigma is the DMAIC Six Sigma improvement model – Define,
Measure, Analyze, Improve, Control. Many of the students (especially those who work for 3M,
Honeywell, Seagate, Medtronic, and so forth) in the Management of Technology master’s
program course I teach have a copy of Rath & Strong’s Six Sigma Pocket Guide in their bag.
Rath and Strong (2000) is based on the DMAIC model.

Further reading on quality is contained in the references by Deming (1993, 1996), Bowles &
Hammond (1991), Dobyns & Mason (1994), Brassand (1989), Saskin & Kiser (1994), and
Walton (1986). You may also want to consult a basic textbook on quality, such as Summers
(1997).
Reflection: Paying Attention
I am often reminded of the advice of the talking mynah birds in Aldous Huxley’s Island
(Huxley, 1962). These birds periodically called out “Attention, attention; Here and now.” Huxley
is emphasizing awareness, as indicated in the following dialogue: "Listen to him closely, listen
discriminatingly. [...]" Will Farnaby listened. The mynah had gone back its first theme.
"Attention," the articulate oboe was calling. "Attention." "Attention to what?" he asked, in the
hope of eliciting a more enlightening answer than the one he had received from Mary Sarojini.
"To attention," said Dr. MacPhail. “Attention to attention?” “Of course.” (page 16). We often get
so wrapped up in achieving our goals and completing our tasks that we forget to pay attention to
what’s going on around us. My sense is that successful project managers have refined their skills
for paying attention.
References
Bowles, J. & Hammond, J. 1991. Beyond quality: How 50 winning companies use continuous
improvement. New York: Putnam
Brassand, Michael. 1989. The memory jogger plus+: Featuring the seven management and
planning tools. Methuen, MA: GOAL/QPC.
Brown, John Seely and Duguid, Paul. 1991. "Organizational learning and communities-of-
practice: Toward a unified view of working, learning, and innovation". Organizational Science,
2 (1), 40-56.
Bucciarelli, Louis, L. 1996. Designing engineers. Cambridge, MA: MIT Press.
Cuff, Dana. 1991. Architecture: The story of practice. Cambridge, MA: MIT Press.
Deming, W.E. 1993. The new economics for industry, government, education. Cambridge, MA:
MIT Center for Advanced Engineering Study.
Deming, W.E. 1986. Out of crisis. Cambridge, MA: MIT Center for Advanced Engineering
Study.
Dobyns, Lloyd & Crawford-Mason, Clare. 1994. Thinking about quality: Progress, wisdom,
and the Deming philosophy. NY: Times.
Donnellon, Anne. 1996. Team talk: The power of language in team dynamics. Cambridge,
MA: Harvard Business School Press.
Dressler, C. 1996. Cited in Lewis, J.P. 1998. Team-based project management. New York:
AMACOM.
Haynes, M.E. 1989. Project management: From idea to implementation. Los Altos, CA: Crisp
Publications.
Huxley, Aldous. 1962. Island. New York: Harper and Row Perennial Classic.
Langford, David P. & Cleary, Barbara A. 1995. Orchestrating learning with quality.
Milwaukee: ASQC Quality Press.
Leeper, John. 2002. Personal communication. November 7, 2002.
Lippincott, S. 1994. Meetings: Do’s, don’ts, and donuts: The complete handbook to successful
meetings. Pittsburgh: Lighthouse Point Press.
McGourty, Jack and De Meuse, Kenneth P. 2001. The team developer: An assessment and skill
building program. New York: Wiley.
Minneman, Scott. 1991. The social construction of a technical reality: Empirical studies of
group engineering design practice. Xerox Corporation Palo Alto Research Center Report SSL-
91-22.
Pande, Peter S., Neuman, Robert P. and Cavanagh, Roland D. 2000. The six sigma way: How
GE, Motorola and other top companies are honing their performance. New York: McGraw-Hill.
Peters, Thomas J. 1989. A passion for excellence. (With Nancy Austin). New York: Knopf.
Peters, Thomas J. 1999. The WOW project: In the new economy, all work is project work. Fast
Company, Issue 24, May, 116-128.
Rath and Strong. 2000. Six sigma pocket guide. Lexington, MA: Rath & Strong Management
Consultants.
Sashkin, Marshall & Kiser, Kenneth J. 1993. Putting total quality management to work. San
Francisco: Berrett-Koehler.
Scholtes, P.R., Joiner, B.L. & Streibel, B.J. 1996. The team handbook. Madison: Joiner
Associates. Also see: The team memory jogger: A pocket guide for team members. 1995.
GOAL/QPC and Joiner Associates.
Summers, Donna C.S. 1997. Quality. Upper Saddle River, NJ: Prentice-Hall.
Uhlfedler, H. 1997. Ten critical traits of group dynamics. Quality Progress, 30(4), 69-72.
Walton, M. 1986. The Deming management method. New York: Putnam.
Welch, John F., Jr and Byrne, John A. 2001. Jack: Straight from the gut. New York: Warner.
Wenger, E. and Snyder, W. 2000. Communities of practice: The next organizational frontier.
Harvard Business Review, Jan./Feb.
Xerox Corporation. 1986. Leadership through quality: Interactive Skills Workbook. Stamford,
CT: Xerox Corporation.
Questions
1. Where did you develop skills for monitoring the work on project teams? Have you had an
opportunity to observe a project team? If so, where? What did you learn from the
experience? Do you try to attend to what’s happening within the group while it is working?
2. What can you do to improve the functioning of teams during “boring and useless” meetings?
List things you can do and strategies for doing them. Try them out!
3. Check out some of the ethnographic research on work in organizations, such as John Seely
Brown and Paul Duguid’s Organizational knowledge and communities-of-practice: Toward
a unified view of working, learning, and innovation; Organizational Science, 2(1), 1991, pp.
40-57. The paper is also available on the Xerox Palo Alto Research Center web site. How
does research affect your view of work in organizations?
4. What are some strategies for building quality into projects?
5. How can project evaluation, which is often seen as a punitive process, become a more
positive and constructive process? What are things that project team members and
managers can do to make evaluation an ongoing part of project work?

Chapter Eight: Project Management Documentation and Communications
“A horse, a horse! My kingdom for a horse.” Richard III cried in Shakespeare’s play of the
same name. Although most of us no longer need horses to travel, we need good documentation
for successful projects; lest we cry “Good documentation, good documentation; my career for
good documentation!”
This chapter is organized into two sections – Project Documentation and Project
Communications. Project documentation is stressed because it is often neglected and there are
many other fine resources for project communication (i.e., reports and presentations), such as A
Beginners Guide to Technical Communication by Anne Eisenberg (1998).
Project Documentation
Why are project documentation and record keeping important? To answer you only have to
think about a time you had to pick up the pieces from a team member and pull them together into
a report or presentation. Was everything easy to follow and understand, or did you have to fill in
or reconstruct much of the work?
Problem solving, especially if it involves developing a computer program, is particularly
susceptible to gaps in documentation. Think about how well you’ve documented projects
you’ve been involved in. Did you insert lots of comments in your programs or spreadsheets to
let the next user know what you’d done and why?
Many of the problem-solving and program-writing assignments students hand in lack
sufficient documentation; thus, the faculty member cannot assess whether the procedures are
correct (even if the answer isn’t). The lack of documentation makes is very difficult for faculty
to grade the report. In engineering practice, poor documentation may make it difficult for a client
to understand the work, and may, therefore, jeopardize future contracts.

Project documentation is important because, as Leifer’s (1997) research at the Stanford
University Center for Design Research indicates, “all design is redesign” and the more
information and insight you provide those who follow you, the better job they will be able to do.
Of course, this works for you, too, when you follow up on someone else’s work.
Reflection: Take a few minutes to think about the types of project records that should be kept?
Make a list. Next, think about the characteristics of good records. List several attributes of good
records. Compare your list with team members.
What did you come up with? How easy or hard was it for you to think about types of
documents and the characteristics of good documentation?
Many engineers prefer to focus on solving the problem, developing the product, or just
getting the job done rather than on documentation, which they see as a necessary (and often
unpleasant) burden.
For comparison, here are lists that were developed by the participants in the Minnesota
Department of Transportation Project Management Academy:
[box]
Types of Records Photographs/videotape
Formal Notes - personal & meeting
Specifications Incident reports
Drawings Telephone/e-mail/FAX memos and notes
Schedule Commitment logs
Budget Change orders
Contract On-site log –
date/weather/time/personnel/equipment
Informal
Survey notes
Inspection reports
Characteristics of “good” records: right media

easily accessible consistent format
thorough – date & time, client secure
organized and legible cost effective
comprehensive – table of contents flexible
Nearly two hundred forms were recently compiled by the Project Management Institute
(PMI) in a book titled Project management forms (Pennypacker, Fisher, Hensley & Parker,
1997). PMI members shared their forms, checklists, reports, charts, and other documents to help
you get started or to improve your current documentation. More information is available on the
PMI web site (www.pmi.org).
Laboratory Notebook/Academic Journal
Notebooks and journals are terrific ways to document work for your own personal use, and
there are many examples of their significance in patent applications or even Nobel Prize
considerations. Think, for example how the notebooks of Charles Kettering (inventor of auto
electric cash register and automobile ignition systems) and Shockley, Brattain, and Bardeen
(inventors of the transistor) helped establish intellectual property rights. Also consider Bill
Gates recently paid $30 million for Leonardo da Vinci’s Codex Leicester, one of da Vinci’s
surviving journals.
Students in ERG 291, a freshman design course at Michigan State University, are required
to keep a Laboratory Notebook/Academic Journal. The box “Academic Journal” includes a
description of the documentation requirements.

Academic Journal2
Suggestions for Using Academic Journals [with additional notes on using a journal with
EGR291 Engineering Design]
What is a Journal? A journal is a place to practice writing and thinking. It differs from a
diary in that it should not be merely a personal recording of the day's events. It differs from your
class notebook in that it should not be merely an objective recording of academic data. Think of
your journal rather as a personal record of your educational experience in this class. For
example, you may want to use your journal while working on a design project to record
reflections on the class.
What to Write. Use your journal to record personal reactions to class, topics, students,
teachers. Make notes to yourself about ideas, theories, concepts, problems, etc. Record your
thoughts, ideas, and readings, and to argue with the instructor, express confusion, and explore
possible approaches to problems in the course. Be sure to include (1) critical incidents that
helped you learn or gain insight, and (2) distractions that interfered with your learning.
When to Write. Try to write in your journal at least three or four times a week. . .aside from
classroom entries. It is important to develop the habit of using your journal even when you are
not in an academic environment. Good ideas, questions, etc., don't always wait for convenient
times for you to record them. [A man would do well to carry a pencil in his pocket and write
down the thoughts of the moment. Those that come unsought for are the most valuable and
should be secured because they seldom return. Francis Bacon (1561-1626)].
How to Write. You should write in a style that you feel most comfortable with. The point is
to think on paper without worrying about the mechanics of writing. The quantity you write is as
important as the quality. The language that expresses your personal voice should be used.
Namely, language that comes natural to you.
Suggestions:
1. Choose a notebook you are comfortable with. A 8½” x 11" hardback bound book with
numbered pages would be a good choice.
2. Date each entry including time of day.
3. Don't hesitate to write long entries and develop your thoughts as fully as possible.
4. Include sketches and drawings.
5. Use a pen.
6. Use a new page for each new entry.
7. Include both "academic" and "personal" entries; mixed or separate as you desire.
Interaction--Professor. I'll ask to see your journal at least twice during the term: I'll read
selected entries and, upon occasion, argue with you or comment on your comments. Mark any
entry that you consider private and don't want me to read and I'll gladly honor your request. A
good journal will contain numerous long entries and reflective comments. It should be used
regularly.
Interaction--Correspondent. Choose a fellow student in your close collection of friends to
read and respond to your journal entries.
2
Adapted from Fulwiler, T. 1987. Teaching with writing. Portsmouth, NH: Boynton/Cook Publishers.
Revised by B.S. Thompson in consultation with K.A. Smith and R.C. Rosenberg, 1998.
Conclusions. Make a table of contents of significant entries. At the end of the semester
write an two-page. In addition, submit an evaluation of whether the journal enhanced or
detracted from your learning experience. Was it worth the effort?
Chapter Seven of Understanding Engineering Design (Birmingham, Cleland, Driver and
Maffin, 1997), Information in design, begins with the following sharply focused statement on the
importance of information: “The raw material of the design process is information, and therefore
the designer’s principal skill is one of information handling” (p. 108). The authors stress five
categories of action that operate on information:
1. Collection
2. Transformation
3. Evaluation
4. Communication
5. Storage
Furthermore they stress that these categories are used at all stages of the design process.
One of the challenges of personal notebooks and journals is that they are not easily
shareable. Lack of easy access to others’ work and thinking makes for considerable problems in
team-based project work. Larry Leifer and his colleagues at Stanford have devised an electronic
notebook that is accessible on the World Wide Web. The Personal Electronic Notebook with
Sharing) (PENS) (Hong, Toye & Leifer, 1995)) supports and implements www-mediated
selective sharing of one’s working notes. Electronic mail is another common form of sharing
thinking about projects. Numerous software products, such as Lotus Notes, provide a means for
sharing information electronically. Electronic calendars and personal data assistants (PDA)
often have features for jointly scheduling meeting by viewing others’ calendars. PDAs and
electronic calendars also provide excellent means for keeping records. The image in Figure 8.1a
is from the desktop interface of my electronic calendar, a Palm Pilot. I’m currently using a Palm
Figure 8.1b Palm Desktop ca. 2003
Figure 8.1a Palm PDA Desktop View ca. 1998
IIIc to organize and keep track of appointments, addresses, and my ToDo list (See Figure 8.1b).
Take a look a the changes in the user interface, especially how the number of mouse clicks
has been reduced to navigate among the different calendar views – day, week, month, and year.
Part of this is due presumably to the improvement of screen resolution (VGA to XGA, etc) and
to improved user interface design.
In addition to having several calendar options, it also has an address book, to do list, memo
pad, and expense section. PDA’s such as the Palm provide for portability, backing up, and
electronic sharing. In addition, all of the sections may be quickly searched which makes for easy
information retrieval. They will likely become an essential tool for project managers and is
currently being used on construction projects (Roe, 2001). Computer-based tools in Chapter 9
are discussed further in Chapter 9.
Project Communications
Presenting our ideas to others both in written and oral form is essential to successful
projects. You may, however, feel a combination of excitement and anxiety about report writing
and public presentation.
Some of the best advice I ever got on presentations is included in a required undergraduate
textbook , Houp and Pearsall’s Reporting Technical Information – “Know your audience; Know
your objective; Be simple, concise and direct.” (Swain, 1945). This brief section follows that
advice.
Communications need to be tailored to the recipients whether they be your colleagues on the
team, your supervisor, or your client. Common ways to tailor communications are to learn more
about the recipients through surveys, interviews, or informal conversations.
Reflection: Take a minute to reflect on some possible objectives in a presentation or report. Try
to think beyond “Because it’s an assignment in this class.” As much as possible tie your list to
actual experiences that you’ve had. If you have a chance discuss these with other team
members.
One of the best references on simple, concise and direct writing is Stunk & White’s (1979)
The elements of style. One of my favorites is Williams’ (1997) Style: Ten lessons in clarity and
grace.
Getting started, keeping going
A practice commonly called freewriting may help you get over the barrier that many of us
face when writing or preparing for an oral presentation. A helpful implementations of
freewriting is Natalie Goldberg’s advice for “writing practice” in her book Writing down the
bones: Freeing the writer within (Goldberg, 1986).
1. Keep your hand moving. (Don't pause to reread the line you have just written. That's
stalling and trying to get control of what you're saying.)
2. Don't cross out. (That is editing as you write. Even if you write something you didn't mean
to write, leave it.)
3. Don't worry about spelling, punctuation, grammar. (Don't even care about staying within
the margins and lines on the page.)
4. Lose control.
5. Don't think. Don't get logical.
6. Go for the jugular. (If something comes up in your writing that is scary or naked, dive right
into it. It probably has lots of energy.)
Revising and Refining
After you complete a draft of your paper or presentation I encourage you to share it with
others. Many papers and reports must undergo a formal review process, but I recommend that
you offer your work for informal review with a colleague or friend. Although it’s hard for many
of us to share our work with others before we feel it is ready, we can often save a lot of time and
get much better products but asking others for comments.
At some stage in the process, of course, you must “freeze the design” and submit the report
or give the presentation. Be sure to solicit feedback (in a constructive mode), reflect on it, and
consider changes for the next time you write a report or give a presentation.
Leaving an excellent paper and electronic record is likely to increase in importance in
projects and project management. Now is the time to develop skills and strategies for effective
documentation. Similarly, communicating effectively both orally and in writing will continue to
be extremely important for project success.
Reflection: Documentation
During the twenty or so years I worked in an engineering research lab I was required to keep
a laboratory notebook. Although I had kept a notebook as a graduate student, I was struck by the
seriousness and formality of the lab’s research notebooks. Laboratory notebooks were numbered
and signed out. Each page was numbered and had a duplicate page (for a carbon copy).
Duplicate pages were collected periodically and filed in a safe place. My mentor in this process,
Dr. Iwao Iwasaki, would ask me to notarize his signature every week or so. This was to certify
the date and signature for intellectual property rights and for eventually filing patent disclosures,
and applying for patents. Several of the ideas he, and later I, signed off on were developed as
patent disclosures. Dr. Iwasaki’s ideas and research earned him membership in the National
Academy of Engineering, the United States’ most prestigious engineering organization. It was
always difficult for me to take the time to write everything down, but it made a huge difference
when we were working on reports and publications and were trying to figure out exactly what we
did and what we found. The notebooks were much better than my memory.
In terms of report preparation I recommend that you get a copy of a good technical
communications book, such as the ones I described above (I’ve used Hoop and Pearsall (?)
throughout me career) and use it every time you work on a report writing assignment.
References
Birmingham, R., Cleland, G., Driver, R., & Maffin, D. 1997. Understanding engineering
design: Context, theory and practice. London: Prentice Hall Europe.
Eisenberg, A. 1998. A beginners guide to technical communication. New York:
WCB/McGraw-Hill.
Goldberg, N. 1986. Writing down the bones: Freeing the writer within. Boston: Shambhala.
Hong, J., Toye, G., & Leifer, L. 1995. Personal Electronic Notebook with Sharing. In
Proceedings of the IEEE Fourth Workshop on Enabling Technologies: Infrastructure for
Collaborative Enterprises (WET ICE). Berkeley Springs, WV.
Houp, Kenneth W. and Pearsall, Thomas E. Reporting technical information. New York:
Macmillian.
Pennypacker, James S., Fisher, Lisa M., Hensley, Bobby, and Parker, Mark. 1997. Project
management forms Project Management Institute.
Roe, Arthur G. 2001. Handhelds hold up well for variety of site uses. ENR: Engineering News-
Record, 247 (19), 31-32.
Thompson, B.S. 1997. Creative Engineering Design. Okemos, MI: Okemos Press.
Stunk, Jr., W. & White, E.B. 1979. The elements of style, 3rd edition. New York: Macmillan.
Swain, Philip W. 1945. Giving power to words. American Journal of Physics, 13 (5), 320.
Williams, J. M. 1997. Style: Ten lessons in clarity and grace. New York: Longman.
Questions
1. What is your experience documenting group projects? Is it a routine activity? If so,
describe examples of “excellent documentation.” If not, consider how can you build the
development of good documentation into the on-going process of project work.
2. What are some of the types of records that must be maintained for projects? What are the
characteristics of “good” records”
3. What is your experience with electronic documentation? What are the advantages and
disadvantages of electronic records (compared with paper records)?
4. Describe the characteristics of good presentations? Are “good” presentations the norm in
your experience? Why or why not?
5. Describe your experiences keeping an Academic Journal. What are some of the heuristics
that helped make it effective for you/
6. Learning to become a better writer and presenter requires effort and practice. How are you
planning to improve your writing and presenting skills? What are some of your favorite
resources?
Chapter Nine: Project Management Software
A wide variety of software tools are available to help project managers and project team
members accomplish their goals. These range from personal data assistants (PDAs) which are
electronic calendars, address books, to-do lists, memo pads, and sometimes expense reports, to
project management programs that do scheduling, resource leveling, and tracking, to web-based
project enterprise systems that manage both of the previous functions as well as drawings and
specification, budgets, contracts, and much more.
Personal Data Assistants
Personal data assistants help project

“The more time we spend on planning a
managers keep track of appointments, critical project, the less total time is required for it.
Don’t let today’s busywork schedule crowd
deadlines, to do lists, notes, and expenses. planning time out of your schedule.” Edward
Bliss, Getting things done.
Many provide for access to calendars over a
network or over the Internet and this features makes scheduling meetings much easier. Most can
be synchronized between personal digital assistants (PDA), handheld devices such as the Palm,
and a computer which makes it possible to easily take the information into the field. See Chapter
8 for a sample screen from the Palm Pilot desktop.
Individual Reflection: What type of calendar (or planner) are you currently using? Is it a small
paper date book or is it a leather bound 3-ring binder? What are the principal uses that you make
of your planner? Paper calendars and planners although inexpensive cannot be backed up easily
(except by photocopying) nor can the information be shared with others very easily (which has
it’s advantages).
Personal Digital Assistants are mainly used to manage time, priorities and contacts. They
help project managers attend to the details that are crucial for successful teamwork and project
management.
Recently, as PDA become more powerful and with the advent of wireless communication,
they are being used for inspection and project check-off, which results in much quicker turn
around (Bryant & Pitre, 2003; Roe, 2001).
Project Management Software
Comprehensive project management software such as Microsoft Project is used on complex
projects to accomplish goals and complete projects on time, within budget, at an acceptable level
of quality that meet the client’s expectations. The basic functionality of the critical path
scheduling aspect of these programs in summarized in Chapter 6 where the CritPath program is
featured.
The two most common views used by commercial project management software are the
Gantt chart and precedence network (sometimes referred to as PERT chart, although technically
it’s a Precedence Network). Examples of the Gantt Chart and PERT Chart views from Microsoft
Figure 9.1 Microsoft Project - Gantt View Figure 9.2 Microsoft Project - Precedence
Network View
Figure 9.3 Primavera Gantt Chart View Figure 9.4 Primavera Precedence Network
View
Project Figures 9.1 and 9.2, respectively.
Examples of the Gantt Chart and PERT Chart views from Primavera are shown in and 9.3 and
9.4, respectively. These Primavera views show the Activity Detail for a highlighted activity, that
is, the project manager can quickly get lots of detailed information on any activity which makes
it easily to track, manage, and update information.
Microsoft Project and Primavera are the two most widely used project management software
packages. Fox and Spence (1998) reported that 48% of the respondents reporting using
Microsoft Project and 14% reporting using Primavera. Pollack-Johnson and Liberatore (1998)
reported similar figures (nearly 50% for Microsoft Project and 21% for Primavera) and provided
extensive information on how these packages are used. Median size of projects is a little over
150 activities, median number of resources is 16, high percentages of respondents regularly
update the information, and about 62% of the respondents use resource scheduling/leveling
(Pollack-Johnson and Liberatore, 1998).
I now include a Gantt chart summarizing the assignments in my project management and
economics syllabus (See Figure 9.5). This visual approach helps many students internalize when
they need to be working on the various assignments, and it especially focuses them on due dates.
Sep '02 Oct '02 Nov '02 Dec '02 Jan '0
ID Task Name Duration Start 9/1 9/15 9/29 10/13 10/27 11/10 11/24 12/8 12/22 1/5
1 Classes Begin 0 days Tue 9/3/0 9/3
2 Homework 1 6 days Thu 9/5/0
4 Brief Review 1 11 day Thu 9/12/0
3 Homework 2 11 day Tue 9/24/0
5 Group Project 1 16 day Tue 9/24/0
8 Brief Review 2 13 day Tue 10/1/0
16 Exam 1 0 days Thu 10/10/ 10/10
6 Homework 3 6 days Tue 10/15/
11 Project Proposal 19 day Thu 10/17/
9 Group Project 2 13 day Tue 10/29/
7 Homework 4 6 days Thu 11/14/
13 Major Paper 21 day Thu 11/14/
17 Exam 2 0 days Tue 11/19/ 11/19
10 Delta Design 4 days Thu 11/21/
12 Thanksgiving Break 2 days Thu 11/28/
15 Homework 5 6 days Tue 12/3/0
14 Last Day of Instruction 0 days Fri 12/13/0 12/13
18 Exam 3 0 days Thu 12/19/ 12/19
Figure 9.5 Project management course assignments Gantt chart
The Project Management Institute recently launched a major project management software
survey available both in print and on CD-ROM (Cabanis, 1999). The survey:
• Compares and contrasts the capabilities of a wide variety of project management tools
• Provides a forum for users and vendors to meet and match requirements and possibilities
• Prompts vendors to become more responsive to customer needs
• Prompts users to create a methodology for software tool selection within their own
companies.
• Categorizes software tools into six areas of functionality aligned with the knowledge areas
of PMI’s A Guide to the Project Management Body of Knowledge (PMBOK™ Guide):
Scheduling, Cost Management, Risk Management, Human Resources Management,
Communications Management, Process Management.

Similar to the use of all software tools, it is important that project management software
serve and not enslave the project manager. Also, if you make the investment of time and money
for commercial project management software I encourage you to use it to organize and manage
your projects and not simply as a reporting tool. Lientz & Rea (1995) offer the following
suggestions for using project management software:
1. Set up the basic schedule information: name of project file, name of project, project
manager; input milestones, tasks and their estimated duration, interdependencies between
tasks; input resources for each task.
2. Periodically update the schedule by indicating tasks completed, delayed, and so forth, as
well as changes in resources.
3. On an as-needed basis, perform what if analysis using the software and data.
Types of use of project management software include REPORTING (Use schedule to
produce graphs and tables for meetings), TRACKING (Log project work and effort in terms of
completed tasks), ANALYSIS (Perform analysis by moving tasks around, changing task
interdependencies, changing resources and assignments, and then seeing the impact on the
schedule), COSTING AND ACCOUNTING (Assign costs to resources), and
TIMEKEEPING (Enter the time and tasks worked on by each member of the project team.).
[Project management software survey]
Unofficial reports indicate that over one million copies of Microsoft Project have been sold.
That’s a lot of people scheduling projects. Advertisements for civil engineering positions often
include familiarity with project management software, especially Primavera and Meridian. Lots
of books, short courses, multimedia training programs, etc. are available to help you learn to use
these tools. Some of the books I’ve found useful are included in the references. This is a rapidly
changing area, so I suggest that you stay tuned to resources such at the Project Management
Institute, especially via their web site (www.pmi.org) to keep current.
Reflection: What’s your experience with project management software packages, such as
Microsoft Project? Have they been bundled with any of your textbooks? Have you used these
programs to schedule project work associated with work or school? Talk about this with your
friends, and work to expand your repertoire of software tools.
Project Management and the World Wide Web
Project management, like many other things – bookstores, newspapers, computer suppliers –
has developed a web presence. I’m currently working on three projects (two writing projects and
a research project) where the repository for all the documents is eProject.com
(www.eProject.com).
The eProjects home
page and ‘My Projects’
view on eProject are
shown in Figure 9.6.
The teams for these
projects are
geographically
distributed and the
eProject electronic
Figure 9.6 eProject web site My eProjects
repository and collaboratory provides us with a place to work together. Additionally, I recently
participated in a successful grant writing project that resulted in a $10 million award, and again
the documents were all shared via an electronic repository. We did meet face-to-face
periodically, but the bulk of the work was conducted in an electronically mediated environment.
As mentioned above, the Project Management Institute has a very thorough web site and
provides access to the A Guide to the Project management body of knowledge (PMBOK™
Guide). I listed several of my favorite project management web sites in the last edition, but these
are changing so rapidly that they are outdated by the time the book is printed. Use your favorite
World Wide Web search engine (I’m partial to Google.com) and do a search on “project
management.” You’ll probably be amazed at the number of useful and relevant sites that come
up.
Bryant and Pitre (2003) describe three broad categories of project management websites:
1. Project Collaboration Networks (PCN): An environment for information sharing, such as my
eProjects described above. An example in the construction industry is
www.constructware.com.
2. Project Information Portals (PIP): Contain information essential to the project on codes and
specifications, permits, product information, cost data, and so forth. An example is
www.aecdirect.com.
3. Project Procurement Exchanges (PPE): These are sites that deal with the exchange of
material, and are essential e-commerce. Examples from the construction industry are
www.buildpoint.com.
Web-enabled project management is gaining momentum and will probably change some
businesses, as it is currently doing to the construction industry (Roe & Pfair, 1999; Doherty,
1999). Web-enabled project management couples both the communication aspects (e-mail,
FAX, voice and multimedia, intranet, extranet, and others) and the project management aspects
(scheduling, document and file management, project administration, job photos, job cost reports,
and project status reports). Doherty (1999) cites several reasons for using a project extranet:
• Fewer communication errors between project team members;
• Up-to-the-minute intelligence on all the decisions and collective information related to a
project;
• Less expense for messengers, couriers, copying, and blueprints;
• Customized sites for each project and customized access for each user;
• Security.
Since project management is about planning, scheduling, monitoring, and controlling
projects having a central project file located at a web site rather than in a project notebook (or in
the project manager’s head) has enormous benefits. The challenge involves moving from our
comfort zones of familiar practice and learning new tools and approaches.
References
Bryant, John A. and Pitre, Jyoti. 2003. Emerging technologies in the construction industry.
http://archnt2.tamu.edu/contech/finalJ/home.html (Accessed 1/4/03).
Bryant, John A. and Pitre, Jyoti. 2003. Web based project management.
http://archnt2.tamu.edu/contech/finalJ/web_based.html (Accessed 1/4/03).
Cabanis, Jeannette. 1999. Project management software survey.
Day, Peggy. 1995. Microsoft Project 4.0: Setting project management standards. New York:
Van Nostrand Reinhold.
Doherty, Paul. 1999. Site seeing. Civil Engineering, 69(1), 38-41.

Feigenbaum, Leslie. 1998. Construction scheduling with Primavera project planner. Upper
Saddle River, NJ: Prentice-Hall.
Fox, Terry L. & Spence, J. Wayne. 1998. Tools of the trade: A survey of project management
tools. Project management, 29(3), 20-27.
Lientz, Bennet & Rea, Kathryn. 1995. Project management for the 21st Century. San Diego:
Academic Press.
Lowery, Gwen. 1994. Managing projects with Microsoft Project 4.0. New York: Van Nostrand
Reinhold.
Marchman, David A. 1998. Construction scheduling with Primavera project planner. Albany,
NY: Delmar.
Pollock-Jackson, Bruce & Liberatore, Matthew J. 1998. Project management software usage
patterns and suggested research directions for future development. Project management, 29(2),
19-28.
Roe, Arthur G. & Phair, Matthew. 1999. Connection crescendo. ENR, May 17, 22-26.
Roe, Arthur G. 2001. Handhelds hold up well for variety of site uses. ENR: Engineering News-
Record, 247 (19), 31-32.
Questions
1. Describe the advantages and disadvantages of different calendar/planner formats – pocket
planner, three-ring binder, pocket electronic organizer, and computer-based personal data
assistant.
2. What are the major types of project management software? What are their common uses?
3. What are the advantages and disadvantages of the Gantt Chart view and the Precedence
Network views available in commercial project management software?

4. Apply Lientz & Rea’s suggestions for using project management software to a project
you’re currently involved in?
5. Check out project management on the World Wide Web!

Chapter Ten: Where to Go From Here
Projects and teams are going to be with you for the rest of you life, no matter what
profession you eventually work in (they are already prevalent in engineering, medicine, law, and
most areas of business and industry). Even if you become a college professor you will probably
be involved in projects and teams, especially on research projects and with your graduate
students. Now you have made a start at learning how to effectively participate in projects and
teamwork. In addition to learning how to participate effectively, I hope you’ve developed skills
for managing and leading a team. There are lots of additional resources available, and I hope
you will continue to read about project management and teamwork. More importantly, I hope
you will talk with colleagues (fellow students and faculty) about project management and
teamwork. If you aspire to become a project manager, I encourage you to check out the Project
Management Institute. They have a special student membership rate and your membership in
this organization will help connect you with project management professionals. Most
professional organizations, such as ASCE, ASME, and IEEE, have a division that emphasizes
engineering management. Check these out as you become a student member of the professional
organization in your discipline.
Periodically reflecting on your experiences, writing down your reflections (as I have asked
you to do throughout this book), processing them alone and with others, reading and studying
further, will help ensure that your project and team experiences are more constructive. A
sustained effort with ensure that you continue to learn and grow.
If you are in a team or project situation that is not working well, rather than just endure it
and hope it will pass quickly, try some of the ideas in this book for improving the team or
project. Suggest that the team members discuss how effectively they are working. For example,
suggest a quick individually written plus/delta processing exercise to survey the team.
Successful project and team work does not just magically happen, it take continual attention to
not only the task but also to how well the group is working. And this is WORK! The
satisfaction and sense of accomplishment that comes from effective team and project work is
worth the effort. There are just so many things that can’t be accomplished any other way. The
more you learn during your undergraduate years, the easier it will be for you after graduation.
Paying attention to these skills now will save you what previous generations of engineering
graduates have had to endure – learning project management and teamwork skills on the job in
addition to all the other complex things they had to learn.
As you work with this book and the ideas and strategies for effective project management
and teamwork, please think about what else you need to know. Develop a learning and teaching
plan for yourself and your project and team members. A few resources are listed below and
these only barely scratch the surface of all the resources that are available. Check out a few of
them. Add your own favorites to the list. Share your list with colleagues. Several students I’ve
worked with have found Stephen Covey’s Seven habits of highly effective people very helpful.
Three or four students have said “this book changed my life.” Covey’s book is also a perennial
bestseller and has been for several years. The earlier you learn the skills and strategies for
effective project and team work, the more productive you will be and the easier life will be for
you later. Start now!
Although the up front goal of this book is on facilitating the development of project
management and teamwork skills in engineering students, the deeper goals are to change the
climate in engineering courses and programs from competitive or negative interdependence to
cooperative or positive interdependence; from suspicion, mistrust, and minimal tolerance of

others to acceptance, trust, and valuing others; from egocentric “what’s in it for me” to
community “how are we doing”; from a sense of individual isolation and alienation to a sense of
belonging and acceptance. I recognize that these are lofty goals, but until we not only take
responsibility for our own learning and development but also take more responsibility for the
learning and development of others, we will not benefit from synergistic interaction.
If you find that project management and teamwork, and perhaps even leadership, are of
great interest to you, then you may want to read some of the business magazines such as
Business Week or the Harvard Business Review, and perhaps even my favorite, Fast Company.
Check out your local bookseller or bookstore on the Internet for some spare-time reading on
these topics. You’ll find an enormous literature available.
If you’re more interested in project management and teamwork specifically within
engineering and technology, then I suggest that you look into some of the books and video
documentaries on projects, such as Karl Sabbagh’s work -- Skyscraper and 21st Century Jet.
Closing Reflection: On Reflection
Much of the material taught and concepts covered in undergraduate education consists of
declarative knowledge, which emphasizes knowing that; whereas the heart of project
management consists of procedural knowledge, which emphasizes knowing how. This
distinction between knowing that and knowing how was articulated by Ryle (1949).
Furthermore, a lot of the essential procedural knowledge needed for success is implicit (or tacit
as Polanyi, 1958, 1966 described it) rather than explicit. This implicit or “insider knowledge” as
it is sometimes referred to is usually picked up on the job; however, I’m convinced that we can
do a lot better job preparing people to “pick up” this knowledge. The opportunities for reflection
I’ve encouraged you to engage in as well as my own reflections are designed to help you more
quickly pick up the tacit dimension. If you would like to explore these ideas further, you may, of
course, read the original work of these philosophers, or you could read the more recent work that
builds on the work and applies it to organizational contexts. An excellent summary of these ideas
in a organizational context is Cook and Brown (1999) or Brown and Duguid (2001). One of my
favorite books on the topic is The social life of information by Brown and Duguid (2000).
Best wishes to you in your project endeavors.
References
Brown, John Seely and Duguid, Paul. 2000. The social life of information. Boston: Harvard
Business School Press.
Brown, John Seely and Duguid, Paul. 2001. Knowledge and organization: A social-practice
perspective. Organizational Science, 12 (2), 198-213.
Polanyi, Michael. 1958. Personal knowledge: Towards a post-critical philosophy. New York:
Harper and Row.
Polanyi, Michael. 1966. The tacit dimension. New York: Doubleday.
Ryle, Gilbert. 1949. The concept of mind. London: Hutchinson.
Cook, Scott D.N. and Brown, John Seely. 1999. Bridging epistemologies: The generative dance
between organizational knowledge and organizational knowing. Organizational Science, 10 (4),
381-400.

Teamwork & Project Management

Uploaded by

Copyright:

Available Formats

Teamwork & Project Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Teamwork & Project Management

Uploaded by

Copyright:

Available Formats

Teamwork and

McGraw-Hill’s BEST Series

Basic Engineering Series and Tools

DRAFT for Review and Comment

Chapter One: Teamwork and Project Management In Engineering . . . . . . . . . . . . . . . . . . . . . . 11

Chapter Two: Teamwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Chapter Three: Teamwork Skills and Problem Solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter Four: Project Management Principles and Practices . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter Five: Project Manager’s Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Chapter Seven: Project Monitoring and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Chapter Eight: Project Management Documentation and Communications . . . . . . . . . . . . . . 174

Chapter Nine: Project Management Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Chapter Ten: Where to Go From Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

especially at the University of Minnesota’s Center for the Development of Technological

Leadership; and participants in short courses in the University of Minnesota Executive

! To understand the dynamics of team development and interpersonal problem solving.

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

! To understanding critical technical competencies in project management

! To explore a variety of "best practices" including anticipating, preventing and overcoming

barriers to project success.

work your way through this book.

joint tasks is critical to success in engineering.

[sidebar] Personal Story

this category?" Engineer after engineer replied, "About five percent"!

Smith, who helped with the editing and graphics.

A special acknowledgment to Michigan State University, which provided me with a

for their great ideas, generosity, and steadfast support.

interest and enthusiasm in project management and teamwork.

Comments and Suggestions

Please send your comments and suggestions to “Karl A. Smith” <[email protected]>.

Preface to the Second Edition

heuristics in this book.

suggested by Kelly Lowery and John Griffin.

Management skills in earlier courses and programs.

teamwork and project work to you!

Johnson, P.E. 1982. Personal communication.

matters. New York: Knopf.

technologies to a degree never witnessed before -- in a way that is enabling individuals,

programs in which I teach – Management of Technology, Manufacturing Systems Engineering,

make it easier and, very likely, you’ll remember it longer.

of engineering are. What did you come up with?

course) that was not developed, produced, or delivered by an engineer?

encounter was developed, produced, or delivered by an engineer or engineers.

Koen’s second question is:

Koen’s third question is:

method for solving a problem?

above all else, distinguishes engineering from science (Hancock, 1986).

engineer – an engineer is a jack of all trades and a master of some.

in computer)? Take a moment to collect your thoughts on design.

engineering programs, defined engineering design as “the process of devising a system,

component or process to meet a desired need.”

Ferguson (1992) writes:

Louis Bucciarelli (1994), an engineering professor who has observed engineering

activity. He describes practices such as "negotiating understanding," "conserving ambiguity,"

"tailoring engineering communications for recipients," and " manipulating mundane

If design is the heart of engineering and

inadequate project management.

1. Understand the market/client/technology/constraints

2. Observe real people in real situations

3. Visualize new-to-the-world concepts and ultimate customers