Defining the output via product descriptions

This post and other recent posts relate to one approach to progressively distilling the voice of the customer into project plan.

It shouldn't be adopted in a vacuum and other posts here on quality and requirements are important as is (doubtless) a world of detail specific to your particular ecosystem.


I have focussed in detail on the WBS (3) though elaboration of the WBS itself, a useful supporting narrative for the WBS and the WBS dictionary. This post will look at product descriptions and touch a little on the composition of work packages.

The schema for the product descriptions is quite large so I've transposed it as shown below. Again, it's Prince 2 aligned and you can download the template here.

1. Identifier- needs to be unique and should be traceable to the corresponding WBS element
2. Title - something meaningful
3. Purpose - Important. Be accurate, succinct and clear - what's this product for?
4. Composition - What's in it? If it's a document, you might describe the particular section headings
5. Derivation - how will this be derived or what from? 
6. Format and presentation - speaks for itself
7. Development skill required - if you need a rocket scientist, here's where to state you case
8. Quality criteria - how will the product's fitness for purpose be measured or ascertained
9. Quality tolerance - and how much can it deviate
10. Quality method - how will it be checked (review, inspection, external audit?)
11. Quality skills required - anything specific? Subject matter expertise, certification or other.
12. Quality responsibilities - who's head is on the block?
13. Status - draft, approved, completed, late and so on and so fourth.

There's probably more detail than is needed for most products and that's fine. Understandably, you're not likely to add additional columns just because you come across a specific product for which you wish to define additional detail. So include all the fields but leave them blank where appropriate. The additional structure can serve as a useful handrail for reviewers.

Those of you with keen analytical eye might have observed a discrepancy. All this work to elaborate and specify detail corresponding to products - fine. What about for all the work for which there isn't a product or for which there is a disproportionate amount of time / money committed for the given product? Where do we instate the control necessary to govern the activity? The answer is in a formal documented 'work package'. I have some views on this so will hold off going into too much detail and make it the topic of a future subject specific post. I'll include a template and some particular content around testing which adds value.


In summary then. A while back I looked at the following abstraction and talked quite a bit about 'achieving quality' and defined quality as 'meets requirements, fit for purpose.

I laboured (but didn't finish) requirements and requirements management, talked in detail about the quality risk assessment and just touched incidentally on defect management and the quality log. (By the way, my quality log is the opposite of the defect log - i.e. it records stuff that's okay as opposed to defective. This is distinct to the Prince 2 quality register which records 'quality activities'. Technically you don't need a quality log, but it can be quite a bleak experience going into project board meetings with a defect log and nothing to illustrate the more positive end of the equation).


This post and the last few posts have dealt in the development and implementation space. Taking the customer's vision, I generate a WBS and an accompanying narrative and get it reviewed and signed-off. I then elaborate the WBS into a WBS dictionary and identify any products. Where products are identified, they are elaborated via product descriptions. Note too that work packages play a part in controlling work without obvious products or for which the cost was disproportionate in comparison to the output. For the WBS elements with products we can probably take items straight off the QRA and apply them to the product descriptions as appropriate.