Confusing words often show us where there are poorly understood concepts lurking below the surface. One such area is scope and quality (yes one area).
Problems with both the labels ‘scope’ and ‘quality’ are grounded in the same simple fact: they have two parallel equally valid but different definitions. Both the titles are the same element of project management described twice and neither is the insightful label that “acceptance criteria” would be.
Two Definitions of Scope
A customer oriented view of the impact any project must make to avoid a threat to business as usual or pursue an opportunity for return.
ALTERNATE: Everything that must be done (task/ activity/ work-package) to deliver products/ Outcomes/ Results.
A technical, team oriented or project internal view of the work to provide the deliverables. Work then breaks down into three ‘real’ work lie brick-laying or welding, quality work that establishes what a good result looks like before ‘real-work’ commences but also checks that results are conforming to specification and thirdly work-about-work or the management tasks required to delegate, escalate, report and control resource use for best overall progress towards targets.
Two Definitions of Quality
FIRST: Fitness for purpose (independently of whatever was actually asked for)
The perspective of a project’s customer who will take deliverables into usage to generate benefits.
ALTERNATE: Conformance to specification – the limit of what the team can target. Unless they are clairvoyant the team can only produce what they are asked to create.
The customer wants deliverables that are fit for purpose, generally has no interest in how they are created as long as they meet expectations and may not be able to express what deliverables they need or the qualities or ‘attributes’ that will make the products fit for purpose.
Project Team Perspective
The team generally has no interest in what the customer needs or wants only in what they have to do to get paid and perhaps where there is potential to extend their skill base while creating what was asked for whether that is actually what is wanted and needed or not.
Tools for Capturing Scope and Quality
In the above differences of perspective are the seeds of all the difficulties, false starts and disputes that arise. With the right view-point and tool-set there is also the setting for freedom of expression and clear communication.
Recognition Event® (RE)
The ‘top of the hierarchy’ is a little know tool called the Recognition Event® or RE and part of a method called Dimension Four®. A Recognition Event® is a dated test at which a goal-owner will literally view (or otherwise experience first hand) some event in a value stream EG “On the 4th Jan next year I talk to a customer as they leave our new retail premises with a purchase of fresh-baked bread”.
The RE sets business direction in concrete terms that are evidence based, testable and outcome oriented. The next scoping tool is to back-cast the significant steps in the journey such as acquisition of premises, ovens, suppliers and skilled staff. These are all project deliverables that are pre-requisite to the RE and will lead to a value stream.
Product Breakdown Structure
The Product Breakdown Structure as PRINCE2® calls it (and sadly confusedly as the PMI describes a Work Breakdown Structure 🙁 )
The tool to capture the customer’s view of both scope and quality is the Product (or Impact/ Result/ Deliverables) breakdown structure. This product oriented decomposition is the tool of choice to define in customer terms what is wanted and how good it has to be.
In fact what we should recognise is that it is the technique of decomposition where used in an Agile, PRINCE2® or PMBoK® Guide context that is the real power-house. Decomposition of the project’s Results or Products is carried out to the level of detail at which the customer says “I don’t know (or care) what that comprises”. The PBS is a collection of nouns or things. For example our new Bakery owner may say to see a customer leaving I need and oven capable of 1,000 loaves per hour in batches of 100 and a baking time of under 20 minutes per batch. When asked about fuel type the customer may not care if the oven is electric or gas or may insist it is wood fired.
For each item in the decomposition about which the customer has expectation of its qualities or attributes the customer’s criteria for acceptance must be recorded (or gaps and ambiguities noted).
The creation of a PBS is an important opportunity for the project manager to gather those with opinion around a wall with yellow sticky notes and involve those sponsoring the project and affected by the projects outputs. Run as a collaborative activity it allows the project manager to gauge the politics and generate customer side motivation.
The tool to capture the technical team’s view of both scope and quality is the Work (Task/ Activity) Breakdown Structure – At least the tool that axiomatically fits its name which is NOT what the PMI definition has been over many years – although the 5th Edition published in Jan 2013 is more accommodating).
A WBS is a decomposition of the lifecycle of each product or sub-product the customer expects to the level of detail at which the project manager and team says “we don’t need more detail to maintain control and track progress”.
The WBS is a collection of verb-nouns pairs or achievement oriented phrases Eg “Buy oven” or “install gas supply” “hook-up oven to gas supply” that reflect as much of the products life-span as the project manager and team are accountable for (EG “Design oven” must have happened in the oven’s life-cycle but was not in this project’s scope and “Deliver Oven” may or may not be in scope depending on how arrangements are made).
The WBS may start life as an extension of the PBS before being regrouped by project phase to aid scheduling or by skill group to aid assignment of responsibility. This is often the easiest and best method
For each item in the decomposition about which the supplier has process or product standards in their quality management system technical testing criteria from unit to integration and system level must be recorded (or gaps and ambiguities noted).
The creation of a WBS is an important opportunity for the project manager to involve those creating, acquiring, amending and integrating the project’s outputs.
Run as a collaborative activity it allows the project manager to create understanding across the team of the project’s goals, alternative solutions, assumptions, constraints, dependencies and risks.
The simple steps to solve (some) of project management’s problems with successful project delivery are to recognise the correct mindset is “product and task”. These map easily to scope and quality but are not the thinking tools that lead to success – those are RE>PBS>WBS where W does mean verb in specific contradiction to the PMI’s guidance and more to the point is to recognise that it is the technique of Decomposition (the “>” above) when used within a social team setting that is the power-house.
Decomposition must first be deployed with a view to “What” which is Outcome and sponsor based. We call the result a Recognition Event®. Then it’s used with a “How” focus by business managers to turn REs into the business transformations needed to create the inspect-able events which leads to further cycles of “What” > “How” specification.
When the sponsors and users have been identified through stakeholder analysis then hold workshop that develop description of “product”, when the products are known then workshop “activity”. Activity must include all those required to build products, verify products, report progress or run configuration management, change control, communications etc, and then all that is left is to estimate, build the schedule, execute to plan, track achievement handover and close out – easy.
Logical Model Ltd consult, mentor and train in the skills to perform the steps above. It’s a couple of days training rather than a few hundred words of explanation to properly absorb the knowledge required.