INTRODUCTION

Project success is an elusive goal in every business or technical domain. Examples of project failure are easy to find. Examples of project success are not as well documented. We tend to focus on the failures rather than the successes. It is difficult to look for the root causes of project failure; instead, we tend to write about the magnitude of the failure and how things went wrong. Corrective actions are rarely discussed based on an assessment of the root causes, because the project participants have usually moved on. When we do look in greater detail, the literature shows the primary root causes of failure start with a failure to define what “done” looks like in any meaningful units of measure. Without a measurable assessment of progress toward “done,” we cannot recognize “done” if or when we encounter it. In this book the word “done” has a special meaning. It means the customer is satisfied with the outcomes of the project. The customer must have specified these outcomes up front in the form of a set of capabilities the project will provide, with some unit of measure meaningful to the decision makers—the customer. This is a very specific definition and will be used throughout the book to mean “compliance with all the measures, technical and operational specifications, planned cost, and schedule.”

Most practices, concepts, and language of project management we see today have their origins largely in the United States aerospace agencies in the mid-1950s. They were developed primarily for use on programs such as Atlas, Polaris, Minuteman, and Apollo manned space flight vehicles as a highly urgent response to the need to develop new ballistic missile capability to counter perceived Soviet threats. After that era, these processes were expanded through the U.S. Department of Defense (DoD) initiatives that capitalized on these practices and processes through today’s methods.

Performance-Based Project Management^SM is about successfully managing projects based on those early processes, but with the added concept of “capabilities,” an idea derived from President John Kennedy’s words of May 15, 1961: “To achieve the goal, before this decade is out, of landing a man on the moon and returning him safely to earth.” This statement is the foundation of one of the Five Immutable Principles of project management: “Define what ‘done’ looks like in units of measure meaningful to the decision makers.” Kennedy made this clear: fly to the moon, land, and return safely to earth. That statement defined success. That statement describes what “done” looks like. In the context of Kennedy’s statement, a capability was the “ability” to fly to the moon, land, and return safely. For all projects, a set of “capability” statements is the starting point of describing “done.”

My motivation for writing this book began decades ago when I moved from a career as a software developer on radar, sonar, and embedded control systems to focus on commercial software products. Clear and concise statements of effectiveness and performance guide the development of software and hardware for things that fly, drive, or swim away, and the control systems that manage them. When I moved to the commercial domain, those types of processes were frequently missing—not because the processes were not in place, but mainly because those asking for the projects were not aware of the fundamental need for defining what “done” looks like before starting the project. There were many books, journal papers, and articles describing the technical activities performed during the execution of the project. Many describe how to define strategic initiatives, business mission statements, and measures of performance for the business. But rarely did I encounter a source of guidance that connected the dots between a business strategy based on projects and the management of those projects. In the end, what was missing was a detailed description of how to connect business or mission strategy with project execution using the contents of this book.

Performance-Based Project Management is about the principles, practices, and processes of project management that make those connections. Before I begin showing you how to do this, I need to make a disclaimer. Although people execute these principles, practices, and processes, my focus in this book is not on people in a traditional manner. There are more than enough books about the “people” side of project management. People’s processes change, and so does the underlying technology of managing a project. The team members, stakeholders, and the project managers looking after the project are probably not the same over the life of the project. People come and go. Technology comes and goes. What is “immutable” are the principles and the practices for how to successfully manage a project.

The singular beneficial takeaway of this book is:

How to clearly define the purpose of the project; that is, how to have clarity of purpose,

How to construct the artifacts, or elements, that represent that clarity, and

How to measure the performance of the technical outcomes from the work on the project performed by the people.

Creating a clearly defined purpose starts with identifying the capabilities needed for business success. These capabilities are not just technical and operational requirements, they also are the “value” delivered by the project. However, this value must be measured in units meaningful to the consumer of the outcomes of the project. These are the Measures of Effectiveness (MoEs) for the artifacts and, thus, not just a statement of value, but the actual measures of that value.

Applying these principles, practices, and processes requires discipline. However, before we can have discipline, we need accountability. This accountability starts with making someone accountable for establishing, improving, and complying with the project management processes. These processes are based on practices, which, in turn, are based on principles. That is the message of this book: principles, practices, and processes are all needed for success.

The second aspect of accountability involves the roles and responsibilities assigned to each position on the project, by which I mean the project manager, team members, stakeholders, external resources, and senior management.

To create accountability, we have to convince all the participants in the project that they are actually “accountable” for the outcomes. This is often difficult, since each person involved in the project has to maintain accountability in order to move on to the next two steps—discipline and clarity of the outcome—for the project to succeed. When we fail to be clear about the outcome, the probability of success is reduced. For example, we might end up on time and on budget, but not produce the capabilities we need. Without discipline, it is difficult to apply the principles, practices, and processes, and without accountability, there is no mechanism for applying the discipline that is the basis for all we do in the project management domain.

After you read this book, I believe you will recognize that traditional approaches to managing a project need improvement. You’ll start asking the question, “What does ‘done’ look like?” more often. You’ll start asking the project owner questions about what capabilities are needed before you start developing requirements. Most of today’s approaches to developing products or services start with the technical and operational requirements of the project. This leads to trouble later on when there is confusion about “why” those requirements are present.

Using the approach described in this book, you will be able to answer the five questions that form the basis of the Five Immutable Principles needed to increase the probability of a project’s success:

1. What does “done” look like?

2. How are you going to reach “done”?

3. Do you have all the resources you need to reach “done”?

4. What impediments will you encounter along the way to “done”?

5. How are you going to measure progress toward “done” in units meaningful to the decision makers?

Once you know the answers to these questions, you can apply the Five Practices:

1. Define the needed capabilities.

2. Define the technical and operational requirements needed to implement those capabilities.

3. Establish a Performance Measurement Baseline (PMB) for performing the work that implements the requirements.

4. Execute the Performance Measurement Baseline.

5. Perform Continuous Risk Management (CRM) on everything you do on the project.

Once the principles and practices are in place, what remains are the Five Processes needed to manage the business activities of your project:

1. Organize the project with a work breakdown structure (WBS) and an organizational breakdown structure (OBS) to show what is being delivered and who is delivering it.

2. Plan, schedule, and budget the work needed to produce the deliverables.

3. Account for the time and money used to implement the deliverables.

4. Analyze the variances that result between the planned time and cost and the actual time and cost and measure the physical percent complete from those measures to determine actual progress to plan.

5. Maintain the integrity of all the information so forecasts of the project’s future performance are based on a solid assessment of past performance.

These principles, practices, and processes are neither new nor unique. And they are not applied with any rigor outside the complex project management processes of government programs. What I have done in this book is distill the essence of the formal project management methods found in defense and space programs for application to a broader range of problems. All projects can be managed using the Performance-Based Project Management^® method. No matter the size, complexity, or domain, the principles, practices, and processes can be applied to increase the probability of success.

Performance-Based Project Management is organized in a layered manner, starting with the principles. Before starting to apply the Five Immutable Principles I propose in this book, we should stop and remember H. L. Mencken’s advice: “For every complex problem, there is an answer that is clear, simple, and wrong.” We need a set of principles on which to build our practices and processes.

Those readers who have looked at the contents page know that we don’t jump right into the principles. Instead, in order to ground you, we start with the “drivers” of project success—the mechanics of how projects work. This will help you understand the data of the project, how the data interact, how the managers of the project can use data to make decisions, and how the data influence how these decisions are made.

Once the drivers of project success are in place, answers to the questions asked by the Five Principles can be developed, and, with these answers, we have what we need to confirm that the customer understands:

What “done” looks like

How we are going to get there

What it is going to cost and how long it will take

How we’re going to handle all the impediments along the way

Most important, how we are going to measure all these things to confirm we are actually making progress, not just spending money and passing the time

With the principles in place, we move on to how to do the following:

Develop a description of the needed capabilities to be produced by the project.

Develop the technical and operational requirements that produce those capabilities.

Plan the work needed to deliver those requirements.

Perform that work.

Manage all the risks that result from normal project work.

These practices are connected to the principles through step-by-step processes. The result is a description of what value is being delivered to the customer—the needed capabilities—and how that value is being delivered—both when and for how much. This approach provides actionable information to the decision makers so they can direct not only the work but also the beneficial outcomes.

The final step is to apply Five Processes to manage the underlying activities of the project. We have to know what we are building; who is actually doing the work to build the desired outcomes; the plans, schedule, and budgets needed to produce this work; and the data needed to show the project is actually on plan. These processes are the foundation on which the practices to implement the principles are performed.

With the principles, practices, and processes in place, we need to know how to tailor them to our own projects. Three projects—a personal Unmanned Aerial Vehicle (UAV), a kitchen remodel, and a health insurance provider network Enterprise Resource Planning (ERP) system—are described to demonstrate how the three elements of successful project management are applied. After an overview showing how to tailor the practices and processes, the details of how to implement them are provided so you can put the practices and processes to use on your own projects.

It is important to note that applying the practices and processes, tailored to your own project, results in a set of artifacts that are needed to actually manage the work. This is the final step in changing how projects are managed—moving project management from simply implementing technical and operational requirements to providing the needed capabilities that produce measurable business value to the customer.

With these principles, practices, and processes in place, you are ready to start increasing the probability of your project’s success. For additional information about specific aspects of project management and details not covered here, consult the bibliography for additional source material.