Managing the Configuration

This is the foundation page for the topic of Configuration Management

Configuration Management (CM) establishes and maintains control over a project’s configuration.  This site does not attempt to describe all of CM’s practices and objectives.  The CM practices of interest here can be abstracted as a matter of knowing what Engineering said should be true, knowing what is true, and objectively reporting the difference between the two.

CM’s control over the configuration isn’t very concerned with whether or not the technical requirements were met.  It is almost entirely focused on archival integrity: what the data are, not what they mean.  The scope of this concept is broader than that of standard SE Verification practices, but does not overlap with them1.

In many organizations, CM has a high degree of Administrative Independence from System Engineering (SE), and this site treats it that way: as providing certain disinterested services to SE in support of its usual objectives.   These services, which sometimes appear to be mechanically pro-forma, exist to ensure that the resulting work products are auditable.

Because of CM’s direct access to released material and institutionally unbiased position in the organization, it often organizes, moderates and chairs technical reviews and audits.  In most cases, CM also provides consultative assistance on project planning in order to support the eventual satisfaction of the basic objectives described above.

CM topics of interest to SE include:

– Product structure, which is the hierarchical relationship between the things we sell (End Items) and their parts, usually established by the way of Parts Lists calling their constituent items.  SE is interested in this general subject area because the Product Structure is not always identical to the hierarchy of allocated requirements.  Consequently, we often have to create a map between the two structures in order to close out Development.

– Drawing Types and Applications, which are of interest to SE for two reasons:

– Each drawing type, often as defined in ASME Y14.24, has it’s own “use case”.  The type of drawing selected for any given situation contains information that’s significant to how it contributes to the close-out process.

– Analysis of the drawing “use cases” shows that each one represents a narrowly-defined special case of SE practice.  Their study clearly shows how the basic concepts of System Engineering pervade associated design practices, even though many Designers don’t realize it2.  This notion is the basis for the CI Development Cycle exegeses.  Exposure to these mini-use-cases is one of the ways we can turn good designers into good System Engineers.

– Engineering Release, whether implemented by a designated Engineering Release Unit or within the originating group, is of interest because it is the point of control for project documentation.  SE looks to these practices in order to understand what information is the developer’s official position3 on all technical topics at all times.

– Both types of Identification, which are of concern to System Engineering for different reasons:

– Configuration Items (CI) are first identified in order to create sets of requirements that are expected to be solved by a single thing.  As alluded to in the Product Structure paragraph above, the “thing” (a CI) is not always in 1:1 alignment with the Product Structure: we can create CI’s that never exist as stand-alone Parts (e.g., items that are Make-on-Assembly).  SE is a primary participant in this activity.

– Stockable parts4, typically identified by Part Numbers (P/N), are of interest because they’re used in the Parts Lists of Assembly Drawings to implement the Product Structure5, and are the means of designating interchangeability between different Serial Numbers of a single P/N.  Interchangeability is a primary element in the rationale by which Qualification results apply to all Serial Numbers of a design.  They are also the most direct means of correlating verification data to the specific things for which (and from which) they were gathered.  Changing Part Numbers will typically suggest close review by SE in order to establish the applicability of data; so too will decisions to not change the Part Numbers.

– Requirements Management, which is a specialty skill within CM, is where the generation of content for technical requirements6 intersects with the accounting processes that record and maintain their allocation to CI’s.  In some organizational strategies, this process includes the bookkeeping aspects of traceability.

– Change Control, the bureaucratic process of creating and revising baselines, is of critical interest to System Engineers because it is the mechanism by which we formally allocate and modify requirements and their allocations.  Failure to understand these practices render us unable to impact anything at all.

– Reconciliation, upon which System Engineering often waits with bated breath, is where SE finds out7 if we were working on what we thought we were working on.  When that doesn’t happen, SE often has to scramble in order to re-stitch the closeout paper trail.

 

Footnotes
  1.   That is, the two scopes are disjoint.[↩]
  2.   And, by the way, neither do most of the System Engineers![↩]
  3.   That is, “a baseline“[↩]
  4.   That can be built and stocked in speculation of later sales[↩]
  5.   An argument could be made that they actually establish the Product Structure.[↩]
  6.   Which is a core SE skill[↩]
  7.   Along with everybody elses.[↩]