5 FAH-5 H-500
CONFIGURATION MANAGEMENT
5 FAH-5 H-510
PROJECT DEVELOPMENT AND CHANGE CONTROL
(CT:ITS-7; 03-09-2017)
(Office of Origin: IRM/BMP/GRP/GP)
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 customers 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 Departments 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
States 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 Departments 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 doesnt 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 projects 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 bureaus 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