I received the email below shortly after an ITMPI Webinar I delivered earlier this month on the role of Configuration Management in Successful Product Critique that he attended. Mr. Aliev has graciously allowed us to publicly display his questions and our response. Thank you very much Mr. Aliev.

Hello Jon,

Thank you for presenting today on the webinar: “Configuration Management and Successful Product Critique”.

As per ITIL definition, “Configuration Management is the Process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships. This information is managed throughout the life cycle of the configuration items. Configuration Management is part of an overall Service Asset and Configuration Management Process.”

During your presentation you didn’t mention or I missed something related to this definition or a role of Configuration Management in the service transition. Similarly, in project management the Configuration Management is mostly responsible for version control of such project items as documents, computing code, data, parts, etc.

I also didn’t get the idea about “Successful Product Critique” – what do you mean by that?

Could you please correct me if I am wrong. You mentioned about some useful templates on your website – could you please send me a link.

Thank you for your time!

Best regards,
Ramiz Aliev, PMP

Historical Background

You are correct; I did not use those explicit words. The ITIL definition needs to be understood in context. Until 1980 the fields of IT management and SW CM and Knowledge management did not exist. The largest split took place in 1991 when the term Knowledge Management was coined.

Below is a summary of the CM landscape at that time

This resulted in the following areas of responsibilities for all CM and can for our purposes be considered the CM fundamentals.

While the above may be somewhat hardware centric, items like the indentured parts list are directly translatable as an indentured CSCI list. Instead of assemblies, subassemblies and detail parts you have SW branching and twigs.

Present Application

The current guidance document applicable to IT, KM and SW Cm and CM in general generally list 5 distinct aspects of CM.

• Planning and Management
• Configuration Identification
• Configuration Change Management
• Configuration Status Accounting
• Configuration Verification and Audit

For your purposes these can be expanded to:

• Configuration identification
• Baseline management
• Change control
• Library control
• Status accounting
• Reviews
• Audits
• Release processing

If you read and synthesize all of the prevailing guidance and add them to the ITIL definition you get a larger view of what CM really is:

• ANSI-EIA 649-B-2011, CM Standard
• ANSI-EIA 836-B-2010, CM Data Exchange and Interoperability
• ANSI-IEEE 1042_1987, SW CM
• GEIA-859, Data Management
• GEIA-HB-649, Implementation Guide for CM
• IEEE Standard 828-2012, Configuration Management in Systems and Software
• IEEE Standard 12207-2008, Systems and SW Engineering – SW Life Cycle Processes
• ISO 10007-2003, Guidelines for CM
• ISO 15289-2011, Systems and Software Engineering
• ISO-IEC TR 15846-1998, SW Lifecycle Processes CM
• Mil_STANDARD-31000A, Technical Data Packages

You will find that it has not really changed much except for the acronyms used from the previous image of CM fundamentals. The tools may have changed but the principles have not.

Further Extension of Configuration Management

Your statement, “…in project management the Configuration Management is mostly responsible for version control of such project items as documents, computing code, data, parts, etc.” is correct. That is the change management part of CM. But CM also involves the management of the development environment, simulations, software licenses and versions as well as any table loads used to configure the test environment and the development environment tool configured settings.

Looking at CM from just the perspective of ANSI-IEEE 1042, SW CM two major aspects stand out

• Planning
• Implementation

Configuration Management and Specification Development

Specification development and iterative testing regardless of its environment are centric to the discussion you attended. They can be viewed as a combination of planning and implementation and form what is known as the establishment of the Functional Baseline with required functionality being allocated downward to various elements of the implementation (Allocated Baseline).

Configuration Management and Reviews

In the case of our specifications, inspections or reviews prior to releasing to configuration management can help ferret out the problems at the specification level before we start physically experimenting with the possibilities and making the product.  These specifications are developed using an iterative approach, meaning we only put into the specification what we are immediately attempting to learn and put that under configuration control. Recall I mentioned a Harvard Business Review on the Six Myths of Product Development.  We are specifically working with item six on that list.   We will periodically produce development baseline(s) depending upon the concepts we are exploring. This baseline may be a tangible incarnation of the product or via models and simulation (also falling under configuration management controls).  When we learn from that baseline, we will once again open the specifications up, add or alter content for the next iteration, review and then put this into our configuration management system. This is now fodder for our next iteration of the baseline to build and critique.

The specifications under CM are reviewed prior to locking them down with a release into the CM system. We plan our testing and evaluations on each of these packages as defined in our CM work.  All along this iterative growing baseline development we use CM to control the iterations and map the iterations to things like reviews, testing, inspections and evaluations, and adapt the next iteration from the learning of the prior.

The project organization should use the Configuration Management process to script the project and product growth – instead of just the version control.  In this way the product content is adjusted formally from the learning that should have happened in the prior work.  I would agree that project management shows more interest in the change management (if we are lucky) aspects of configuration management. However, the real power from CM is in the orchestration, coordination or facilitation of learning about the product.  Configuration Management can help us focus on the important aspects of the development work.

Configuration Management Summary

I chose the title carefully. A successful product critique does not happen as some may suggest via testing, neither is it at the end of the product development lifecycle. The product critique is more than the quality of the product to specifications (often associated with specifications), but the ability of the product to meet the customer needs (validation and evaluation methods) as well as reliability (quality of the product over time).  To perform this critique requires approaches similar to the top level identified in TIEMPO (Testing, Inspections, and Evaluations) all through the development process.  Critique in this context is appraisal – and what we want to know….. is the product what we need it to be for our customers and our company.

The first 30 seconds of this YouTube video may give additional insight:

https://www.youtube.com/watch?v=vBguassbAzo

I hope this helps,

Jon M Quigley and Kim Robertson