Principles of Change

Management of change can be considered in two stages:

• establishing a 'baseline';
• controlling the changes from the baseline.

Technical baselines are usually identified as Functional, Allocated (HWCI or CSCI) and Product are formal authorized requirements or descriptions of the design usually established by systems engineering.
Modifications or alterations to these established baselines will change the defining specifications or drawings by authorized Change Reports (Proposals and Requests).
The format and content of the baselines shall be identified in a Statement Of Work (SOW) and Documentation Standard usually as specifications.
Change Management aims to avoid wasted effort by establishing and promoting communication during the design of a system and its comprising parts; ensuring that all designers are aware of the activities of other designers which affect their own work.

Example: The number of communication channels (person to person) in a team of 5 people is ten; with 10 people there are 45 channels, and with a team of 20 people there are 190 channels. This situation is exacerbated where, on large and complex projects, design teams are separated geographically and work in establishments or organizations with historically different approaches.
There are three important parts to change management;

• the form, content, and classification of a change report;
• the division of the work;
• the communication medias.

All three can have an effect, not only on the efficiency with which the design is produced but also on the design itself.
Traditionally systems and subsystems are decomposed into elements of hardware and software configuration items detailed in the 'System/subsystem Design Description' see documentation SSDD example.
This has the advantage of providing clearly defined boundaries and responsibilities thereby reducing the chances of error. However, this doesn't always lead to good design if not managed and controlled to allow for simplification of a broader view.
When the baseline bas been established the change control system can be formalized,

1. A formal, written proposal for a change shall be prepared. This shall include the reason for the change, nature of the proposed change, the impact on other elements of the system or subsystem, and estimates of the time and cost of implementation.
   NOTE: Change proposals can be categorized as Class I and Class II see Configuration Control for an example.
   
   • A screening of proposals followed by formal authorization of work on the proposed change. A warning to all those likely to be affected that a change is being considered is then sent out.
   • Once work on a change has been requested all those affected must either stop work until the final details of the change are known or institute very close liaison with the instigators of the change.
   • Investigation on the change proceeds, with testing if necessary;
   • Approval of the change is formally stated using a 'Change Request' to notify all those affected and implementation of consequential changes to other areas, e.g., test, publications, etc.,
2. Change control (configuration) requires good administration to ensure:

• out-of-date issues and revisions of the design description documents are removed from the work areas.
• once work on a change has been approved, all those affected must recognize this fact and stop any further commitments until the final details are known or institute close liaison with the originators of the change;
• Configuration control is a dispersed activity requiring many people at a variety of locations to work in a standardized, conscientious, and disciplined way.
  
  

1. CONCLUSION
2. All assumptions and reasoning of a change must be recorded as well as a complete description of the design (development and product specifications for the HWCI and CSCIs). To avoid confusion and wasted effort it is essential that all personnel involved in the design and test knows enough about the design and its interfaces to avoid adversely affecting efforts of other members of the team.
   Once the requirements and product specifications have been established it is necessary to institute formal configuration control of all changes to ensure what has been agree is produced.
   To be continued.

This page is under construction
Back to Home page MANAGING STANDARDS Home page
Please send any beneficial comments or identification of errors using the following form to: kenr@wysywig.airtime.co.uk