Introduction | Book Structure | What We Liked
Downside | Summary

Downside

In a book as large and as detailed as this, it should not be difficult to finds "points of departure". So it is that we have a few nitpicks.

First and foremost, we were disappointed to see the reference to "triple constraint" right there in the Preface even.[22] This obsolete construct has, unfortunately it seems, become institutionalized. Not only is it inaccurate but also implies a lack of basic understanding of project management on the part of the user. For those not familiar with the argument, there are four interdependent variables fundamental to project management, namely: Scope, Quality, Time, and Cost. From a systems perspective, the scope of the product, together with the required quality grade, establish the "requirements" input. As a consequence of applying project management tools and techniques, together with the work required by the particular technology to create the product, a certain amount of Time is required that in turn gives rise to consequent Costs.

Obviously, you can increase both time and cost simply by conducting the work inefficiently. However, assuming an acceptable standard of efficiency, then you can only reduce the Time and Cost components by reducing the Scope and Quality components. You can tinker with the relation between the Time duration at an increase of Cost, by applying more resources or working overtime and so on, but the effect is limited and marginal at best. We like to think of the interrelationship between the four interdependent variables as the Tetrad-Tradeoff.[23]

It is true that author Claudia Baca introduces yet another variation. Her triangle is labeled: Cost, Time and MOP, see Figure 2.

Figure 2: The triple constraints using MOPs[24]

This arrangement leaves us really scratching our heads because the results represented by an "MOP" are not evident until the product is put into use by a third party after the project is completed. Hence the MOP is dependent upon the competence and dedication of the third party and so is only indirectly related to the time or cost of the project.[25]

In the discussion of "Influencers" under Politics I Chapter 3 on How Big is This Project? Claudia suggests that: "Your strategy with influencers is to shower them with information about the project."[26] We have several difficulties with this. First, gathering the information and presenting it in a form suited to public consumption takes time and effort; You don't always know the right information at a given point in time on the project; You might have to modify the scope anyway, down the line so the early information may come back to bight you; and finally undue "snowing the public with information" can result in as much public reaction and cynicism as undue secrecy.

In the Politics of handling executives, we learn that we no longer escalate issues but instead we "delegate up".[27] Isn't that a bit of an oxymoron?

In Chapter 5, The Art of Estimating we really enjoyed the discussion of Time Spent versus Time Duration and the distinction between the two. According to the example:

"You start the assignment on Monday at 8 a.m. You work until 10 a.m. and then take a 30-minute break for coffee and for returning e-mail. You start again at 10:30 a.m. and work until noon, when you stop for lunch ... [and so on]"[28]

Aside from being so lucky, the outcome of this discourse is a work calculation that results in 11.5 hours of work effort, i.e. time charged to the project, in a total of two days, i.e. sixteen hours. What we'd like to know is - who pays for the other 4.5 hours, or where is it accounted for?

We have a little difficulty with Chapter 6, Quality - How Good Does It Have to Be? Here we see that "You translate the word expectations to the word quality."[29] That seems to be a bit over generalized. The customer may be expecting certain functionality. If it is missing and the customer is disappointed, that is not a problem of quality grade but of lack of scope. Under Organization Standards we see that Product standards "cover how the product of the project is created."[30] Certainly, poor quality workmanship will likely lead to a poor quality product. However, good workmanship does not necessarily produce "the right product that satisfies the objectives for which the project was undertaken", which is the question asked under Planning Quality In. [31]

Chapter 8 is about Risk - What Should You Worry About? This chapter provides a good overview of the subject. However, to compare risks the text says: "you need to determine which risks you will work on. You do that by adding up the probability and impact numbers you've generated."[32] While adding is feasible, because probability and impact are two different dimension, it is usual to multiply them together rather than adding.[33] The result is a Risk Criterion Value that produces a more evident segregation.

On budgeting, Chapter 10, Claudia very wisely recommends pressing for two types of Reserve: a Project Reserve (i.e. a project manager's Contingency allowance) and a Managerial Reserve (i.e. only at the disposal of the project executives.) "The managerial reserve is used for risks that are unknown", e.g. for major emergencies such as a fire in the workplace.[34] We think this reserve should also cover the inevitable scope changes required during the course of the project.

In Reconciling the Budget, Claudia suggests that "It is usually cheaper to use an employee than to use a contractor."[35] Perhaps on paper, but otherwise we beg to differ. Circumstances vary of course, but contract employees on average work more efficiently (otherwise they would not be hired). Besides, they are not interrupted by administrative chores and office politics during their chargeable hours of work and only charge for production hours (where did the others charge that 4.5 hours that we talked about earlier?). Research has shown that there can be as much as a 10-fold difference between good programmers and poor ones,[36] but contract houses would not survive if they housed low-end programmers so you can expect higher average production anyway. And finally, they have access to more and better solutions through the experience of their home office.

Under Monitoring and Controlling Variance, in Chapter 12, Keeping the Project on Track, we "learn about gathering performance information during your status meetings."[37] (Emphasis added.) We sincerely believe that this should not be the case. Status information should be submitted before the meeting, duly analyzed and only unsatisfactory results discussed at the meeting. Moreover, the meeting should not be about status, i.e. past accomplishments, but about intended progress in the next reporting cycle, and what needs to be coordinated to achieve a set of short-term goals in this period. In fact, a better name for the meeting is "Project Progress Meeting".

As to gathering "How much work (hours or days) has been completed on the task?"[38] for purposes of calculating Earned Value, this should be determined on the basis of an objective assessment of accomplishment and not on time spent or cost incurred. To illustrate the Earned Value Technique, the rental of a backhoe, presumably to dig a hole, is used. We are told that "The earned value at the end of day 5 was $3,200: That was the value of the work accomplished up to that point in time."[39] Well, maybe it was or maybe it wasn't because the amount quoted was the amount charged. We don't know how much of the hole was dug, how well it was dug or even whether it was in the right place!

What We Liked

Summary

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page