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."
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."
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."
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:
"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:
"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: "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." 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." 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."
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. 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.
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.
- Effective project management means knowing what to ignore as well as what to pay attention to.
- The critical path method will not produce a valid schedule in a resource-constrained environment.
- Establishing an appropriate planning horizon - It is just common sense not to plan in detail or execute beyond your [visible] planning horizon.
- [A better] way to accommodate a planning horizon that is shorter than project duration is to use 'rolling wave' scheduling.
- 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.
- You need to strike a balance between control and bureaucracy.
- 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.
These are all accompanied by good advice. But you'll have to read the book to find out why and how.
9. Ibid, p88
10. Ibid, p92
11. Ibid, pp89-90. This situation frequently arises where employees are expected to "multi-task". This is all very well among projects in various stages, but we think it is a profound mistake to mix projects and operations for the very reasons cited.
12. Ibid, p30-31
13. Ibid, p54-55
14. Ibid, pp58
15. Ibid, p59. We're sure James enjoyed great satisfaction in writing that!
16. Ibid, 69-70
17. Ibid, p73
18. Ibid, p85
19. Ibid. This is entirely consistent with the conclusions you
may draw from the findings in this paper: Optimizing Success by Matching Management
Style to Project Type www.maxwideman.com/papers/success/intro.htm.
In particular, see Table 6: Potential
Selection of Leader Type or Management Style to Optimize Success, Given the Project
Type and Project Phase.
20. Ibid, p103
21. Ibid, p104
23. Ibid, p106
24. Ibid, p108
25. Ibid, p109
26. Ibid, p111
27. Ibid, p113