Published March 2010

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

Downside

As is our custom with our book reviews, we started at the beginning, starting with the short introduction, and began to make notes on each page. Almost immediately, we began to fall over what we felt were rather sweeping and unsubstantiated statements. For example:

  • "[C]ompanies that will survive the future will be those that have processes in place and can repeatedly integrate new people and new technology into their existing processes."[28]
  • "[I]nnovation can still be a driving force for a company, but innovation without process is short-lived."[29]
  • "More often than not, project failure is not the project manager's fault, although he or she is frequently blamed. The real cause of the failure is faulty program management."[30]

The question in mind in each case is: Is that all there is to it? But then, this is only in the introduction.

However, moving on into Chapter 1, we had trouble with the very first paragraph. For example:

  • "The organization that can learn, change, adapt, and do so rapidly is destined for success."[31]

Our reaction: But not every organization is that sort of establishment and in any case it presumes that the "change" is fortuitously in the right direction.

  • "These companies exist in this dysfunctional [chaotic] state because they do not have an effective program management structure in place.[32]

"Program management" frequently means different things to different people. Therefore, we were anxious to make sure that we understood the author's particular slant on this term. The book has a Glossary[33] but although Program Management is the subject of the book, this term is not defined in the Glossary.[33a] In any case, not every company has a program management department. But even if they do have several projects on the go, they do not necessarily need a program management department. After all, it is possible to be a program manager without a department, as we are sure the author would agree.

  • "[T]ruly great program managers turn this chaos into clarity by creating a culture that facilitates success."[34]

This last statement contains four key words that are open to interpretation, namely: "chaos", "clarity", "culture" and "success". "Chaos" is defined as "A state of extreme confusion and disorder"[35] (Are there really that many companies that are that bad?) and "clarity" is defined as "Freedom from obscurity and ease of understanding".[36] True that "clarity" is explained more clearly several pages later. In reference to a program manager's perspective, clarity is described as "clear objectives for success, clear lines of accountability, and adherence to established processes".[37] However, the author's view of "culture" and "success" are not explained nor are they defined in the Glossary.

It is not until page 16 that we learn what the book is really about. As the author says:[38]

"This book addresses project management policy from a program manager's perspective because the program manager is ultimately accountable for the delivery of the business objectives and adherence to the policy."

All well and good, but it seems to us that this is only true if the corporate body sees fit to establish a corresponding position and mandate. In practice, the problem is that the position may or may not be called "Program Manager" and may or may not have a proactive mandate.

Another feature that we found disconcerting is the frequent use of "buzz" or "adapted" words that occur throughout the book. Terms appear such as "Ugly" (is the enemy of "clarity");[39] "presence" (the ability to appear or outwardly demonstrate the characteristics of a leader);[40] "self-regulating"[41] (defined later as having your team answer your questions before you ask them);[42] "whispering" (communicating information to a stakeholder under casual circumstances before it becomes publicly known);[43] "notifiers" (those who think that reporting the results arrived at by a computer software program is project management);[44] and "consistency" and "anchors";[45] "lens shaping";[46] and so on. We don't know if these are from common usage in the NASA culture that the author enjoyed in his previous employment, but they are not part of the accepted lexicon of project management.

Finally, we note that the author is an advocate of "Slow, Steady, Gentle Pressure" and that "Pressure works whether you are managing up or down." However, he does "not believe in deploying tremendous pressure, because the subsequent stress levels can harm people and relationships"[47] (Emphasis added). Unfortunately, the book provides no guidance for determining the borderline between "gentle pressure" and "tremendous pressure".

What We Liked  What We Liked

28. Ibid, p1
29. Ibid, p2
30. Ibid, p3
31. Ibid, p5
32. Ibid.
33. Ibid, pp241-244
33a. However, program management is characterized on page 30
34. Ibid, p5
35. Ibid, p12
36. Ibid.
37. Ibid, p24
38. Ibid, p16
39. Ibid, p25
40. Ibid, p34
41. Ibid, p35
42. Ibid, p45
43. Ibid, p71
44. Ibid, p152
45. Ibid, p38
46. Ibid, p223
47. Ibid, p233
 
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page