I have worked with several client regarding the principles of change management. What I found was, all in different forms follow CMII principles however the DYNAMICS in which change is implemented into the product and the management process differ. They all operate the specific objects to record change, and also the ‘back-office’ organizations, such as the Change Control Board and some operate also a dedicated Change Introduction Board.

What do I mean with this ‘dynamics’. The change dynamics is the business rational how change introduction ripples through into the product and specifically aspects surrounding product sustainment i.e. sustainment being the process to maintain a product and secure save operation from an engineering perspective. There is a name for it emerging: Sustainment Lifecycle Management.

Read the rest of this entry »

Advertisements

Many high tech products these days cannot work without software that controls specific (user) functions of the product. Take your car; engine functions that were traditionally mechanically controlled have now been replaced by devices and capabilities that are managed by software. Also when you travel to your vacation destination by air the very plane you are flying in is loaded with software to control for example the avionics or the (glass) cockpit instrument panel. Recently I was asked to consult for a client that had configuration management issues regarding software installed in their product. They had challenges to manage the appropriate version of the software in relation to the hardware configuration and also assuring that certification results were correctly captured. A further challenge was the collaboration with partners that actually does the software development and the maintenance. Our recommendation consisted of the following set of improvement initiatives and functions.

Read the rest of this entry »

In the previous post I talked about Software Configuration Management. This post is about management of software requirements and the link to software configuration management.
Although I did not specifically discuss management of software requirements in the previous post, it is evident that managing the configuration includes the specification sources i.e. the requirements. In the first recommendation of the previous post I touched on the object Work Request and example supporting materials e.g. specifications that may be attached. Ideally requirements are decomposed to individual requirement line items, i.e. similar to a tree. Each such line item would then specify the desired function but also instructions essential to developers but also test scenarios and the required end results that must be met.
In the requirements set you also find the actual failure mode and effect analysis i.e. if this function fails; what would be the effect and what would would need to be implemented that this failure would not occur. Obviously this is not just the software itself but the complete integration with the hardware it may need to control. As pointed out earlier, this level of detail is critical to also manage the prototype test process and also the actual life test i.e. the software as it is installed onto the product. The myriad of interconnections considering this level of detail and also combined with Change management records makes data management a daunting task without the right PLM capabilities.

Read the rest of this entry »