Cover Page

Engineering Project Management

 

Neil G. Siegel

The IBM Professor of Engineering Management

University of Southern California

Los Angeles, US

 

 

Wiley Logo

About the Author

Neil Siegel spent many years successfully managing engineering projects, big and small. He managed successful projects in aerospace and defense, civil government (at the federal, state, and city level), health‐care, the steel industry, the energy industry, higher education, the entertainment industry, and others. His inventions are also widely used in the consumer electronics industry.

He has won many honors and awards for his work as a manager of engineering projects, including election to the U.S. National Academy of Engineering, the U.S. National Academy of Inventors, the IEEE Simon Ramo Medal for Systems Engineering, and many others. In addition to these personal awards, projects that he led have received honors and awards, such as the inaugural Crosstalk Award for the best‐managed software project across the entire U.S. Government.

He earned a Ph.D. in systems engineering at the University of Southern California, where his advisor was the noted computer scientist and systems engineering Barry Boehm.

He retired after 18 years as a vice‐president of the Northrop Grumman Corporation at the end of 2015, and now teaches systems engineering and engineering project management at the University of Southern California.

More information is available at https://neilsiegel.usc.edu.

Acknowledgments

I started working on actual engineering projects in 1976, and did so full time until the end of 2015, building systems for customers in aerospace and defense, but also civil government (at the federal, state, and city level), health‐care, the steel industry, the energy industry, higher education, entertainment, and others. My inventions are widely used in the consumer electronics industry (I sometimes say “used in a billion devices worldwide,” but a rigorous count is beyond my means). I also had the opportunity to build such systems for customers in several countries outside of the United States, to travel extensively in those countries, and even to live overseas for a couple of years on such an assignment. I draw upon those experiences in writing this book.

Over that period of time when I worked on these engineering projects, I benefited from many people, a few of whom I will name herein.

First, I want to recognize the many people who taught me how to be the manager of an engineering project. I will let Peter Karacsony, Dr. Joe Mason, and Jack Distaso represent the large number of people who helped me along this wonderful (but demanding) life path.

Next, my many customers, most of whom truly believed in being effective partners in the difficult enterprise of building complex engineered systems. LTG (ret) William Campbell will represent this group of great people.

My childhood friend Dr. Mitch Allen is an archeologist who spent much of his professional career as an academic editor and publisher. When I conceived the idea of writing this book, Mitch (despite being retired from the publishing business) taught me everything that I needed to know in order to write a book proposal, and actually found me acquisition editors by name to whom I could submit my proposal.

I also wish to thank my collaborators at Wiley, my publisher: Eric Willner and his staff.

I wish to thank my former company, TRW/Northrop Grumman (TRW was acquired by Northrop Grumman in 2002). In addition to offering me an amazing career – with the opportunity truly to save lives, improve the defense of the United States and our allies, aid humanity, and enjoy continuous intellectual stimulation – they kindly allowed me to create a set of teaching and research materials that drew upon data and lessons learned from real projects, and allowed me to release that information about those real engineering project experiences to my students and the public. This book could not exist in this form without my ability to tell those stories.

Two real engineering projects were key learning experiences during my career, and are the source of some of the lessons learned and stories described herein:

  • The Forward‐Area Air Defense Command‐Control‐and‐Intelligence System. Peter Karacsony was the manager of this project; I was the chief engineer.
  • Force XXI Battle Command Brigade‐and‐Below (also known as the Blue‐Force Tracker, the Appliqué, or the Digitized Battlefield). I was the project manager; Jack Distaso was my direct supervisor during this time. LTC (ret) William Campbell was the senior customer (called in Army nomenclature the program executive officer) for this project, and for many more projects that I had the opportunity to build for the US Army, as well.

I was always blessed with an amazing team of engineers and other professionals when I set out to manage an engineering project; several are named at appropriate places within the stories told in this book. I owe a great deal to those colleagues at TRW and Northrop Grumman, and to those colleagues at various other companies who worked with me as subcontractors on these great projects.

I used an early draft of the book with my undergraduate engineering students at the University of Southern California, and am grateful for the feedback that they provided. Some of them were willing to be recognized by name, and so I would like to acknowledge (in alphabetical order) Terry Lam, Aaron Lew, Seema Snitkovsky, Sara Stevens, Kathleen Sullivan, and Tal Volk.

Lastly (but always first) my wife, Dr. Robyn Friend, who – in addition to everything else – was always the first to read every chapter, and provided useful and thoughtful feedback.

About the Companion Website

This book is accompanied by a companion website:

www.wiley.com/go/siegel/engineering_project_managementflastg001

The website includes:

  • Briefing charts for lectures
  • Reviews in advance of examinations
  • Solution manuals

Scan this QR code to visit the companion website.

flastg002

Introduction

I spent many years as a practicing engineer, including many assignments as the manager of engineering projects. The projects that I managed ranged from very small to very large; as I got older and more experienced, the projects that I led tended to get larger and more complex. Our teams were in general successful in delivering systems and products that our customers found useful, and at times constituted revolutionary improvements over previous capabilities. I have been credited with saving lives, money, and time, all on a large scale.

As I progressed from project to project, I drew certain conclusions about managing such engineering projects, and developed my own techniques and methods. I took courses offered by my company in project management, and read books on the subject. I found a significant difference between what I experienced as a project manager, and what the books had to say. What I did as a project manager, what I spent my time doing and worrying about, seemed very different from what the books said.

I also, learned through my reading and research, that the overall track record of success in engineering projects is not very good. A shockingly large portion of the engineering projects that are started turn into failures.

Recently, I elected to retire from full‐time work as a practicing engineer and engineering project manager, and took an appointment at a university as a full‐time professor of engineering in a department of systems engineering. Systems engineering is my love and my passion, and I wanted to create courses that taught systems engineering my way, and to continue my researches into how to do systems engineering better than we do it now.

After I had a good start in creating my systems engineering courses, the university asked me to teach a course in engineering project management. It had never occurred to me to want to teach that; I was completely focused on systems engineering. Of course, systems engineering and engineering project management are, in my mind, very closely related. When I was the manager of an engineering project, I employed what I characterized as the “systems engineering mindset” in order to plan and manage the project.

I discovered that I had quite a lot to say about engineering project management, and enjoyed teaching the course quite a bit. The students seemed to find my approach – grounded in actual experience as an engineering project manager, and full of examples from actual projects – both informative and enjoyable.

And, of course, I had to select a textbook for my engineering project management course. I purchased and read several of them. They were all as I remembered them: they talked a lot about stuff that I didn't actually do, and said nothing about many things that I had found were vital. After I had taught the course a couple of times, I realized that perhaps there was room in the world for a textbook that would describe my approach to engineering project management, one that would teach the activities that I found myself actually spending time on and worrying about when I was the manager of large, complex engineering projects. This book is the result.

Concept of the Book

The book is “sized” for a one‐semester course, but could easily be adapted to either one or two quarters of instruction.

The book is intended to serve both upper‐division undergraduates (e.g. juniors and seniors) and students who are just starting graduate studies. I use essentially the same course materials for both of these student audiences; the graduate students will get additional readings and a lot more homework (in ways which I will describe within the text).

Engineering is all about achieving practical results, and in that spirit of hands‐on, practical results, my class does not consist entirely of lectures. For most of the weeks within the course, I use at least one class session for what I call a “facilitated lab session.” During these facilitated lab sessions, I take only a short amount of time to explain a technique, and then provide the students with a problem which they work on (in teams) during the class session. They are allowed to consult with each other, to look at their class notes and books, to ask me questions, to show me their in‐progress work, and get feedback on the spot. What I find is that they seldom actually finish the work during this class session (and therefore they still have to do that work as homework), but by the end of each facilitated lab session, they understand the method properly, and are able to do the problem correctly.

So the course – and therefore this book – is laid out as two parallel, week‐by‐week tracks: one a progressive set of lectures, and one a progressive set of practical techniques and team exercises. As the students' knowledge and practical techniques are built up and mastered, this leads to a set of gradable course materials, and an integrated set of learning (via a combination of reading, lectures, hands‐on facilitated sessions, individual homework assignments, and team homework assignments) for each student. I supplement these gradable materials with a mid‐term and a final examination, in order to develop grades for each student.

At the ends of the chapters that correspond to the weeks which have these facilitated lab sessions, therefore, there will be a subsection that addresses the topic, technique, and assignment for that week's lab session.

Many of the artifacts created by the students could be viewed as sections of a project plan. The graduate students get assigned to create more elements of a project plan than the undergraduates, commensurate with their extra year or two of previous instruction, and most especially the fact that a large portion of engineering graduate students who are taking a course in engineering project management have a few years of actual work experience. That experience is likely to have been focused in just a couple of small teams buried within large projects at their companies, but they are at least aware of the larger world of project management, and are motivated to want to learn quickly about that larger world.

The organization of the book is described in the following table:

Chapter/weekLectureIn‐class facilitated workshop
1 The role and the challenge. What is engineering project management? Why do we teach engineering project management? Do engineering projects matter to society? Do projects matter to business? What is a “project?” What is an “engineering project?” What is a “project manager?” In this chapter, we discuss all of these questions and also provide you basic information about the role of engineering project manager and the opportunity that this role represents for you. Team exercise: the value of engineering projects to society
2 Performing engineering on projects (part I). How do we do engineering on projects? Engineering projects are different from other projects, so learning to be an effective manager of an engineering project starts by understanding how we do engineering on projects. We accomplish this engineering through the engineering life‐cycle. In this chapter, I summarize key aspects of how we do the initial stages of the engineering life‐cycle, which are called “requirements analysis” and “design.” This week is all lectures
3 Performing engineering on projects (part II). In this chapter, I continue our summary of the key aspects of how we do engineering on projects, covering the remaining stages of the engineering life‐cycle, from “implementation” all the way through to “phase‐out and disposal.” This week is all lectures
4 Understanding your users and your other stakeholders. We have two coordinate systems of value and engineering the user experience. Engineering projects often create products and/or services that never existed before. Under these circumstances, it is easy to lose sight of what aspects of the new item are essential, and which are less so. We solve this dilemma by rigorous and continuous focus on our eventual users and customers. What are they trying to accomplish? How do they do it now? What are the shortfalls? What are their needs and desires? At the same time, our degrees of engineering freedom are usually entirely within the technical domain: choices about materials, parts, algorithms, mechanical structures, and so forth. In this chapter, you will learn how to understand your users, how to relate that understanding of your user to the engineering choices that are your degrees of design freedom. We then extend this focus on our users to all the “stakeholders” of our project. We end the chapter with a discussion of how to use good engineering and good management to achieve a compelling and effective experience for your users and your customers when they operate your system, through what we call the user experience. Team exercise: the customer's coordinate system of value, the engineer's coordinate system of value, relating them, use of operational performance measures (OPMs) and technical performance measures (TPMs)
5 How do engineering projects get created. Creating winning proposals. When we get our first job, we are likely to be assigned to work on an existing engineering project; we are not troubled by the question of how this engineering project came into existence. Who created it? Why? How is it being paid for? How did it come to pass that it is our company that is doing the work? But as we progress in our careers, we come to realize that these aspects matter a lot. In fact, understanding them, so that you can help your company win new projects, is an important path for you to achieve attractive assignments and career success. In this chapter, I will therefore teach you the basics about winning engineering projects for your company, which centers around something called the “proposal.” Team exercise: proposals, the Heilmeier questions, win themes
6 Organizing and planning. Congratulations! You have been named the manager of our new engineering project. What do you do next? You decompose the work entailed in performing the project into smaller pieces, using a hierarchy. When this is done in a particular fashion, it is called a work‐breakdown structure. Projects all over the world are managed using a work‐breakdown structure. In this chapter, I both teach you the basics of creating and using a work‐breakdown structure and show you how to do it effectively within the specific context of engineering projects. Then, we move on to discuss the organizational structure of your project, and finally, I show you how to use your work‐breakdown structure as the basis to create a complete project plan for your engineering project. Team exercises: the work‐breakdown structure and its essential components
7 Creating credible predictions for schedule and cost. In Chapters 2 and 3, I provided you with insight about some of the key factors regarding how we do engineering on projects. We will now use that knowledge as I start discussing the processes that we use for performing actual project management on our engineering project. In this chapter, I focus on the activity network, which allows us to make credible predictions regarding the schedule (that is, how long it will take us to do all of the work entailed in our project). We will also see how this same activity network is an essential first step toward estimating how much our project will cost. Predicting schedule and cost in a credible fashion are among the basic expectations for a good engineering project manager. Team exercise: the activity network as the primary schedule management artifact; exercises in creating an activity network, including three‐point (optimistic, nominal, and pessimistic) durations for tasks in an activity network. Characterization of the magnitude of the impact the use of such three‐point estimates has on the outcome, in contrast to the outcome using single‐point estimates
8 Drawing valid conclusions from numbers. Invalid data and poor statistical methods can lead to bad decisions! There are many ways for an engineering project manager to make mistakes, but one of the most common and most insidious is through making logical and procedural mistakes that cause us to draw erroneous and invalid conclusions from quantifiable data, and as a result make poor data‐based decisions. As engineers, we measure things, and then we often make decisions based on those numbers. For example, we predict when our project will be done, how much it will cost when it is done, and what the technical capabilities of our product will be (e.g. how far will our new airplane be able to fly safely without refueling), and use those data to make decisions for our project. Whenever we use numbers, however, there is a chance or error: our measurements always involve uncertainties, a particular assumption is only true under certain circumstances, we may not have collected appropriate samples, and so forth. In this chapter, I show you the most common ways that we undermine our own credibility through poor data collection, errors in logic, procedural mistakes, weak statistics, and other errors, and how you can instead use valid methods and strong statistics to create credible predictions for all of our project management roles and measures. No facilitated lab session this week; this is often the time for a mid‐term examination
Optional team exercise: building and using a control chart; the five tests that separate signal from noise
9 Risk and opportunity management. Some things can (and probably will) go wrong on your project; how can you still get the job done? Every human endeavor entails uncertainty; things may not go as planned. In light of that uncertainty, how do you get the project done within the promised parameters, such as schedule, cost, technical capability, and so forth? In this chapter, I show you how to combine good engineering and good statistics in a manner that allows you to cope with these uncertainties. Team exercise: risk management
10 Monitoring the progress of your project (part I). Once you have created a great project plan, you can start work on your engineering project. You now need a set of tools and mechanisms to allow you to monitor what is going on, and to determine if progress is as expected (or not!). In this chapter, I show you how to assess progress on schedule and cost. I also introduce you to the principal financial measures that your company will use to measure the business performance of your project. Team exercise: earned value
11 Monitoring the progress of your project (part II). There is much more to monitor on your engineering project than just schedule and cost (although sometimes it will seem like those are the only things your boss cares about!). In this chapter, I teach you a comprehensive method for monitoring schedule, cost, technical capability, and risk … and to make sure that all of these parts fit together correctly. Since on most projects your contract will require you to assess progress at least once a month, I used to call this method the monthly management rhythm, but have (reluctantly) switched to the more general phrase “periodic management rhythm.” Team exercise: the monthly management cycle
12 Four special topics
  1. (a) Congratulations! You have won a competition for a new engineering project. How do you go about getting this new project started? Starting a new project turns out to be a special problem that requires a special set of skills, which I will teach you in this chapter.
  2. (b) Most systems today have large amounts of software, which provides particular benefits, but creates many particular liabilities and risks too. I show you how to deal with projects that involve large amounts of software development.
  3. (c) People will come and ask if you are going to use agile software development methods on your project. I show you some of the key differences between agile and conventional development methodologies, show you how to decide if your project is suitable for agile methods, and show you how to cope with some of the most common risks and weaknesses of the agile methods.
  4. (d) Projects are defined as temporary activities, so every project ends. I tell you what you need to do to end a project.
Team exercise: project start‐up
13 The social aspects of engineering project management. It is a cute cliché that engineers lack social and interpersonal skills. In actual fact, being a good engineering project manager is a highly social activity, and you will find that exercising effective interpersonal skills is in actual fact an important part of your success as an engineering project manager. In this chapter, I teach you what you need to know: aligning and building an effective team, motivating and inspiring people, managing conflict, and other topics. The good news is that we engineers can actually learn to do this aspect of the job just fine … despite the clichés.
I will then discuss how you can get ahead in your career. I conclude with a couple of special topics: how to deal with the special problems presented by those projects whose work is geographically distributed across more than one work site, and those projects that include teams located in multiple countries.
Team exercise: the social aspects of engineering project management
14 Achieving quality. Many engineering textbooks teach that what you need to focus your management efforts on are schedule, cost, and technical capability. In the real world, that is insufficient. Factors such as reliability, safety, low latent defect rates, and “environmental friendliness” increasingly play a role in product and company success. In this chapter, I teach you the basics of this aspect of your role as an engineering project manager, which we group together under the title of “quality.” The facilitated lab sessions in this week are used for student team presentations
15 Applying our ideas in the real world and ethics in engineering. In many aspects of engineering and engineering project management, there are factors in tension with each other. In fact, we have seen many examples of this throughout this book: making the airplane lighter achieves better fuel efficiency, but makes the plane more expensive; hiring more people for your project might get it finished sooner, but probably increases the total cost at complete. Every engineering management process that we have discussed is subject to similar tension when you go out into the real world and try to apply it. In this chapter, I help you understand how to use these techniques within the limitations of actual people, companies, and customers. I also discuss the sort of knowledge that you will need to acquire on a continuing basis as you move through your engineering project management career.
I conclude with a discussion on the important subject of ethics in engineering.
The facilitated lab sessions in this week are used for student team presentations