How much is enough?

The WBS is the bedrock of the project plan on which everything is subsequently built, including the schedule, budget, risk management plans etc.

Yet, all too often, preparing a WBS is either rushed or cut-and-pasted from past plans.

This can leave project teams with an incomplete or inaccurate understanding of the required work. 

Especially when this is a direct result of poor stakeholder consultation in the planning stage, these errors can be quite expensive to remedy once project delivery begins.

Perhaps not coincidentally, one of the biggest challenges in preparing a WBS is knowing when to stop. In other words, at what point have we broken things down enough? Can we break things down too far?

Although the theoretical answer to that question is no, at some point, you have to stop planning and get on with project delivery. 

So, where you stop breaking things down is usually a judgment call determined by the skills and experience of the project delivery team.

Ideally, you want to get to the situation where, if you gave the task to two people with the same skills, time, and resources, your task outputs would be equally fit for purpose for the subsequent project requirements.

---

For example…

Let’s use the design of house plans as an example…

If I independently gave three architects $20,000 each and two weeks to prepare a house plan, I will likely get three different designs.

If, however, I gave them some more detail, such as three bedrooms, north facing, with a swimming pool, then the three plans I receive will all likely meet my basic requirements.

Yet if I go on and give them detailed instructions on how to operate the design software (that they are clearly experts in), I’ll not only drive them mad but waste my own scarce time and not add any real value to the outcome I’m trying to achieve.

Therefore, as well as an output (or deliverable), every WBS task should be a discrete unit of work that can be assigned an ultimate owner. 

The level of detail or ‘decomposition’ will depend on what you would reasonably expect an appropriately skilled task owner to act on.

A task owner might be a supervisor who provides a subsequent level of decomposition for their team, or you might prepare a highly detailed breakdown if an unskilled intern is the only person available to complete the work.

---

Defining acceptable

Each task must also be sufficiently broken down so that the time and cost to complete it can be reliably estimated.

We will explore this next step in more detail in the following topic.

Nonetheless, it is important to remember that consuming time and resources does not guarantee an output. 

After all, spending $500 and three weeks on an activity doesn’t, by default, mean that I have achieved my goal.

Therefore, each task in our WBS must have clearly defined and agreed-upon acceptance criteria.

Acceptance criteria are the scope specifications that tell us how we know our task is finished. 

They define the standards that meet the input requirements of the next task or person in the chain.

In other words, it doesn’t matter what the person delivering the task thinks is good enough (the task owner); it is the person or people accepting that output (the task clients) who decide whether or not it is fit for purpose.

Acceptance criteria depend on having clearly defined quality metrics. 

A quality metric is an operational definition that describes, in precise terms, a project or product attribute and how it will be measured.

A metric is an actual value, but a certain margin of error – called a tolerance – may also be allowed.

For example, a tolerance of staying within the agreed specification by ±10% could be applied to every task. 

Other examples of quality metrics include defect frequency, failure rate, availability, reliability, and test coverage.

Some tolerances need to be tighter than others

Acceptance criteria might also include a reference to a checklist. 

A checklist is a structured tool used to verify that a set of required steps has been performed – they range from simple to complex, based on project requirements and practices.

Many organizations have standardized checklists available to ensure consistency in frequently performed tasks. 

In some industries, checklists are also available from professional associations or commercial service providers.

When clear acceptance criteria are not written into the WBS and mutually agreed upon, projects risk descending into chaos as incomplete or unfit tasks are either delivered or endlessly argued over.