This topic has in all likelihood been discussed and hammered more than any other CM-related subject. But it’s a good idea to revisit it now and then, especially from another prospective and point-of-view, just to keep it fresh.
One of the first things asked by those “threatened” by the notion of controlling changes is, “Why do things have to change?,” and “What should be controlled?” As we all should realize, we don’t live in an ideal world, so when a configuration item or component is approved, there’s no need to change. However, we live in the real world where change is dynamic and inevitable. Requirements change, boundaries change, errors are found in documents and specifications or are just plain wrong, designs change, customers change their minds - in general, stuff happens! Consider the following important input criteria for change:
- Nature: What is the nature of the change?
- Alternatives: What are the alternative solutions?
- Complexity: How difficult is it to implement?
- Schedule: When is it required?
- Cost: What are the potential costs/savings?
- Severity: How critical is this change?
- Priority: How important is this change?
If we stop to think for just a moment, the number of items that should be controlled becomes clear. For example, requirements, design, test, and user documentation, source and executable files, database objects, models, prototypes, libraries and repositories, the CM domain, tools, scripts, plans, schedules, impact analyses, change requests, problem reports, migration requests, build requests, baselines, release notes, etc. The list of items that should be controlled can be staggering. Yet in many organizations, these items are not taken seriously and subsequently lost or worse - deleted.
To drive home a case in point, the affects of changes can be summarized as follows: - Requirements changes affect design
- Design changes affect code
- Testing finds problems the result of which causes changes to code, design, or requirements
How can we define the need for change? To answer this, a number of questions must be asked and their responses analyzed and considered. Such questions may include: - What needs to be changed?
- Why must it be changed?
- Who wants the change?
- How will it be changed?
- Who approves the change?
- Who will make the change?
- When must it change?
- What are the impacts? If changed? If not?
- How much will the change cost?
- How long will it take to implement
- What are the schedule and resource impacts?
Now that we’ve identified some “what” and “why” criteria for change control, let’s focus on the “how” and “who.” To begin, we need to define a change control process, which is established by accepting changes in a controlled and stable manner. The change control process controls and manages the release and change of configuration items and components throughout the development lifecycle. It also provides several key functional aspects including: - Change impact analyses
- Change authorization
- Tracking changes through closure
Changes made to baselined configuration items should be done according to a defined process and documented procedures. Such procedures should specify: - Who can initiate change requests
- Approval/rejection authority
- How revision history is kept
- Impact (analyses)
- Check-out and check-in procedures
- CCB process
- Escalation process
The most effective mechanism for controlling changes is the change control board or configuration control board (CCB). The CCB should include in its membership those stakeholders closest to or impacted most by changes, provide overall authority for managing baselines and configuration items or components, and ensure that all changes are considered, reviewed, coordinated, approved/rejected, and implemented. The CCB should also control impacts to project costs and schedules, categorize and prioritize enhancements (new requirements), resolve defects and problems, and establish an authority responsible for all change activity. The CCB also considers: - What is the specific benefit of the change?
- How would the change affect project costs?
- How would the change affect the project schedule?
- How would the change affect product quality?
- How would the change affect the project’s resource allocation? Would it add work to people already on the project’s critical path?
- Can the change be deferred to a later project phase or a later version?
- Would the change destabilize the product?
The actions of the CCB must include: - Being pro-active
- Being responsive
- The approval/rejection of all proposed changes
- Documenting all decisions
- The assurance approved changes are implemented
The entire project team must embrace change control if it is to be executed successfully. That is, there must be an overall understanding and acceptance of the process, and the process must be clearly and concisely documented for consistency of use. Change control expectations must consider: - What needs to be controlled?
- Who has approval/rejection authority?
- Who (resources) will implement the change?
- What (process and/or tools) will be used to implement the change?
- How will changes be tracked through closure?
- What should be measured to demonstrate clear benefit?
Remember that business cultures and problem domains are and will be different, so what works well for one does not guarantee success everywhere. Before change control is installed or written into law, make sure that there is total buy-in from all major and intermediate stakeholders. Without stakeholder buy-in, you have a process that is doomed for failure. Ensure the involvement of stakeholders and communicate results of change activities.
Dick Carlson is the founder of Software Engineering Solutions, a training and mentoring consulting firm. Dick has 20+ years of software engineering experience that focused on training and mentoring, development and implementation of software lifecycle methodologies, software configuration management, software quality assurance, and software process improvement. Dick has trained and mentored teams and individuals on efficient SCM activities, project management, requirements development and management, risk management, business modeling, and business re-engineering. He has also been involved in software process improvement initiatives in preparing organizations for SEI CMM Levels 2 and 3 compliance.
Dick is the VP of Education with the Association for Configuration and Data Management (ACDM) and can be reached at dcarlson@iascar.us.
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed