We’ve all been in a meeting where a large piece of work turns into a flurry of individual tasks. People volunteer, teams get moving, and everyone leaves feeling productive.
But a few weeks later, the harder questions emerge: How does all this work connect? Who owns the overall outcome? Have we missed anything? And how will we know when we’re finished?
This is why I find it useful to think in pyramids.
I use a work breakdown pyramid to visualize the parts of a problem or a large program of work. It is a simple picture of the larger components, how they break down, and who is accountable for each part. The detail sits in the supporting plans and requirements; the pyramid gives people a shared view of the structure.
When planning delivery, the picture provides a starting point for discussion: What are the main components of work, how do they fit together, and who is accountable for each? Those owners then work with their teams to understand the requirements, coordinate delivery, and agree what completion means.
From scattered tasks to a connected program
During discovery work for a very large merger, I saw how easily activity could get ahead of structure.
A group would identify a broad need: “We have a whole bunch of work to do for regulatory compliance.” People would put their hands up for different tasks and head off to get them done. The willingness was there, but it became difficult to trace how all those individual efforts connected to the overall requirement.
In my view, we needed to establish regulatory compliance as a defined program of work, with an accountable owner for the whole.
That program could then be broken into several areas, such as marketing, security, and documents. Each area would have an accountable owner responsible for understanding its requirements, coordinating the work, and demonstrating completion.
Each owner would then break their area into smaller pieces, with clear ownership for those pieces too. The person accountable for an outcome would not need to do every task personally, but they would need to understand what completion required and ensure the work came together.
For example, within the documents area, the team might need to identify affected documents, determine required changes, arrange review and approval, and confirm that the approved versions were in use. Those are illustrative steps; the actual requirements would come from discovery and validation with the appropriate experts.
Now each piece of work has a place in the larger picture. A piece might be an individual task or an entire project with multiple tasks beneath it. The pyramid shows the level of detail useful for that discussion; it does not need to contain every task or requirement.
With requirements and progress maintained in the supporting plans, a team member can trace their work to a specific requirement. The documents owner can explain what is complete and what remains. Through regular conversations with the area owners, the program owner can identify gaps and address dependencies across the whole program.
Those conversations matter because requirements can overlap between teams. During the merger, for example, some documents needed branding changes owned by marketing. The pyramid identifies the accountable owners; those owners need to understand the high-level requirements and work together to agree who will do what. Coordination between the documents and marketing owners helps ensure the changes are covered without two teams repeating the same work.
Define what “done” means at every level
Naming an owner in the diagram is only a starting point. Each owner needs to understand the requirements for their area and agree how the team will demonstrate that they have been met.
The program owner works with the area owners to define the intended outcome and the requirements that establish its scope. Each area owner then works with their teams to make those requirements more specific and validate that they support the wider program.
Then connect the work and its acceptance criteria back to those requirements. A completed task is useful evidence only if it helps demonstrate that the requirement has been met.
Progress can then be reported upward with meaning. Each owner confirms the status of their area, including unresolved issues, dependencies, and the evidence supporting completion. The program owner brings those confirmations together to assess whether the overall outcome has been achieved.
A collection of green task checkboxes does not, by itself, establish that a program is complete.
This is the value of the pyramid: a shared visual reference for discussing a problem or a program of work. It helps people see the larger components, where their work belongs, and who to talk to.
The diagram is simple. Its usefulness depends on the people behind it understanding the requirements, coordinating across teams, and following through on their responsibilities.