Project Engineering The Essential Toolbox for Young Engineers

224 Pages·2007·11.74 MB·English

by  Frederick Plummer

Project Engineering:
The Essential Toolbox for Young Engineers
by Frederick B. Plummer

• ISBN: 0750682795
• Publisher: Elsevier Science & Technology Books
• Pub. Date: June 2007
Preface
When you think of a toolbox, you imagine a collection of handy implements
organized well enough that you can find them when you need them. They're
durable and collected over timemsome handed down from generation to genera-
tion. Most of them are essential, for without them you couldn't imagine starting a
tough task. If you add to your collection as the need arises, and if you keep them
sharpened, rust-free, and maintained, they'll serve you well for a lifetime.
I view this book as a "starter set" of tools for the engineer just arrived at his or
her first job, and for the engineer with a few years' experience (I won't draw the
line on how many) who wants to make the transition from a technical assignment
to a leadership position.
Project engineering is a chance to lead and coordinate the efforts of others on a
project or part of a project. Especially in smaller companies, you may be thrown
into the middle of a significant task shortly after you've walked in the door and
found out where the restrooms are. It's crucial to be prepared and not be caught
flatfooted. That's when this book can help you the most.
The book is organized in the order you need the information. The first half pre-
sents the fundamentals of project engineering. It begins where you begin when you
take on your first job. It then lays out what you have to do as a project engineer in
terms of fundamental duties that are common to almost every project engineering
situation. A crash course in management gives the essential principles of leader-
ship and the basic skills for getting along with coworkers and management. An
overview of how projects work helps you visualize how project engineers fit into
the big picture. A case study takes theory into practice for a young project engineer
in a realistic situation; it's like a transfusion of practical experience.
Fundamentals are one thing, but success is another. The second half of the
book moves to the broader and perhaps more important topics of being successful
and managing your career. Being effective in the performance of your job, com-
peting with contemporaries, and dealing with office politics are balanced against
the values of ethical business conduct. Tools for working internationally add the
xiii
xiv Preface
cultural skill set needed to compete in our global business world. That's followed
by a chapter of advice from project engineers and managersmwise guidance spe-
cifically tailored for young project engineers--addressing the points those project
pros feel are most important. The book ends with a description of the most power-
ful asset you can have: confidence.
I hope you will find this unique collection of technical, business, personal
effectiveness, interpersonal skill, and leadership tools of value in getting you off
to a good start and headed in the right direction on your career journey. The book
doesn't cover all aspects of project management; it just explicates what over 30
years of coaching and counseling young engineers have shown me to be essential.
These pages are filled with what a friend called high-end common sense.
To keep it short and to the point, I've used the criteria that the material must be
essential. When you find the book going into more detail on one topic or another,
it's because most engineering schools don't teach it, but you need to know it. If
you don't need to know it right now, I predict that you will. So mark the passages
you find most useful now, and make sure to glance back over the rest of the book
a little further along the road.
In addition to making the material essential, I strive to always present some-
thing you can actually do to solve the challenges confronting you. Use what you
need when you need it and seek important training. You won't want to change
your entire style overnight, but over time your performance and effectiveness will
improve.
Like any good, basic toolbox, I expect you will use the book many times during
your early years, and less as time goes by. But even as an accomplished project
engineer you may find yourself coming back to put your hands on the basics every
so often. And just as good tools get loaned to someone who has a job to do, some-
day you may lend the book, or advice from it, to other people.
Acknowledgments
A number of people in my writing community have helped give life and energy
to this book. I'm indebted to my teachers, Elizabeth Harper Neeld, Alexis Glynn
Latner, and Jacqueline Simon, for introducing me to the craft and for their encour-
agement. Alexis, with her uncanny insights into things technical, went on to be
my "ideal reader," editor, mentor, and a continual source of support, advice, and
confidence.
My thanks go to Lesley Summerhayes. She put aside her disdain for engineer-
ing and pitched in with constructive criticism on the voice, the concept of the case
study, and the conception and shaping of those early chapters. Her death was a
tragic loss.
So many colleagues and friends have contributed to the content. The list
starts with my brother, Ken Plummer, and my sons, Fred Plummer III, Robert
Plummer, and Jon Erlend Holand, for their comments, advice, insights,
and plain, ordinary help when I needed it. Other key contributors include
Lynn Boyd, Mike Brady, Kristin Farry, Jim Flood, Arnt Erik Hansen, Paul
Hellen, Rob Howard, Jeff Hulett, Rick Johnson, Jing Kuang, Peter Lacey,
Olav Lappegaard, George Lock, Lisa Solberg Mallon, Don Maus, Will Moon,
Christina Nordstrom, Yarami Pena, Ruzica Petkovic, Dick Rolstad, Haakon
Sannum, Sandy Setliff, Bjorn Solheim, Ray Steinmetz, and Harry Underland.
All of these people made their mark on this book in one way or another but
three stand out: Jeff Hulett for his priceless collection of project proverbs
and a score of other inputs, Yarami Pena for his wise counsel in the for-
mative stages when I was deriving the content and synthesizing the project
engineer's duties, and Harry Underland for improving my understanding of
manufacturing.
Special mention goes to Eric Namtvedt and his crew at FloaTEC, LLC, for
bringing me out of retirement to learn the "contractors' world" and for their per-
mission to publish their artwork. I'm indebted to Malcolm Taylor for his candid
insights and Ricky Brown for help with the figures. The many conversations with
XV
xvi Acknowledgments
Liz Maraist on the subject of business conduct helped me calibrate my under-
standing of that crucial subject.
Above all, I can't begin to thank those who made possible the transition from
book project to the published book: Bud Griffis, Dan Morris, Joel Stein, Jeff
Freeland, and Shelley Palen. Without them this wouldn't be on your bookshelf.
Frederick B. Plummer, Jr.
Table of Contents

Chapter 1
When Opportunity Knocks
Chapter 2
What Do Project Engineers Do?
Chapter 3
A Crash Course in Management
Chapter 4
How Projects Work
Chapter 5
Learning Project Engineering on the Job: A Case Study
Chapter 6
Skills That Can Get You Ahead
Chapter 7
Things That Can Get You Fired
Chapter 8
International Business Skills
Chapter 9
Advice from the Pros
Chapter 10
Approach the Job with Confidence
Glossary
Index
About the Author
Chapter I
When Opportunity Knocks
Project engineers are an integrating force in modern industrial society. They
link the people who envision the work to the ones who do it. They tackle a job
and do what it takes to make plans into reality. Your company or organization
consists of departments and groups that specialize in engineering, purchasing,
construction, manufacturing, accounting, and other skills. Within those depart-
ments and groups are specialists, such as process engineers, machinists, accoun-
tants, ironworkers, and more. All add value in their own specialty. Project
engineers, on the other hand, have overall responsibility for a certain part of the
work or maybe even a small project. They add their value by coordinating and
integrating everyone's contribution into an end product. They solve problems
through reasoning, teamwork, and leadership. They communicate, and they ask
important questions, such as
(cid:12)9 Is the work being done correctly?
(cid:12)9 Does it cost too much?
(cid:12)9 Is someone falling behind?
(cid:12)9 Are the working conditions safe?
They lead, and they get the job done.
As a young engineer, a project engineering assignment is a golden
opportunity for you. It's a chance to demonstrate that you can accomplish a
job through influencing, coordinating, and leading the efforts of others. Most
of those who succeed in project management positions started in the trenches
as project engineers. This kind of grassroots leadership experience is hard to
obtain later in your career and can be a first step toward a supervisory position,
if you do well.
2 When Opportunity Knocks
WHERE DO YOU START?
Early in my career I took over a supervisory position from a guy I will call Jim.
He was a bright, articulate veteran and a seasoned supervisor. As we discussed the
job, he must have sensed my uneasiness about following in his footsteps. Eventu-
ally, he steered the conversation to some fundamentals I will never forget. He said
that a person had to do three things to get ahead in the company:
(cid:12)9 Find out who your boss is.
(cid:12)9 Find out what he or she wants.
(cid:12)9 Doit.
To many of you this will seem logical, if not somewhat simplistic, as it did
to me at the time. Others may mutter, "That's just kissing up to the boss." No,
it's not. "Yes-people" don't always produce results valuable to the organization
and aligned with what the management wants. In fact, most effective managers
appreciate employees who are strong enough to offer their opinions because their
suggestions often lead to improved results. The challenge is knowing how to
fulfill the expectations of your boss while you navigate simultaneously through
the demands of other stakeholders who are, in a sense, also your bosses. Nowhere
is this more the case than in project engineering.
YOUR BOSS(ES)
As a recently hired engineer beginning a new job, you find it easy at first to
know who your boss is. Many companies give you a clear assignment and a mentor
to get you started. As you develop competence, you're given more responsibility.
Eventually, likely you will be handed a task that involves coordinating the efforts
of otherswa project. You have become a project engineer.
Imagine you are a mechanical engineer who has been working in the Engi-
neering Department of a moderate-sized engineering and construction firm for
over six months. Your boss is Bill, the engineering manager, who heads the
department. There is a mechanical lead engineer, Walter, who checks all the
mechanical work for the department. Walter has been with the company for
a long time. He gives you a lot of technical advice and mentoring but doesn't
supervise you directly.
Your company has recently been awarded a job to design and build a compressor
station for a natural gas pipeline. Sara, in the Projects Department, has been
designated as the project manager. Bill has assigned you to the Compressor Station
Project, working directly for Sara. You are the project engineer for the compres-
sor package, the key component of the station that consists of the gas compressor,
motor, control systems, and the enclosure that contains them.
When Opportunity Knocks 3
On the organization chart, your boss is Bill, the engineering manager, who
is responsible for supplying people and technical tools (design processes
and computer programs) to the projects. The engineering manager rates your
performance and manages your promotions and career. In many organizations
the engineering manager may be responsible for the technical quality of the
engineering work, as he is in this case.
On the other hand, Sara, the project manager, is the one who is accountable
to management for getting the job done. She has to be happy with the safety,
progress, quality, and cost of the compressor package. Sara is your boss too.
As you may know from experience, this is what looks like an impossible
situation. You can't serve two masters. But here you are with two bosses, each
with differing requirements, and you must find a way to keep them both happy.
WHAT DO THEY WANT?
Now let's continue by finding out what your boss wants. But wait. You have
two bosses, and you have to find out what both of them want. So what's the way
fbrward?
The best thing to do in this situation is to sit down, by yourself, and list the
objectives you want to achieve, taking into account what both bosses want. Then
review those objectives with each boss, individually. Ask for their input and be
willing to accept their comments and work out compromises. It may take a while,
but it's time well spent. Above all keep your credibility high and don't lose your
cool or your confidence.
As you go through this process, don't forget about Walter, the mechanical lead.
While he's not exactly your boss, he is a source of advice and experience, since he
has been through this many times before. Having his support will help--especially
down the road when you need him as a sounding board to solve problems, or when
he checks your work.
Of course, you can't just jump into the middle of writing your objectives. You
need information. You have already had a conversation with Bill when he assigned
you to the job. He stressed the fact that the client has been having operational
problems with the type of compressors that were used on the previous job because
of manufacturing quality issues. Bill wants you to make sure that those machines
meet or exceed the client's requirements. After that meeting you went to Walter
to learn more about the problems on the last job. While meeting with Walter, you
took the opportunity to ask him to help you brainstorm your objectives.
Next you met with Sara to introduce yourself and get her thoughts on the proj-
ect. She took up most of your 1O -minute conversation stressing that safety is the
highest priority. She also stressed that the client has imposed a large penalty in
the contract, in case the project isn't finished by the completion date. (Walter had