From Scope to Structure: Why Breaking Work Down Still Matters
Breaking work down has a reputation problem. For a while the work breakdown structure was the thing project managers produced to show they had done project management, and a great many were produced, filed and never opened again. The reaction against that was fair, and it threw out something that still does a job nothing else does.
A scope structure exists to make four things possible: assigning work to somebody, estimating it, knowing when it is finished, and reporting progress in a way that means anything. A project without one manages none of those four properly, whatever its delivery approach happens to be.
What a structure has to make possible
Each piece of a good structure passes four tests, and the tests are more use than any rule about how many levels to go down.
It has one owner. Not a team and not a department, but a person who, asked how it is going, can answer without going away to find out. A package owned by two people is owned by neither, and the first sign of it is a status update assembled out of two emails.
It has an estimate somebody believes. Belief is the test, not precision. If the person who has to do the work looks at the number and says it depends, the piece is either too large or too loosely defined, and splitting it fixes both.
It has a completion condition somebody can check. Not a percentage, which is an opinion, but a condition: the environment is built and the application team have logged into it, the drawings are issued for construction, the data is loaded and reconciled. Anything reportable only as a percentage has no completion condition and will sit at ninety per cent for a month.
It is independent enough that its progress means something on its own. A piece whose completion waits on three other pieces is not a piece, it is a milestone with a name. A structure should put dependencies between packages where they can be seen, not bury them inside one.
Three ways the structure goes wrong
Section 2.2.2 of the PMBOK® Guide Eighth Edition carries developing the scope structure as a named piece of work, and the common failures are recognisable from the shape of what comes out.
Decomposing by organisation is the most frequent and the most damaging. A structure with a branch per department looks tidy and reproduces the organisation chart, which puts every interface between departments in the gaps between branches, where nobody owns it. Progress reported that way misleads in a particular direction: each department reports its own work advancing while the thing being built has not moved.
Decomposing by time turns phases into work packages. Design, build, test, deploy is a sequence and not a division of work, and a structure built on it cannot say what is being designed, so the estimates are aggregate guesses and the completion conditions are dates.
Getting the depth wrong happens in both directions. A structure with four hundred leaves is a maintenance job nobody will do, and it will be stale by month two. One that stops too early leaves a package called integration carrying forty per cent of the budget with no structure inside it, which amounts to having no plan for forty per cent of the project. The rough convention that a package runs from a few days to a couple of weeks of effort is a starting point rather than a rule, and the four tests settle it better.
Three hundred and forty servers
An IT services provider was migrating a client's estate into a new data centre: about three hundred and forty servers supporting some sixty applications, across eleven months. The first structure had four branches, one for each infrastructure team, network, storage, compute and security.
By month four the reporting looked healthy. Network was at seventy per cent, storage at sixty, compute at fifty-five, security at eighty. Nothing had moved. Every team was working on the parts of the migration it could do without the others, and the parts needing two teams together sat in nobody's package, so they were nobody's problem until an application tried to move and could not.
The restructure took two days and changed the units. The new structure had a branch per migration wave, nine of them, with each wave divided by application group. A package was a group of applications moving in a wave, owned by one migration lead, estimated by the people doing it, and complete when those applications were running in the new facility and the service owner had signed. The infrastructure teams carried on existing as resources against packages instead of branches of the structure.
Progress after that was unflattering and useful. It read eleven per cent complete in a month where the old structure would have shown sixty, and the eleven per cent was true. The interfaces that had been falling between branches surfaced as dependencies between packages, and three of them turned out to need work nobody had scoped.
For a PMP® candidate, the useful reading is that a structure is a management instrument and not a document. A project that cannot say where it is usually has a structure producing no checkable completion, and a response calling for better reporting is treating the symptom. The useful question is what one piece of the work actually is and who owns it, because most reporting problems dissolve at that level. A structured PMP exam preparation course works through situations where the plan looks orderly and the progress is unknowable.
Put the four tests to five packages picked at random from the current structure. Any package failing two of them is worth splitting this week. Then look at the largest package in the plan, because on most projects it is the one with the least structure inside it, and it is where the schedule goes.
Interested in going further?
A structure that reproduces the organisation chart will report steady progress on a project where nothing has moved. Omega's PMP® Exam Preparation works through situations where the plan looks orderly and the units are wrong.
Turning scope into a structure is one of the named processes in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A103: Requirements vs Scope: Why the Difference Matters
A104: Acceptance Criteria: The Small Detail That Prevents Big Arguments
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
