One of the key tenants of PRINCE2 and Project Delivery is to be very clear on what needs to be delivered, by whom, when, and against what criteria.
A “product description” or “deliverable detail” should describe the item, possibly including format, content, specification depending on whether is a intangible item (eg review, report, policy, process) or tangible item (eg a PC, house, oil rig) .
It might also detail the author, owner, and approver (or equivalent which might be architect, builder, QS, owner) and the acceptance process so that there is clarity on what is or is not acceptable.
If you do all this there is a risk you spend more time describing the product and process than you actually spend developing and delivering it. However the other risk is that you spend time developing and delivering something that is not suitable, feasible, acceptable or agreed.
It can be tricky to get the balance right.
There are plenty of good guides and template, particularly for PRINCE2
PROJECT MANAGER V PROJECT LEADER
Often a client knows they have a need, but are not 100% clear on the solution or indeed the components and criteria necessary to satisfy their needs.
A Project Manager is someone who can deliver exactly what is required, on-time, on-budget, to-specification with low-risk and high-communications
A Project Leader is someone who can help the client develop clarity on exactly what they need. This may be by workshop, facilitation or prototyping. Once that clarity is there developing and delivering is much more straight-forward.
CLARITY V COMPLEXITY
As noted above, the level of detail that goes into describing and documenting what is required can either add clarity or complexity. Too little detail and there is ambiguity of product, roles, responsibility, time-scale or cost. Too much detail and “…it all looks too difficult..”
One approach is to use a database and then switch-on or off the elements that you and the client feel need documentation.
This then allows you to dial-up or down the clarity v complexity ideally to the point where everyone is singing from the same hymn sheet and that hymn sheet has both words and music necessary for each project participant.
Below is an example of some headings which you might consider.
DELIVERABLENAME: This is the name, title or short description identifier
REQUIREMENT: It is important to briefly outline the need, so as to be clear what the requirement is that needs to be satisfied.
PURPOSE: It is also useful to clarity the purpose. Whilst the need is what needs to be delivered, the purpose is why. To…[be faster, cheaper, better, safer, compliant]
INSCOPE: It is useful to be clear what is included, and what is not included. If there are changes of requirement having a clear scope will help assess the impact of changes on time, budget, or quality of output or outcome.
OUTSCOPE: It is useful to be clear what is included, and what is not included. Taking the time to say what is not included may be useful to managing stakeholders who want to extend the work or scope to satisfy their own ends. This “scope-creep” can push up costs and add to time, without adding value to the outputs or outcome.
CRITERIA: It is useful to be clear on acceptance criteria, which may be passing an audit or standard ISO or SOC or perhaps satisfying a key output or outcome, possibly measured by KPIs
GUIDANCE: You might want to refer to relevant guidance including laws and regulations, or policy, procedures and processes
FORMAT: If it is intangible the output may be a report, certification, perhaps in a .doc, .pdf, .xls or other format. If it is tangible the output may be described in a specification eg bicycle, moped, motorbike, car, van or bus.
CONTENT: If it is intangible the output may be a report headings: Introduction; Executive Summary; Method; Report; Recommendations. If it is tangible the output may be described in a specification eg blue-prints, architects drawings, technical details.
AUTHOR: The supplier
OWNER: The customer
APPROVER: The authority
METHOD: In some cases the process is as important as the outcome. This is true where there are many stakeholders, different views, change or cultural implications. Being clear on the approach is useful. It might be simply gather agreed information and inputs (including existing policy, process, paperwork); Meet agreed stakeholders; Draft report; Consult; Review; Finalise report
DAYS: Estimating days is always difficult because the availability of people and resources can speed things up or slow things down. Try however to give a realistic indication of time, based on sensible assumptions about the availability of data, people, process and technology.
LIMITATIONS: It is important to outline any risks or limitations. For example progress and content may be dependent upon availability of people and data, and consequently subject to variation. [Albeit within the control of Owner/Approver as regards resources and priority] Other constraining factors may be time or budget.a
NOTES: You might want to include additional notes or comments.
Doing all the above may be onerous but in some cases may be worth the invested of time and thought. I recommend you talk with the client or customer and agree the best approach to ensure mutual understanding and a shared commitment to delivery.
ABOUT THE AUTHOR
Tim Rogers is a Qualified Change Practitioner and PRINCE2 Project Manager, with an MBA in Management Consultancy. Past projects have included the incorporation of Ports of Jersey and Operations Change and Sales Support for RBSI and NatWest. He is a tutor/lecturer for the Chartered Management Institute.
+447797762051 Skype: timhjrogers TimHJRogers@gmail.com
Source: Adapt Consulting Blog