Introduction | Book Structure | What We Liked
Downside | Conclusion | Author's Response

What We Liked

This book is full of snippets of sound advice. For example this observation on "culture":

"Creating the kind of culture in which the organization has a desire to please the leadership hinges on relationship building. The strategies that provide pain when there is a lack of discipline in the organization are also required. Both approaches are required to maximize success, because all people are not alike."[9]

Or this personality observation:

"[T]he skill set and natural ability to become proficient in the use of project management software is different than the skill set and natural ability needed to be a great project manager, which is primarily people- and relationship-driven."[10]

Or this capability observation:

"[W]hen people have dual responsibility, like operations and project management, they often gravitate to the one they are most comfortable with, sometimes to the expense of the other."[11]

However, for reasons that we will explain in our next section, we had to get well into Chapter 3 on the subject of Stakeholder Management before we began to warm to the book. It transpires that author James Brown's view of program management, or at least the role of a program manager, is largely one of salesmanship. For example, in Chapter 2 he says:[12]

"As the main program champion, the program manager needs to garner resources and use his or her relationship capital to pave the way for the program to be successful. Relationship capital is the amount of influence a program manager can wield through the organization by establishing relationships of ever-increasing trust, internal and external to the organization. In this role as program champion, the program manager is always selling the program's importance to the company's stakeholders and team members."

We are very sympathetic to this point of view, even though it seems a far cry from the PMI-accepted view of program management. However, it is not until Chapter 3 that we learn how to fully identify who those stakeholders really are. In that regard James provides this valuable advice:[13]

"To fully identify stakeholders, use the following guidelines:

• Follow the money!
• Follow the resources.
• Follow the deliverables.
• Follow the [required] signatures.
• Examine other programs' stakeholder lists.
• Review the organizational chart to assess which part of the organization may be stakeholders.
• Ask team members, customers, and any other confirmed stakeholders to help you identify additional stakeholders.
• Look for the 'Unofficial People of Influence' ".
  [Explanations of each omitted.]

James then goes on to describe different types of "problem" stakeholders in these terms:[14] "The meddling stakeholder; The overbearing stakeholder; The poor stakeholder; The untrustworthy stakeholder; The indecisive stakeholder; The unavailable stakeholder." He even adds (perish the thought) "I hope you never have a meddling, overbearing, poor, untrustworthy, indecisive stakeholder who is never available."[15] James then describes each in some detail with suggestions as to how to deal with each type.

Other pieces of good advice include: "Don't get baited or caught in the trap of talking negatively about a particular stakeholder whether that party deserves it or not." Unfortunately, this reaction is quite common and very easy to do. Another: "Expect stakeholders to check up on you ... [They] often ask questions they already know the answer to ... They are simply testing [your] credibility."[16] And: "Program managers should also check up on how well [their] project managers are doing [their] stakeholder management by periodically (weekly or monthly or at milestones) calling each stakeholder and asking them how the project manager is doing and whether their [the stakeholder's] needs are being met."[17]

Given a number of projects in the program, the number of identified stakeholders and suggested frequency, this sounds like a full-time job in itself!

In Program Process Strategy, we were interested to see that under "How Project Managers Are Assigned" James advocates assigning project managers by phase.[18] He describes this "powerful strategy" this way:

"Program managers should consider assigning project managers in the same way a baseball manager assigns pitchers. In other words, the most senior personnel can be used to kick off the project to ensure a good beginning. Once the requirements are established and baselined, a transition can occur to a more junior project manager capable of maintaining control for a project that has a good start. This transition has to be formal, with a 'sign-off' among the two project managers. The stakeholders must also be prepared for transition and may be included in the transition process. Once the transition is complete, the junior project manager may run the project until the project is ready to close. Then a switch can be made to a project manager who is more skilled or who specializes in closing projects.

Closing out a project is vital. The experienced program manager should recognize that the skills required to start and organize a project, (herd and manage stakeholders), are different than the skills required to manage an established project, and are different than the skills needed to close a project."

This observation is entirely consistent with our own research.[19]

One of the longest chapters in the book deals with Program Execution Processes. Here we receive advice on a number of topical issues such as:

• The organizational leader who hears about Earned Value and wants to implement it immediately, only to discover that it requires a valid plan to be meaningful.[20]
• Effective project management means knowing what to ignore as well as what to pay attention to.[21]
• The critical path method will not produce a valid schedule in a resource-constrained environment.[22]
• Establishing an appropriate planning horizon - It is just common sense not to plan in detail or execute beyond your [visible] planning horizon.[23]
• [A better] way to accommodate a planning horizon that is shorter than project duration is to use 'rolling wave' scheduling.[24]
• Implement a stage gate process to ensure proper execution of the planned schedule [but] all projects within a program don't have to follow the same execution strategy.[25]
• You need to strike a balance between control and bureaucracy.[26]
• Your change management process should be designed so that it's intentionally cumbersome. I know that may not sound customer-friendly, but it is actually for the customer's own protection.[27]

These are all accompanied by good advice. But you'll have to read the book to find out why and how.

Book Structure

Downside

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page