So it begins with the assignment of a configuration management or change management manager. We will typically, of course, set up a review board, commonly called a CCB, or Change Control Board, and this will be committed to their care. Now, this function, of course, is shared by the CM manager, and this operational element provides the overall control and oversight of this process. And then, it's gonna process in detailed steps the receipt of change requests regardless of source. And through their process they will adjudicate these. They will ensure that various parties receive the changes, that they're able to review them, comment on them, recommend acceptance or rejection, whatever the case might be, but that every step along the way, the change requested is being reviewed by proper subject matter experts.

Once a change has been approved, then it has to go into a separate process, where it is dissected, examined closely, possibly prototyping is done, and then, if it's recommended for implementation, then the documentation has to be prepared, and it has to see it all the way through proper execution, and then verification once it's done. This also has to be committed to the application and the overall system history so that, should it ever come to this, we'll be able to recreate everything and know exactly what we had when whatever blew up, blew up. We have a baseline now. And the baseline has to ingest this particular application, as it does all, so that we have a sense of what is going on and what the elements are, in our baseline, what configuration each element has.

Now, the change assurance process is the part that focuses on and maintains the integrity of all affected elements, and of the overall, by extension, overall system or application. And then, periodically, we have to go through the validation process so that we can capture not just the baseline on paper, so to speak, but we compare that with the true status and configuration of the system or application actually in operation at any point. There has to be complete fidelity and alignment between what we think we have and what we actually have to make sure that this process is, in fact, working and producing the results we need. So the plan itself, serving as the overall guide as to how the change and evolution of this system will proceed, again, to keep it in alignment with the organization's mission that it supports. It's going to process change.

Now, a brief stop here. Change management is a larger macro-level process, you could call it, where we're talking about the introduction of change. As a broad type of concept, change management is more about the evolution of organizational elements and the system in alignment with them, whereas configuration management is more about the tactical-level manipulation of a program or a system to ensure that it operates reliably and in alignment with those things. So you could think that configuration management is more of a micro-process within the macro-process of change management.

So our CM Plan is doing the implementation of the change management process, seeing to it that all the parameters, et cetera, of each program and system element are maintained. We're maintaining the baseline. Every time a change happens, we have to replicate it and ensure that the baseline captures it, and, of course, our verification and validation activities all the way along the line. We have to have the participants and stakeholders directly involved. They need to understand what role they play. Some will be directly on the CCB, having approval authority. Others will be, what you might call, ex officio members with an interest but not necessarily input or approval/disapproval authority. But we need them involved, we need to know what role they bring to it, what information they'll supply to the process, what impact this process will have on them and their organizational elements. Because we need to get feedback from them on the individual activity that is being performed and the process generally to ensure that our process remains very high with its integrity. And there are going to be, invariably, there will be exceptions that have to be dealt with. And like all processes that we have, we're going to have to have process steps and metrics around this process so that we have a way of measuring this as another management activity that we have, and we can tell whether or not it's being effective, being efficient. And then, reporting.

Management will want to know how we're doing. Now, let's break this down a little bit further. Let's talk about this in more detail. The purpose of this is to create and maintain the operational integrity of the system elements at all times by all items that we place under configuration management. Now, that infers, of course, that not all elements that could be will be. Critical elements are other elements. It may be a decision to put them under it, or in the way that they change and evolve, it may be that configuration management is overkill or doesn't bring any value.

So the decision to place an item under configuration management is a very important one. What we have to do here is we have to determine that the program is ultimately ready and available to user populations in a proper state. So we're going look at process implementation. Identify what the configuration elements are that are impacted and what they will do in the way of impacting others. We have to have control processes. Not everything can run in, not everything can be designed, not everything is acceptable or unacceptable.

So configuration control is the process element over which we're making all of these decisions. We'll have to do status accounting. We'll have to evaluate not only the quality of each individual activity but the quality that is produced by the process itself. And then, at the end of it all, we have to have a way of releasing it, basically giving the element the stamp of approval and say, "Yep, everything we meant to do, we did. It turned out the way that we wanted, doing the right things, not doing the wrong things, and it's ready for the users to have." So we implement this process.

Now, reality is, in any mature organization, this CM process is probably well-tried, well-proven, and been in existence for quite some time, but like all processes, it will periodically have to be reviewed to make sure that the process is still delivering the value and the control and visibility that we want. So that's why we're covering it here.

Now, the plan itself describes these specific activities. It's going to, as I've mentioned, outline the parties, what they're supposed to do, and how they're going to interact. And it will go further to describe any delegation of action or authority made by the CCB to the participants themselves, any limitations on this and direction on any related collaboration, basically, who is going to work on a particular item, who they're going to work with, or the fact that they're going to work with some other party, get other input, and then come back to the board with whatever their recommendation or findings might be. The plan itself, of course, is under configuration management since it too is gonna require periodic review.

So the process steps, let's flesh them out a little bit further. This is going to involve the setting up of a configuration controlled item and the scheme for the elements that we're going to place under CM, what they are. And this will involve determining guidance and rationale for what elements are there and how they can be modified. Various objects that we may place under CM can probably be modified in a great many ways, but that doesn't mean that every way that they can be is a way that they should be. So we're going to have to define what that scheme is with those thoughts in mind, this direct items and any artifacts that may be affected by a change in another.

Now, the documentation, as much as that may be an administrative overhead, or an administrative nightmare by the definition of some, that must be taken care of as well because we have to record this and commit it to the history of the application or system. We need that in case we ever have to reconstruct it or to go back and use as reference when we build something new to replace the old.

Now, configuration control typically is the most visible and the commonly regarded step. And this is the administrative process of receiving, evaluating, and then, ultimately, accepting or rejecting any request for change regardless of where they come from. Now, this obviously has to go to a reception point. Then, it has to go to the board. The board has to decide what action they're going to take at the very beginning. We're gonna pursue this. We're not going to pursue this. And then, when the decision is made to proceed, who is going to get this and what they're supposed to do with it.

They will hand this off to the appropriate participant. They will do whatever the step is, review, comment, test, et cetera, prototype. They will evaluate, and this is the crux of this whole thing. They will evaluate what the change is, what it affects, what the potential impacts might be, and what sort of secondary effects it could produce, hopefully to determine that it's operationally necessary, beneficial, and ideally risk-neutral. There may be testing and assessment techniques that will go along with this because this is all leading up to a Go/No-Go decision at the end.

This also is captured so that we have a full audit trail for every change that has been submitted regardless of its final disposition. The status accounting is about the tracking mechanism for the change management process itself, all the different steps, all the different actions taken each one, and then the ultimate disposition of the change proposed. And then, it's just a tracking mechanism as well, changes, queue position, and then, ultimately, leading to the final disposition.

The evaluation itself takes two forms. First, pre-evaluation. Now, this one is done to validate that the change meets all the applicable standards and criteria, and it meets the relevant baseline requirements. Those things, if they're found not to do so, if the change is still wanted, the change then will have to be reverted to its author and changed to meet all of these requirements, then resubmitted. And for those that have gone through, the post-implementation evaluation has to be done to ensure that the change itself went in and functional completeness has been attained, that all the intended results were accomplished, and if they were not as envisioned, they have to be captured as accomplished in the way that they actually were so that, again, the history of this has integrity.

Then, once this is done and confirmed complete, then it's reverted back to the CCB to give it the stamp of approval, so to speak, and approve it for operational release. That leads us to the sub-process for release management. This process is to ensure that all of the clean-up, so to speak, has been taken care of as the item is now released for operational use. We have to ensure that the historical accuracy, the capture of all the process steps, results, et cetera, and the final outcomes have all been captured and integrated to the history and the application or system baselines.

Once we have finalized all of this, the release management activities are going to complete the tie-up of all these different loose ends. We have to make sure the code itself has been captured and prepared for archiving. That's a very necessary step in case we ever have to go back, fix something, rebuild something, replace something, et cetera. We are going to have to have the documentation as well. Now, this means, of course, we have to have a repository built where all of these different modules are going to persist for history.

Some of them are going to be controlled items. These items are, in this context, defined as the library of master images. And that includes documentation as well as code. Some are going to be branded dynamic, which means these are elements that have been brought out of the control, and they're now out as work in progress. Now, that means, of course, there's gonna be a check-in/check-out process and all of that that goes along with it to make sure that, eventually, the work in progress is cleaned up and a new master is put back into the controlled area.

Then, we have the archival. This is where the historical versions that have been retired have now gone, and we archive a version. We roll these things. The most recent retired version goes into the archive, and the production version will eventually make it in there when it is superseded by the next one.