Work with the Configuration & Change management

As a Process Engineer working with Configuration & Change Management, you will find different people and different projects have different problem areas. This section offers tips and tricks that have been found to be useful when implementing a software process such as the Unified Process in the Configuration & Change management discipline.

Ideas that were beneficial

• Regular feedback sessions on the progress of the Process Engineering effort, to the rest of the team.

• Use a simple worked example of some source undergoing a change to demonstrate the CM process.

• Understand the existing Change management process.

• Draw a State Transition Activity diagram to explain the Change Management Flow for the project.

• The importance of having a properly configured directory structure for the development process.

• Do you have more ideas to add to this list? Please send them in for us to publish
•  

Understand the existing Change Management Process

In order to make any enhancements or fixes to the change management process, the first thing that needs to happen is to understand the existing process. How do we go about doing this?

One way of getting it down is to Model the exiting process:

• Define the static elements of the process. What is being used to transfer information? Forms, Documents, emails, paper, verbal. Use a Class Model to do this.
• Define the exiting roles involved in the process. Who is doing what? What are their goals and reasons for doing what they do? Use a Business Use Case for this.
• Define the dynamic order of the process and the States the static items are altered to. Show the Activities in the order of their execution. Use either an Activity Diagram, a State Diagram and or a Sequence Diagram to show who does what when, and what state each item comes to rest in. States can be things like 'Submitted', 'Pending', 'Approved for change', 'Awaiting change', 'Being Changed', 'Changed', 'Cancelled', 'Rejected', etc.

Next we need to get a feel for how mature the process is in general.

• Are we bringing in a change management process from scratch, where nothing currently exists?
• Are we changing a process that largely works, but has some identified flaw/s?
• Is the change management tool in place already, or does one need to be brought in?
• If one exists does it integrate into the other processes, such as requirement management, testing, configuration management, etc?

Now evaluate this process and ask questions of it:

• How many different states are there?
• How many transitions between states are there?
• Is it simple to follow? Is it too simplistic or too complex?
• Could items be left in some dead end state such as 'pending' or 'cancelled' and be lost?
• How hard will it be to train people on this process?
• How likely are they to use it?
• Have they been using it?
• Why does this process need to be changed?
• What does it not allow for?
• Is this a Role problem?
• Is this an Activity problem?
• Is this a State Problem?
• Is it a Process Problem? As in timing, performance, accessibility, practicality, etc.
• Is it any combination of the above?

Home