Topic 5.3: Acceptance criteria

Likes people like this topic - including you!

SharesThis topic has been shared 25 times!

Progress2,585 people have passed the quiz

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

Yet all too often, the process of 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 work that is required.

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 in the process of breaking things down is usually a judgement 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 skillstime and resources, your task outputs would be equally fit for purpose for the subsequent requirements of the project.

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

We will teach you how to manage conflict in the next Module

If I independently gave three architects $20,000 each and two weeks to prepare a house plan, I am likely to get three wildly 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 are all likely to 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 expert 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.

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

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

It is nonetheless important to remember that the act of 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 as well as an output (or deliverable), every WBS task should be a discrete unit of work that can be assigned an ultimate owner

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

You can't just throw it over the fence and hope for the best

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 very specific 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.

Some tolerances need to be tighter than others

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.

Acceptance criteria might also include 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 organisations have standardised 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, projects risk descending into chaos as incomplete or unfit tasks are either delivered or endlessly argued over.

What happens if you cannot get stakeholder agreement on acceptance criteria?

What happens if your stakeholders just don’t make any sense?

Source: YouTube