CRITERIA FOR THE SELECTION OF CONFIGURATION ITEMS

1.1.    Background Information

(1)    Configuration Item (CI) selection is probably one of the most significant and lasting decisions made during the entire life cycle of most complex systems. CI selection is a major commitment point in the acquisition process which affects every phase of system development, program management, and integrated logistics support. It is the basis for most acquisition, engineering, and logistics support planning. Since adverse effects of CI selection may not be felt until late in the in-service phase, the CI selection process must anticipate the needs for future procurement, logistics support, and system change. Potential adverse effects can be minimised by considering and applying the information in this Appendix.
(2)    The selection of CIs early in the development process is closely related to system design, in fact, one cannot be separated from the other. Initial selection, which is normally limited to designation of CIs at the major component level of the Work Breakdown Structure (WBS), separates the components of the system into identifiable subsets for the purpose of managing further development. Initial CI selection at this point should reflect an economical management level during early acquisition. As development continues and as system design evolves, complex items are further subdivided into their constituents.
(3)    CI selection should be determined by the Purchaser's need to control configuration. CI selection establishes the Purchaser level of control throughout the system life cycle. CIs must be manageable levels of assembly. The selection of CIs separates the system into individually identified components for the purpose of managing their development and in-service support. Configuration item selection should reflect an optimum level to support Purchaser control during development and in-service support. During development, this is the level at which the Purchaser specifies, contracts for, and accepts individual components of a system. During in-service support, this is the level at which the support activities organise and allocate tasks.
(4)    CI selection has an impact on costs and may have impact on project progress. Such impacts can be minimised by tailoring out certain effects of CI selection that are deemed to be premature or unnecessary for individual CIs. This tailoring can be accomplished in the SOW, the Contract Data Requirements List (CDRL), or some other contractually recognised vehicle. Such tailoring could include complete deletion of the requirement or delay in the documentation/baselining of the CI requirements.
(5)    The following effects normally result specifically because a system element is designated as a CI:
a.    Formal preparation of discrete configuration identification (documentation), most often in the form of a discrete development requirement or requirement specification and a companion product specification.
b.    Purchaser approval of changes over the configuration identification governing the CI.
c.    Separate nameplates and discrete CI identifiers (i.e. CI number and nomenclature).
d.    Individual design review activity during development.
e    Individual qualification testing and reporting.
f.    Individual Functional Configuration Audits (FCAs) and Physical Configuration Audits (PCAs).
g.    Discrete and separate "related" Engineering Change Proposal (ECP) preparation, review, approval and nego-tiation (for changes affecting related CIs).
h.    Continuous accurate recording of the exact configuration status of the CI, including providing operators/maintainers with precise data dealing with impending or completed modification actions.
i.    Preparation of separate operation manuals and maintenance manuals.
j.    Provision of the traceability of detailed design for follow-on activity, including historical data and individual status information for accident investigations, failure analysis, etc.
(6)    The following questions shall be used in selecting CIs tailored to individual project requirements. If most of the questions can be answered no, the item probably should not be a CI. If most of the questions can be answered yes, the item probably should be a CI. The selection of CIs is a management decision based on experience and good judgement. It should be kept in mind that some of the factors such as serialisation and nameplates will be required for certain elements, regardless of whether they are selected as CIs (e. g., part of a higher level assembly):
a.    Is the item a schedule-critical, high risk, high cost and/or a safety related item?
b.    Is the item computer software that satisfies an end use function?
c.    Is the item a computer software sub-program that is designated for use in more than one higher level computer program?
d.    Is the item a firmware item?
e.    Is the item a computer software sub-program or module that will be incorporated into higher level computer software and is being supplied by multiple sources of supply ?
f.    Can the item be readily marked to identify it as a separate, controlled item (size, shape)?
g.    Will system requirements require development of a new design or a significant modification to an existing design?
h.    Does the item incorporate new technologies?
i.    Does the item have an interface with hardware or computer software developed under another contract?
j.    With respect to form, fit or function, does the item interface with other CIs whose configuration is controlled by other entities?
k.    Will it be necessary to have an accurate record of the exact configuration and the status of changes to this item during its life cycle?
l.    Can (or must) the item be independently/ individually tested?
m.    Is the item required for logistics support (e.g. spare parts, Line Replaceable Unit (LRU), repairable item, replaceable item, item subject to a specific maintenance procedure)?
n.    Is the item already in use in other projects (previous or existing) ?
o.    Is the item readily identifiable with respect to size, shape and weight ?
p.    Will there be a need to ensure timely incorporation of modifications into the item ?
q.    Does it require collection of data for field activities to assure installation of compatible items and to take correct maintenance action ?
r.    Are engineering data and/or publications available to define with acceptable tolerance the functional and physical characteristics of the item?
s.    Is there  non-deliverable software that affects the deliverable item?
(7)    Items of the following types should not normally be selected as CIs:
a.    Minor items of support equipment. Minor in this context refers to simple hand tools peculiar to the system as opposed to complex hand tools and fixtures peculiar to the system such as hydraulic torque wrenches, engine build-up tools, etc. There will usually be little or no change activity on these minor items. It will normally be sufficient to specify the general requirements that must be met by these minor support items, as well as to list these items separately.
(8)    There are no rules to dictate the optimum number of CIs for a given system. In general, however, the fewer CIs, the better. Selecting too many CIs increase development and support costs. Each CI, especially Computer Software Configuration Items (CSCIs), comes with an associated set of technical reviews, audits, qualification evaluations, formal unit and integration tests, and documentation requirements. Each of these has an inherent development and maintenance cost. Purchasers should always avoid the temptation to over-design a system. An extravagantly structured and fragmented design, is not necessarily a good design. The consequences of the number of CIs selected are discussed in the following paragraphs.
(9)    The consequences of designating too many CIs include:
a.    Increased administrative burden in preparing, processing, and reporting the status of configuration changes, which are directly related to the number of CIs.
b.    More CIs create more inter-configuration item interfaces, each of which must be rigidly defined and documented. The use of too many CIs can inhibit the contractor's freedom to modify his evolving design as development progresses. Problem solutions can thereby become more difficult and opportunities for advantageous change may be lost. Whenever the ongoing design requires changes to the baseline specifications, the contractual consequences can seriously impact cost and schedule.
c.    Too many CIs can result in their associated functionality being defined at too low a level or including unnecessary design constraints. This, coupled with the increase in the number of interfaces with detailed requirements, may increase the cost and complexity of the formal test program far beyond what is required for the Purchaser to achieve reasonable assurance of system performance.
d.    In addition to formal testing, many of the normal technical reviews are usually tied to individual CIs. This can not only add to schedule and cost, but, if too fragmented, actually decrease government visibility and understanding of the evolving design.
e.    Most documentation is required on a CI basis; more CIs result in more documents. While the technical contents of the documents may not increase proportionately, the total page count grows significantly if only because of the considerable standard requirement for each document. In addition, increased fragmentation in the description of functionality increases the volume and can result in the document being difficult to understand. Also, it increases the efforts associated with the document review, approval, and control process for both the Purchaser and Contractors.
(10)    The consequences of having too few CIs include:
a.    The increased size and complexity of each CI resulting from too few CI designations can decrease management visibility to the development process, and makes it more difficult to manage the configuration of the item as it progresses through the development process. This is particularly true if the lowest level designated CI is a complex item containing both hardware and software components.
b.    When unrelated functions are combined into a single CI, the formal testing of critical capabilities may be delayed or made more difficult.
c.    Large and complex CIs, implementing many (and possibly unrelated) functions, reduces the possibility of reusing the CIs in other systems or being designated for reprocurement.
 1.2.    Additional Considerations
(1)    Additional considerations upon which the CI selection decision shall be based include:
a.    Careful consideration shall be given to modified design items from Purchaser inventory. They are usually CIs already, but they may be candidates for redesignation where more than a modest degree of added complexity or utilisation of new materials, processes or technology is involved. Also, they may be candidates for redesignation if the old and new CIs are not interchangeable in their mission applications, especially when the Purchaser wants separate definition and control over the performance requirements for that design item.
b.    Consideration shall be given to selecting commercially available equipment and/or computer software as CIs where the existing design is modified. Primary factors in making this decision should be the extent of the modification, the criticality of the modified item to the mission of the system and the effect on life cycle cost.
c.    Once development of a system and its CIs is nearly complete, or after operation of the CI has begun, additional sub-elements of the system can be designated as CIs, if appropriate. When different agencies have responsibility for maintaining parts of a top-level HWCI or CSCI, consider breaking the CI into separate CIs for each of the agencies. Eventually, logisticians must deal with LRUs which comprise the principal components of the subsystem. However, designating all LRUs as CIs for development would add significant cost to the development effort. The LRU level is usually too low a level for effective configuration control during development. Even during production and in-service phases, adequate configuration management can be exercised over most LRUs as components of HWCIs. Only certain selected LRUs need be designated and managed as separate CIs.
d.    Major items of support equipment should be designated as separate HWCIs with their own dedicated specification.
e.    If there are different configurations due to different adaptation data for each operating location, the different configurations should be identified by types within a single CI, rather than as separate CIs.
f.    Different system and subsystem elements which are accepted by the Purchaser under separate contract, as contract end-item deliverables, from different suppliers and which are due to be provided as Purchaser Furnished Equipment (PFE) to the Contractor should be designated as separate CIs.
g.    Elements which are general purpose in nature, require the capability to be operationally reprogrammed, or are intended to be reused in another system should be considered as separate CIs.
h.    Elements scheduled for development, testing and delivery at different times should be assigned to separate CIs.
i.    Configuration item selections which cannot be made on the basis of other criteria should be made to keep the system to manageable proportions.

Just reviewing articles on Enterprise CM.

Siloes are for farmers to store grain in.  But we've adapted siloes in our organizations.  Check this workflow (from a medium size UK company) out:

Hurrah! If you follow my community blog (the one you're now looking at) then, assuming you enjoy reading my ramblings, you should immediately switch to following my shiny new featured blog. I will not be maintaining this community blog for much of anything from now on.

Greetings one and all,
Has anyone sucessfully installed the R12 Enterprise workbench?

If you have come here through the 'Featured Blog' link  you may notice that this blog has a legacy of entries taken from my community blog on CMCrossroads. That's because this IS my community blog. It has simply been linked to from the 'Featured Blog' menu, which was a good way to get started but has resulted in a rather bizarre post explaining why I will not be posting to this blog. Obviously this is not correct.

how has the economic downturn impacted you? While salaries were lower, demand for CM experts remained strong throughout the economic downturn. Now that the recovery is underway, qualified CM experts are positioned well to benefit. What do you think??
Write on my wall and tell - oh make sure you friend me as well!

Bob Aiello
Editor in Chief

as with all of you I have only so much time in a day.

Overview

This is a general idea on how to solve the issues by taking complete advantage of all the resources of the whole project and other stakeholders. As project progresses, due to the characteristics of unique, all kinds of issues raised from time to time, such as framework issues, module versions issues, technical issues, business appliance issue, etc. Different resources across different teams might strive to solve the same problem at the same time, maybe not. This is a totally waste of time which should be saved to make the project more effective and efficient.