Managing Change Using Advanced Baselining Concepts

July 15, 2009

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.

Not only is there sustainment to products already in the field, also with new product development (NPD) there is a form of ‘sustainment’ on a micro level. When you read my post on Digital Mockup and the WIP, I stated that the DMU cannot be dynamically changed without impacting configuration management principles. In this post I discuss that there is also a ‘delay’ to decide which modifications are incorporated when. This is a formal process, you can consider this a form of sustainment during product development.

When you consider the development of a vehicle body and all of the cross functional team that are involved and the synchronization complexities, you then must coordinate the change moment with all partners. Also you need to consider that the car body development has the biggest program influence on time, cost and impact (consumer acceptance) to the market. Consider also the current difficulties with the Boeing 787 wing to fuselage connection design and the same applies to aircraft air frames.

Working with a developer/producer of military aircraft we discussed principles of change dynamics and to be frank, I have seen the same principles also in other industries. What I found; there are three approaches to change introduction, change driven by:

  1. Improvements during development at IPT level (also cross functional teams, see also post on IPT in Collaboration)

  2. Modifications after certain Design Reviews (gates) have taken place i.e. when substantial resources are needed and consumed to make corrections/improvements.

  3. Improvements that will be introduced in newer versions/models of the product.

In scenario 1, changes are processed and incorporated by specialists. For the ‘record’ the ‘background’ to the change is recorded. As a generalization this is the ‘fast track’ principle of CMII.

In scenario 2, changes are processed and incorporated again by specialists, but the change introduction board decides when this takes place as (external) resources need to be planned and accounted for. For purposes of efficiency changes are collected and are ‘put on hold’, i.e. they will be batch processed according to e.g. priority and product zones. Subject to criticality changes may also be retrofitted to products in production. There can be conditions that these ‘mods’ need to be fitted to relevant products in the field, either mandatory or at owner choice.

In scenario 3, and last scenario; all mandatory changes and product improvements are ‘collected’ and retrofitted back into the original baseline and this now creates the baseline for a new ‘Mark #’ product, or the technical lessons learnt as a base for the next model upgrade. To manage change effective you need some additional capabilities.

Managing change Dynamics and the process behind this as I touched on in my intro, you appreciate that it is critical that Change Request and Notices are ‘collected’ i.e. a ‘record’ that a group or series of changes have been incorporated. In an object oriented engineering collaboration solution, Change objects have relations to the affected and resulting items. Change objects can be collected in a container object; ‘baseline’. The baseline will describe the purpose, for example the Platform/Model and the Review Gate (+iteration number). In an automotive context you would have complete overview of what changes were incorporated at any point in time and you could also compare one baseline with another. If costs would be collected against the Change object (for example the authorizing task as discussed in one of my post on Business Activity Management) a program manager would have complete overview and could easily report on costs and the increases caused addressing what technical issues.

The baseline further provides a different ‘view’ compared with classic unit effectivity; a key configuration management concept. To understand the extent of changes introduced; a great report would be what group of changes resulted in what new product state. Such report provides a ‘time’ based view regarding a product. It would also provide a concise view what engineering effort would be needed to ‘port’ improvements back into the new product base e.g. to creating the new Mark II or your new 2010 model. Further great insights would be gained from a comparison between a specific unit effectivity with the new Mark II baseline. This kind of comparison allows an OEM to plan specific field upgrade packages and would provide the ultimate lean Sustainment Lifecycle Management support.

Can you imagine the tremendous effect such reports would have on productivity gain and the risk you could reduce in case of service level agreements ‘selling’ your product based on usage-by-the-hour.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: