Read an Excerpt
Project Engineering
The Essential Toolbox for Young Engineers
By Frederick B. Plummer, Jr.
Butterworth-Heinemann
Copyright © 2007 Elsevier Inc.
All right reserved.
ISBN: 978-0-08-054621-6
Chapter One
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 departments and groups are specialists, such as process engineers, machinists, accountants, 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
• Is the work being done correctly?
• Does it cost too much?
• Is someone falling behind?
• 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.
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. Eventually, 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:
• Find out who your boss is.
• Find out what he or she wants.
• Do it.
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 others—a project. You have become a project engineer.
Imagine you are a mechanical engineer who has been working in the Engineering 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 compressor package, the key component of the station that consists of the gas compressor, motor, control systems, and the enclosure that contains them.
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 forward?
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 project. She took up most of your 10-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 mentioned that the compressor is "long-lead equipment," so you make a note that the schedule will be important.) Finally she told you that the compressor package must come in within the budget.
Sara plans to have a kickoff meeting with the project team next week. After Sara's kickoff meeting, you will likely have enough information to write a draft of your objectives and start the process of reviewing them with Bill and Sara. Already you can see that you will have a challenge balancing quality, schedule, and cost.
The good news is that you realize this challenge now—not a year from now, when a balancing act you weren't aware you had to do falls apart, and all your bosses are unhappy with you. Forewarned is forearmed.
Keep in mind one more consideration when trying to find out what your bosses want. At times, their requirements may be out of bounds. They may not be aligned with company policy, or they may be asking you to do something unethical or illegal. In such a situation, you will have to know who you are. We'll get into this later in Chapter 7 when we talk about business ethics. This should be a rare situation for most engineers. If not, you're working for the wrong company.
DO IT!
With knowledge of who your bosses are, and with an agreed set of objectives, life on the project becomes easier. Now you can turn your attention to getting the job done. That's what the rest of this book is about.
We'll consider the roles and the duties of effective project engineers. We'll focus on the fundamental aspects of getting a job done from the time you start to plan the first activity, until you turn the final product over to the customer.
You'll gain a working knowledge of how to develop your own competence, personal effectiveness, and business judgment while you struggle with all the other demands of the job. We'll explore the concepts of teamwork, leadership, and management. Even though you are a new engineer, such skills are important to your success. We'll even consider the rudiments of office politics, competition with your peers, and an overview of business ethics. A case study illustrates all of those concepts in a relevant, understandable project setting. Chapter 9 offers advice from other project professionals and managers who started their careers as project engineers.
A common thread throughout is the issue of dealing with other people. It's present in the everyday contacts with management, peers, and the people whom you lead. It's present, in spades, in the interactions with people from other cultures, either in your own workplace or in far-off places around the globe. Chapter 8 provides an awareness of the challenges of working internationally and suggests how to deal with culture shock. It also introduces you to a set of cross-cultural communication skills and offers a simple approach to resolve cultural differences.
In all of these topics, the emphasis is the same: to make you aware and offer tangible steps you can take to enhance your job performance. This book is a toolbox of skills, strategies, and options for development that you'll find useful —no, essential—for launching your career. It's not every tool you'll ever need, but it's something you can carry with you while you're getting started and probably for the rest of your life.
Now let's consider what project engineers do in a little more detail, but still at a fundamental level.
Chapter Two
What Do Project Engineers Do?
TOTAL AREA RESPONSIBILITY
As a project engineer, your overall role is rather straightforward. You are totally responsible for everything that has to do with your area!
The idea of total area responsibility is more of a mind-set than anything else. It's something you have to become comfortable with, without being arrogant. If you do it well, you'll be recognized and respected by the rest of the project—and others outside the project—as the go-to person for your area.
Total area responsibility includes planning the work and controlling it. It involves handling whatever comes along. Sometimes there are disturbances to quell, or disagreements to mediate, or problems to solve. There's an aspect of doing whatever it takes, but priorities have to be set to stay within deadlines, budgets, and the realm of what's humanly possible. I was on a project once that had as one of its ten principles, "Good enough is usually the best." That's excellent advice when one considers most projects entail an avalanche of work, and each one of us has a personal life to live. Prioritize, or you'll be buried by the flow!
Types of Areas
To get a grasp of what an area is, let's consider a few examples.
Specific Part of a Facility, or a System
For a design or construction project engineer (on either the client's or contractor's team) an area is often a specific part of a facility—for example, a part of a building, the engine room, the control room, the living quarters, a structure, and more. The area could also be a system, like the process system, the electrical system, or several of the instrument and control systems.
Main System or Assembly
In equipment manufacturing companies, the project engineer's area could be a package, which is either a main system or a main assembly of parts for the product. The project engineer or package engineer then becomes the steward for the package as it passes through the design, development, manufacturing, and acceptance process. The package engineer doesn't do the design, or the manufacturing, or the testing. He or she leads a team that develops the design requirements and then ensures that the design drawings and specifications are produced in accordance with those requirements and the project schedule. The package engineer also works the interfaces and may be responsible that the quality of the end product satisfies the requirements and the client's interests.
(Continues...)
Excerpted from Project Engineering by Frederick B. Plummer, Jr. Copyright © 2007 by Elsevier Inc.. Excerpted by permission of Butterworth-Heinemann. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
