The views expressed in this article are strictly those of Max Wideman.
Published here July 2012.

Introduction | Book Structure | What We Liked
Some Useful Ideas | Downside | Summary

Some Useful Ideas

On Work Breakdown Structures

Some people ask: Why bother with a Work Breakdown Structure (WBS)? Joseph Heagney answers that question as follows:

"A major problem in project planning is determining how long tasks will take and what it will cost to do them. Inaccurate estimates are a leading cause of project failures, and missed cost targets are a common cause of stress and recrimination in project management.

The most useful tool for accomplishing all of these tasks is the WBS. The idea behind the WBS is simple: You can subdivide a complicated task into smaller tasks until you reach a level that cannot be further subdivided. At that point, it is usually easier to estimate how long the small task will take and how much it will cost to perform than it would have been to estimate these factors at higher levels."[14]

Later, Joseph goes on:

"Generally, we use average times to plan projects... . That is the idea, anyway [but] Parkinson's Law discredits this notion, however. Parkinson said that work expands to fill the time allowed. That means that tasks may take longer than the estimated time, but they almost never take less. One reason is that when people find themselves with some time left, they tend to refine what they have done. Another is that if they turn in work early, they may be expected to do work faster the next time or that they may be given more work to do."[15]

So it is important to recognize these realities when estimating and managing your project. Joseph suggests

"Some guidelines for documenting estimates:
  • Show the percent tolerance that is likely to apply.
  • Tell how the estimate was made and what assumptions were used.
  • Specify any factors that might affect the validity of the estimate (such as whether the estimate will still be valid in six months).
In fact, it is impossible to make sense of any estimate unless these steps are taken, so they should be standard practice."[16]

On scope changes and multitasking

Joseph Heagney notes that:

"I am often told that scope and priorities change so often in a given organization that it doesn't make sense to spend time finding critical paths [in scheduling]. There are two points worth considering here. One is that if scope is changing often in a project, not enough time is being spent doing upfront definition and planning. Scope changes most often occur because something is forgotten. Better attention to what is being done in the beginning usually reduces scope creep.

Second, if priorities are changing often, management does not have its act together. Generally, the organization is trying to tackle too much work for the number of resources available... . One company found, as an example, that when it stopped having people work on multiple projects, employees' productivity doubled! That obviously is highly significant."[17]

On task durations

"A good rule of thumb to follow is that no task should have a duration much greater than four to six weeks. For knowledge work, durations should be in the range of one to three weeks, because knowledge work is harder to track than tangible work."[18]

Applying mathematics

One thing that caught our eye is Joseph's observation: "You Can't Have It All!"[19] and goes on to explain:

"One of the common causes of project failures is that the project sponsor demands the project manager must finish the job by a certain time, within budget, and at a given magnitude or scope, while achieving specific performance levels. In other words, the sponsor dictates all four of the project constraints. This doesn't work."[20]

We agree, even though we are not entirely sure of the meaning of "Performance". It could be the efficiency of the work performed by the project team, the quality of the work reflected in the product, or the performance of the product in use in successfully producing benefits? Nevertheless, the author expresses the relationship mathematically as follows:

C = f(P, T, S)

That is to say, "Cost is a function of Performance, Time, and Scope"[21] where function "f" is some factor or other.

Expressing this relationship mathematically is a useful idea. However, the true project management variables are Scope (of the required product), Quality (grade of the required product) as inputs that result in Time (required to do the work) and the consequential Cost (of the whole exercise including materials, equipment and overheads). Or as an equation:

SxQ = ƒ(TxC)

Where "" is a factor reflecting the efficiency of the work force, its management and the obstacles (risk events) encountered. But what this equation means is that the author's relationship can be more precisely written as:

third formula

Obviously "" could be analyzed further but the problem is in determining suitable cost scales for the S, Q, and T variables. Perhaps here is a valuable area for future project management research, especially beneficial for estimating. But simply understanding this relationship is a valuable background to decision-making.

What We Liked  What We Liked

14. Ibid, pp68-69
15. Ibid, p75
16. Ibid, p77-78
17. Ibid, pp86-87
18. Ibid, p89
19. Ibid, p8
20. Ibid.
21. Ibid.
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page