The problem is that there are likely to be many items that are too detailed to be in a Test Plan or management plan that need to be of a certain level of quality for the project to be successful. We aren't going to create a separate Quality Assurance document for each one are we? No. But we can work to cement agreement on what "quality" means for these lower level things.
Lets take a look at a project plan.

Here you can see a project and the detailed lines for finishing the requirements phase and the first two quality assurance/ design sessions. So here you can see "Prepare for QAS - Create and send out Read-Ahead Package (RAP)". We're not going to be creating a separate document on measuring quality on that. I tried to be pretty clear in my work statement when it came to sending out a RAP but there is an opportunity here to be even more clear.
This next image displays the "Notes" field for a work package in the project plan.

Notice how I use this field to identify the details for exactly what I am looking for in this work package. Keep in mind I'm not writing a tome here. But I am creating objective measures for what I expect when it comes to that or any other work package in the plan. If we going to spend 4 or 8 hours on something, I want to know what we're going to get out of that effort.
I recommend using this notes field to capture the quality metrics for work packages on your plan.
No comments:
Post a Comment