Read an Excerpt
Performance-Based Project Management
Increasing the Probability of Project Success
By GLEN B. ALLEMAN AMACOM
Copyright © 2014 Glen B. Alleman
All rights reserved.
ISBN: 978-0-8144-3331-7
CHAPTER 1
The Ten Drivers of Project Success
Project success is elusive. Many books, articles, and professional societies suggest methods that can be used to produce this success, and I believe that anything and everything we read, listen to, and participate in around the notion of managing projects can add value to and increase the probability of a project's success.
Of course, anyone who has been around project management has anecdotes about failed projects and has participated in failed projects despite using the checklists, flowcharts, tools, competency assessments, and certifications designed to improve the chances of producing a successful project. In each of these cases, the project failed because something was missing.
To optimize project success, we need to look to the foundation of all project success, the immutable principles and practices of managing projects.
The Five Immutable Principles of project management success are built on ten success drivers, which are the underlying mechanics of all project work. They are the core processes that take place during the life of any project (see Figure 1.1). The Five Practices used during the management of projects are built on the Five Immutable Principles. The relationship between the principles and the practices is important to the success of any project. Without first establishing the principles, the practices have no foundation on which to "practice." Figure 1.2 shows how these drivers relate to one another. We'll look at them in detail later in the chapter. The principles, which are built on the drivers, and the practices, which are built on the principles, are the foundation of project success. This does not mean success is assured, but it does mean that without them the project has less of a chance of success.
The success drivers are organized into three classes:
1. Planning. We need a plan, a schedule, a budget, a description of the work to be performed, and the order in which that work should be performed.
2. Execution. Once the work is defined and the required order established, execution of the work packages (WPs) can take place.
3. Performance Management. While the work is being performed, we need to measure our progress against the plan. This measurement should be tangible, not just an opinion. The best tangible evidence is confirmation that the planned outcome of each work package actually occurred at the planned time for the planned budget.
Figure 1.1 summarizes the principles, practices, and drivers and their functions. As we proceed with this chapter, we will explore each in greater detail.
Project success depends on doing many things right, each of which must operate as a close-knit system, supporting each other in order to deliver a successful project. It all begins with the drivers of the Five Immutable Principles of project management and the Five Practices that implement these principles. They and their relationship to one another are illustrated in Figure 1.2. Without understanding the drivers, there is no real way to check the validity of the principles or practices. These drivers are found in any project, in any business, in any technical domain, using any project management or product development method.
The Immutable Principles and Practices of Project Success
There is an unspoken question in the project management community: How can we integrate strategic, technical, and managerial processes into a framework based on sound principles, while providing practices that can be applied in a wide variety of domains?
There are numerous approaches to managing projects. Many can be found in books like A Guide to the Project Management Body of Knowledge (PMBOK® Guide), in Prince2®, and in agile software development books. These describe the technical and operational side of project management. The management of cost, schedule, and technical performance can be extracted from these descriptions. Human actions relevant to the management of projects—such as communications, the intent of the leaders, understanding, uncertainty, and the tacit knowledge required to successfully deliver the project's value to the stakeholders—are also taken into account in these descriptions. A recurring theme in all these methods is that good project management practices need to be built on principles. "Best practices" alone are necessary, but they are not sufficient. Practices, even ones built on sound principles, must be effective in the face of uncertainty, confusion, and ever-present change. With this in mind, we need to search for the drivers that are the foundation of the Five Principles. The Five Practices are then built on these Five Principles. These drivers are the source of both project difficulties and project success. When the driver is absent, the project is missing information needed for success. When the driver is present, it is connected to a principle, which in turn is connected to a practice to increase the probability of success. Without understanding of what "drives" success or failure, the project manager has no insight into how to manage the project to produce success. The project manager is unable to "connect the dots" between what is happening in the project and what should be happening to increase the probability of the project's success.
Traditionally, a set of project management activities (e.g., product or service integration, cost, communication, scope, quality, risk, time, human resources, and procurement) is applied throughout the management of the project. These activities focus on the execution of the project.
This approach has shortcomings in our quest to increase the probability of project success. For example, the previous list of project activities does not include project strategy, creation of value from the project, measurement of effectiveness of the resulting outcomes, or measures of performance of the work activities in units meaningful to the decision makers.
The Basis of the Five Immutable Principles
Some people in the field talk about the "basic tenets" of project management. But where do these come from? Some say they come from hands-on experience, anecdotal "best practices," and the good old "school of hard knocks."
According to Webster's Dictionary, a principle is a "general truth, a law on which other laws are founded or from which others are derived." In the project management domain, a principle can be further defined as:
* A rule or law of action based on desirable ends or objectives based on a fundamental set of actions. Principles are the basis of policies or procedures that govern the behavior of the people, processes, and tools used on a project. One common principle is, "time is money." In all project work this is the case. If work is being done, time is passing, and people must be paid for their time.
* A fundamental truth that can explain the relationship between project variables—usually cost, time, or technical attributes. These can be independent and dependent variables in this relationship. This fundamental truth can be descriptive, explaining what will happen, or it can be prescriptive, indicating what a person, a process, or a tool should do based on some known standard. The principle can also reflect a scale of values, such as efficiency, reliability, availability, or other "... ilities." In this case, ... ilities imply value judgments as well as actual measurements. In another example, cost and schedule are directly related through some multiplicative factor. The more time the project takes, assuming constant productivity of the labor, the larger the cost will be for that labor. Quality, cost, and schedule performance can be described in the same way, with the same productivity factors. Technical performance of the planned deliverables is also related to cost and schedule in the same way.
For the principles of project management to be effective, Max Wideman suggests they must do the following:
* "Express a general or fundamental truth, a basic concept ...
* "Make for a high probability of project success. The corollary is that the absence of the condition will render project success on a majority of the key criteria as being highly improbable.
* "Provide the basis for establishing logical processes and supporting practices that can be proven through research, analysis, and practical testing ...
* "Be universal to all areas of project management application.
* "Be capable of straightforward expression in one or two sentences.
* "Be self-evident to experienced project management personnel, and
* "Carry a concise label reflecting its content."
Max Wideman's PM Glossary (www.maxwideman.com) is a great source of information about project management terminology.
The Five Principles
The Five Immutable Principles of Performance-Based Project Management are designed to meet both the definitions of a principle and Wideman's requirement that they be effective. Here, they are stated as questions that need to be answered by the project manager:
1. Where are we going?
2. How are we going to get there?
3. Do we have everything we need?
4. What impediments will we encounter, and how will we remove them?
5. How are we going to measure our progress?
These questions can be applied to projects just as they can be applied to any endeavor from flying to Mars to taking a family vacation. If we use the dictionary definition of immutable, "not subject or susceptible to change or variation in form or quality or nature," we can apply these principles to any project in any business or technical domain.
The Five Practices
The Five Practices, which are derived from the Five Immutable Principles, are used to keep the project on track:
1. Identify needed capabilities.
2. Define a requirements baseline.
3. Develop a Performance Measurement Baseline.
4. Execute the Performance Measurement Baseline.
5. Apply Continuous Risk Management.
The Ten Drivers of the Principles That Enable the Practices
Let's look at the ten drivers shown in Figure 1.2 that are the foundation for the immutable principles and practices of project success.
1. Capabilities drive system requirements. Capabilities provide the customer with the means to generate business or mission value. With these capabilities in hand, the mission or business need can be carried out and the desired beneficial outcome produced from the project. If we understand what capabilities are needed to produce business value or satisfy a mission, we can then identify what technical or operation requirements are needed to deliver those capabilities.
2. Requirements are defined in work packages. Requirements are derived from the needed capabilities by asking and answering the question, "How can this capability be delivered using the technical or operational solutions at hand?" The mechanisms for implementing a capability are described in a requirement. Requirements state the "shalls" of the solution in support of a capability. The requirements are implemented in work packages (WPs), which produce deliverables that are assembled into the capability that produces the products or services needed by the customer.
3. Work packages produce the deliverables. This is where labor and materials come together; it is where the work needed to produce the components of products or services is done.
4. The Performance Measurement Baseline (PMB) describes the work sequence. The PMB is the time-phased arrangement of the work packages that produce usable results in a planned order to produce the desired product or service.
5. Measures of physical percent complete define "done" for each work package. Working software, usable products or services, all measured in predefined units of "physical percent complete," provide the evidence needed to demonstrate that work is progressing according to plan.
6. Work authorization assures proper delivery of value. Keeping the work flowing to maximize the delivered product or service requires a well-structured schedule.
7. Produced and measurable value defines progress. Measurement in units of effectiveness and performance for the user is the definition of value that all projects require.
8. All measures are adjusted for technical performance compliance. Performance to plan is adjusted for the technical and operational aspects of the project, not just the passage of time and consumption of resources. These adjustments are necessary to correct our measures of effectiveness of our cost and schedule. If we planned to complete a deliverable in a specific amount of time for a specific amount of money and that deliverable was not technically compliant, we would have to spend more money and time to finish it. Therefore, we would be over budget and late on the planned day of completion of our deliverable.
9. Fulfilled requirements produce delivered capabilities. With the requirement fulfilled by products or services, the capabilities can be deployed to the customer.
10. Past performance is a forecast of future performance. For all measurements of future performance, what happened before is a good starting point.
The ten "driving" elements shown in Figure 1.2 illustrate the various activities applied across the life cycle of a project or program. They start at the inception of the project (Driver 1) and the initial assessment of the business's or system's capabilities and continue through requirements elicitation (Driver 2) and the creation of the PMB describing the time phased work and its budget (Driver 3 and 4), to the execution of the baseline (Drivers 6, 7, and 8) and project close-out (Drivers 9 and 10).
The drivers of Performance-Based Project Management provide feedback loops to assure that subsequent activities provide measurable information about the corrective actions needed to increase the probability of success. This repeated step-by-step approach to project management assures that the periods of assessment provided for corrective actions are appropriately spaced to minimize risk and maximize the delivered value to the project.
The ten drivers are the basis of the principles and practices of Performance-Based Project Management, and each is present in every project domain, every business paradigm, and in every project management method. If the driver is not recognized and dealt with, it will still "drive" the project outcome, whether the project manager looks after its performance or not. For example, if the work is performed out of sequence, the project is missing Driver 6: Work Authorization, and the work products may need rework. If we install the wallboard in the house before the electrical wiring, we will have to cut the wallboard to pull the wiring.
Putting the Ten Drivers to Work
Let's look in more detail at each driver and see how addressing it with the Five Immutable Principles and Five Practices can increase the probability of project success.
Capabilities Drive System Requirements
The first driver of project success is the principle that all technical and operational requirements must be derived from the needed capabilities.
We hear all the time about bloated software products, with features no one uses. But what we don't hear about is how to address this supposed issue. It turns out all the capabilities in those products are needed by someone—maybe not us, but someone. They are there for a purpose. Maybe not the right purpose, but they didn't get there by accident. Knowing up front what capabilities are needed for a product is not an accident, either. This is the role of capabilities-based planning. What capabilities do we need for the project to be successful?
Defining a capability creates the flexibility needed to ensure system responsiveness and sustainability in the presence of constant change. At the same time, we need to deliver tangible benefits to the user. These capabilities may include:
* Agility. Adapting to emerging situations that had not been planned for or even foreseen.
* Tailorability. Changing the behavior of the product or service to meet emerging needs.
* Architecture. Measuring the coupling and cohesion (interrelationships) between the business processes that support agility and tailorability with the least amount of disruption to previously developed project outcomes.
(Continues...)
Excerpted from Performance-Based Project Management by GLEN B. ALLEMAN. Copyright © 2014 Glen B. Alleman. Excerpted by permission of AMACOM.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
