Performance-Based Project Management Increasing the Probability of Project Success
Glen Alleman MSSM
Vietnam Veteran, Applying Systems Engineering Principles, Processes & Practices to Increase the Probability of Program Success for Complex Systems in Aerospace & Defense, Enterprise IT, and Process and Safety Industries
(A book review by R. Max Wideman, FPMI)
Introduction
"Projects fail to meet goals for many reasons: poor time and budget performance, inability to deal with complexity, uncontrolled changes in scope. Even the most experienced project managers can be caught off guard. Performance Based Project Management helps you avoid nasty surprises and enhance the probability of success. Rather than simply implementing technical and operational requirements – the traditional approach – you'll learn to focus on providing specific capabilities that produce measurable business value."
So says the back page of the book's flysheet. That's a pretty tall order, and potential readers should be wary of what is intended by the term "success", in what environment, and who are you that might be seeking that success? So the promotional material goes on to observe:
"Performance Based Project Management adapts the project management methods originating in the aerospace industry to accommodate any project, in any industry, and of any size."
While that may be true of any project, traditional industries like engineering and building construction will likely be less interested. However, as presented by author Glen Alleman, the "step-by-step framework in the form of immutable principles, practices, and processes" is much more likely to interest project proponents in the many hi-tech and software industries. Indeed, this impression seems not unreasonable given the author's background described below, the reading list on his website, and the author's assertion that: [1]
The singular beneficial takeaway of this book is:
That is the language of projects in the hi-tech industries.
Nevertheless, the author makes a great play of the word "done," which we think is more insightful and universal and would make a better title for the book. As the author says: [2]
"In this book the word 'done' has a special meaning. It means that the customer is satisfied with the outcomes of the project."
We heartily concur. But then he adds: [3]
"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'."
That's all good, but not every project proponent is technically sophisticated and, in many cases, waits to see what "done" looks like to decide: "Well, that's not really what I had in mind!"
In the following chapters, the author describes in great detail how "done" can and should be achieved by applying the project management "principles, practices and processes that are all needed for success." Thus, The details provide an excellent macro project management process for any project work in the medium to hi-tech industries. We will discuss this further in a later section of this review.
The book concludes with a chapter on fourteen documents that the author thinks are essential to be established during the execution of a project if that project is to be successful.
Book Structure
The content of this book is set out in seven chapters and two Appendices as follows:
Each chapter concludes with a summary of "Looking Back" and an alert about "What's Ahead." The book contains 29 explanatory figures and has a total of 238 pages. It does not include a Glossary of Terms or a list of acronyms for ease of reference.
As the chapter titles imply, the project management framework of the book is built around the project's Drivers listed in Chapter 1. These are supported by the Principles and their respective Practices that call for the Processes that ultimately result in fourteen key documents during project execution. Although none are explicitly listed in the Table of Contents, we list them here for ease of reference and to facilitate an understanding of the book's contents.
The ten drivers of the Principles that enable the Practices are: [4]
The Five Principles presented in the form of questions are: [5]
The Five Practices, derived from the foregoing Principles and presented in the form of activities, are: [6]
Having laid out this pattern, the Drivers are then looked at in more detail and we find that each can be further subdivided into bulleted or numbered lists as appropriate. [7] Finally: "With our principles and practices in place, we can now go to work." [8]
What We liked
How to Measure Progress to Plan
Author Glen Alleman starts this section with the observation: "Measuring progress is difficult on many projects." [9] He observes that some measure money spent relative to budget, while others measure the passage of time relative to scheduled completion. But these " separately or together "do not support the 'Five Immutable Principles.' None of these measurements speak to what was done on the project regarding our movement towards 'done'." [10]
Glen goes on to say: "The key principle here is 'planned progress'. . . . Preplanning progress is the basis of 'performance-based' measurement for both project processes and technical products." We heartily agree. Note the distinction between "project processes", that is to say the processes involving the tools and techniques of project management, and "technical products", which refers to the work involved in the "maturing" (or evolving) final deliverable, product or outcome.
With these words, Glen effectively disentangles Project Process Management (project management) from Product Development Management (technology management). [11] While it might seem obvious, this is an important distinction. Many arguments surrounding project management issues arise due to the failure to recognize this difference.
So what is the definition of "done" or the definition of "success" in a project context? Our author suggests: [12]
"Let's ask the questions for the Five Immutable Principles again in a slightly expanded form and examine what credible answers might be:
Done needs to be measured as the capabilities provided to the buyer. These capabilities provide the business or organization with the 'ability' to do something new, something in support of its strategy."
A Framework for the Five Immutable Practices
Glen states that: [13]
"Each of the Five Practices, guided by the Five Immutable Principles, performs a specific function in our efforts to increase the Probability of Project Success (PoPS). Like the principles, the practices are not a cafeteria-style approach, from which you can pick and choose what to apply to the project. Each practice contains specific steps needed to produce measurable outcomes to increase the PoPS."
And adds:
"This actionable information is the feedback information needed to keep a project under control and on track. These control processes are not impediments to progress; they are the tools needed to increase the probability of success." (Emphasis added.)
"The customer doesn't actually buy features and functions. The customer buys a capability to do something of value."
领英推荐
"Without knowing what capabilities we need at the end of the project, the requirements, and everything else around managing the project has no home, no reason for being, and no connection to the goal of the project."
"Instead of starting with requirements, we need to start with capabilities that describe 'done' in Measures of Effectiveness for the outcomes of the project, not just delivery of solutions derived from the requirements." [14] (Emphasis added.)
Glen then describes how this should be approached, how to identify the Requirements Baseline, establish and execute the Performance Measurement Baseline, and perform Continuous Risk Management. These provide the backdrop for deploying the better-known processes necessary for executing the project's work. Glen lists these in another "set-of-five" as follows:
We prefer the traditional version of "Plan, Organize, Execute, Monitor, and Control" [15], but perhaps Glen's version is more specific in today's environment. [16]
Tailoring the Principles and Practices for Project Success
We were very pleased that this complex "Performance-Based Project Management" arrangement can and should be tailored to various projects. Interestingly, the author needs to classify projects according to the anticipated cost, the expected duration, the number of stakeholders, and so on, as is most typical. Rather, the tailoring of the Performance-Based Project Management practices and processes has three levels: [17]
In short, before executing any project, you should figure out its "Level" (of required management) and apply that level accordingly.
Three Examples of Project Management Execution
We enjoyed reading Chapter 5, which is dedicated to demonstrating how to apply these principles, practices, and processes across three simplified, hypothetical, but real-world projects, namely:
In each case, as you might have guessed, is the key question: What constitutes "done"?
Downside
The principles, practices, and processes author Glen Alleman presents make good sense and provide good checklists for the action items needed to complete any significant project. However, we need to determine whether they all flow linearly or to what extent some activities that come under different headings can be undertaken concurrently.
As an aside, one cannot help feeling that the author has a love affair with the number "five" in deriving his several sets of listings, even though some items are compounded to meet the limit of five. But perhaps that is just good salesmanship!
We needed help understanding the first two chapters, to the extent that we abandoned trying to make logical sense and flow of the content. For example, in the Introduction, Glen Alleman asserts: "The customer must have specified these outcomes [that prescribe the word "done" as defined] 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." [19]
This assumes that the customer is sufficiently sophisticated to know exactly what they need or want and has knowledge in the potential project technology. In our experience, sufficiency is rarely the case and requires the contributions of subject matter experts (SMEs). Indeed, the author later observes: "The classic example is the enterprise IT project, where the users don't know what they want the system to do." [20]
Speaking of SMEs, we needed more mention of the principles, practices, and processes needed to find the right people for the project team. Firstly, the project requires the right people for input when developing requirements and baselines, and secondly, people with the right production expertise are required to carry out the work. Then there is the question of how best to get the production (or execution) phase started. Would you be willing to open a brainstorming or information session?
Of course, the book defines the word "done" regarding specific projects. However, the book is also about PoPS (Probability of Project Success), [21] but we need help finding a definition or indication of what the author had in mind for this term. We raise this because the project management community is seriously divided over this issue.
Traditionally, project success has been seen as completing the work "On Time, On Budget, and As Defined [or specified]." To this may be added "stakeholder satisfaction". But none of these include the concept of a resulting successful product, as many would like to assert. This is largely because the determination of product success requires successful product deployment – a responsibility that is typically beyond the purview of the project manager. The author does indeed provide us with "The five Immutable Principles of project success," but these all address the issues of how to get there rather than explaining what that success is.
As an aside, we had difficulty making sense out of some of the figures, or seeing their relevance, especially where key information is presented in white characters in a box of black background. White characters on a black background are much more difficult to read. Thus the message behind many of the figures could be improved — in our opinion.
Summary
This book is important because it reveals what is needed to implement advanced project management and how that should be accomplished. It emphasizes the significance of "done", i.e., what does "done" mean, what does it look like, how do we get there, and how do we know when we have got there? Many people know this proposition as the "characteristics of completion."
Some parts of the book are difficult to follow and could be edited for technical consistency and simplicity. The novice reader could easily get lost in the intricacies of the book's framework. Nevertheless, the book does provide sound advice at an in-depth level. That is, at a level that the experienced reader can use to implement the author's recommendations on an actual project.
R. Max Wideman Fellow, PMI
[1] Alleman, Glen B., Performance Based Project Management, AMACOM, USA, 2014, p3
[2] Ibid, p1
[3] Ibid
[4] Ibid, pp17-18 [5] Ibid, p16
[6 Ibid]
[7] Ibid, pp19-34 [8] Ibid, p126
[9] Ibid, p55 [10] Ibid.
[11] Ibid – see also Figure 6.3 on p177 and Figure 6.4 on p179
[12] Ibid, p59
[13] Ibid, p69
[14] Ibid, p70
[15] Derived from the definition of management, first developed by Henri Fayol circa 1916 in his work Administration Industrielle et Generale
[16] Performance Based Project Management, pp101-102, developed in detail in pages 102 to 125.
[17] Ibid, p165
[18] Ibid, p137. "There is only one stakeholder — the 'monarch' of [the author's] kitchen." (p138)
[19] Ibid, p1
[20] Ibid, p23
[21] Ibid, p69
Google Overview of Performance-Based Project Management