Ever wonder about that ephemeral word quality while elicting and documenting requirements on your projects? How can you plan for quality and reduce re-work, especially if you are an Information Technology professional whose products cannot even be seen or maybe even conceptualized until they have already been produced? Of course, you will use illictation methods and models to show your clients what you understand to be their requirements, but what about the production of the deliverables, the fruits of your labour?
Well, the old adage "when you fail to plan, you plan to fail" applies here just as it does in any of the ten knowledge areas PMI defines for all projects. Yes - believe it or not - quality doesn't just happen. And quality does not equal perfect, otherwise every project would go on forever, just like that children's song "This is the song that never ends." :)
So - how can you plan for quality? Well, for a start, you can tell your project sponsor and stakeholders how you plan to meet the requirements they have laid out for you, starting with identifying the deliverables you will produce as defined when you broke the work down into an understandable structure (look up "work breakdown structure".)
Engage your team and stakeholders in describing each deliverable before you start producing it. Identify who is going to produce each (probably team members) and who is going to review and sign off on each (probably clients). Seek their input, agreement and sign off of a "deliverable expectation document". Use this subsequently when the deliverable has been produced and the review is occurring.
Assure quality - build it right the first time, but control quality too - check that it was, indeed, built right the first time.
How do you assure quality? Standards, best practices, templates, examples, expert advice, lessons learned, past experiences, involving the right people, measuring - all these and more go into assuring quality.
How do you control quality? Review by subject matter experts, carefully planned testing, dreaded re-work (made unnecessary, of course, by your excellent quality assurance processes).
Remember - you can't test quality in, so pay a great deal of attention to quality planning and assurance.
There... now that is simple, isn't it? Can you get it right the first time? Well - probably not always, but it is sure worth the try, don't you think?
Now, if I could just get the cursed song out of my head... this is the song that never ends... it just goes on and on my friends... some people started ... help!
There appears to be a bit of split in the use of terminology in defining the scope of a project through the creation of the Work Breakdown Structure. Some seem to take an activities-based view, as evidenced by the template on this site called Project Work Breakdown Structure Guidelines, while others seem to take a deliverables-based approach, as found in PMI's Guidleine to the Project Management Body of Knowledge, which says that creating a WBS is the process of "... subdividing project deliverables and project work into smaller, more manageable components". Still others take a hap-hazard approach - don't worry - we won't talk about that here.
I have long held that a deliverables-based approach to project planning, executing and, most importantly, progress tracking and reporting is key to creating a mindset on a project that focuses not on what you have done (the "activity"), but on what you have produced (the "deliverable"). Have you seen status reports that focus on activities done last period, and activities planned for next period? Are they effective? How about status reports that delve into what was produced last period and what is planned to be produced next period? See the difference? One pulls you down into the whirlpool of things people did, often with no relation to why they did these things and what they hoped to accomplish. The other is much more concrete - what you produced in relation to the project WBS. You can even get very black and white about these things using the done/not done approach - a given deliverable is done, or it is not done - 0% Complete or 100% Complete. Of course, this doesn't work very well with ill-formed project schedules where a deliverable can consume many months or even years of effort. But if deliverables are concise, well defined and restricted to maximum effort levels, it works very well. Or you can consider breaking large deliverables into work products, the "done/not done" of which determine an overall %Complete, and track your deliverables that way.
If you consider a deliverable to be the output of an activity, why not flip it around and relegate activities to those things you must do to produce a deliverable? You can structure your project schedule around deliverables, and you can measure your progress based on the deliverables you have produced, or the portion of a deliverable you have produced. This ties in very nicely to Earned Value Management, but that is another topic.
How do you define the scope of your project? Are you an Activities-based or a Deliverables-based thinker? Do you measure progress based on what your team did for a period of time? Or on what they produced?