Downside
The lists of principles, practices and processes that author Glen Alleman presents make good sense and provide good check lists for the action items needed to get any significant project under way. However, we are not clear whether they all flow linearly, or to what extent some activities that come under different headings can be undertaken concurrently.
As an aside, one cannot help feeling that the author has a love affair with the number "five" in deriving his several sets of listings, even to the extent that some items are compounded to meet the limit of five. But perhaps that is just good salesmanship!
We did have difficulty in understanding the first two chapters, to the extent that we abandoned trying to make logical sense and flow of the content. For example, in the Introduction, Glen Alleman asserts: "The customer must have specified these outcomes [that prescribe the word "done" as defined] up front in the form of a set of capabilities the project will provide, with some unit of measure meaningful to the decision makers — the customer."[19]
This assumes that the customer is sufficiently sophisticated to know exactly what they need or want and has knowledge in the potential technology of the project. In our experience sufficiency is rarely the case and requires the contributions of subject matter experts (SMEs). Indeed, the author later observes: "The classic example is the enterprise IT project, where the users don't actually know what they want the system to do."[20]
Speaking of SMEs, we found little mention amongst the lists of principles, practices and processes of the need to find the right people for the project team. Firstly, the project requires the right people for input when developing requirements and baselines, and secondly people with the right production expertise required to carry out the work. Then there is the question of how best to get the production (or execution) phase started. How about an opening brain storming or information session?
Of course, the book is all about defining the word "done" in respect of specific projects. However, the book is also about PoPS (Probability of Project Success),[21] but nowhere could we find a definition or indication of what the author had in mind for this term. The reason we raise this is because the project management community is seriously divided over this issue.
Traditionally, project success has been seen as the completion of the work "On Time, On Budget and As Defined [or specified]". To this may be added "stakeholder satisfaction". But none of these include the concept of a resulting successful product, as many would like to assert. No doubt this is largely because the determination of product success requires successful product deployment — a responsibility that is typically beyond the purview of the project manager. It is true that the author does provide us with "The five Immutable Principles of project success" but these all address the issues of how to get there rather than explaining what that success actually is.
As an aside, we had difficulty making sense out of some of the figures, or seeing their relevance, especially where key information is presented in white characters in a box of black background. White characters on a black background are much more difficult to read. Thus the message behind many of the figures could be improved — in our opinion.
19. Ibid, p1
20. Ibid, p23
21. Ibid, p69
|
Tailoring the Principles and Practices for Project Success
