Downside
The text of this book pretty well runs the gamut of generally accepted project management practices, processes and techniques laid out in the sequence of the generic project life span. As such it tends to regurgitate generally accepted techniques and some bulleted lists that are to be found in most common, or rather simplified, project management literature. That's fine for those who want simple advice all in one place. Indeed, as it states on the back cover:
"Packed with invaluable guidance, this book will help novice and experienced project leaders get the best from their project teams."[14]
However, this does tend to miss a number of opportunities that we feel are germane to the subject of getting "Results without Authority". For example in Chapter 1 we read:
"Many projects that fail do so because the project leader lacks sufficient control to keep things moving towards a successful conclusion. Insufficient project control is a result of many factors: lack of authority, geographically distributed teams, excessive project change, competing priorities, and inadequate planning, just to name a few."[15]
It seems to us that these are all things that a competent project manager should be able to handle. One of the biggest omissions in this list, and the source of many project failures, and one that the project manager can do less about, is the matter of management support and management's creation of the right project environment.
Further, the same section observes:
"As leader of your project you must assume control, whether you possess organizational authority or not."[16]
This too seems a little disingenuous. If you are going to consume someone else's resources, you need their (formal) permission to do so.
In a bulleted list of "Factors that Any Project Leader Can Control",[17] "Communication" is fourth on a list of ten items. Given that communication is the only way that a project manager can exercise any form of serious "control", we would have sung its praises and put it at the top of the list! Indeed, as we mentioned earlier:
"Using the power of your pen, you can control your project through filtering and summarizing, and deciding how best to distribute information and when."[18]
And, in our view, foremost amongst all the things that need to be communicated, are the project's goals and objectives - that you must convey with such enthusiasm and passion that anyone who hears you is bound to "buy-in" and support your project. Assuming the project is worth doing in the first place, we feel that describing the product scope in this way will be the most powerful control influence that you have.
Under "Change Management" Tom observes:
"One of the most problematic aspects of technical projects is a lack of control over specification changes. Solving this problem involves two things: freezing project scope when setting the project baseline, and adopting an effective process for managing changes throughout the remainder of the project."[19]
We are skeptical. If as premised by the book you are expected to deliver "Results without Authority" then without the necessary authority it is unlikely that you really can freeze the product scope and make it stick. On the contrary, if the boss wants something changed at the last moment, then you simply do what you are told.
The section on "Operating Style" lists the standard five sources of power (Position; Coercion; Reward; Expertise; and Personality).[20] What is missed in most texts on this topic, including this one, is the Power to generate enthusiasm, based on the goals and objectives of the project.
In a section titled: "Types and Uses of Project Metrics" we learn that:
"There are three basic types of metrics, and each plays a different role in project management.
- Predictive project metrics based on definition and planning information and help set realistic expectations for the project.
- Diagnostic metrics based on current status and serve as indicators of progress and as timely reminders for risk response, problem solving, and decision-making.
- Retrospective metrics assess how well the work you have completed was done and provide insight into process issues and recurring problems.
Predictive project metrics are primarily used in project initiation and project planning."[21]
While these statements are true, we think they fall short of the best intent. Project management is not just about starting a project; it is as much about managing it to completion. So retrospective metrics, while necessary, simply serve the function of audit and accounting. Diagnostic metrics, as defined above simply mean you are a bystander watching and reporting on the ongoing saga. The serious project manager spends relatively more time with predictive metrics in continuously forecasting what still has to be done, how long this will take and hence the time of arrival. In our view, this is the most important function of the project manager - and the most difficult.[22]
14. Ibid, see back cover.
15. Ibid, p1
16. Ibid.
17. Ibid, p2
18. Ibid, p5
19. Ibid, p16
20. Ibid, p32
21. Ibid, p62
22. "Using Predictive Metrics" and their use in the difficulties of negotiating a viable project with your sponsor are discussed in more detail in Chapter 6.
|
What
We Liked
