Economics of Engineering Project Management (eBook)

1. Introduction

In my first textbook1, I set out my methodology for engineering project management. There are many goals of that activity, including:

• Creating value for society and our customers, through the timely creation of useful products and services

• Creating monetary value for our company &/or organization, which includes meeting contractual and financial commitments

• Creating a good working environment for our employees

All of these, and more, are discussed in that textbook. All of these are important, although some people have a tendency to focus on the second item (that is, the financial aspects). In fact, we have to achieve all of these goals simultaneously; it is not sufficient just to achieve a good financial result.

But achieving a good financial result is certainly a part of the goals of good engineering project management. In that textbook, I did not discuss certain underlying concepts and procedures relating specifically to finance and economics, as at our university we teach a separate course exclusively on that aspect. I have been asked, however, to introduce certain aspects of engineering economics into this course. Therefore, this slim volume is intended as a supplement to the previous textbook; herein I introduce a set of topics which might be called “the economics of engineering project management”.

I have been a successful manager of many engineering projects, over a period of many years. To achieve that success, I conducted extensive research regarding the economics of engineering projects, developed theories concerning reporting and analysis methods, subjected those theories to experimental test by applying them to multiple real engineering projects, and then gathered data from customers and management regarding what aspects of those theories worked. The theories were then adjusted, and the experiment repeated, all multiple times.

Herein, I have drawn from that research and experience to present just those aspects of economics that I believe have proven relevant and essential to the good management of engineering projects.

Economics is a vast subject, with a huge literature of its own.

The accounting world has created hundreds of economic and financial measures. But what I am going to tell you is that we, in the world of engineering project management, have only to deal with a handful of them. These are all listed and described in chapter 3. This is the first insight for you from this book.

There is another major insight in this book that can help you in your career as managers of engineering projects. The accounting world acknowledges that it ignores certain factors when it makes its calculations; perhaps in the domain of traditional accounting, ignoring those factors is harmless. But I can assure you that in the world of engineering project management, ignoring those factors leads to gigantic errors. I am going to tell you exactly what factors these are that the accounting world ignores, but that we managers of engineering projects cannot afford to ignore. And I am going to tell you exactly how you can do it better.

Furthermore, I have discovered that there are short-cuts that are often taken with data and analyses in the world of engineering project management, too. Our colleagues are, at times, just as sloppy as the accountants. But I have found that these short-cuts, just like those I mentioned above in the accounting world, also lead to gigantic errors. So, I am going to tell you exactly what these “short-cuts” are that are in common use in engineering project management, the disasters to which these short-cuts can lead, and how you can do it better.

A very large portion of engineering projects are cancelled before they are completed. That leads to a lot of wasted effort, wasted money, damaged reputations, and lost opportunities. The causes of these project cancellations are manifold – my own research and experience has indicated that much of the time, an inadequate technical design is the root cause – but many of these problem projects display the trait that their current financial and economic projections diverge significantly from the versions of those projections that allowed the project to be started and funded. Because of this, it is of cardinal importance that we engineering project managers have an appropriate level of knowledge about a certain set of economic parameters, that we know how to create financial and economic estimates that are credible, and can use these metrics in a fashion that helps us manage our projects to a successful conclusion, and do all of these while meeting the expectations of our company’s management. This is what this book is about.

Throughout the book, I will use a hypothetical engineering project to design and build a spacecraft as an example of each concept and term that we are discussing.

Let us assume that this spacecraft is intended to be “the first of its kind”, in some technical dimension; our project must therefore invent some techniques and capabilities. Because we are inventing techniques and capabilities, there is a significant amount of uncertainty involved in our project; we are not just building another spacecraft that is a copy of a proven spacecraft. There is uncertainty, of course, in every human activity, but the need for invention in our spacecraft project introduces an additional, and very significant, type of uncertainty: how do we determine in advance of starting our project the rate at which our team can create these inventions?

In fact, most engineering projects involve this type of creation and invention. Because of this characteristic, most engineering projects necessarily involve a significant amount of uncertainty, which as project managers we express as risk.

As project managers, you have to bring together and supervise the team that is going to create these inventions; that is going use those inventions in order to design, build, and test the product (in this case, the spacecraft); and is going provide all of the associated items and services required by our contract (which might include spare parts, training for customer personnel, data packages, and many other items). But we also have somehow to do all of these things within the constraints of a schedule and a budget, and while attempting to foresee and forestall items that might derail our project. These last are the items that we call risks.

In this context, we use the term schedule to refer to the time-frame over which the project will be performed, and most especially, the date by which we have contracted to deliver the product: the date by which we will be finished. In our example project, this is the date by which we have contracted to deliver our spacecraft. We also use this same term schedule to refer to the artifact that we use to document the time-phased details of our plan for accomplishing that work: tasks and their estimated durations, the timing relationships between tasks, and so forth.

In this context, we use the term budget to refer to the amount of money for which we have contracted in order to do the complete set of tasks defined in our contract. Associated with this total amount of money are the contract terms that specify when we actually get paid, in what increments, and what happens if the project ends up needing more money than the amount for which we contracted. In our example project, the budget is the price for which we have agreed to design, build, and test the spacecraft, and included in that price is delivering the spacecraft to whatever location the contract specifies. This location might be the loading dock at our facility, it might be the loading dock at the customer’s facility, it might be the launch facility, or it might even be on orbit around the Earth. And, similar to the term schedule, we also use the term budget to refer to the artifact that we use to document the financial details of our plan for accomplishing that work: the estimated cost of each task, the materials that we are purchasing, and so forth.

There are additional constraints that we must observe, too. For example, there are laws and regulations that always apply to contracts, and procedures that might be specified in the contract itself, such as the forum and method for resolving disputes between ourselves and the customer.

As the project manager of our spacecraft project, you have to deal with all of these factors. They are all...