ProjectConnections Print View
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.
Learn more about ProjectConnections and who writes our content.
Site Help
| Content Levels | |
 | Register for free access to papers, case studies, and almost 50 templates. |
 | Subscribe for complete access: $14.95 monthly or $149/year |
| Risk-free 15-day trial!
Compare levels View sample templates Corporate subscriptions | |
Guidelines - Completion Criteria
Quick Summary
Completion criteria are explicit goals that must be attained to call an element of a project, or the entire project, "complete."
What this is
This term is used to refer to setting explicit goals that must be attained to call an element of a project "complete."
Why it's useful
Completion criteria are really a communication tool and an important aspect of "quality management" on your project. The team needs to agree on when a particular activity or phase is done. For instance, is detailed design of a subsystem or software module done when drawings or design documents exist and the engineer says it's ready to be prototyped or ready to be coded? Or is it complete when a document has been written, reviewed, updated, and is officially under change control and published to everyone who needs it?
Obviously the latter is a very different definition of "complete" than the former. This is a qualitative form of completion criteria. The ramification of using the former definition is that the design may not be of high quality; it may have mistakes in it. The former definition of "done" leaves a lot to chance. The longer list of completion criteria are meant to ensure that all the right review steps get taken, problems are identified and fixed, the right people are involved in the review, etc.
The term Completion Criteria is often meant to convey quantitative criteria as well. For instance:
A very typical completion criteria for a testing activity will specify:
- No category 1 bugs (usually things that make the system crash)
- No category 2 bugs (often "must-have" customer requirements) unless explicitly signed off by Manager X, Executive Y, etc.
- Less than X category 3 bugs (usually non-critical feature aspects)
- Less than Y category 4 bugs (minor user interface or cosmetic issues)
The purpose of these criteria is to set very objective measures to ensure the system is not allowed out of test prematurely. If the testing in question is integration testing, which must be complete before we let the QA group have it for independent testing, then we want to make sure we don't hand them such a buggy system that they spend all their time having test cases fail and handing the system back to the software group to be fixed!
Or say we're doing the QA testing and the next step is to take the system/software to a beta customer (internally for IT or externally for a product). Typically beta at a customer implies they're using it in their normal production environment or close to it—which means we had better be sure we ship them something that works well enough for their use. The list above are very typical for "QA is done - OK to ship to beta" completion criteria. Note in this case, the completion criteria might also include "Customer service has reviewed and approved the draft user manual we have to send to the beta customer."
How to use it
Completion criteria are employed at different levels within a project:
- Completion of a project task
- Completion of a project major activity or phase
- Completion of customer acceptance of the product/service/system being created
- Completion of an entire project
©Copyright 2000-2008 Emprend, Inc. All Rights Reserved.
About us Site Map View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy