Configuration management is a systems engineering technique first developed in the Cold War, to control US military projects. It was conceived to prevent common project afflictions of scope creep, poor documentation, and undisciplined change to a product (the output of a project) throughout its lifecycle.
At its core, it creates a comparison between product requirements, product documentation, and end product. This comparison collectively reflects the configuration of the product.
[caption id="attachment_43449" align="alignright" width="300"]
Configuration Management Equilibrium, as envisaged by IAEA[/caption]
The ultimate goal that configuration management hopes to achieve is that at any stage in the product's development and operational life cycle, these three items are in equilibrium with each other (that is to say, that the requirements have been achieved in the end product, and the documentation is completely faithful to the end product) - you therefore then have a fully configured product.
This insistence upon only considering a product complete if its documentation and requirements are in good order as well as the physical realisation can be quite frustrating; however, it is nothing new to most people looking back on their mathematics classes in school - any schoolchild is well aware of the frustration at only being awarded half marks in a mathematics test - if you can't show your work leading to the answer, can you trust that the answer wasn't a fluke?
In order to achieve this product equilibrium, three core rules are applied throughout the product lifecycle:
● Ensure that equilibrium between product requirements, documentation and physical realisation is strictly maintained;
● Ensure that the configuration of the product develops in a structured manner during the design & build phases of the project (and this can be confirmed at any time);
● Ensure that any changes to the product configuration are planned and implemented in a proper manner.
Types of projects it can apply to:
● Waterfall developed projects (where one stage follows the previous, and builds upon it);
● Industrial construction projects;
● Software development projects;
● Commercial construction projects (and it is this opportunity which I describe in this article).
Compatibility with conventional project and design management techniques
Configuration management is entirely compatible with typical project management techniques; however, it shouldn't be directly compared to them - configuration management alone does not provide a model for managing a project.
Instead, it can be considered as a way of containing a project within an organisation, aligned with the input from a project sponsor. A project sponsor and interested stakeholders would use elements of configuration management to evaluate the product realisation throughout a project.
Configuration management is also quite different to project management, in the sense that project management is concerned with movement/action, whereas configuration management is concerned with knowing where you are.
Configuration management also doesn't directly address design or build quality - it is possible to have a configuration managed project that's low design or build quality. However, configuration management creates a structure to achieve quality more easily than conventional commercial design and construction techniques.
Pros and cons of configuration management
● Without a doubt, the biggest pro in favour of configuration management is that the delivered end product has all of its documentation in very good order. From an owner's perspective, configuration management is extremely advantageous, considering the life cycle of whatever that product is (and the ease with which future modifications can be made starting from good as-built design documentation);
● By consistently checking back on fulfilment against the original user requirements, a good degree of cost control can be attained (that is, scope creep is prevented, and any changes to requirements are introduced properly before implementation);
● You get exactly what your staff wanted in the user requirements. No more and no less. They have to check same, and discipline themselves against pushing for more during design and construction without proper change management;
● It is end product rather than project orientated, which can diminish the sense of freedom good project managers attain during a well-managed project, and also their feeling of empowerment. If not properly managed in an emotionally intelligent manner, this can lead to a difficult project - mature communication and clear responsibility boundaries should be defined to prevent issues;
● Can take a long time, particularly in earlier stages (for example, requirements gathering and design) due to stakeholder approvals. This is frustrating, but helps prevent schedule slip later in the project.
Putting configuration management into practice
One of the rules of configuration management as described above is that the product develops in a structured manner, and the other important rule is that changes are properly introduced to the product.
In order to develop the product in a structured manner, and later have something to change, you must fix it in the first place (for example, if I have a design, it must be fixed before future development can occur upon it, or construction can commence).
This structured development is recognised as splitting the project into configuration baselines, whereby the product configuration is developed to an increasingly mature level at each configuration baseline.
A minimal number of configuration baselines is considered best for any project, as the bureaucracy burden of 'freezing' a configuration baseline (described below) can be significant. From putting configuration management into practice on a number of commercial projects, the author’s team settled on having three baselines in a project as being optimal:
● Requirements defined baseline;
● As designed/contracted baseline;
● As built/handed over baseline.
These configuration baselines give the project a basis from which future development can occur (e.g. next phase, and scope co-ordination), and represent a solid step in the product's life cycle. For that reason, it is important that each configuration baseline represents an end state, rather than a process along the way (that is why the as designed/contracted baseline isn't called the design baseline). And if a given baseline needs to be abandoned (a bad situation), at least the preceding baselines are still valid from which to plan future works.
Freezing each configuration baseline is a significant step, which involves checking that all of the stakeholders are satisfied that their requirements are partially or fully fulfilled, and for the project manager to decide if the content of the baseline works together as a co-ordinated whole.
Motto of 'trust is great, proof is better' should be everyone’s guiding principle
The time taken for this step should be adequate to allow full diligence be performed, and the motto of 'trust is great, proof is better' should be everyone’s guiding principle.
Interactions with other projects should occur based on frozen configuration baselines; for example, if a commercial kitchen is planned for an office development, its fit-out design should be based upon the space and building services allocation from a frozen main project design configuration baseline.
This way, should there be a change in either project (for example, if the kitchen designer needs natural gas, or the main office project needs to relocate shell and core door positions in the kitchen), the change can be evaluated and introduced against a fixed starting point.
Sensible coupling and decoupling in designs and processes, while seemingly more bureaucratic, can also allow end results greater than the sum of its parts. See figure below showing how an overall programme to achieve an end product can be broken down to sub-projects (with configuration baselines), with interfaces managed between each sub-project.
Have predefined rules for how to handle changes
In order to introduce changes to the project, it is important to have predefined rules for how to handle changes. As noted, the advantage of configuration management is that you have a solid basis from which change can be evaluated, against the previously frozen content.
From this basis, you can consider the impact of any change in terms of configuration (impact to requirements, design or physical) and also the normal project management parameters (impact to scope, cost or schedule).
This way, both the short-term impacts to the project, and long term to the end product, can be evaluated in a balanced manner, combatting situations where operational interest is overridden by project interests/incentives, and vice versa.
Equally, considering both changes, and fulfilment of original requirements, it is important to know when to relax the discipline of configuration management.
Too much uncompromising adherence to a change procedure or refusing to freeze a baseline due to requirement non-fulfilment can cause avoidance behaviour by project staff, so appropriate rules governing non-controlled field changes, concessions (permission to release a product not conforming to its requirements or specifications), and risk management need to play a role in a mature configuration management aware organisation.
Conclusion and further reading
All of the above discipline should result in a smooth handover of the end product to operations, with a comprehensive (and true) set of as-built documentation. And if this documentation is properly stored and kept up to date, future modifications, significant and small, should be far easier, compared with the conventional practice by consulting engineers of walking down a building, hunting for printed as-builts in equipment panels, and trying to relate them to what is actually built.
There is far more to configuration management than what is outlined above (for example, splitting the product into configuration items, integrating it with a quality management system, defining, managing and elaborating requirements, using configuration status accounting reports to evaluate project progress, verification and validation, configuration auditing and so on); however, for commercial construction projects, I believe if the essence of configuration management is applied, positive outcomes can be attained.
[caption id="attachment_43451" align="alignright" width="300"]
Darragh Rogan[/caption]
For further reading, please refer to ISO-10007, ISO-15288 and
SEBOK.
Author: Darragh Rogan is configuration management consultant for M+W Group, supporting energy clients in Europe. He holds a bachelor’s degree in electrical and electronic engineering, and is a chartered engineer