The Handbook of Program Management: How to Facilitate Project Success with Optimal 

Program Management 

Dr. James T. Brown, McGraw Hill, 2008 

I received this book unsolicited in the mail from Dr. Brown. I had not heard of Jim, his firm, or the book 
before I opened the package. What a pleasant surprise. I say Jim, not because we have met, but because 
that’s his signature on email for our requests of him to speak at our PMI Symposium in 2009. We could 
not work out the details, but next year I hope he will be one of the headliners . 

Before starting this review let me state my point of view. Working on DoD, NASA and DOE projects, I see 
the world as a Systems Engineering paradigm. Systems Engineers see the world in an integrated manner 
– product development and process development are inseparable. Managing interfaces is the primary 
role of Systems Engineering along with product and process architecture.  One of my Master’s is 
Systems Management, University of Southern California, 1980.. 

A Quick Look 

Buy this book. Buy it even if you’re not a Program Manager. Buy it because it is written by a Program 
Manager, for Program Managers, about how to manage programs. It’s not a survey book in the sense 
many are. Telling about high level principles – although the principles are there. It’s a handbook – just 
like the title says – about managing programs. The author speaks in practical terms, from experience. 
But of course the author’s experiences are credible experiences – NASA. 

Summary 

The notion that Program Management is like Project Management is naïve. Program Management is 
about managing Project Managers. It is NOT about managing Projects. Managing Project Managers is 
much more difficult than managing projects. The term Program Manager is used often in IT. This book 
should be mandatory for those in IT who call themselves Program Managers. It’s unlikely you’ve been 
doing your job according the guidance found in this book, the PMI Standard of Program Management, or 
the OGC Project, Program, Portfolio Management Maturity Model. 

My Biased Approach to Book Reviews 

My approach to a book review is to read the chapters in sequential order, making notes as I go. I then 
use these notes to comment on the chapters and write a summary recommendation at the end. Before 
starting the reading the chapters, I look through the bibliography to find papers or books that I have not 
come across before. This book has no references or a bibliography. I blame that on the editor not the 
author. 
 Next, I look at the art work to see if the pictures are notional1 or substantive in nature. For the most 
part they are substantive, but this is probably the best that could be done for the audience.  

I assume the substance of the book is valid, and make I comments on how I would use this content in my 
work as a leader of teams of PP&C and Project Managers in aerospace and defense and commercial 
programs. 

There will be simple “I like this book reviews,” on the  cover, which by the way come from Gene Krantz 
(Director NASA Space Operations) and Norm Augustine (retired CEO of Lockheed Martin). My review is 
pitiful in this company.  

Chapter 1 – Chaos to Clarity 

Dr. Brown speaks to the difference between project management and program management. Project 
Managers focus on cost and schedule. Program Managers focus on the cultural aspects of the collection 
of projects. This transforms the Program Manager into a leader in ways not found in Project Managers. 
The primary duty of the Program Manager Leader is to turn chaos into clarity.  

This might be seen as the role of the Project Manager on a project, but if the project is in chaos, there 
are larger problems not addressable by the Project Manager. The ideal culture for a successful Program 
is one based on the following layers 

1. People Accountability 
2. Process Accountability 
3. Discipline 
4. Integrity 
5. Clarity 
This pyramid has Number 1 at the bottom and Number 5 at the top. 

There is a list of the conditions found in a chaotic program management culture. These are common in 
all failure environments. Dr. Brown provides guidance in the following sections on how to address these 
conditions, starting with Accountability. Each of the descriptions provides advice that can be put to use. 
The key here is to have processes around which people can be accountable. These are not rigid 
processes, but processes that guide the program. You would not call this book “agile,” but many of the 
principles found here can also be found in agile approaches – once you put in place the people and 
process accountabilities. 

The notion of achieving discipline with minimal process ends the chapter. 

                                                            
1
 The idea of a notional description is powerful but it has limits if not bounded. These unbounded descriptions are 
very common in the project management literature. The exuberance of using the notional description as the 
executable description is common. The problem of course is the three infamous words this doesn’t scale come into 
play. 
Chapter 2 – Attributes of the Effective Program Manager 

The chapter starts with ‐ “Project Management is the management of a group of activities or initiatives 
with a defined deliverable and a definite starting point and end point.” “Program Management is 
management of a group of projects…” 

Programs never end. This results in higher complexity, higher level stakeholders, use more resources, 
and have more inherent conflict. The result is more coordination. It’s the coordination that makes 
projects different from programs. 

Some success factors are provided. But the key success factor is the leadership aspects required of a 
Program Manager. Now there are endless PMI training sessions on Project Leadership. While this may 
be useful in a project environment, it’s the program world where leadership is mandatory. The guidance 
to managing relationships guided by Dale Carnegie, Frank Bettger, and Harry Beckwith. All sales authors. 
Are guideance for Program Management leadership.  In many domains the Program Manager “keeps 
the program sold.” 

The chapter describes the behaviors needed by a Program Manager. These attributes can be put to work 
directly on your program – and possibly a project. 

Chapter 3 – Stakeholder Management 

Stakeholder management  is a primary role of a Program Manager. I have seen programs fail because 
the Program Manager focused on the project aspects – technical, cost, schedule. Dr. Brown’s advice is 
simple and actionable: 

1. Follow the money 
2. Follow the resources 
3. Follow the deliverables 
4. Follow the signatures 
5. Examine other programs stakeholders 
6. Review the org chart 
7. Ask others to help 
8. Look for unofficial influences 

There is a nice chart for assessing stakeholder influences. He multiplies the preference scale with the 
power scale to produce on assessment value. This is similar to multiplying probability of occurrence with 
impact in a risk matrix. This should be avoided in both cases, for the same reason. The value on either 
side of the multiplication sign are not “numbers,” but probabilities or “variables” with undefined 
distributions. It’s certainly not a show stopper like it is in risk assessment, so no real harm. 

There is discussion of problem stakeholders, with some simple approaches of discovery and handling. 
The “ideal” stakeholder is described as well. With this “ideal” description, the Program Manager can test 
these stakeholders, determine their attributes and provide the appropriate response. 
Chapter 4 – Program Process Strategy 

Creating a successful program culture means balancing process objectives with the people side. The 
content here is a “must read” for anyone claiming to be an “agile” project manager. Words like: 

1. People dependency versus process dependency 
2. Time spent planning versus time spent executing 
3. Resources spent on new projects versus resources spent on maintenance 
These tradeoffs are not are “over” but “versus.” 

Another section is subtitled “execute progress strategy keys.” Status, mentoring, project manager 
assignments, strategies for organizational discipline, etc. These are Program Management activities. The 
list is longer and actionable approaches are provided in the remaining sections of the chapter.  

This is one chapter I’d read over again and again. 

Chapter 5 – Program Execution Processes 

Executing the program means putting the previous chapters to work. This starts with a planning horizon. 
The “red herring” of many agile thought leaders is the use of the Waterfall project planning process. In 
fact Waterfall is no longer allowed in DoD. The “red herring” aspect is pure nonsense in any credible 
project management culture. It is in fact a test of the credibility of the organization. If they are 
comparing Waterfall to some alternative, they are naïve and likely subject to the marketing hype of 
proponents of an alternative approach – pick your favorite. 

Scheduling philosophies are discussed along the way. An important concept is mentioned – the balance 
between control and bureaucracy. This sounds a bit odd, but it is the tradeoff between how many 
assessment points and the decision making process. Since the early 90’s I’ve been using the following 
phrase how long are you willing to wait before you find out you are late? The answer to this will guide 
how many progress assessment points there are in the program execution process. 

The details of a program management status report format is provided. A 4 section status report is 
described – we use a 5 section chart. The 4 elements are described in enough detail to put them to 
work.  This approach to status reporting is the norm in space and defense. I find the narrative 
approaches found in IT to be wonderful ways to hide the status of the project or program behind the 
smoke screen of words. A successful status report states what was planned, what was delivered, and 
how any resulting gaps will be closed, and when that closure will take place. Other than that, no 
narrative is needed. But this approach depends on knowing what was planned to be delivered. This is 
where most in projects go in the ditch. 

Chapter 6 – Team Building at the Program Level 

This chapter provides good guidance for building teams of project managers and their stakeholders. This 
is not my personal strength – being a quant inside. Retreats, off sites, and the like are described as a 
preferred way. I’ve participated in these and found them useful. I’m not the organizer – that’s all. 
Chapter 7 – Program Communication Processes 

“All program managers need to strategically choose program communication processes” says it all about 
this chapter. 

Chapter 8 – Program Risk Management 

This chapter comes closest to my interest – along with Earned Value and Cost Estimating processes. Dr. 
Brown’s definition of “risk” has both positive and negative units of measure. This Risk and Opportunity 
approach is starting to emerge in the IT business. There are serious issues with adapting this approach 
without understanding the difference between static and dynamic risk processes – the underlying 
statistical nature of risk drivers. 

Program Management is Risk Management. There are several approaches to risk management, but a 
very good starting point is the Software Engineering Institutes Continuous Risk Management. All is going 
well in this chapter until we come to the multiplication of likelihood with impact. In the current DoD Risk 
Managers Handbook this is not allowed. The 5x5 chart is still there, the range of values are still there, 
but the “coloring” of the 25 boxes does not use the multiplied values. If you ignore this mathematical 
detail, the chapter is a great starting point for managing risk in the context of Program Management. 

Chapter 9 – Portfolio Management Essentials 

Portfolio Management is a separate topic, deserving a book to itself. This chapter is a good survey of the 
topic and the issues. The first issue is to allocate and mange resources. There is a “basics of portfolio 
management” section that provides the principles needed to have a credible discussion on this complex 
topic. 

Dr. Brown references a chart from Norm Augustine’s book Augustine’s Laws. The Augustine book is 
mandatory for anyone claiming to understand complex projects and programs and has a passing interest 
in the business of aerospace and defense.  

This chapter also contains a reference to Analytical Hierarchy Processes (AHP).  AHP has success in 
commercial and defense. It uses many of the aspects of Paired Comparison Analysis, coupled with 
decision making. 

Chapter 10 – Positive Program Outcomes 

The end is the result if course. This chapter has a powerful concept I had not heard of before – 
calculated failure points. These are controllable points in the program (or project) that trigger an 
evaluation of the effort so far. Deciding whether to move forward or not. The DoD IMP/IMS (Integrated 
Master Plan / Integrated Master Schedule) paradigm does this on paper. Each Program Event is a mini‐
authorization to proceed. In practice of course very few programs are canceled early in the process 
(except some NASA programs) and certainly rarely in the later stages of a program. 
“If you don’t make calculated decisions about failure points, then failure is subject to happen 
haphazardly or in unanticipated areas.” 

Wrap Up 

Buy this book, read it straight through, then reread it again. After 3 to 5 reads you’ll start to put all the 
pieces together and the book will have yellow highlights on the sections that glue together those pieces.