Do you know the following situation? A software project is restarted and the individual tasks are distributed within the project team. Sometime if (nearly) all roles are assigned – no one has thought about the configuration management. Often this role is quickly assigned to the project leader, because – so the assumption -there is anyway not much to do, so the project leader can get the job done easily.

Then the project is started. For quite a long time the project is going well, although the project leader is not able to find the time to take care of the configuration management in daily business. Even the first delivery to the customer can be carried out successfully.

The more complex and extensive the project is, the more likely a phase will start where you realize, that the project is increasingly difficult to control without any configuration management.
Problems usually occur, when you have to assign the tests to the software. The Requirements never fit properly to the tests and the software. There are more and more inconsistencies even at the planning documents.
Now the time is getting closer when the project team and the project leader realize, that the project is getting out of control, if the role of the configuration manager isn’t actively filled. The project leader realizes that he is not able to handle this task himself “by the way”. The team will often be enlarged and a configuration manager will be deployed.
At this point of the project, it is usually a big challenge to work out a suitable configuration management strategy and to implement it.
On the one hand there is an enormous time pressure; on the other hand the project runs late to have the ability to change a lot of things.
The graph illustrates the task.

Over and above tool boundaries diverse artifacts must be combined into one configuration state. Here a suitable strategy for the procedure is required. The use of tools is necessary but not sufficient to solve the task successfully.
You should ask yourself the following selection of questions when you have to prepare a configuration management strategy:

• What is the content of a configuration item?
• How many times a new configuration item is generated?
• Which naming conventions for”labels” are skilled and helpful?
• How to combine artifacts which arise in different tools, overall into one configuration status?
• How will change management and configuration management be synchronized?
• How is the configuration management to be aligned with long term archiving of the development results during the product development phase?

If you proactively resolve at least these issues at an early point of time, you will perform a successful configuration management.
At any time you will be able to request and to determine the status of your development.

Are you ready for a status workshop, to analyse improvement potentials in your configuration management, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.