|
Feb 15
2010
|
CM Procedures VS. Functional Department ProceduresPosted by: Shari Councell in MyBlog Tagged in: Untagged
  |
 |
Here’s the issue: The CM Plan tells an organization what it is we are going to do, such as…establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.
The CM Process, usually included within the CM Plan, tells an organization how we are going to accomplish the CM Plan by identifying each CI, implementing change management, maintaining CSA, and conducting audits.
So, that leaves procedures to specify who is going to be accomplishing the process, and when is it going to happen. Using a part change being made to a critical system, as an example, involves an engineer receiving a requirement to make a change. He/She initiates a Change Request (CR), and then goes through the whole change management process until the part is changed and the baseline is updated.
To change this part, does the engineer refer to an Engineering Procedure that is written and maintained by the Engineering Dept. which incorporates directions for submitting CR’s to CM, or do they refer to a CM Procedure that is written and maintained by CM for HWCI changes?
The same question then applies to HWCI identification, CSA, and audits. In other words, if there are “CM Procedures”, is there a minimum core set that should be written for implementing CM within an organization?
TrackBack URI for this entry
Subscribe to this comment's feed
Bob Aiello
said:
 |
... seems like CM folks always have wolves, tigers & other wild animals at the door. Kinda goes with the turf. I was just writing about CM and personality the other day and I noted that the personality of a Police Officer is considered by personnel psychologists to often be in high in a trait called conscientiousness - hmmm similar to a CM/QA person in my opinion. (I will explain this more clearly in future articles but CM does involve an "enforcement"-like role. BTW - I have been an Auxiliary Cop/EMT for over 15 years - but I digress... How do you plan on handling the intersection of hardware and software? Specifically, firmware loaded onto a chip. I actually think that the procedures have a LOT more in common than we often consider. Basically, identifying a configuration item that is a circuit chip or an OS patch or a new release of a binary or the firmware of a circuit board is fundamentally the same. Hardware needs version IDs just like software or you cannot do a configuration audit. Remember that there is actually a fine line between what is in hardware and what is in software. Years ago much more of the logic was in hardware. Computers have evolved and now we put much more in software, but a CI by any other name.... What say you? |
Shari Councell
said:
|
... Ok, please allow me to provide feedback to make sure I understand what you're saying correctly...I will create one procedure for CM Identification that describes how the CSCIs, HWCIs, and technical technical documentation are identified. Then, I will create another procedure called CM Change Control that describes how change control is implemented for CSCIs, HWCIs, and technical documentation, and two others for Status Accounting, and Audits which also describe how they're carried out for CSCIs, HWCIs, and technical documentation. Now, I see this being accomplished another way and here's why. For example, the folks that are working the Software CM will have a procedure called "Software CM" and in it will include how their software is identified, changed, accounted for and verified. ~And the folks in charge of maintaining critical and non-critical hardware systems will have a procedure called "Hardware CM", which includes instruction for obtaining the appropriate identification, how changes are made, etc. Then, another for technical documentation that works for both development and operational phases which includes the CM elements of ID, change, accounting and verification. Here's the rational...a person that is working the Software CM is going to look for a software procedure when they are looking for direction on completing their job task. I don't foresee a "Software" person, or an "Engineer person" out in the field changing parts, is going to look for a CM procedure, but rather a procedure that is written for their group. I see it as CM's role to audit their procedures to ensure they include the CM elements and the results are producing the correct outputs (i.e. a properly configured system). The other reason I see this being accomplished this way is in regards to revising procedures. For example, a change has been made regarding the way the "Drawing folks" obtain their identification. Maybe a new database has been introduced, or the approval steps has changed a little bit. When this happens, if I am understanding what you have typed, the entire procedure for CM Identification would change, thus effecting the people working the software and technical documentation too, when in fact nothing regarding them has changed, only the "Drawing" piece. Thanks for the good dialogue on this, as I have a wolf on my door and looking to get this matter resolved quickly. |
Bob Aiello
said:
|
... absolutely! There are a minimum set of core procedures and most standards and frameworks list them as Configuration Identification, Change Control, Status Accounting and Configuration Audits. But the truth is that you need to take a Risk based approach and understand what YOUR organization requires. Remember that CM Planning for a life support (or missile) system is different than CM Planning for a cool video game. You need to consider your risks and adjust your planning accordingly. BTW - the same issue exists with regards to QA & Testing - right? Bob Aiello Editor in Chief |
