Downside
As a reader of project management texts, we really had a struggle with both the title of the book and its adoption throughout to describe "a modular approach for driving a company's strategy through its decisions and actions".[17] Nowhere is the term "DNA" explained other than to suggest that it leads to "a family resemblance",[18] a point that we utterly missed on first reading. You see, "DNA" could equally refer to "Daily News Analysis", a web site out of Mumbai, India.[19] Catchy labels are fine with us for pushy marketing of "flavor of the month" or cult-like products, but not for serious tomes of lasting value. Only when we studied the flysheet cover of the book did we understand the significance - as we described earlier in our Introduction.
We also have to admit to having some difficulty in making sense out of Chapter 2, Strategy Clarification and Mapping. Many of the illustrations in this chapter are highly conceptual and littered with fancy arrows, blobs and arrangements containing text too small to read. See Figure 8 for example.[20]
Figure 8: Example of a strategy map
Lawrence rightly tells us "To stop Wasting Resources on Less Important Actions".[21] Following this he suggests that we can "Reduce Volatility" through a list of 14 items such as: "Continually changing priorities; Uncoordinated inefficient efforts; [and] Weak governance and poor accountability."[22] However, we think that the over arching time waster of "choking the pipeline with too many projects" could have been made explicit and at the top of the list. This would emphasize the point for the casual reader who might otherwise miss the significance of this factor, a factor that is implied throughout the chapter.
We also agree that we should "Be careful with Expensive Benchmarking [because] benchmarking can also result in either analysis paralysis or very complex metrics".[23] And to avoid the associated costs, we should "Stop Measuring Valueless Metrics [such as:] Time filling in [unnecessary] fields on forms; [consequent] Computer processing and storage; [and resulting] Management review and discussion"[24]. However, we were not clear as to just exactly what we should do instead.
Like us, Lawrence is a great believer in Decision Gates (Control
Points). However, he cites as an example a decision-gate scheme used by a large
energy company. This scheme is displayed in a table that names the "Gate", and
describes its "Assessment of; Gate Prerequisites; [and] Outcomes". The list of
gates thus illustrated is as follows:[25][26]
- Business needs understood
- Project defined
- Project designed
- Project planned
- Mid-project review
- Deliverables complete
- Benefits realized
- Project closed
The problem we have with this scheme is that item #7, "Benefits realized", is the result of the work of operations management, and not project management. Operations management requires quite a different style and approach compared to project management and therefore is the work of a different group of people. Hence, as we have said many times before, the project should be closed once the Deliverables are complete and transferred to the "Care Custody and Control" of operations. Thus item #8 should appear before item #7 and at some time in the future, when the deliverable is "retired", a further gate could be added to represent the closure of the product life cycle.
In our earlier discussion of what we liked, we commented on Lawrence's observation that "Many strategic portfolios result in a great deal of change for people working in and with the organization" and that "people can develop open and hidden resistance to change." However, Lawrence goes on to say that:[27]
"Each project team should anticipate the human factors that stand in the way of success and incorporate the work, time, and resources needed to address them properly in project plans."
While we agree in principle, we consider this is an unfair expectation of the project team.[28] After all, project teams are expected to carry out their mandate within time and cost constraints. It is the project sponsor (read senior management) that sets the project agenda (i.e. project scope). If this does not include the necessary budget to cover public relations, then this is an omission of management and not the fault of those teams executing the project.
17. Ibid, p xi
18. Ibid
19. Second entry of about 153 million on first page of Google, accessed 9/22/10
20. Author's comment: "Yes, this is probably true for a project manager reader but may be less so for a balanced scorecarder or corporate executive already familiar with many of these concepts. It's hard to know where to pitch it!
21. Hobbs, p97
22. Ibid.
23. Ibid, p55
24. Ibid, p54
25. Ibid, p140
26. Author's comment: "This is a real example (not my scheme) but is an interesting argument that might depend on the specific project and managements point of view. For smaller projects OK but for large transformational strategic projects why should the project team not be partly accountable for the benefits being realized? If you paid IBM to build the Olympic scoring system why would you not make them accountable for it being successfully used? Project teams should not be absolved of responsibility just because their product is used by someone else. This Oil Company chooses to keep projects open until benefits have been quantified
27. Ibid, p150
28. Author's comment: "Not for strategic change projects. If the project team doesn't take responsibility for managing the organizational change (when they are the only people who, as yet, see what the future will look like) then who can?
|
What We Liked
