|
|
Understanding the design change control process
by David Dick
Are you frustrated because it seems that a project will never end? Are you working longer hours, weekends, and holidays to compensate for schedule slippage due to an avalanche of design changes? Is the project manager unaware of how changing the design affects schedules, resourcing, and budgets?
There is a solution and it's called Design Change Control.
This article is intended for documentation managers and technical writers who want to understand how changes to product design affect documentation projects. It does not cover the design and development process, or responsibilities and authority for design and development activities.
Purpose of design change control
This is certain: design changes occur at every stage of the design process, from the stage at which the customer requirements are defined, to when the design is proven fit for delivery to the customer. How design changes are documented, communicated, planned, and implemented makes design change control important.
Benefits of design change control include:
- Assurance that the design adheres to the objectives and goals.
- Better accountability and scheduling of design changes.
- Creativity allowed in a controlled and structured way.
- Stakeholders awareness of what changed, why, and how changes affect product design.
- Less tension and conflict among teams and individuals.
Without design change control:
- The design deviates from the objectives.
- There is no accountability for design changes, and scheduling is chaotic.
- Design changes may be implemented without the knowledge and approval of the project manager, stakeholders, or customers.
- Costs escalate because changes are implemented without considering the impact on development time and budget.
- Documentation may be inaccurate and incomplete.
With no control of usability and quality assurance testing the product may operate in unsuspected and undesired ways. Never deliver a product to the customer until it has been tested and proven fit for use.
Methods to identify and record design changes
There are three steps in identifying and recording design changes:
Step |
Purpose |
Change Request |
Describes the reasons for the change and the results of evaluation. It is used to initiate the change and obtain approval before being implemented. |
Change Notice |
Provides instructions for defining what must be changed. It is issued following approval of the change request as instructions to the owners of the various documents affected by the change. This ensures that the necessary changes are made in the documentation. |
Change Record |
Describes how the changes were implemented and the test results, and how documentation was updated. |
Managing Design Change Requests
Change requests are reviewed by a Change Review Board, which evaluates the requests to determine:
- Whether the changes are feasible by time, resources, costs, and time constraints.
- The requirements necessary to satisfy the change.
- The impact of the changes on other products with which they interface and in which they are used.
- Depending on the severity of the changes, the schedule to implement them in the current release or a future release.
The Change Review Board consists of the following members:
Board member |
Responsibility |
Project Manager/Product Manager |
- Presents change requests to the Change Review Board.
- Assesses the feasibility and practicality of implementing the changes, and impact to other systems.
- Identifies time, resources, and cost to implement the change requests with customers.
- Informs top management of time and cost to implement change requests.
- Informs external customer, if any, of time and cost to implement change requests.
- Approves change notice.
|
Project Team
(i.e., designers, developers, programmers, technical writers, trainers, and programmers) |
- Advises Change Review Board of feasibility and practicality of implementing the changes, and impact to other systems.
- Issues change notice.
- Updates change records.
|
Acceptance Testing (Quality Assurance) and Usability Testing |
- Tests functionality and usability of changes
- Updates change records.
|
Top Management and External Customers |
- Is advised on the status of the product.
- Proposes design changes.
- Is informed of design changes.
|
Facilitator |
- Convenes meetings.
- Keeps a record of discussions and decisions.
- Moderates meetings.
|
How the design control process affects documentation
Product design changes affect customer requirements, functional requirements, use cases, test plans, design specifications, overall design documents (optionally high-level design and detailed design), user guides, system administrator guides, installation guides, and training manuals, press releases, marketing brochures, service descriptions, and release letters.
If project management and designers are unaware of how changes to product design, no matter how small or cosmetic, affect documentation, you need to educate them.
Here are some suggestions:
- Publish a documentation development process. Educate stakeholders on how the process contributes to quality documentation.
- Participate in project meetings. Keep stakeholders informed, by publishing your own progress report, of the status (budget, schedule, and resource allocation) of documentation projects. For projects experiencing frequent and numerous changes, provide periodic progress reports to ensure that you communicate your concerns about design changes.
- Ensure that you or your department is represented on the Change Review Board.
- Create your own change request form to identify the impact of product design changes to documentation.
- If you manage a documentation department, stress the importance of design change control to your team.
Summary
The design control process will not assure quality. However, if everybody follows the process, it will result in better control of design changes, better scheduling to implement changes, documentation that accurately reflects the changes made, and products that satisfy customer expectations—all of which contribute to a better business-to-customer relationship and greater harmony in your workplace.
References
Hoyle, David, (2001). ISO 9000 Quality Systems Handbook (fourth edition), Butterworth-Heinemann.
ISO 9001:2000, Quality systems model for quality assurance in design, development, production, installation and servicing.
Hackos, JoAnn T. (1994). Managing Your Documentation Projects, Wiley & Sons, Inc.
About the Author
David Dick (david.dick@swift.com) is a technical writer for the Society for Worldwide Interbank Financial Telecommunication (SWIFT) in LaHulpe, Belgium.
|
