5 FAH-5 H-500
CONFIGURATION MANAGEMENT
5 FAH-5 H-510
PROJECT DEVELOPMENT AND CHANGE CONTROL
(CT:ITS-12; 06-05-2024)
(Office of Origin: DT/BMP/SPB)
5 FAH-5 H-511 PURPOSE OF CONFIGURATION MANAGEMENT
(TL:ITS-1; 02-13-2002)
a. Configuration management (CM) is both a management discipline and a process. CM is a communicator; it establishes relationships with all the project activities. CM communicates by providing technical information about each specification, document, manual, code, and so forth, provided to the project team. Knowing the state of the product that a project is developing and knowing that it satisfies the customer’s requirements are of utmost importance for any project manager. CM can also be viewed as a support function that helps a project manager better manage and control the project. CM provides services to several activities and it has working relationships with some of those. One activity CM has a very close relationship to is quality assurance, which plays a major role as an independent body dedicated to ensuring the integrity of the product from beginning to end. Quality assurance also monitors the performance of other activities, including CM. CM, in turn, provides status accounting to quality assurance and relies on that activity to review changes to ensure product integrity. CM is also intertwined with an activity that prepares and manages documents containing the requirements and design criteria as well as the testing requirements of the system and/or product and documents such as the user manual to be delivered with the system and/or product. This activity is known as data management. It is related to CM in terms of the specifications and documents that CM ensures are correctly identified, have a recorded history of changes when released or delivered to a customer. Data management also checks the status of documents when they are changed or released.
b. This chapter presents configuration management, its purpose, and relevance to IT developmental projects. CM establishes a disciplined structure, such that purchased, developed, or integrated configuration items (CIs) are identified, controlled, tracked, and managed according to CM and organization standards and procedures. Effectively implemented, CM is integral to all phases of a project or system life cycle. CM is unique in its focus on controlling outcomes. It makes sure these engines of efficiency are marshaled together to produce the right product. It also controls change, making sure that its impact is assessed and that every effort is made to prevent erosion of product functionality or safety.
c. The Information Technology Change Control Board (IT CCB) function is vital to the success of the CM process for projects that will utilize the Department’s networks and is the central point for change once all the mechanisms are in place for identification, tracking, and monitoring progress (see 5 FAH-5 H-512).
d. The primary activities of configuration management are identification, change control, status accounting, and configuration audit. Also added is interface control and subcontractor CM control. In detail, the six activities identified here are defined as follows in 5 FAH-5 H-530.
5 FAH-5 H-512 THE INFORMATION TECHNOLOGY CHANGE CONTROL BOARD (IT CCB)
(TL:ITS-1; 02-13-2002)
a. The IT Change Control Board led by the Enterprise Network Management (ENM) Office in IRM, manages changes to the Department of State’s information technology (IT) infrastructure. The IT CCB is concerned with the availability, reliability, integrity, security, interoperability, and performance of the Department of State enterprise infrastructure, and ensuring that it does not degrade any Department of State infrastructure performance. It makes sure all changes are seamless. Because so much depends on the continuation of services of the Department of State IT infrastructure, change evaluation to it must be made with an eye to the whole enterprise.
b. The IT CCB is the enterprise central point for evaluating change. When a change of any nature affects the Department of State infrastructure or has potential for affecting the infrastructure then that change must be presented to the IT CCB. The IT CCB is not intended to police development activity, rather it is intended to be an assessor and advisor to change and how it affects Department of State’ infrastructure.
c. The IT CCB works with both the MRAG and/or TRAG previously identified, and the IT Program Board to assure that projects meet the Department’s IT standards and assure their scope does not adversely affect the enterprise infrastructure.
d. IT CCB recognizes the importance and practicality for bureaus and offices to maintain their own local CCB functions. Therefore, should a change request be made, it should first go through the local CCB or system manager. The local CCB or if one doesn’t exist, the system manager will be responsible for evaluating whether the change request should be forwarded to the IT CCB.
e. The IT CCB processes two types of requests:
(1) Assessment requests; and
(2) Change requests.
5 FAH-5 H-513 IT CCB ASSESSMENT REQUEST (AR) AND APPROVAL
(CT:ITS-6; 12-15-2016)
a. An assessment request is submitted to request that a project or idea be studied for its impact to the IT infrastructure. The AR is only analyzed by primary reviewers identified in the IT CCB SOP and is not passed to the IT CCB members.
b. Examples of when ARs may be needed are:
(1) Requirement of IT Program Board (ITPB) in funding approval process;
(2) Proactive request from a project manager prior to submitting to the ITPB; and
(3) New idea under consideration for funding approval.
c. ARs may be submitted by any Department of State organization. ARs must be completed and provided to the change manager.
d. The AR must clearly state the project’s functional and technical characteristics. The priority of the assessment request is determined by the change manager.
5 FAH-5 H-514 IT CCB CHANGE REQUEST (CR) AND APPROVAL
(CT:ITS-7; 03-09-2017)
a. A change request may be submitted by any Department of State organization that has a requirement to add a product to or change a product on the baseline. The change request must be submitted prior to making the change. A change request must be completed and reviewed, signed and approved by the local board prior to submission to the IT CCB.
b. The change request originator must submit a change request to his or her bureau’s voting representative who passes it to the change manager of the bureau choosing to sponsor it.
c. The change request originator should expect a response to the request within two weeks.
5 FAH-5 H-515 CONFIGURATION MANAGEMENT PLAN
(TL:ITS-1; 02-13-2002)
a. The CM plan is the work breakdown structure for how CM will be applied for each project. It defines what is going to be done and how it will be accomplished. A configuration management plan is written for each project. The CM manager develops the CM plan for the project configuration and components (hardware, software, documentation, data, personnel and budget) and implements the change control process as specified in the CM plan.
b. The CM plan must be developed during the study period and must be augmented throughout the system life cycle. It identifies the types of configuration items (i.e., hardware, new applications, vendor software, etc.) The CM plan must be updated when the project plan and QA plan are updated, usually at the conclusion of a particular life-cycle phase (i.e. study period, acquisition phase, operations and maintenance). See 5 FAH-5 Exhibit H-515, Model Configuration Management Plan (Sample).
5 FAH-5 H-516 THROUGH H-519 UNASSIGNED
5 FAH-5 Exhibit H-515
Model Configuration Management Plan (SAMPLE)
(TL:ITS-1; 02-13-2002)
1.0 INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Definitions
1.4 Terms
1.5 References
2.0 CONFIGURATION MANAGEMENT
2.1 Organizational Authority and Responsibilities
2.2 Configuration Management Responsibilities
2.3 Interface Control
2.4 Configuration Management Plan Implementation
2.5 Charter, Policies, Directives, and Procedures
3.0 CONFIGURATION MANAGEMENT ACTIVITIES
3.1 Configuration Identification
3.2 Baseline Identification
3.3 Configuration Control
3.4 Configuration Status Accounting
3.5 Special CM Repositories and Libraries
3.6 Audits
3.7 Backups and Archives
4.0 TOOLS, TECHNIQUES, AND METHODOLOGIES
4.1 Configuration Control Tools
4.2 Release Management Procedures
4.3 Problem Report System and Process
4.4 Special CM Tools and Procedures
4.5 Outline for Testing
5.0 SUPPLIER CONTROL
5.1 Vendor Provided Software
5.2 Subcontracted Software
5.3 Vendor and Subcontractor Software
CM PLAN APPENDICES