Configuration Management

At Brüel & Kjær I was responsible for a number of software process improvement projects. Focus on one of these was to improve the efficiency of the configuration management process. The results of this will be presented below. The results of the other process improvement projects can be found via the main page.
Lately I have been most interested in studying configuration management from a project manager's viewpoint.

Improvement Project at B&K

In June 1999 we started an experiment to improve the configuration management process at Brüel & Kjaer. Unfortunately this was not completed before the end of the large Danish software process improvement project Center for Software Process Improvement (CSPI).

In order to find the real causes behind some of the configuration management problems, that Brüel & Kjaer had experienced, we used a problem diagnosis technique based on interviews with developers, project managers, and persons responsible for software quality.

These interviews changed the focus of the improvement project from a perspective of documenting/updating existing configuration management procedures to one of workshops creating a better understanding with developers for the value of configuration management as seen from their perspective, so that they could create themselves the optimum framework and procedures for configuration management on their projects.

We were ready to introduce the new principles for improvement of configuration management on the first projects in September 1999, but ran into the resistance of the development management against our approach to solving the configuration management problem. The planned experiment was terminated before the ideas had been tried in practice.

Return to top of page.

Configuration Mangement from the Developers' Perspective

Configuration management is normally regarded as a quality control discipline focusing on managing changes to products, which have been released to the market. Through interviews with developers, project managers, and persons responsible for quality we have, however, found that there is an equally important need for using configuration management techniques even during the development process itself.

This led os to work on alternative metaphors for configuration management concepts, so that we could better match the developers' own need for configuration management. We have incorporated the metaphors in a workshop format, where the developers learn to work with the configuration management techniques.

The work on defining configuration management from the developers' perspective has been performed together with Lars Bendix, who is a researcher specialising in configuration management. The result is now presented in the form of a one day workshop, which we can give for developers on development projects. The workshop was held the first time as a one day tutorial at EuroSTAR 2001 in Stockholm: Configuration Management from a Developer's Perspective [1].

Return to top of page.

Configuration management from a project manager's viewpoint

Teaching master level future project managers at Roskilde University", I have become increasingly interested in making the importance of configuration management more easily understandable for project managers (as well as managers higher up) – just like I have been doing it for other disciplines like requirements and test.

This interest has meant, that I over a number of years have attended the annual "Scandinavian SCM day" in the SNESCM-network (The Scandinavian Network of Excellence in Software Configuration Management). I have presented papers, lead panel discussions and Open Spaces in order to make more clear, what CM-specialists see as their core competences on a project – and through this understand what every project manager must request from his/her configuration responsible person.

In 2009 I started with a presentation titled: "SCM and Process Improvement". The presentation aimed at giving some ideas to how professional SCM persons could better exploit their great knowledge and experience and thereby contribute to the success of their company.

In 2010 I facilitated a panel discussion titled: "SCM as a service - what do our customers want?". The panel discussed SCM from the perspective of the many types of users and their different needs. The panel particiapants were both SCM specialists and users of SCM.

In 2011 I facilitated an Open Space titled: "Getting to the essentials of CM – what are our core tasks?", where we tried to find the core services in CM based upon the many different types of tasks, that the participating SCMs perform in their day-to-day work. There was aggreement that the most important task for a SCM person is to manage the different configurations of the compny's products, because the CM responsible is the real owner of the physical product.
In this Open Space I also tried to find out the ”one” question, that every project manager should ask his/her configuration responsible person to assess, what the status of the product (components) is. This way of simplifying CM is of course completely extreme, but sufficiently provoking to start a discussion about the subject. The answer that the Open Spacet came up with was: What prevents me from releasing my product? Ie: What is the release status of my product's components?
This question can be compared to the ”one” question a project manager should ask his/her test managers: What is our test coverage? Ie: How far are we wrt. our test coverage goals. It would be interesting to find similar types of “one” questions that a project manager should ask each of his/her subject specialister (eg. requirements analysts, design architects, database experts, usability experts etc).

In 2012 I facilitated another Open Space titled: "CM in Heterogeneous Environments – what solutions do you use?", where we tried to find practical solutions to CM problems of: Combination of mainframe and .net systems; Document and code handling systems; Supplier and in-house CM systems; Distributed CM systems. The result showed that there were no easy solutions (only manual), but that products are emerging which can handle some of it.

In 2014 I facilittated yet another Open Space titled: "The 5 dimensions of CM – How can we manage them?", where we discussed a paper by Van den Hamer & Lepoeter on Product Data Management, because it claimed, that automated tools can only handle them pairwise. The dimensions are: Versions, views, hierarchies, status og variants. There was aggreement about this for the first 4 dimensions, but that variants are something quite separate – and must be treated as such.

Return to top of page.

Seminarer og Præsentationer

Lars Bendix and I give a one day workshop titled: "Configuration Management from a Developer's Perspective" [1]. The workshop is designed to be held when a project team should decide how they are going to use configuration management on their project. The idea is that the project team after the workshop can formulate all their configuration management procedures so they fit exactly their project. The optimum would be to have one of the company's process consultants participate in the workshop, so the results can be incorporated in the process improvement programmes of the company.

Furthermore we give a half-day workshop titled: "What would you like CM to do for you - and what value can CM bring you?". The goal of the workshop is, through discussions based on the specific company case(s) of the participants, to make the CM principles applicable in your/their context. The workshop is aimed at middle managers and subject specialists (other than CM), who need to get more knowledge and insights into the principles of configuration management.

We also give presentations on this subject varying from 45 minutes to 2 hours depending on your needs.

Return to top of page.

Home Page -
Hjemmeside - mail@ottovinter.dk