CHAPTER 5

Principles of Project Management

Introduction

One of the unsung advantages of any standard technology is how much innovation it stimulates, that is, innovation that complies with the standard. As discussions about dominant designs pointed out, once one appears, innovation that does not comply with the standard tends to drop precipitously. Not until a radically different idea comes along, does the standard become replaced or, at least, radically revised. This is true about just about any kind of standard.

The closest thing to a standard approach to project management is that of the Project Management Institute (PMI) in the United States. It publishes and periodically revises A Guide to the Project Management Body of Knowledge, or PMBOK, which itself is an ANSI Standard. The PMI also provides an accreditation to university programs, and most, if not all, project management textbooks adopt it as a main reference in any case. The Project Management Professional (PMP) certification is generally recognized as the most prestigious of its kind, and many contracts require it of project team leaders. The PMI also awards a PMP and other competency-specific certifications and publishes other standards that are directly related to this book: risk management, portfolio management, schedule, cost, and others. In short, PMI is considered best practice globally.

The PMI paradigm is universal and accommodates virtually any project, including the kind of capital projects considered in this book. However, neither the PMI library nor the general collection of university texts published by others nor the popular press does much to provide detailed guidance about capital project finance. It was this observation that largely motivated the development of this series. To help complete the picture, this chapter outlines the PMI paradigm with capital projects in mind.

After Studying this Chapter, the Reader will be Able to

Explain how a project management approach is well-suited to managing capital projects individually and in portfolios.

Describe various ways a firm can be organized for project management from the top of the organization chart.

Give examples of why managing trade-offs is at the heart of project management as an organization wide capability.

Critique the relative importance of the knowledge areas under different management scenarios.

Define: project, scope, charter, statement of work, constraint, and deliverable.

Project Management as an Organizing Principle

Many corporations are organized by division, product line, or industry served, and each of these is hypothetically a representative of a different asset class (see Volume II) by which to consider systematic project risks in discount rates and hurdle rates. In this section, the general assumption is that this has already been accomplished if appropriate. In other words, most concerns from there are intra-divisional. With that assumed, the discussion will proceed using a basic rubric for organizing projects that first poses two extreme cases, and then something in the middle. The two extreme cases are the pure project organization and the classic functional organization, and the compromise in the middle is called the matrix organization.

Interested readers should consult the vast literature known as the organizational theory (Daft 2004; Scott 1993). This field is not the same as organizational behavior. The former focuses on organized groups on the whole, while the latter focuses on human behavior in groups. Both fields have been central contributors to management for over a century (Wren 2003).

The Functional Organization

As the industrial revolution progressed throughout the 19th and 20th centuries, technology advanced faster than management could adjust. This happened in several ways, but none was more obvious than about how to organize a scale-based economy, one firm at a time. At that time, the major imperative was to rationalize production or, in other words, make it more efficient. In plain terms, high-tech business in factories was a mess, and compared to the sole experience of running agrarian-based economies, it was far from obvious what to do about it.

It was found that the most efficient way to organize was along the lines of job function, or job specialization, a kind of division of labor. It soon became more than common, for example, for accountants to work in a single department with other accountants, engineers with engineers, personnel people with other personnel people, and so forth. This was not just common sense at the time. The idea went beyond the obvious instance when people worked near each other and were sequentially dependent, for example, along assembly lines. It was also true when mutual adjustment among similarly skilled people enhanced their overall efficacy both as individuals and as work units.

This “economic function” kind of structure also became known more simply as the “functional organization.”

This term has nothing to do with level of competence per se, but rather, refers to the commonality of job functions among its members. It applies whenever people are more basically grouped by skill-based similarities than by their differences—for example, the business guys versus the floor guys. The allusion to somewhat different professional cultures is intentional as well, and it can matter.

In the simplest case, efficiency is a matter of meeting a target level of production while minimizing wasted resources—labor, raw, materials, overhead, time, and everything in between (Fairtlough 1994; Scott 1993).

This is especially seen in mature industries, where cost-based competitive advantage is a common goal, dominant designs exist, regulations abound, configuration management is strict, and “bureaucracy” can choke innovation.

However, where innovation and not efficiency is the imperative itself, things work well (if not best) when people are “taken from” functional units and formed into multi disciplinary teams.

Whether considering a small team working on an operational project with a not-to-exceed budget, or a bet the company capital project working as a separate business unit with profit objectives, sometimes, being efficient is not as important as being effective at accomplishing an output, a result, a strategic objective.

Such a dilemma poses an obvious management challenge. For example, there may be many informal multidivisional teams working all over an organization on an ad hoc basis, without a hint about it on the top-level organization chart. If left unmanaged, some unintended effects can be serious enough to wreck an organization over time, so alternatives are needed.

The Pure Project Organization

By nature, it was never possible for some industries or major lines of business to organize by economic function. This has always been particularly true of what are now called fixed position layout production schemes, where the final product stays in place. This is a kind of production concept where an entire product must be developed not just in situ, but at one exact spot from where it will never be moved.

Examples abound in construction industries. Whole sections such as rook lattices are often partly fabricated elsewhere, and then the sub-assemblies are joined in situ. In fact, there are pre-fabs and trailers, too, that are just trucked to the home site and positioned, though not necessarily forever. Still, it is unusual for a finished house to ever again be moved—or a bridge, or a dam, or a pyramid.

Sometimes, a line of business must have a fixed-position production scheme due to technology alone. Phased or not, then, it is common for each production end-item to be organized as a project all its own, and a whole company can be organized project-by-project even at the top level of an organization chart. This can happen when a final product is intensely customized and very costly, even one-of-a-kind—say, the Hubble Telescope.

When this happens, it can result in what is sometimes referred to as a pure project organization. The geographical imperative for the separation of projects is only meant to be a clear image, however. The same principle can apply if driven by other imperatives, such as the strategic wisdom of keeping each project focused on its own particular market in order to create an atmosphere of customer orientation and response, project-by-project.

Some organizations are organized project-by-project even at the highest level, disregarding the benefits of grouping people by specialization except below that structure.

Such an organizing scheme is inviting to organizations with the kind of capital projects that have been described as bet the company endeavors, which in cases like Tesla (e.g., Roadster, Model 3) are no exaggeration at all. Constraints such as stakeholder transparency, profitability of specific projects, and even keeping Generally Accepted Accounting Principles (GAAP) quarterly or annual reporting can sometimes leave little other option.

In the middle, so to speak, is the matrix organization. The matrix and ideas like it are plain evidence that large and old organizations are indeed capable of learning from more entrepreneurial younglings.

Matrix Organizations

The advantages and disadvantages of the economic function organization and the pure project organization are well studied and understood. The matrix form is a conscious effort to establish a working optimum. Naturally, the textbook matrix is idealized just like the two extremes, and every situation is likely to be unique enough to require some adaptation. In fact, employee training and professionalism are key components, and any organization chart is likely to not fully represent how people get it done. But, the organization chart is still helpful and is the best way to begin an understanding.

It takes a certain ability to think abstractly, but first imagine an org chart that looks like the classic economic function type, and then imagine an overlay of a periodically changing pure project type of organization laid perpendicularly to it. The classical, vertical lines of functional authority intersect at right angles with horizontal lines that connect individual workers who are members of project teams, each led by a project manager. Each economic function is the regular administrative home of all the workers sharing the same specialization that circumscribes the departmental function, but individuals are temporarily assigned the responsibility to respond to the project manager for project-related things.

Now, it must be admitted that assigning a temporary responsibility to someone who is not even a member of one’s home department invites accountability problems alone. This scheme might sound like the invention of pure chaos, but again, many organizations do this successfully, and there is no shortage of empirical findings that explain its pros and cons.

A well-working matrix organization needs professionalism and some modicum of dedication by all involved. Training can help; depending on “common sense” is risky.

Some kinds of conflicts are almost inevitable—role ambiguity, promotion and advancement, changing job locations for short periods—and some personal adjustment is regularly required. Administrative and project managers may experience resource and scheduling conflicts, even among each other. Executives may need to intercede. It is not unfair to say that it is one of those things that works about as well as people want it to. It is not perfect, but in any given organization, it may work much better than either extreme case.

Project Management Overview

The PMI defines a project as “A temporary endeavor undertaken to create a unique product, service, or result” (PMI-PMBOK 2017). This definition is not confined to capital projects, operational projects, business projects, or for that matter, any other kind of formally organized endeavor. For that matter, no organization need exists at all, at least not as usually imagined. It can apply to a personal effort to throw an elaborate wedding, or to build an extension on a house needing subcontractors, or a government endeavor to send a person to Mars “by the end of this decade and return him [or her] safely to the earth,” and just about everything in between. The principles are much the same across the board.

The nature of new product development in the modern era practically makes project management a necessity (Brentani and Kleinschmidt 2015; Sicotte, Drouin, and Delerue 2014).

Again, it is important to define terms. In the definition of a project, temporary is not necessarily the same thing as short term and rarely will be in the case of capital projects. All the term really means is that a project is intended to not last forever, like an operations program, such as ongoing manufacturing. More to the point, projects have serious deadlines for total project accomplishment and then, formal closeout and shutdown. In the author’s view, whereas programs and operations might be said to fail if they ever stop, projects fail if they drag on very much past the original deadline. Nevertheless, the kind of capital projects of interest here are generally of strategic importance and sometimes bet the company.

The goal of a capital project is to make an economically real return on the investment, called economic value-added (EVA). Free cash flow is not EVA, but it is close. Because of impact of time on the cost of capital alone, deadlines matter!

Next, projects are said to be unique, which usually means that their goals are, to some extent, new. Technical uniqueness is not the only kind needed to define a project, but this is generally true. In the present case, discussions have used dichotomies that describe innovation like incremental versus discontinuous, but by no means should uniqueness necessarily be taken to mean discontinuous, radical, or breakthrough. It just means that there is sufficient newness in the overall set of objectives that they require a unique project effort; otherwise, it probably would not happen, or happen well, or happen on time, or happen at acceptable cost.

That said, projects are said to be constrained. A constraint is “an applicable restriction or limitation, either internal or external to the project that will affect the performance of the project or a process” (PMI-PMBOK 2017). The three classic constraints are (technical) scope, schedule, and cost. Capital projects have clear, formal, and relatively non-negotiable deadlines, budgets, and deliverables that can be defined by measurable and contractually enforceable standards. Standards can be formal or de facto, such as might be the case by a dominant design. Other kinds of constraints (e.g., resources, time, and quality) have been added to the classic three, but upon inspection, many of them can be seen to be derivative of time, money, and technical scope.

A typical quip of the project manager is something like “you can have it on time, under budget, or done right—pick two.” This speaks to the real competency set of the project manager, which is to manage constraint trade-offs.

Not only is it a natural reality that a change in one constraint usually affects either or both of the other constraints, but the planning makes it almost inevitable. For example, technology goals are intentionally set aggressive and challenging enough, to not have much slack in them to accommodate any ongoing improvements without a negative effect on schedule and cost.

The same can be said where the main priority is not technical, but a matter of timing, or a matter of available money. In fact, slack, first and foremost, is a technical measure of how long a project can be delayed before the deadline is threatened, suggesting at face value that time, not technology, is of the essence. Discussions in this series note the importance of timing and not speed per se; as well, the importance not only of capital budgeting, but of the cost of capital as the final “hurdle” before EVA and any claim to competitive advantage (stressed in Volume II). In the abstract, then, no one constraint is any more independent, or important, than another when it comes to capital projects.

The PMI Knowledge Areas and Capital Projects

As in any field of management, effective project management is embedded in a strategic context. For present purposes, it does not matter whether the strategy is corporate or business—multidivisional or single-industry—though the main strategic concern for capital projects is corporate, regardless of how many lines of business are involved. This is a hair that no longer needs to be split. As well, many capital projects are such major endeavors that in print, one can seem like a mixture of a strategic plan and a business plan, all in one project proposal, complete with a mission statement and its conceptual derivatives like clear strategic objectives.

By dint of thinking through constraints and their trade-offs, a major capital project planner is almost forced to make clear what the plan will do and by clear exclusion, what opportunities it will forgo down to relatively small scheduling and budget details. This is characteristic of any good strategy, information permitting. That said, it is natural to first consider project integration as the first knowledge area in the project management (PM) paradigm.

Project Integration

This label is more or less self-explanatory, considering all there is to manage. This is where managing constraint trade-offs becomes a constant challenge. The trade-offs are not only among the major constraints, but over time. Consider first, this view of investor concern as a beginning point for strategic planning for say, the upcoming year 2018:

A lesson to take from the preceding excerpts is that some better planning may have avoided production hell at Tesla. Uncertainties were rife, and many difficulties were difficult to foresee, but accounts like this do suggest that Musk underestimated not only the problems of scaling up to mass-manufacturing, but also the transition from design to manufacturing writ large. Risk management is one of the most important knowledge areas in the PM paradigm, and managing the integration of investment risk and technology risk alone, suggests opportunities forgone at Tesla.

Now, consider scaling up as a project unto itself, that is, focused as much on measurable productivity-efficiency goals as production-total goals. Or possibly, one so concerned with production economics that total production goals were clearly secondary until the scaling-up project was practically completed. In fact, total production goals would become an ongoing operations program immediately thereafter, and not organized as a project per se. It is perhaps the case that overall results would not only have been better, but faster and less costly as well—the three classic PM constraints having served their purpose.

The planning, execution, monitoring and control, and closeout (i.e., the project lifecycle) of capital budgets is well-served using PM principles.

Project charter. Some capital projects are so strategic that a sense of fiduciary responsibility alone should compel the most professional approach and set of available techniques. In such cases, it is wise to have a single, clear document that serves little other purpose than to provide the official authorization to begin a project, deploy resources, and begin work. Such things should not be ambiguous, not the least of which is investor interest.

Some capital projects warrant their own mission statements, and the kind of matter that appears atop a strategic plan. The project charter may be thought of as an elaboration of a complete mission statement, complete with strategic objectives.

The project charter is normally a separate document a few pages long, articulating: (PMI-PMBOK 2017):

Project purpose or justification, including financial goals;

Business needs, including a high-level project description or business proposition;

Measurable requirements that satisfy customer, sponsor, and other stakeholder needs;

Initial project Scope Statement which at least implies the major project deliverables;

Assigned Project Manager and the key team members;

Summary budget and milestone schedule;

Organizational, environmental and external assumptions and constraints.

To emphasize the point about its strategic relevance, a charter is normally signed by the principals, though, of course, the legal implications of that would be more limited than a signature on any legal contract. A legal contract, remember, involves the delivery of a good or service for some form of compensation, monetary or otherwise. As long as all signatories agree on terms, free of duress, there is not much more to the legality of what constitutes a valid contract.

Statement of work (SOW). In the logical flow, next comes a statement of work. According to the PMBOK, this is “a narrative description of products, services, or results to be supplied.” The SOW should be plainly derivative of the charter, and almost painfully so. Altogether, the SOW defines the scope of the project, and remember, scope is one of the major constraints of any project. Whether or not the SOW contains a clear and summary scope statement (which is common) and then proceeds to elaborate about it, by its nature, the SOW circumscribes a project scope. A typical SOW is many pages long, but at the same time, is extremely concise and succinct for the sake of clarity alone.

As to the elaboration of project scope, the typical SOW contains a carefully numbered hierarchy of short pithy paragraphs that have the effect (as well as an eerie feeling) of a contract. A main purpose of the numbering scheme is for quick cross-referencing among legally and contractually important documents; then, as the logic continues, down to individual schedule and budget line-items, earned value management (below), and even job descriptions of key team contributors. It is not too much to expect every member of the project organization to know exactly what paragraph(s) of the SOW one is working on, if, for no other reason, so that the person understands the scope of what labors are to be expected and what would be out of scope. This expression is common and is a guiding star used for many purposes.

PM plan. In between writing a project proposal and a project plan, there may be additional documents required beyond a charter and a SOW, but the main points have been made. An understated point aforementioned is that external stakeholders, like investors of capital, need to be considered up front. The project plan is more utilitarian perhaps; it is referenced and used every day for proper execution, monitoring control, and so on throughout the project lifecycle. The “baseline” plan is a term that refers not to the original plan, but the most recent, formal, and official plan, as it will probably be revised from time to time. It is the current plan that reflects the present, updated scope and so forth.

Therefore, it is wise to assign some meaningful, dedicated effort for its maintenance and coordination. An obsession with the plan can certainly become counterproductive when innovation is part of the scope of a project—a major theme that runs throughout this book in fact—but legal and stakeholder issues at least need satisfaction.

If it has not been articulated as yet, near the top of the project plan is a clear scope statement, often accompanied by a list of major deliverables, outcomes, or requirements. Such things should be written in measurable terms, at least definite enough to enable further translation into contractual and engineering specifications, quality assurance parameters, and perhaps most importantly, customer sign-off and acceptance criteria at time of closeout.

Developing estimates of project returns, that is, free cash flow and all that it entails, is highly dependent on the articulation of the scope.

Project Scope

Managing the project scope, not just articulating one, is one of the main PM knowledge areas. The PMBOK defines scope as “the work that must be performed to deliver a product, service, or result with the specified features and functions.”

Another important word is deliverables: “Any unique and verifiable product, result or capability to perform a service [internal to the project or to the end-user] that must be produced to complete a process, phase, or product.” The word deliverable is part of everyday PM jargon, at every level and by most people. Partly, this is because deliverables are major contractual outcomes that also serve as the basis for schedules, budgets, quality goals, and so on.

A deliverable is something that can be measured and quantified as being delivered to that measure. The measure can be something entirely unique such as a design (engineering) specification, or perhaps a simple reference to a broad ISO quality standard (especially for processes), or anything in between. Here, the allusion to technology standards and dominant designs is intentional. As such, the deliverable description should provide guidance as to monitoring and control throughout the project, and legal or contractual sign-off at project closeout.

Project scope statement. The project scope statement serves as an important referent over the project lifecycle, whereas previously mentioned scope descriptions are somewhat more abstract and only need to serve the purpose of the immediate document. The project charter, for example, is mainly used as the official documentation for project approval and authorization to deploy resources, so the scope description there only needs to be enough for that purpose. In the project plan, more is generally needed in order to provide ongoing guidance to just about any project stakeholder. It is the initial arbiter of misunderstandings about what is in scope, and what is not. It should be updated and officially revised along with other living management tools like the baseline plan.

Work breakdown structure. One might think of a work breakdown structure (WBS) as an exact derivative of the project scope statement, fully elaborated and in a hierarchical format. Before continuing, however, it is important to realize that the WBS bears no necessary connection to the organization chart, an important subtlety in the following definition: “A deliverable-oriented hierarchical decomposition of the work to be executed … The WBS is decomposed into Work Packages. The deliverable orientation of the hierarchy includes both internal [process capabilities] and external [end-user] deliverables.” If the WBS seems a bit inconvenient, that is, if the formal organization chart differs and will create work flow issues, then the organization chart should best be modified, not the WBS. Of course, this is not always practical, so there are ways to handle this. At a high level of organization, there are methods such as the matrix approach described earlier. At lower levels of organization, especially when the time comes to assign duties to specific individuals, there are tools like the responsibility assignment matrix, described later.

It is important to develop the WBS to explicate the scope statement, as it has been articulated into a set of deliverables. A WBS is not an organization chart per se.

That said, a work package is: “A deliverable or project work component at the lowest level of each branch of the Work Breakdown Structure. The Work Package includes the Schedule Activities and Schedule Milestones required to complete the Work package deliverable or project work component.” Here is further convincing about how important it is to maintain the organization of the WBS, not the organization of the firm. The full litany of work packages becomes the lowest level of “line items” on budgets and schedules. If one wants a workable schedule and budget, it is clearly better to maintain a tight accordance with the unique set of deliverables, and not just mimic the standing administrative structure of the local departments.

Hypothetically, GigaRobots suggests an imaginary, dedicated, managed project of installing robots at the Tesla Gigafactory. Emphasis on production, not product development, is intentional because of the plight that Tesla got itself into by Musk’s own admission—“we were idiots.” Now, it must be admitted that enormous external pressures on Tesla did emphasize production totals over productivity, so things like Project GigaRobots would not get priority in such an environment. But a team dedication to such a project might at least keep new capital equipment from being hung from the ceilings as a temporary fix, as happened at Fremont!

Apart from that, these discussions consider capital projects that can be so large, and be so long lasting, that a unique organization must be created and maintained anyway. In that case, as they will both come and go with the fortunes of the project, there is more opportunity to set the project organization chart so be so customer-oriented, that it looks much like the WBS. In that case, a project-specific organizational breakdown structure (OBS) is “A hierarchically organized depiction of the project organization arranged as to regulate the work packages to the performing organizational units.” Now, perhaps, building the entire Gigafactory may enable a clear picture of a distinct capital project that (again, hypothetically) might be funded by, say, a separate bond issue. For example, preparing the property, building the plant, and installing the equipment (the capital PPE on a balance sheet, not coincidentally) intuitively lends itself to an identity of WBS and OBS, where at least identical budget management provides transparency that serves all stakeholders.

This leads naturally to the consideration of scheduling.

Project Schedule

Managing schedules is a major contribution of the PM profession, and one might say “is where it all began” with Henry Gannt, a disciple of Frederick Taylor over 100 years ago during the “Scientific Management” era of the Industrial Revolution.

We still have many charts from those days that Henry Gannt invented and perfected. Today, computerized tools such as PERT and the critical path method, resource loading and balancing, buffering techniques in the resources constraint theory, fast-tracking and slack reallocation, and integration with budget tracking, are all advanced in the PM lexicon. There are plenty of available software tools to help, including server-based capabilities for managing many projects at once—perhaps as portfolios. The implications for managing PM organizations (PMOs) and corporate strategy should be obvious.

Delays in capital projects can easily ruin the business propositions promised in proposals because they change cash flows, the time value of moneys, the true cost of capital, and overall financial results. Scheduling uncertainties is a serious risk factor that can ruin project returns for no other reason than the impact on discounting.

Incidentally, this reality illustrates a vitally important integration task, that of managing schedule and cost (or capital) constraints together—in a way, as one problem. Investors readily depend on project deadlines to be met on time to gage their own investment risks and results. Related in a very big way to project success at meeting deliverables, there can be serious legal ramifications about statements that provide guidance during official and formal quarterly calls. So the one problem here, is a legal one:

Not very long after articles like this appeared, Tesla was sued for making impossible delivery promises, not just ambitious ones. It can never be stressed too much that market cap and the price of corporate stock reflect future expectations, not recent results. The issue at Tesla was not settled by the time of writing, but the suit alone makes the present point, which incurs major moneys just to manage and settle.

Project Cost

After all the discussions about capital, capital investments, costs of capital, and the rest, little needs to be said about the importance of this constraint. Perhaps, a main contribution is simply to place into the PM consciousness at large how important the costs of capital, hurdle and discount rates, and the effects of time itself, are all so influential to generating free cash flow and satisfying the true owners of the capital being deployed.

There is no such thing as “profit” on a project, really; it is all about free cash flow that contributes not only to accounting profit (earnings), but also economic profit, EVA.

Recall when Tesla was really nothing more or less than the project to field what would become the first Roadster. It is hard to imagine something simpler in the present story and context. Even at that time, and even if strict project management had been employed, there would still be an accounting distance between project outcomes and overall company outcomes. The mere reality that the founders had already incorporated assures this as a matter of fact. There is no such thing as project profit, properly understood, and it matters when capital is externally sourced at the least.

Earned value management (EVM). That point stressed again, next, it needs to be said that EVM should not be confused with EVA. The term earned value itself bears a difficult connection to the true economic meaning of value (Martinsuo and Killen 2014).

Without trying to connect all the dots between final corporate EVA and project-budget EVM, there is no doubt that good EVM should contribute to EVA. In fact, EVM can be a key value-adding competence in a project integration capability, especially a PMO.

The overall point of EVM is to provide a composite picture of how the three major project constraints are faring, so intuition alone assures this as one of the effects of good EVM. EVM is a bottom-up technique that takes much time and effort.

It has already been noted that the work package is the lowest level of distinction in project budgets and schedules, or at least the lowest level that is needed for EVM. Each package is carefully monitored for progress in terms of technical accomplishment and cost, which is one good reason to get a good PM software package. From there, ratios of accomplishment versus costs are constructed, which is another good reason. These are basically bang for the buck measures that provide drill-down visibility.

As the level of analysis builds from bottom to top, overall indices are created that track progress. These indices are the basis for developing graphical reports used at major review. The following figure provides an example. Its neatness belies all the imaginable what if’s, of course, once one understands that the curved lines are plots of ratios and indices, constructed from work package data from the bottom-up. See Figure 5.1.

Figure 5.1 EVM summary chart

Project Quality

The PMBOK defines quality as “The degree to which a set of inherent characteristics adheres to a set of requirements” (PMI-PMBOK 2017). Here the PMI borrows heavily from the corpus of quality management research (Greasley 2006; Heizer and Render 2005; PMI-PMBOK 2017; Stevenson 2009). A main contribution of the PM field is to place quality management tools, techniques, methods, and so on into its overall paradigm of management process flows. The consequences of quality-related problems in new technologies and industries—and companies like Tesla—hardly need explaining, but illustrations help:

Now, it must be said that quality management and its set of tools are heavily oriented toward operations that are repetitive, such as in mass manufacturing. Familiar tools include statistical sampling, design of experiments, and control charts. This is excellent as far as it goes, but recall that the definition of a project insists on some level of uniqueness. It is common for a project to only produce something that is one of a kind. Countless capital projects serve as cases in point such as, for example, productizing the Freemont factory as a manufacturing dreadnought. For that matter, anything with the words first-mover advantage attached—meaningfully and not blithely attached, that is—must, by definition, be similar.

Most of the capital projects in these discussions imply a significant amount of uniqueness and indeed, true innovation whether it be incremental or discontinuous. In such cases, the risks differ, and this affects investment risk and hurdle rates.

Here, the reader is referred to Volume II for discussions about capital projects as real options. What emerges from this view is a strong need in management itself to develop a combined capability in technology risk management, quality management, and capital project finance. Consider:

Such an accomplishment is unique and does not happen as a matter of course, or as a fortunate happenstance of everyday operations. Still, the Tesla story makes plain that unless something about it precludes the competition from doing much the same at reasonable capital cost and within a reasonable time frame (to at least catch up), there is no first-mover advantage per se. It did not take long for VW, Daimler, Nissan, Toyota, GM, and even SAIC to come out of nowhere even in this massively capital-intense and capital-costly field.

The double-edged sword of depending exclusively on high quality is that “the good is the enemy of the best,” and even the definition of “best” is always elevating. Quality-based, time-to-market based profits are short-lived, unless a firm has the organization wide capability of consistently and sustainably being first; this exemplifies profitability and sustained EVA, and high returns to capital employed.

Project Staffing

Technically, the PMI calls this knowledge area project resources management, though even then the issue is really HR as it directly relates to PM. To be more avant-garde about it, though, one might also draw the distinction between intellectual capital and other forms of capital such as money, land, and equipment. That would certainly be in line with the main themes of this series, which all come down to making a return on invested capital in the broader idea of how capitalism works as an economics theory.

No form of capital should take precedence over any other, especially in an information-driven economy. “Intellectual property” is no misnomer in the modern understanding of capitalism.

Anyway, upon inspection most of the project-specific issues seem attuned to the problem of staffing—but throughout the entire project lifecycle, not just the more specific issue of internal or external recruiting. Staffing is a very critical issue as it concerns initial project team formation, but the team composition can easily change over time. As most of the kinds of capital projects considered here are truly multi disciplinary in nature, project managers are themselves constrained to finding a very few people of high competencies in their respective fields. Moreover, the portfolio of competencies in any long-term capital project is likely to evolve over the project lifecycle, and for more than the obvious reasons. Consider:

Assuming the preceding recruiting proved successful, each person would seem to be a very valuable asset. How should their work be allocated in a way that precludes competition or their services?

The RAM. Many project team members are formally assigned to more than one project at a time. Not only is getting the right people a challenge, then, but getting enough of their time allocated to a project is another. Again, anything approaching matrix management should be accompanied by some training of managers as well as individual team members.

A tool that may help is the responsibility assignment matrix (RAM). See Table 5.1. It shows how individual members of a project team can be assigned to specific roles toward the accomplishment of various work packages and deliverables. One may find the slicing and dicing of roles a bit too fine or impractical in this example, but the idea right now is about planning the project HR along with and as part of planning budget, schedule, and the rest. See Table 5.1.

A tool like this can also help initially plan labor as a resource while providing good visibility into who should be doing what as it relates to the lowest-level schedule line-item, budget line-item, and EVM, that is, down to the level of the individual work package, each package subordinate to a deliverable. Once a project is off and running, it is more the case that team members will act smoothly as a unit. Still, things can drift and get confused on long projects, especially if there is turnover, and the RAM can be used to get back on track. In contrast:

At the latter end of the project lifecycle, there are closeout issues that are not to be mishandled. Assume for the moment that a Project 5,000 had been organized to accomplish the aforementioned milestone months earlier and that now, borrowed people could go back to their regular jobs in Nevada and so forth. Or, consider the potential for confusion when it comes time for formal performance appraisals from one’s real boss:

In some industries, it is not uncommon for the closeout of major capital projects to include layoffs, even when a project has been very successful. In a matrix organization, an individual may at least take solace in the probability that another project is right around the corner, and that one’s career contiguity is already in the planning. Project team members and managers alike should take into account that they will probably work with each other again.

Project Risk

The PMBOK (PMI-PMBOK 2017) defines risk as “An uncertain event or condition that, if it occurs, has a positive or negative affect on a project’s objectives.” First, it is interesting that this definition says that uncertainties can be either positive or negative. As counterintuitive as that might sound at first, it does open the mind in a good way. One immediate practicality is that there are strategies for both positive and negative risks.

Second, it helps avoid a common error that is easily fixed with just a few seconds’ thought. The error occurs where managing risks becomes confused with managing crises. In an important sense, they are opposite. Without torturing the obvious, the uncertainty of any event applies to its future, not its present. One might say that when risk management is perfect, crises never occur, but, this is not to say that bad things never occur. It means that the planning has been good enough to keep urgencies manageable short of panic, injury, catastrophic cost, and so on.

A main objective of managing an uncertain future event—in the present—is to avoid a future crisis from ever occurring.

Still, despite the best planning, events do occur without enough warning to manage well. Contingency plans, budget set-asides, and scheduled time buffers are often wise to incorporate in plans. However, there is no such contingency called just in case, unless perhaps one is thinking of a black swan event.

By way of contrast, (a) a black swan in business lingo is an event that could not have been foreseen, a kind of unknown-unknown in the jargon, while (b) a random event is one where its probability of occurring is the same as any other alternative possibility, a kind of known-unknown.

Even a random event has a manageable probability. Lightning strikes and some kinds of auto accidents are examples; for that matter, lightning actually striking an auto is a random event, as opposed to, say, an auto striking a pedestrian versus a telephone pole. It does help to understand this if one has at least a good intuitive sense of probability theory, if not a bit of training. Still, there is an ordinary point to this, soon.

A random event is not one where the probability of occurrence is very low for example, miraculous. An event is random if its probability is the same as the probability of any other possibility. The flip of a coin is a random event, but after all, the probability of either possibility is a very known, dependable, and manageable 50 percent. Guessing heads and winning is no miracle, at least not in Vegas.

To apply this lame attempt at whimsy, when it was suddenly (in the media, anyway) realized that there was plenty of lithium in the world, completely reversing the prior expectation of its encroaching rarity due to demands for batteries of many kinds, that was a black swan event to anyone invested in lithium as a commodity (the commodity price plunged). Nobody saw it coming, but we all know stuff happens even when it comes completely out of the blue (with apologies, another confusing lightning reference).

In contrast, which battery advancement (or type) would someday replace present-day lithium technology due to the mythical technological breakthrough (always rumored to be a year away) should be considered random (as the rumors were so unreliable, and because the number of firms involved was large and yet, because many such efforts were done quietly, if not secretly).

Now, imagine yourself being a project risk manager at an auto firm. There, just in case is not a tool, it is a short cut. It should be plain that managing a future black swan, now, is still not only a possibility, but a responsibility. However, its nature requires a different tool than events that have estimable probabilities, to include random events, where methods like actuarial analysis serve well historically.

“Risky” events differ in their basic (e.g., probabilistic) natures, first and foremost, not just their kinds (e.g., financial versus schedule).

Now, more for general interest, intuitive closure can be reached on an earlier point. A contingency reserve is not a slush fund. Such thinking really applies to black swans, and black swans are not contingencies. Contingencies are known to happen, even if they happen randomly. In contrast, slack in schedules or anything else (here, budgets) applies to managing probabilistic contingencies.

Slack is a valuable resource, not a waste of time; the idea applies to slack of all kinds. It is a matter of project efficiency and the productivity, hence profitability, of capital.

The summary point is that it matters to proper risk management that the proper tool be applied to the nature of the problem, not just the kind. There are different tools and techniques for assessing each in the very broadly dispersed risk management literature. There is no single scholarly corpus covering all the possibilities, so readers are invited to explore their fields.

Financial risk is one kind, though it can then be understood as being characterized by the natures of various subcategories. For example, to a financier used to Capital Asset Planning Model methodology (Volume II), systematic asset risk is not the same in nature as inflation risk, though they are both measured in compatible ways, and can literally be added to determine a discount rate. More broadly, later discussions in this series outline how to handle the investment risks due to the nature of capital projects, building from scratch starting, say, by considering the time value of money, namely, the risk-free rates of government treasuries, to adopting complex asset pricing models for managing whole project phases as financial options. There are whole categories of other risks to consider, but they all relate to investment risk in the end: technology risk, political risk, market risk, economic risk, … not to mention the competition. Consider:

That article sums up the entire Tesla story about as well as any other, and the one thing that leaps out at the reader is the complexity, not just the enormity, of the risk(s). Certainly, a rational method of sorting it out should help. There are several.

The most common rubric for managing risk is to imagine future events along two dimensions. First, and as one should expect at this point, there is the actual, statistical probability of the uncertain future event occurring. Second is the qualitatively assessed impact of the event should it occur at all.

The risk of a future uncertainty, to be managed today, is the probability ¥ the impact.

Of course, it is technically impossible to multiply a probability times a qualitative measure and get one number, but this is beside the present point. The two basic parameters are often considered to be two orthogonal axes (independent of each other in principle), which is commonly illustrated by using a matrix like the one shown next. What has been added here are the boldfaced risk strategies or policies in the boxes.

For example, if during the design stage of an important subsystem component, an engineer, safety analyst, or the like realizes that all the suitable components available from suppliers have worrisome reliability histories, and that if the component should fail, there will be injuries, then the obvious strategy is to do something at that point to disallow it from ever happening. In such an instance, the understated word for this a policy (see the table 5.2) is avoid. Options include, on the probability side, reducing the likelihood to near-zero, say, by designing a superior component internally with much better reliability, or, on the impact side, change the effect by designing a fail-safe feature, such that when the component fails, it does so without anybody getting hurt—by design. Either solution is adequate in terms of the word avoid and compliance with its inferred policy.

At the other corner of the matrix, assume that the same, superior component will also be used in another subsystem, where it will have a low probability of failure, and when it does fail, there is no meaningful immediate effect. By policy, as a matter of planning that is, the economically best thing to do about the system design is nothing, except perhaps to make sure the component can be readily and economically repaired or replaced.

As disturbing as it may seem to the novice to just let things fail as a matter of planning, one can observe that many, if not most, failures in life are managed in much the same way. Controversies surrounding preventive health care and its insurance provide a sterling example. One does not plan to fail, but failing to plan is another thing entirely. Once more, we see the management of constraint trade-offs emerging as a real competence across-the-board.

The nature of failure is handled by a policy consequent to its overall risk. The matrix is not an ex post diagnostic tool, it is an ex ante, policy determination aid.

Procurement and Contracting

The importance of supply chains surfaced over and again in the Tesla story, from the very beginning with the relationships with ACPropulsion and Lotus, to the last when Musk complained publicly to investors that the company needed to regain control of its many contractors for cash flow purposes alone. Especially in the kind of capital projects being considered, managing supply chains is of paramount importance from the standpoint of finding, certifying, and bargaining with contractors, to determining the number and nature of collaborative relationships, to vertical integration and outsourcing strategy, on and on down to include the need to handmade components during the final assembly stage. Also, the acquisition of capital equipment (not just vehicle parts, and not just whole companies and Gigafactories) was in the balance. When it all comes down to it, everything, except the purest service, is logistical.

Because the procurement and contracting function is the one that directly interfaces with external providers, there is scant room for sloppiness. Not only is cost at immediate issue, but so are many legal considerations. Consider:

A great deal of work is generally needed just to identify qualified suppliers, and legal statutes governing the fairness of these processes exist at all levels of jurisdiction. There are also industry-specific standards and of course, international. The bidding process itself can be quite rule-bound, and here is where contracting people often refer to RFPs, which stands for request for proposal, an important precursor to letting a final contract for important and costly things. The issue not only about raw materials, but property, plant, and capital equipment—the PP&E that appears first as fixed assets on balance sheets, and which constitutes the majority of the investment capital in many cases.

There is no more important business function than procurement and contracting toward making positive free cash flow at the project level, and EVA at the corporate level. This is where the economic theory turns into final numbers on the cost side of the equation, at least. Luckily, there is no shortage of literature on the matter, and there are many fine professional associations to contact. Many are industry- or profession specific.

Project Communications and Stakeholder Management

Because of their elevated importance in the Tesla saga, these knowledge areas were addressed in the previous chapter.

Conclusion

This chapter complements other chapters and volumes in the series by explaining the basics of PM as guided by the PMI and the PMBOK. The PMI is generally considered to be the global thought leader in this field.

PM is broken out into areas of knowledge, where each can be likened to a managerial competency. Altogether and when managed using portfolio and PMO concepts, it becomes a viable capability and basis for competitive advantage.

The discussion was framed in the more specific context of managing capital projects that are found in capital budgets and are subject to the capital budgeting process exercised in most corporations, whether single-industry or multidivisional. The Tesla saga was extended as an illustrative case study.

Discussion Questions

Referencing any organization of choice, how could a PM approach help manage capital projects individually and in portfolios?

Continuing the aforementioned, what is the relative importance of the knowledge areas as they relate to managing capital projects?

Exercises

Continuing the aforementioned, diagram a project-oriented organization chart, and discuss the pros and cons of your decisions.

Continuing the aforementioned, circumscribe one major capital ­project, identify its major constraints, and note the consequent trade-offs among them.

Continuing the aforementioned, outline its scope, charter, SOW, deliverables, and devise a top-level WBS.