1) SCM Configuration Management (CM) Program Requirements Management:

A sound CM program will assure compliance to your contractual requirements. As we shall see, the process of tailoring your CM program to a specific program's needs and your own ‘best CM practices', then negotiating this tailored CM program with your customer will get both your business and your customer off to a good start. You will both be ‘singing from the same sheet', and there will be no surprises as your program evolves. Your CM audit process will assure compliance to your negotiated requirements.

The first step in establishing the groundwork for a successful CM program is the planning activity. I am including ‘planning' in the same paragraph as ‘tailoring' because they are so closely linked. They are built on the same foundation, in much the same manner as the way in which the living room and kitchen are built on the cellar of the same house.

If we think of the living room as the location where we invite the customer in to chat about how we are going apply CM disciplines and processes to meet his requirements, then the kitchen is the place where we cook the stew, i.e., put those processes to work after we assemble our team of cooks.

As in the case of a great meal, the courses require "tasting" along the way to assure that we haven't strayed from our desired goal. We call these "tastings" Design Reviews. At each Design Review, we expect a certain amount of  "goodness" in the design. These events are also a good place to correct anything "bad" that has found its way into our meal.

At this point in the planning process, the primary task for CM personnel is to identify and understand the customer's requirements. In the past, proposals were often trimmed of CM-related quotes and activities even before the program or project began in a misguided attempt to save money. This practice is unacceptable in today's business environment. CM has at least as major a role to play in the planning for and execution of a contract as any other organizational function. The early identification of the customer's ‘wishes' as expressed by his Request For Proposal (RFP) requirements, or market surveys or other forms of communication is a ‘must'.

Once the customer's CM related requirements are identified and understood, the next step is to plan and articulate what your CM organization sees as the most effective ‘best CM practices' to apply to this particular program. In would be quite a coincidence if the results of this activity matched exactly the requirements articulated by your prospective customer, so you must tailor your CM practices as appropriate to meet both the customer's real needs and your business' requirements for program control and visibility.

You must then negotiate your tailored ‘best CM practices' with your customer in order to achieve a resolution on the issue and to finalize the definition of your CM Program Requirements. It is absolutely mandatory that your internal functional organizations agree to and support the results of your negotiations. Make sure that they are participants during the negotiation process. When you and your customer finally agree, document the results of your negotiations in your CM plan and spread the word to your internal organization.

Figure 1, Four State Level of Control System Model, presents a methodology for the establishment of ‘best CM practices' for the entire life cycle of any product, including the capture and control of your SCM product requirements. This methodology is adaptable to any program or product, regardless of the size of your enterprise, provided that you have an engineering organization to start with. If you don't, then use the ideas behind this scenario, anyway. It can't hurt, and you will most likely find that you are headed in the right direction to create order out of chaos. This methodology is based upon a division of the product life cycle into four states.

1. In the first state, "Designer Control", the design is initiated and controlled by the designer. Control of the design data is in the hands of the designer. He or she can use any means at their disposal or within their range of preferences to manage these design data. Your designers' only constraints are those imposed upon them by the system level specification which documents the product requirements. This specification is the output of Design Review #1. Your Functional Baseline (system level) and Allocated Baselines (subsystem level) are established at this point.

2. In the second state, "Design Internal", the level of control (still informal) is increased because at that point, an event has occurred which establishes the expectation of a certain amount of "goodness" in the design, and the design efforts of other people may be impacted by changes to your design as you move into your prototype build phase. In the example presented herein, that event is Design Review #2. The designer has enough confidence in his design to submit his code for build or , in the case of hardware development, to sign the drawing (or approve his digital design files) and turn them over to your engineering development laboratory to start construction of your prototype hardware.

Proposed changes to the design must be approved by the design lead. It is your lead design engineer's responsibility to communicate with other functional areas and personnel proposed changes which may impact their design activities.

As the  software code or hardware prototype evolves and design problems and improvements are identified, the initial software code library or drawing/design tool database is updated, i.e., red-lined drawings and new design files or model versions are created. This iterative process continues until Design Review #3 is held and all identified problems are resolved. Your Development Baseline is established at this point, and your requirements specifications are updated under CCB control to document this state of your product design.

These two states are generally referred to as "Work-In-Progress" (WIP).

3. At the conclusion of Design Review #3, there is sufficient confidence in the design to justify the procurement of  production hardware. This event triggers the transition to the "Formal Internal" state.

At this point, the design database is updated (software or hardware), the hardware design data are fed into your business's manufacturing inventory and ordering system, and initial (or all) orders are placed for production hardware.

Future proposed changes to the design (including changes to the system level specifications - your product requirements documentation) are documented on your internal "change notices" and are approved or disapproved by  your internal Configuration Control Board (CCB). Unless otherwise negotiated,  your customer should not participate in the change approval process until the Product Baseline has been established, as defined below.

Your Functional Configuration Audit (FCA) is conducted on the engineering prototype during the "Formal Internal" state. The purpose of the FCA is to assure that tests have been conducted to verify that each hardware and/or software requirement specified in your system level specifications has been met by the design. If tests cannot be performed to verify a particular requirement, then a ‘theoretical error analysis" must be performed to verify satisfactory compliance to the requirement. These tests are generally referred to as Design Evaluation and Qualification tests. They are used primarily on military product programs. The purpose of these activities is universal, though and should be an integral part of every development program.

4. The transition to the "External" state occurs at the successful completion of the FCA. This event initiates the conduct of the Physical Configuration Audit (PCA). During the PCA, the engineering drawings are proofed by comparison to the first production unit. This unit should be built to manufacturing planning that was created from the engineering drawing package. Measurements are verified and all instructions, processes and technical data specified on the engineering drawings are verified against the hardware. Historically, many businesses referred to this activity as the "First Article Inspection (FAI)".

The second major activity of the PCA is the capture of drawing revision and serial number data and comparison to "as-defined" revision levels plus a verification that serial numbers have not been previously used.

The final activity of the PCA is the performance of an Acceptance Test (AT) to assure that the unit examined is physically and functionally the same as the unit that passed the FCA. Your Product Baseline is established at this point.

NOTE: Design Reviews also present an opportunity for CM personnel to present checklists to identify required inputs to and outputs from your CM system and to re-enforce the agreements made prior to contract award and during your program planning phase. They present an excellent opportunity to remind folks of their agreements with the CM organization as documented in your CM Plan (just in case someone forgets).

Remember that ‘best CM practices' are those disciplines, processes, procedures, and mindsets which ‘get the CM job done' with the greatest degree of control and efficiency, minimal risk, and the least intrusion on other program activities and operations. The last thing we want to do is to slow down any program activity. Instead, we want the highest level of success for the program. This means that we have to capture and control baselines (including requirements documents), allow designer and draftsperson access to engineering designs for updates and modifications, review and dispose of problems as they are identified, conduct audits without disruption to program operations, and provide visibility and access to program data to those who need it to do their jobs. By adhering to the methodology of the four state level of control system model, you will be able to establish, fine tune and document ‘best CM practices' for your business and to properly manage your product requirements.  

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment