Moving from Standard to QA Document, Part 2
Making a document and a procedure for checking CAD files will hopefully give your teams some way of checking the CAD files for compliance. One way to do this is to use your Standard as a guideline for creating a QA checklist. Last month, we discussed how to do that. Now we turn ourselves to the process of making it happen.
Once you have the checklist in place, you need to be the workflow to encourage its use. Who has the power to make this happen? The person who controls the process is typically the project/product manager. It is his or her job to get the project completed and to control quality. It is up to that person to make it happen.
Your part in this is to convince the project/product manager that it needs to happen. Look for ways to show that the lack of quality is impacting speed, coordination, and collaborations efforts. Many of the issues are out of the view of most PMs. You need to bring them to light. How do you do this? Find these issues by reviewing the projects yourself. Get permission or do it on the sly. Take a look at the files for yourself and report back to the PM.
Project Review - Triage
Take your checklist and start opening files. Take one file of each type. If you are working Architectural sets, then take a plan drawings, sections, elevations, details, legend, and so on. Open each file one at a time and go through the checklist. Move quickly and check as many things as you can in a short amount of time. All you are doing is assessing whether or not the files are in fairly good shape. If you pass by quickly and things look good, you can move on to another file. If you don't find much, you can safely assume that the files are in okay shape and that any troubles will be fixed as part of the regular design process. When problems occur in a normal set of files, they can be fixed as they arise.
Project Review – Deep Dive
If you find that the files are full of variations and non-standard data, then you need to do a deeper dive. Look longer and harder. The goal is to find out how deeply the bad data has permeated the whole set. And to find out what it will take to clean it up. Now you need to start documenting what you are finding. A good deep dive should not take more than two hours or so, depending on the size of the set. You are not fixing things, just defining what needs to be fixed.
Project Review – Diagnosis
Now that you have a good grasp on what needs to be fixed and how pervasive the problems are, you can determine what it will take to fix the files. Some of the fixes may be critical and others may be pushed off until later. Make a good stab at what you think it will take to fix things. You may even take the time to fix some of the problems just to see how long it will take. Ask others what they think it would take to fix the problems. In other words, get a second opinion.
Project Review – Reporting In
After you have defined what needs to be done (and written it down) go have a talk with the Project Manager. Show the PM your findings and share your concerns. Don't move on until you get the manager to agree to fix things or to take total responsibility for the bad files (in writing).
Seeing the Light
At this point the focus is to get the PM to see that there are problems and to understand the need to fix them. You are trying to fix the project needs and also address the overall need for a quality check process. Do a review on several projects to see if there is a pattern. Report back to several managers to show that the issues exist. Then start talking about a workflow change that will incorporate a QA process.
Next time we will look at fixing the bad files and setting up a process for Quality Assurance.
