What We Liked
We found the book very well structured, whether for continuous reading or for singling out any particular area of project management. As can be seen from the list of chapters under Part I, on the previous page, the author works his way through the natural sequence of a representative methodology covering the life span of a typical product development. Then in that part he consistently sets out, first the Business Perspective, followed by the Project Perspective, and then how he suggests that Bridging the Divide might or should be accomplished.
With the exception of the Introduction, chapter 1 and the Conclusion, chapter 17, each chapter concludes with a bullet list of any where from 2 to 15 items succinctly summarizing the Key Points of the chapter. Moreover, the last bullet in each case lists as many as 16 action items for accomplishing the recommendations of the preceding list. This rigorous arrangement enables Part 1 of the book to be used as a periodic reference, following the course of the reader's own project.
Having followed the project methodology in Part 1 of the book, it seems only reasonable that the Business side should have its share of exposure, too. So Part 2 of the book covers the "Common Strands" to be found in the Business-as-Usual side of the equation. Again to our surprise we learned a lot about the typical experience, pace of performance, and consequent attitudes, of those in the typical Business environment, all of which helps to create "The Divide".[7] A couple of very selective examples may help to illustrate the reasons for our enthusiasm.
Here are some potted notes taken from Chapter 5, titled "Requirements". The author observes that:[8]
"The area of requirements is often one where expectations diverge between the business and the project, because the business is staffed by a number of individuals with a range of attitudes that are likely to span the following:
- It's obvious — I shouldn't need to explain it to you.
- Show me what's possible.
- I'll know what I want when I see it.
- I'm not sure who knows.
- There's too much to take in all in one go.
- Why do I need to read this massive requirements document?
- It's not yet certain.
- Can't we just get started?"
"Whereas from a project perspective, a good set of requirements needs to satisfy a number of criteria such as:[9]
- Complete,
- Unambiguous,
- Able to be validated,
- Prioritized,
- Traceable,
- Adjustable,
- Clarifiable, and
- Current.
After elaborating on each of these positions listed in the chapter, author John Brinkworth then recommends "bridging the divide" by using a range of techniques, also explained in detail, such as:[10]
- Talking
- Testing of assumptions
- Demonstrations
- Iteration
- Segmenting
- Freezing
- Using an agreement process,
- Proof of achievement.
Of course you have to read the whole chapter to get the full depth of the advice provided.
As another example, the following are some potted notes taken from Chapter 9, titled "Going Live":[11]
"From the Business Perspective, the significance of this is that the focus of power, ownership, control and action, which for many months (and maybe years) has been with the project team, moves back to the business. The business, which, might have felt that it was the junior partner in terms of actually getting things done, moves back into the ascendency. This can be quite a challenge and an eye-opener, since habits of thought and behavior that will have built up over an extended period of time are now swept aside and the roles reversed."
"From the Project Perspective, going live can be more complex and nuanced than the business viewpoint. This reflects the fact that the project has a fuller appreciation of the nature of the deliverables that it has just provided and what needs to be done to turn them from a set of deliverables into a successful working solution. The moment the solution is made available for use, it can be said to have gone live. However, the actual usage of the solution may not happen immediately. There may be a different sort of uptake whereby usage increases gradually over time.
This may be because the solution, although built for a particular volume of activity, can only ramp up to this level of business in a series of gentle steps. Not because of system constraints, but due to the level of availability or enthusiasm of the user community, who may not all rush at once to start making use of it.[12]
This may affect when the project thinks it ought to get paid for a successful go-live and when the business thinks the project actually deserves to get paid."[13]
Here John notes that to achieve the best outcome for the go-live process, it is crucial that:[14]
"The go-live moment, being the most public part of the project's delivery, is one where a united front presented by both the business and the project to the rest of the world is highly advantageous. It is crucial that everybody needs to be together in terms of deciding whether the solution is right for go-live to happen. This will require a substantial series of meetings. Depending upon the degree of partnership or animosity, there may be a benefit in using a neutral party or facilitator to ensure these meetings run smoothly and are productive."
7. Although we have worked in large organizations and small, and of varying stripes, it has always been in the context of project work. No doubt that is why we found the book so enlightening.
8. Ibid, p71-72
9. Ibid
10. Ibid
11. Ibid, p113
12. Ibid, p116
13. Ibid, p117
14. Ibid, p118
|
Book Structure
