The views expressed in this article are strictly those of Max Wideman.
The contents of the book under review are the copyright property of Tom Kendrick.
Published here October 2017

Introduction | Book Structure | What We Liked
Snippets | More Snippets | Downside | Summary/Conclusion

Snippets

Author Tom Kendrick's book is too large and too detailed to give fair comment in a limited book review such as this. Instead, we have picked up some valuable pearls of wisdom from each chapter many of which we feel are not only essential prerequisites to conducting a program but also have broader implications. Here is our selection.

Chapter 2 Program Initiation

  • Launching a program of almost any scale benefits from a well-planned startup to ensure that it hits the ground running.[12]
  • ... each new program benefits greatly from a clear and compelling business case showing how it contributes value that supports the organization's goals.[13]
  • Undertaking a multiyear program to deal with a current situation can be perilous unless the objectives are sufficiently flexible to deal with future realities as they emerge.[14]
  • For both projects and programs, sponsorship works best when the people involved have a substantial stake in the work.[15]
  • ... effective program leaders work to identify and connect with all the individuals having sponsorship responsibilities to ensure that they understand their roles and what the program is undertaking.[16]
  • At the inception of a program, document the expected benefits, and engage in sufficient analysis to build confidence that the efforts will be worthwhile.[17]
  • Programs decompose the work into component projects to simplify the work and manage risk, but this is only effective when you do a good job of creating a balanced mix of projects having modest size, substantial independence, and reasonable levels of inherent risk.[18]

Chapter 3 Program Deliverable Management

  • It is always dangerous for any task to have two (or more) owners, because this may result in everyone thinking someone else will take responsibility. [Also,] Multiple owners can result in turf battles, conflicts, and other unpleasantness.[19]
  • Stakeholder analysis begins with the most influential individuals in the mix, those with sponsorship responsibility for program work.[20]
  • Stakeholders who will be affected by program deliverables must also be part of your analysis.[21]
  • Based on the work of Noriaki Kano in Japan in the 1980s, requirements can be thought of as falling into three broad categories: basic, performance, and excitement.[22]
  • Stakeholder priority conflicts and resolution ... it is rarely possible to make all stakeholders equally happy.[23]

Editorial comment: Which suggests that a successful project (or program) is one that makes everyone feels about equally unhappy!

  • Characterizing programs ... Two useful distinctions that can help with this are the timing of the deliverables (integrated "big bang" delivery versus incremental "step-by-step delivery) and the type of deliverables (tangible versus intangible).[24]

The remainder of this chapter discusses, among other things, different types of program road maps, system analysis, scope risks and optimization, documentation, and program change management. It concludes with a valuable list of "Key Ideas for Program Deliverable Management".

Chapter 4 Program Planning and Organizing

  • To ensure coherence, it is best to define a consistent life [span] that will be followed by each project in the program. Having a common life [span] provides for effective synchronization of work undertaken by separate project teams and a foundation for aggregating project plans into useful program-level schedules for analysis and tracking.[25]
  • Program Plan Change Management ... Once a baseline for the next stage of a program work is set, establish a formal process for detailed assessment of any plan changes that are proposed, with a default disposition of "reject" or at least "defer" that ensures that only essential plan changes representing significant, credible value to the program will be accepted.[26]
  • Decomposing a program into a set of projects is one of the sources of complexity that makes program management challenging. Managing this complexity requires reviewing the initial program breakdown structure to explore adjustments that might result in a set of projects that could be more easily managed.[27]

In the remainder of this chapter, Tom Kendrick goes into great detail on integrating, interface management, workflow risks and documentation. The chapter concludes with a list of "Key Ideas for Program Planning and Organizing".[28]

What We Liked  What We Liked

12. Ibid, p23
13. Ibid, p25
14. Ibid, p26
15. Ibid, p28
16. Ibid
17. Ibid, p34
18. Ibid, p51
19. Ibid, p81
20. Ibid, p82
21. Ibid, p83
22. Ibid, p85
23. Ibid, p88
24. Ibid, p90
25. Ibid, p131
26. Ibid, p133
27. Ibid, p142
28. Ibid, p180
 
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page