|
|
|
Direction for Data
|
Quality processes - How to build quality into project deliverables
- Recommended Quality Documents
The following list shows the typical quality documentation that results from the
implementation of quality processes. All project deliverables (written documentation and
software, including installation and configuration of COTS products must go through the
quality definition review and final acceptance process. The documents are loosely arranged
by category.
- General
- Project Charter: A statement of vision and objectives that has been reviewed and approved
by the executive steering committee.
- Meeting Agendas
- Written Deliverable Definition and Acceptance Criteria and Signoff Form: A document
that provides a high-level description, purpose, audience, review list, distribution list,
review schedule dates, and detailed table of contents for the written deliverable to be
created. The document author, Project Manager, and Project Director, each signoff on this
document two times. The first signoff is upon acceptance of the definition and the second
signoff is upon final acceptance.
- Written Deliverable Quality Acceptance Review Form: This is the cover form for
documents being reviewed. Used to record dates, revisions, comments, resolution of
comments, and team signoffs.
- Project Manual: A detailed scope of work with roles and responsibilities for deliverables.
- Deliverable Quality Acceptance Process: This document describes the tasks, roles, and
responsibilities for each team member from a quality perspective.
- OCM Plan: OCM prepares the organization for the new work processes and organization
(if required). The OCM plan begins at the IBPM (integrated business process modeling)
process when the work processes are defined across the enterprise and then reviewed and
improved within the associated subprocesses.
- Engineer and Build Software
- Software Deliverable Definition and Acceptance Criteria and Signoff Form: This form
includes a high-level software description (including a list of modules to be built and/or
installed), delivery, acceptance test and documentation review schedule dates, and a list of
software documentation to accompany the delivery (release notes, user manuals, system
administration manuals, code listings, etc.). This form should be designed for three
signoffs; one for the deliverable definition, one for code escrow certification (if used), and
one for final acceptance.
- Functional Requirements: A document derived from the IBPM process. The functional
requirements record how people, processes, and technology are envisioned to interact in
an efficient way.
- Use Cases: Detailed scenarios describing how each business work process will work.
Includes end user actions and interactions between systems and applications and data.
- Design Specifications: Functional requirements and use cases combined into programmer
level language.
- Coding Reviews: Peer reviews of an individual's coding deliverable. Coding reviews
should be done at both a unit and a system level.
- Test Plans and Scripts (peer testing, unit testing, operational testing, and acceptance
testing)
- Configuration Management: This document defines the tools and processes used to
manage versions of code during the software development lifecycle.
- Technical Administration Manual: A manual that provides a technical description of the
new system. This document will help in the care and feeding of the new system, and
provide support for troubleshooting.
- Quality Certification/Deliverable Signoff Sheets: The software engineer, consultant, or
contractor certifies that the software meets the requirements and specifications, has
completed a code review and testing, contains no known defects, and was produced
according to the governing quality process.
- Engineer and Build Data
- Data Conversion/Migration Plan
- Data Specifications: These include a from/to matrix, identification of primary data
sources, and documentation of rules for interpretation or calculation of values.
- Data Acceptance Test Plan and Scripts
- Deficiency Reporting and Corrective Action Documentation
- Deficiency Report Form: Used to record specifics of the deficiency: records the
requirement, requirement reference, and a high-level description of the defect. Includes
space for a tracking number and dates submitted, reviewed, and resolved. A detailed
description of the deficiency is attached to this form (if needed). All pertinent project team
members participate in the review and signoff of the deficiency and planned corrective
action plan. The final signoff is by the person assigned responsibility for the resolution.
Procedure steps are included as a part of the form for easy reference.
- Corrective Action Plan: This form is used to respond to the Deficiency Report by
documenting the root cause of the deficiency and a corresponding corrective action plan to
cure the deficiency. Interim preventive actions are defined as required. Mitigating actions
are also defined for any deliverables that may have been accepted prior to the discrepancy
being discovered and reported.
- Request for Corrective Action: This document is used to elevate an issue that is not/cannot
be solved at the project level to the Executive Steering Committee. An example of when
this form is used is when a written or software deliverable has proceeded through the
maximum number of redeliveries (usually two) without being accepted. Another reason to
use the form may be when a consultant or contractor chronically misses scheduled
delivery dates, or appears to have resourcing problems that adversely affect your project.
- Quality Metrics:
Last, but not least, how do you gauge that quality processes are being followed and that they
are effective? The list below is recommended as a starting point to measure you quality
processes.
- Written deliverables submitted versus approved
- Software deliverables submitted versus accepted
- Defects found during acceptance testing
- Defects found in previously submitted deliverables
- Process deficiency reports initiated
- Total open deficiency reports
- Corrective action requests issued
- Total open corrective action reports
Conclusion
In today's business environment that focuses on speed to market and immediate access to
enterprise data for employees, partners, and customers, there is a great temptation to bypass and
do without quality processes. We contend that quality processes are needed more than ever due
to the complexity of the GIS systems integration projects being planned, developed, and
implemented, and due to the relatively high incidence of documented project failures. The risk of
losing customers is very high if the interaction that you design and implement to help them is
difficult or confusing to use.
Speed and content do not have to be sacrificed, and, in fact, they are supported by the
incorporation of quality processes into your project.
|
|
|
|
