http://www.engineersjournal.ie/2018/06/12/configuration-management-overview/ - I am archiving it in this blog for posterity / to maintain a cache of my work.
Configuration Management overview
 |
| Configuration Management Equilibrium, as envisaged by IAEA |
At it's core, it creates a comparison between Product Requirements, Product Documentation, and End Product. This comparison collectively reflects the Configuration of the product.
The ultimate goal that Configuration Management hopes to achieve is that at any stage in the product's development & operational lifecycle, these three items are in equilibrium with each other (that's 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 it's 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?
Types of projects it can apply to
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 quality - it is possible to have a Configuration Managed project that's low design quality. However, Configuration Management creates a structure to achieve design quality more easily than conventional commercial construction techniques.
Pros and cons of Configuration Management
Interactions with other projects should occur based on frozen Configuration Baselines e.g. if a commercial kitchen is planned for an office development, it's 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 (e.g. the kitchen designer needs natural gas, or the main office project needs to relocate shell & 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 it's parts.
In order to introduce changes to the project, it is important to have pre-defined 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 fulfillment 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 it's requirements or specifications), and risk management need to play a role in a mature change management organisation.
Conclusion & 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, major and small, should be far easier, than 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 (e.g. splitting the product into Configuration Items, integrating it with a Quality Management System, managing & elaborating Requirements, using Configuration Status Accounting Reports to evaluate project progress, Verification & Validation, Configuration Auditing etc.) however for commercial construction projects, I believe if the essence of Configuration Management is applied, positive outcomes can be attained.
For further reading, please refer to ISO-10007, ISO-15288 and SEBOK.
In order to achieve this product equilibrium, three core rules are applied throughout the product lifecycle:
- Ensure that equilibrium between product requirements, documentation & 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
- 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)
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 quality - it is possible to have a Configuration Managed project that's low design quality. However, Configuration Management creates a structure to achieve design quality more easily than conventional commercial 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 it's documentation in very good order. From an owner's perspective, configuration management is extremely advantageous, considering the lifecycle 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 fulfillment 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 & 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 & clear responsibility boundaries should be defined to prevent issues
- Can take a long time, particularly in earlier stages (e.g. requirements gathering and design) due to stakeholder approvals. This is frustrating, but helps prevent schedule slip later in the project
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 (e.g. If I have a design, it must be fixed before future development can occur upon it, or construction can commence).
In order to develop the product in a structured manner, and later have something to change, you must fix it in the first place (e.g. 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
The 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 lifecycle. For that reason, it's important that each Configuration Baseline represents an end-state, rather than a process along the way (that's 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 requirement 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. 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 everyones guiding principle.
Freezing each Configuration Baseline is a significant step, which involves checking that all of the stakeholders are satisfied that their requirement 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. 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 everyones guiding principle.
In order to introduce changes to the project, it is important to have pre-defined 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 fulfillment 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 it's requirements or specifications), and risk management need to play a role in a mature change management organisation.
Conclusion & 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, major and small, should be far easier, than 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 (e.g. splitting the product into Configuration Items, integrating it with a Quality Management System, managing & elaborating Requirements, using Configuration Status Accounting Reports to evaluate project progress, Verification & Validation, Configuration Auditing etc.) however for commercial construction projects, I believe if the essence of Configuration Management is applied, positive outcomes can be attained.
For further reading, please refer to ISO-10007, ISO-15288 and SEBOK.