Published here November, 2008.

Introduction | Book Structure
What We Liked | Downside | Summary

Downside

There are few things with which we would take issue. We are not quite clear why Dhanu Kothari should have linked "ratholes" to "rainbows" in the title of his book. Other than for the alliteration effect, "Ratholes" (as a single word) is not common but the wiki Wiktionary describes it as:

  1. An entrance to a living area or passageway used by mice or rats.
  2. A living area used by mice or rats.
  3. A particularly squalid human residence.

We think that if our project was that bad, we'd seek a mandate to cancel it and start over - or get out as fast as we could!

Success, as in "a successful project" is not exactly defined in the book, but it is implied by passages such as the following:

"Project management plays a significant role in the global economy where the success of international co-operation and world-wide trade depends on projects that are delivered on time, within scope and under budget and that ultimately meet the test of customer satisfaction."[12]

While it is true that this is the standard test of sound project management, in today's world we are not sure that this necessarily represents a successful project. The question we are really left with is: Did the product of the project actually provide a benefit to anyone?

Perhaps the essay with which we have the most difficulty is #5 on Scope. This one starts out with the statement:[13]

"Projects are defined by their attributes - scope, cost, time and quality."

This is a very popular but unhelpful misconception. You may perhaps want to sort a set of projects on one or more of these attributes but that doesn't help the management thereof. The expected, hoped for, or anticipated product (depending on whom you talk to) is determined by scope and quality. The consequence of setting scope and quality, plus the quality of the project management, determines the outcome of time and cost.

In a subsequent paragraph, Dhanu observes:[14]

"The idea of scoping forces us to differentiate the 'What' from the 'How" of Project Management. It is based on the following principle: Let's define 'What needs to be done' before 'How we are going to do it'."

Here again we would demur. Before you can decide what needs to be done, you must first have a clear idea of what it is that you are going to produce. Then and only then can you really determine exactly what has to be done to produce it.

Later, Dhanu says:[15]

"The Project Manager's job is to set [a] realistic scope for the project."

Here again we would disagree. We don't think it is the project manager's job to set the scope of the project. That is the project sponsor's job. It may, however, be the project manager's job to obtain clarification of the project scope - and certainly to establish whether or not producing that scope is feasible within the constraints of time and cost.

The next one is not exactly a criticism but an interesting contradiction. In essay #6 on Stakeholders, Dhanu provides a useful insight into "The Ten Roles of a Project Organization". There he provides a list of the ten key roles, or stakeholders, that are critical in an organization, following that up with a description of the role of each.[16] These are preceded by a Basic Model of a Project Organization, see Figure 2.

Figure 2: Project organization view - a basic model
Figure 2: Project organization view - a basic model[17]

Aside from the two boxes that appear to be switched (see our penciled-in arrows), this is an interesting and useful model. However, note in particular, that there are two project managers. This is not at all unusual in reality, but it does beg the question: Who is really in charge? This is especially so, when later Dhanu states:[18]

"The Project Manager role represents the single point of responsibility for the success or failure of the project."

So the questions that remain are: Which Project Manager? In what role? And, for what measure of success? Since the situation that Dhanu illustrates in Figure 2 is indeed quite common, it is clear that the project management industry still has a lot of explaining to do!

What We Liked  What We Liked

12. Ibid, p1
13. Ibid, p31
14. Ibid, p33
15. Ibid, p34
16. Ibid, pp42-47
17. Ibid, p41
18. Ibid, p44
 
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page