**Run IIb CDF Detector Project**

**Project Management Plan**

######## 

#### 10 December 2002

**Submitted, Approved and Accepted By**:

**[CDF Run IIb Project Manager]{.underline} [CDF Collaboration
Spokespersons]{.underline}**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

P. Lukens A. Goshaw

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

N. Lockyer

**[Concurrence]{.underline} [Approval]{.underline}**

**[Fermilab]{.underline} [Department of Energy]{.underline}**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

J. Cooper P. Philp

Head of Particle Physics Division DOE Run II Project Manager

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

H. Montgomery

Associate Director for Research

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

M. Witherell

Director

[1. INTRODUCTION 5](#introduction)

[1.1 Overview of the Project Management Plan (PMP)
5](#overview-of-the-project-management-plan-pmp)

[1.2 CDF Run IIb Detector Project Description
5](#cdf-run-iib-detector-project-description)

[1.3 Historical Background 5](#historical-background)

[1.4 Reference Documents 6](#reference-documents)

[2. JUSTIFICATION OF MISSION 7](#justification-of-mission)

[2.1 Physics Objectives 7](#physics-objectives)

[2.2 Technical Objectives 7](#technical-objectives)

[2.3 Cost Objectives for the CDF Run IIb Detector Project
8](#cost-objectives-for-the-cdf-run-iib-detector-project)

[2.4 Schedule Objectives 8](#schedule-objectives)

[3. PROJECT DESCRIPTION 9](#project-description)

[4. PROJECT MANAGEMENT, ORGANIZATION, AND RESPONSIBILITIES
11](#project-management-organization-and-responsibilities)

[4.1 Department of Energy 11](#department-of-energy)

[4.2 Fermilab Director and Deputy Director
12](#fermilab-director-and-deputy-director)

[4.3 Fermilab Associate Director for Research
13](#fermilab-associate-director-for-research)

[4.4 Fermilab Particle Physics Division Head
13](#fermilab-particle-physics-division-head)

[4.5 Project Manager 14](#project-manager)

[4.6 Project Leaders 15](#project-leaders)

[4.7 Advisory Functions 16](#advisory-functions)

[4.7.1 Project Management Group 16](#project-management-group)

[4.7.2 Spokespersons 17](#spokespersons)

[4.7.3 CDF Executive Board 17](#cdf-executive-board)

[4.7.4 Internal Review Committees 17](#internal-review-committees)

[4.7.5 Subproject Technical Committees
17](#subproject-technical-committees)

[4.7.6 Godparent Committees 18](#godparent-committees)

[5. WORK BREAKDOWN STRUCTURE 19](#work-breakdown-structure)

[5.1 SVXIIb 19](#svxiib)

[5.2 Calorimeter 20](#calorimeter)

[5.2.1 Central Preradiator System 20](#central-preradiator-system)

[5.2.2 EM Timing 21](#em-timing)

[5.3 Data Acquisition and Trigger Systems
21](#data-acquisition-and-trigger-systems)

[5.3.1 Event Builder 21](#event-builder)

[5.3.2 Track Trigger Upgrade 22](#track-trigger-upgrade)

[5.3.3 Replacement of the TDCs 22](#replacement-of-the-tdcs)

[5.3.4 Replacement of the Level 2 Decision Crate
22](#replacement-of-the-level-2-decision-crate)

[5.3.5 Replacement of the Level 3 Processors
23](#replacement-of-the-level-3-processors)

[5.4 Project Administration 23](#project-administration)

[6. RESOURCE PLAN 24](#resource-plan)

[6.1 Equipment Resources 24](#equipment-resources)

[6.2 Personnel Resources 24](#personnel-resources)

[7. Technical, Schedule, and Cost 25](#technical-schedule-and-cost)

[8. Change Control thresholds 26](#change-control-thresholds)

[9. RISK MANAGEMENT ASSESSMENT 27](#risk-management-assessment)

[9.1 Technical Risk 27](#technical-risk)

[9.2 Cost Risk 27](#cost-risk)

[9.3 Schedule Risk 27](#schedule-risk)

[9.4 Risk Analysis 27](#risk-analysis)

[10. PROJECT CONTROLS SYSTEM 29](#project-controls-system)

[10.1 Guidelines and Policies 29](#guidelines-and-policies)

[10.2 Work Authorization and Contingency Management
30](#work-authorization-and-contingency-management)

[10.3 Baseline Development 30](#baseline-development)

[10.4 Project Performance Measurement
31](#project-performance-measurement)

[10.4.1 Funds Management 31](#funds-management)

[10.4.2 Accounting 31](#accounting)

[10.4.3 Performance Measurement and Analysis
31](#performance-measurement-and-analysis)

[10.4.4 Schedule Variance 31](#schedule-variance)

[10.4.5 Cost Variance 32](#cost-variance)

[10.4.6 Resource Variance 32](#resource-variance)

[10.5 Change Control 32](#change-control)

[10.5.1 Out-of-Scope Changes 32](#out-of-scope-changes)

[10.5.2 In-Scope Changes 33](#in-scope-changes)

[10.6 Information and Reporting 37](#information-and-reporting)

[10.6.1 Project Meetings 37](#project-meetings)

[10.6.2 Reporting 37](#reporting)

[11. ACQUISITION STRATEGY PLAN 38](#acquisition-strategy-plan)

[12. ALTERNATE TRADEOFFS 38](#alternate-tradeoffs)

[12.1 Silicon alternatives 38](#silicon-alternatives)

[12.2 Central Preradiator Alternatives
38](#central-preradiator-alternatives)

[13. TECHNICAL CONSIDERATIONS 39](#technical-considerations)

[13.1 Technical Reviews and Documentation
39](#technical-reviews-and-documentation)

[13.2 Research and Development 39](#research-and-development)

[13.3 Quality Assurance and Tests 39](#quality-assurance-and-tests)

[14. INTEGRATED SAFETY MANAGEMENT 41](#integrated-safety-management)

[14.1 Overview 41](#overview)

[14.2 Objectives 42](#objectives)

[14.3 Organization and Responsibilities
42](#organization-and-responsibilities)

[14.4 Documentation and Training 42](#documentation-and-training)

[APPENDIX A: List of Referenced Documents
44](#appendix-a-list-of-referenced-documents)

[APPENDIX B: List of Schedule Milestones
45](#appendix-b-list-of-schedule-milestones)

[APPENDIX C: Quality Management Program
47](#appendix-c-quality-management-program)

[APPENDIX D: Configuration Control Program
54](#appendix-d-configuration-control-program)

########### 1. INTRODUCTION {#introduction .unnumbered}

This document describes the Project Management Plan for the Run IIb CDF
Detector Project.

##################### 1.1 Overview of the Project Management Plan (PMP) {#overview-of-the-project-management-plan-pmp .unnumbered}

This document outlines the objectives of the Run IIb CDF Detector
Project. The project management organization is described, participants
are named, and a plan is presented to meet the objectives. The Project
Management Plan is supplemented with the following documents:

1\) The CDF Run IIb Detector Technical Design Report (TDR);

2\) The CDF Run IIb Cost and Schedule Plan (CSP), including the CDF
Financial Plan;

3\) The CDF Run IIb subproject Memoranda of Understanding and work plans
(MOU\'s).

4\) DOE Project Execution Plan (PEP) for Run IIb CDF Detector Project
and D-Zero Detector Project.

The physics goals of the project are presented in the Technical Design
Report. The Cost and Schedule Plan includes a cost estimate for the
project and a resource-loaded schedule, both based on a common Work
Breakdown Structure (WBS). The full project is divided into four WBS
subprojects as follows: SVXIIb; Calorimeter; Data Acquisition; and
Project Administration. The MOU\'s and work plans for each subproject
describe all necessary tasks. Appendices to these MOU\'s reapportion the
subproject tasks by institution and indicate explicitly who is
responsible for each sub-task.

##################### 1.2 CDF Run IIb Detector Project Description {#cdf-run-iib-detector-project-description .unnumbered}

The CDF Run IIb Detector Project prolongs the useful life of the
detector for operation at higher luminosity now anticipated at the
Tevatron collider. Specifically, the detector must be capable of
handling peak luminosity up to 4 x 10^32^ cm^-2^ sec^-1^ and an
integrated luminosity of 15 fb^-1^. Several detector systems must be
replaced or modified in order to meet these requirements.

##################### 1.3 Historical Background {#historical-background .unnumbered}

CDF first detected pp collisions in 1985. The detector has collected
data in 1987, 1988-89, 1992-93 (\"Run Ia\") and 1994-1996 (\"Run Ib\").
Collider Run IIa began in 2001. A large number of important physics
results have been produced by CDF and have been published in numerous
articles in refereed physics journals. These results include the
discovery of the top quark and precision measurements of its mass and
production cross section, precision measurement of the W boson mass, a
broad program of electroweak measurements, QCD measurements, B physics,
including measurement of lifetimes of exclusive states, and Exotic
Physics including limits on the production of a variety of non-Standard
Model objects.

CDF has gone through periods of extensive upgrades. Between 1989 and
1992, the detector was improved in several ways. This included the
addition of a silicon vertex detector, additional muon detectors to
increase the muon acceptance, improvements to existing muon systems, and
a new inner tracking chamber used to measure the *z* position of event
vertices. The experiment recorded 110 pb^-1^ of integrated luminosity
during the 1992-96 operating period (Run I).

In October 1990 a proposal was submitted to upgrade the CDF detector to
allow it to continue to exploit the physics opportunities as
improvements, including the Main Injector, were made to the Fermilab
collider. The running conditions for collider Run II specified that the
detector must be capable of handling peak luminosity up to 2 x 10^32^
cm^-2^ sec^-1^, bunch spacing as small as 132 ns, and an integrated
luminosity of 2 fb^-1^. The CDF Run IIa upgrade included replacing

the plug and forward gas calorimeters with a new scintillator-based
calorimeter and replacing the Central Tracking Chamber with a device
with shorter drift time to allow tracking in a high-luminosity
environment. A completely new silicon system was built and installed.
The front-end electronics and trigger systems were upgraded to
accommodate data-taking at higher rates and with shorter bunch spacing.
Muon detection systems were upgraded to increase acceptance and allow
the electronics to work with shorter bunch spacing. The data acquisition
system was upgraded to increase throughput and reliability. A new
time-of-flight detector was added, as were new detectors in the forward
region. The CDF Upgrade Project for Run IIa was successfully completed
in March 2001.

##################### 1.4 Reference Documents {#reference-documents .unnumbered}

Appendix A contains a list of documents referenced in this PMP or which
provide direction to the project. References to these documents appear
throughout this plan.

########### 2. JUSTIFICATION OF MISSION {#justification-of-mission .unnumbered}

The Department of Energy has established the need for the Run IIb CDF
Detector Project by completing and approving a Justification of Mission
Need (CD-0) document. The scientific objectives of the project were
confirmed by the Fermilab Physics Advisory Committee report from June,
2002. The scientific, technical, cost, and schedule objectives
pertaining to this project are described in sections 2.1 through 2.4
below.

##################### 2.1 Physics Objectives {#physics-objectives .unnumbered}

The primary goal of the CDF Run IIb Detector Project is to enable the
detector to exploit the physics opportunities available during Tevatron
operation through 2008. The data from Run II will represent a set of
detailed measurements that can be compared with the predictions of the
Standard Model at the highest available collision energy. The main focus
of the experiment in Run IIb will be the continuation of the search for
the Higgs boson. The increased size of the data sample will also allow
us to study the top quark by measuring the details of its production and
decay mechanism. In addition, we plan precision electroweak and QCD
measurements, continued searches for a variety of phenomena that are
predicted to exist beyond the Standard Model framework, and to explore
CP violation in the *b* quark sector. The detailed physics goals of the
upgrade are described in the Technical Design Report (TDR).

##################### 2.2 Technical Objectives {#technical-objectives .unnumbered}

The major tasks of this upgrade are:

-   Replace the silicon micro-vertex detector with a device capable of
    withstanding the expected radiation dose for Run IIb and with fast
    *r-φ* (axial) and small angle stereo readout.

-   Upgrade the calorimeter by replacing the Central Preradiator Chamber
    with a device with shorter response time to allow operation in a
    high-luminosity environment, and adding timing information to the
    electromagnetic calorimeters.

-   Upgrade the data acquisition and trigger systems to increase
    throughput needed for higher luminosity operation and efficiently
    trigger on the higher multiplicity events of Run IIb.

The off-line computing hardware and reconstruction software must be
enhanced to assure efficient and timely data analysis and production of
physics results from the large amount of information that will be
accumulated during Run II. Off-line computing and software are managed
as a separate project and will be discussed in a separate document.
Additional technical detail appears in the CDF Run IIb Detector
Technical Design Report.

The installation activities for the Run IIb Detector will be managed as
a separate project. Installation will include removing the central
detector from the collision hall, extracting the ISL/SVXII detectors
from the tracking volume, installing the replacement silicon into the
ISL, returning the central detector to the collision hall, and
installation of new cabling as required.

##################### 2.3 Cost Objectives for the CDF Run IIb Detector Project {#cost-objectives-for-the-cdf-run-iib-detector-project .unnumbered}

The project estimated costs are summarized in Table 5.1 in the PEP.

Financial support for this project includes contributions from CDF's
international collaborators (Japan, Italy, Taiwan, Canada, Finland,
Korea, Russia, Spain, Switzerland, UK) as described in the CDF Financial
Plan. The estimate for international contributions does not include
substantial in-kind labor contributions, nor funds contributed for
experiment operating expenses.

##################### 2.4 Schedule Objectives {#schedule-objectives .unnumbered}

The critical objective of the Run IIb CDF Detector Project is to have
the upgraded detector ready to install in 2006. Schedule objectives are
summarized in the list of milestones presented in Table 8.3 of the
Project Execution Plan and Appendix B. The Project is complete when the
Run IIb Detector is ready to be installed in the collision hall. The
objective is to meet this goal by June 2006.

########### 3. PROJECT DESCRIPTION {#project-description .unnumbered}

The Project is described extensively in the CDF IIb Detector Technical
Design Report. A summary description is presented later in this document
(Chapter 5: Work Breakdown Structure). The Run IIb CDF Detector Project
will be funded through a combination of DOE and international funds. It
will be scheduled and controlled under general DOE authority with
management of non-DOE elements provided through
Memoranda-of-Understanding (MOU's).

The projects needed for Run IIb can be broadly separated into two
classes: projects needed due to the increase in instantaneous
luminosity, and those needed due to the integrated luminosity and
therefore the length of the run required. The former represent an
increase in the capability of the detector, beyond the specifications
set for the Run IIa upgrade of CDF. The latter are essentially the
maintenance costs due to the duration of operation. The Run IIb projects
are presented here in three categories: Silicon Detector Replacement,
Calorimeter Upgrades, and Data Acquisition and Trigger Upgrades.

The goal of the Run IIb CDF Detector Project is to maintain the
viability of the CDF detector as a Higgs search experiment during the
Run IIb Tevatron operation.

The trigger efficiencies after the offline analysis cuts for these
backgrounds are assumed to scale linearly with that of the signal. We
assume the background kinematics is similar to the signal in our
approximation. The Higgs search needs the integrated luminosity
attainable in Run IIb, and a detector capable of exploiting it fully.
The effect of the proposed Run IIb upgrades is summarized here:

-   A new silicon vertex detector is the essential element of the Run
    IIb upgrades, and must deliver a *b*-tagging efficiency of at least
    60*%* of taggable high-*E~T~* jets. A loss of even 10*%* (to 54%) in
    this efficiency due to lack of redundancy would cost 20*%* in
    required integrated luminosity to discover the Higgs, which
    translates into 3 fb^-1^ for discovering a Higgs with a mass of 120
    GeV/c^2^, more than a half year of running time.

-   The upgraded detector needs the best possible $b\overline{b}$ mass
    resolution, and this in turn demands maximal information regarding
    jet energy flow. The proposed Central Preshower and Central Crack
    upgrades will enhance the information available in the Run IIa data,
    and likely lead to a few percent improvement in jet energy
    corrections overall. This detector improvement is equivalent to
    several months of running time towards the discovery of the Higgs
    Boson. The timing upgrade to the electromagnetic calorimeters will
    reduce cosmic ray backgrounds, and improve the quality of the events
    that contain photon candidates. This is known to be for important
    searches in final state channels with photons and missing energy
    (supersymmetry, anomalous couplings etc). This will provide a
    vitally important handle that helps confirm that all the photons in
    unusual events (such as the Run I CDF eeγγ+$E_{T}$ candidate) are
    from the primary collision.

-   Triggers for the isolated lepton and $b\overline{b}$ + $E_{T}$ final
    states must remain fully efficient at high instantaneous
    luminosities. Instrumenting the outer Central Outer Tracker stereo
    layer for use in the trigger decision would limit fakes and aid in
    hit pattern recognition in the Secondary Vertex Trigger. We estimate
    that this upgrade will extend our track trigger effectiveness to the
    instantaneous luminosities anticipated in Run IIb. Without this
    upgrade 20% more integrated luminosity is required for the Higgs
    discovery.

-   Finally, the upgrade in bandwidth for the Event Builder from 300 Hz
    in Run IIa to 1 kHz in Run IIb, along with a complementary upgrade
    to the TDC system, allows us to retain the high efficiency for the
    triggers on which the Higgs search is based. A simultaneous upgrade
    to the Level 3 trigger processors is also required for this higher
    data collection rate. The proposed 1 kHz system is well-matched to
    the rates and signal efficiencies of the most important high- *P~T~*
    physics of Run IIb

Although it is not formally part of the Run IIb CDF Detector Project,
the installation of the experiment during the period between Runs IIa
and IIb will be managed by the same management structure that is used
for the project. The installation subproject involves extraction of the
CDF central detector from the collision hall, replacement of the
detector components built for Run IIb, and the return of the central
detector to the collision hall. This process is essentially identical to
the installation performed for Run IIa, so the time and resources
required are well understood.

########### 4. PROJECT MANAGEMENT, ORGANIZATION, AND RESPONSIBILITIES {#project-management-organization-and-responsibilities .unnumbered}

The Fermilab Director carries the prime management responsibility for
this project at Fermilab. This project will be carried out in
collaboration with the universities and laboratories in the U.S. and
other countries that make up the CDF Collaboration. This project will be
managed to a predetermined scope, cost, and schedule. Figure 4.1 shows
the organization chart for the Run IIb CDF Detector Project. The
descriptions presented here serve to clarify the roles of key personnel.

Fermilab and many organizations and institutions external to Fermilab
will undertake construction of the components for the CDF Run IIb
detector. Significant portions of the detector funding will be provided
by sources other than Fermilab. For these reasons, part of the
responsibility for construction of detector components will reside
outside Fermilab. However, responsibility to the Fermilab Director will
be maintained by the CDF collaboration management through the CDF Run
IIb Project Manager resident at Fermilab.

##################### 4.1 Department of Energy {#department-of-energy .unnumbered}

As mentioned above, the Department of Energy has established the need
for the Run IIb CDF Detector Project by completing and approving a
Justification of Mission Need (CD-0) document. The Department of Energy
has also participated in peer review processes for the Fermilab program
including the annual DOE laboratory-wide review and the Fermilab Physics
Advisory Committee meetings. The Department of Energy provides the
majority of funding for the Run IIb CDF Detector Project. These funds
are provided through the Fermilab annual financial plan by contract
modification. The Division of High Energy Physics provides annual
program guidance to the Laboratory as well as annual guidance on the
funding profile for the project. The Department exercises oversight of
the project by:

-   Conducting periodic reviews of the project;

-   Participating in regularly scheduled Project Management Group (PMG)
    meetings;

-   Overseeing operations and fabrication activities;

-   Monitoring project progress via monthly progress reports; and

-   Monitoring milestones/performance measures.

The primary contact between the Run IIb CDF Detector Project and the DOE
will be the DOE Run II Project Manager. The management structure and
roles of the DOE are presented in further detail in section 4 of the
PEP.

> ![](media/image1.wmf)

##################### 4.2 Fermilab Director and Deputy Director {#fermilab-director-and-deputy-director .unnumbered}

The Fermilab Director has the overall responsibility to the Universities
Research Association and the Department of Energy for the successful
completion of the Run IIb CDF Detector Project and is the only person
authorized to commit funds appropriated for Laboratory use. The Director
determines the proposed scope of the upgrade project with advice from
the Fermilab Physics Advisory Committee (PAC) in response to proposals
from the CDF collaboration. Decisions regarding the scope of the project
are made in a two-stage process. Stage I approval is given to endorse
the scientific merit of the proposal when sufficient information is
known regarding technical designs so that costs and schedules can be
estimated. Resources can then be allocated so that a project Work Plan
and Memorandum of Understanding (MOU) can be developed, detailed
technical designs can be prepared, and cost estimates and
resource-loaded schedules can be generated. In addition, a financial
plan identifying the necessary funding resources is prepared. Upon the
successful completion of these plans, the Fermilab Director may grant
Stage II approval. Stage II approval for the project may proceed in
parts, subsystem by subsystem. R&D of a subsystem normally begins after
Stage II approval has been granted for that subsystem but may proceed
earlier with the Director\'s approval. The Director may at his/her
discretion delegate tasks to the Deputy Director.

The CDF Collaboration consults with the Director as part of its
procedure for appointing spokespersons. The Technical Design Report, the
cost estimate, the schedule, the financial plan for the project, and any
out-of-scope changes in the project require the concurrence or approval
of the Director.

##################### 4.3 Fermilab Associate Director for Research {#fermilab-associate-director-for-research .unnumbered}

The Fermilab Director has delegated certain responsibilities and
authorities to the Associate Director for Research (ADR). The ADR is
responsible for management oversight of the project. The Project Manager
is appointed by the ADR and reports to the ADR directly and through the
Head of the Particle Physics Division. The ADR chairs the Project
Management Group (PMG) that meets as required to monitor the progress of
the project. Directorate oversight of the project is implemented in part
through reviews including the PMG and Director\'s reviews. In concert
with the routine project management interactions, these reviews will
identify actions and initiatives to be undertaken in order to achieve
the goals of the project including the allocation of both financial and
human resources. The Project Management Group will also function as the
Change Control Board for the project. Progress will also be monitored
through presentations to and discussions with the PAC.

To implement the work plan for the upgrade project, Memoranda of
Understanding are written assigning responsibilities and describing the
work to be executed for each subproject. The ADR will approve all
Memoranda of Understanding. The ADR is responsible for providing a
funding profile consistent with Laboratory funding in consultation and
guidance from the DOE Program Office. The ADR assures that the
Laboratory long-range schedule and the dates of important project
schedule objectives are provided to the Project Manager in a timely
manner. The ADR advises the Director on the concurrence and/or approval,
as appropriate, of the TDR, the PMP, the cost estimate, the schedule,
and the financial plan and concurs with these approvals.

##################### 4.4 Fermilab Particle Physics Division Head {#fermilab-particle-physics-division-head .unnumbered}

The Fermilab Director and ADR have delegated certain responsibilities
and authorities to the Fermilab Particle Physics Division (PPD) Head.
The PPD Head is responsible for portions of project management and
oversight as the line manager for financial resources, human resources,
technical resources, space resources, and ES&H issues for this project.

The PPD Head and his/her deputies are members of the Project Management
Group. The PPD Head advises the ADR on approval of Memoranda of
Understanding relevant to PPD resources and concurs in these approvals.
The PPD Head advises the Director and ADR on approval of the PMP and the
CSP and concurs with these approvals. On advice from the Director, the
PPD Head allocates yearly budgets to the Run IIb CDF Detector Project.
These project funds are then administered by the Project Manager within
the context of PPD procedures and policies and with the assistance of
the PPD budget office.

Particle Physics Division is the primary source of Fermilab labor and
technical resources for the project. The Head of the Particle Physics
Division will provide support to the project, in accordance with the
CSP, through PPD technical resource groups via specific work plans or
Memoranda of Understanding. The Project Manager utilizes assigned
personnel to achieve the project goals. The PPD Head maintains line
management responsibility for these PPD employees via the technical
resource group leaders.

Since the Particle Physics Division is the primary source of Fermilab
labor needed to achieve the project schedule goals, any mismatch of
labor to the needs of the project must be reported in a timely fashion.
The PPD Head or designee will advise the Project Manager and ADR and
report to the CDF PMG if insufficient labor is available to meet the
requirements specified in the CSP. In this event, the Project Manager
will conduct a schedule impact study and submit a schedule variance as
appropriate to the ADR as required by the project controls.

##################### 4.5 Project Manager {#project-manager .unnumbered}

The Project Manager (PM) is appointed by the ADR with the approval of
the CDF Spokespersons and the PPD Head. The PM is part of the PPD line
management chain at the department head level and has the responsibility
to complete the Technical Design Report, the Cost and Schedule Plan, and
the MOU/Work Plans for the project. The technical description of the
project is that proposed in the Technical Design Report by the CDF
collaboration as well as any out-of-scope changes approved via the
change control process. As part of the CSP, the PM will provide the
Laboratory with labor profiles required to complete the project on
schedule. Once the CSP is agreed upon and the necessary resources
provided, the Project Manager has the responsibility to complete the Run
IIb CDF Detector Project on the agreed upon schedule, and within the
agreed upon budget and scope.

The PM is responsible for preparing the Project Management Plan (PMP)
and for updating it as necessary with the concurrence of the ADR. The
Project Manager may identify the need for project scope changes as they
arise. When there is a need for a change having a significant impact on
the physics capability of the detector the PM reports to the CDF
Collaboration Executive Board and also identifies the need to the
Director through the PMG. The PM receives technical advice from Internal
Review Committees. The PM creates such committees as needed for
technical advice and, in consultation with the CDF spokespersons,
appoints their members. The procedure for out-of-scope changes to the
project is described in Section 8 of this document. The Spokespersons,
representing the collaboration, seek approval for all scope changes
having a significant impact on the physics capability of the upgraded
detector by making scientific proposals to the Director.

The PM is responsible for organizing presentations at reviews and status
reports on the upgrade project to respond to the Director and funding
agencies. The PM has the authority to speak for the Collaboration on
technical questions raised in these processes. The PM will initiate
reviews of upgrade subprojects to insure that adequate progress is being
made and that the subproject is meeting its technical performance, cost,
and schedule milestones. The PM may request that a godparent review be
organized by the CDF spokespersons when questions pertaining to the
adequate technical or physics performance of a subsystem are raised.

The Project Manager has the responsibility to complete the Run IIb CDF
Detector Project on schedule, on budget, and within the agreed upon
scope by managing the resources of the Collaboration and the Laboratory.
The Project Manager, in consultation with the CDF Spokespersons and PPD
Head, has the authority to appoint deputy and assistant managers as well
as sub-Project Leaders (PL). The PM, working with the subproject
leaders, is responsible for the completion of the CSP and agreement
documents such as the Statement of Work (SOW) and Memorandum of
Understanding (MOU) for each subproject. These documents specify the
contribution to that subproject from each collaborating institution. The
MOU\'s describe responsibilities for the design, construction and test
of new detector components that are a part of this project. Additional
MOU's describe work plans for activities that support and maintain
existing parts of the CDF detector complex. The MOU's and SOW's are
considered to be supporting documents for both the PMP and CSP.

The PM has the authority to negotiate on behalf of CDF with
collaborating institutions and Fermilab Section and Division heads for
collaboration or Laboratory resources. All negotiations with
collaborating institutions will be made in consultation with the
Spokespersons. The Project Manager has responsibility for coordinating
all collaboration-wide resources for the project via the MOU\'s. The PM
has authority to negotiate with all institutions for optimal utilization
and management of these resources. The PM has fiscal authority for U.S.
funds and is responsible to the Fermilab ADR through the PPD head for
monitoring expenditures of U.S. and international funds as well as
tracking and reporting variances from baseline scope, schedule and cost
estimates specified in the CSP.

The Deputy Project Manager will have the full authority of the Project
Manager, in the event of the PM's temporary absence. The Deputy Project
Manger will normally assist in the management of the project.

##################### 4.6 Project Leaders {#project-leaders .unnumbered}

The major sub-projects that make up the detector are shown in Figure
5.1. Each of these sub-projects is headed by one or more Project Leaders
(PL). The Project Leaders are appointed by the Project Manager, as
described in section 4.6, and report directly to the PM. The Project
Leader is responsible for all coordination, tracking, and technical
communications involved with the design and production of a subsystem.
For subprojects that involve construction of equipment, the Project
Leaders are responsible for the design, fabrication, integration, and
testing of all components of that particular subsystem. Subsystem
fabrication activities will generally be widely dispersed and will
involve both the United States and international collaborating
institutions.

In some cases, project funds to support the subsystem activities
originate with Fermilab and are allocated to subsystem projects on the
authorization of the PM. The PM delegates limited signature authority to
the PL\'s for items related to their subproject to be purchased with
such funds. In many cases, even though the PL is based in the United
States, part of the support will come from international funds. The PL's
interact closely with the international leaders of activities relevant
to their subsystem to ensure that international funds are appropriately
spent on the subproject and to maintain good coordination. The PM does
not have budget authority for international funds or for contributions
to the project made by collaborating U.S. institutions, but he/she does
have the authority and responsibility to ensure that project work at all
institutions is technically adequate and within the approved scope of
the project. Collaborating institutions agree to the scope, schedule and
cost estimate for their work though the MOU process. The PM will
interact with the PL's and the representatives of collaborating
international institutions to ensure that the distribution of resources
is matched to the project objectives and schedule.

It is the responsibility of the PL's to bring to the attention of the PM
any anticipated changes in the subproject from the approved baseline
that may significantly affect the cost, completion date, or performance
of the subsystem. The PL's will provide information on the detailed
cost, schedule and performance of the subsystem and will make
presentations to review committees, funding agencies, and the
directorate when requested to do so by the PM. The PL's may specify Task
Managers and appropriate subproject organizations for each subsystem.
Further subproject organizational details appear in the subproject SOW's
or MOU's. The PL's are responsible for quality assurance and quality
control plans for their subprojects and for assuring that their
subsystems meet the ES&H standards of Fermilab. Specifically, PL's have
responsibility for the following aspects of quality control:

-   Incorporation of the necessary design reviews into the project CSP
    and establishing adequate approval processes prior to procurement
    and fabrication of subproject components.

-   Incorporation of necessary acceptance tests into fabrication plans
    and practice.

-   Verification of system performance requirements.

-   Incorporation of sufficient \"on-site inspection" at off-site and/or
    international institutions to assure adequate quality of
    deliverables fabricated using these sources.

    -   Documentation and management of records related to the design,
        development, production, fabrication, installation, operation,
        servicing, and repair of subsystems.

##################### 4.7 Advisory Functions  {#advisory-functions .unnumbered}

############################### 4.7.1 Project Management Group {#project-management-group .unnumbered}

The Project Management Group (PMG), chaired by the ADR, brings together
for regular meetings, at least monthly, those who have management
responsibility for the success of the Run IIb CDF Detector Project and
who have authority to redirect resources within the Laboratory and the
Collaboration. The PMG also functions as the Change Control Board for
the project.

############################### 4.7.2 Spokespersons {#spokespersons .unnumbered}

The CDF spokespersons are responsible for all scientific aspects of the
CDF Collaboration including operation and upgrades of the detector, data
analysis, and publication of the results. In this capacity they provide
the means of contact between the CDF Collaboration and the Laboratory,
and represent the Collaboration in interactions with the Laboratory. The
Spokespersons serve as chairs of the CDF Executive Board and are a
principal contact point for the PM to communicate and coordinate
discussion and review of issues that impact the entire Collaboration.
The Spokespersons are elected to two-year terms by the Collaboration
with the approval of the Fermilab Director.

############################### 4.7.3 CDF Executive Board {#cdf-executive-board .unnumbered}

The CDF Executive Board advises the spokespersons on scientific and
sociological aspects of the collaboration. The Board consists of the
Group Leaders (or designates) of each collaborating institution. The
Board also approves the addition of new collaborating institutions, as
well as significant changes to the detector or the scientific goals of
the collaboration. The CDF Executive board is the decision making body
that determines the scope to propose to the Laboratory as the Run IIb
CDF Detector Project. Decisions by the Executive board are based on
consultation with the full CDF collaboration. The Executive board is
required to ratify actions by the PM only if the fundamental definition
of the Scope of the Run IIb and its physics potential are at issue.

############################### 4.7.4 Internal Review Committees {#internal-review-committees .unnumbered}

Internal review committees provide a means for the PM to review
technical, cost, and schedule issues for upgrade subprojects. These
committees may also be charged with reviewing the physics performance of
the subsystem or recommending scope changes. Internal review committees
are appointed as required by the PM. The PM charges them, often in
consultation with the Spokespersons. Reports and recommendations from
internal review committees are transmitted to the Project Manager and
are in general made available to the entire collaboration.

Internal review committees are also a vehicle for communication between
the PM and the Collaboration. In particular, in response to a technical
concern raised by members of the collaboration, if the PM has not
already done so, the spokesperson may request of the PM that an internal
review committee be appointed to provide advice regarding the concern.

############################### 4.7.5 Subproject Technical Committees {#subproject-technical-committees .unnumbered}

There may be technical committees associated with a subsystem and
separate from the CDF internal review committees discussed above. These
are appointed by the PL\'s as needed. Members of such technical
committees advise the subsystem PL on technical directions,
alternatives, and methods of performance. The members of the committee
would include scientists responsible for the design and fabrication of
the subsystem or of major tasks within it. Other technical experts may
also be included. The PL chooses the membership of sub-project technical
committees. These committees act in an advisory capacity with decision
authority in the hands of the PL. Their reports are made available to
the Spokespersons, PM, and internal review committees.

############################### 4.7.6 Godparent Committees {#godparent-committees .unnumbered}

Godparent committees provide an additional means of reviewing complex
technical and physics performance issues. These committees provide
additional guidance related to physics goals and a means for
collaboration input into the upgrade project. Godparent committees are
appointed as required by the spokespersons. The spokespersons charge
them, often in consultation with the Project Manager. Reports and
recommendations from the godparent committees are transmitted to the
spokespersons and the Project Manager.

########### 5. WORK BREAKDOWN STRUCTURE {#work-breakdown-structure .unnumbered}

The technical description of the Run IIb CDF Detector Project is
presented in the TDR. The TDR describes the principal components of the
detector and serves as reference for the following descriptions of
detector subsystems. Detector subsystems are the basis for defining the
high-level WBS of the detector upgrade project. The WBS to level 2 is
shown in Figure 5.1. The task-based WBS extends to many levels to
facilitate planning, scheduling and cost estimation. Detailed cost
estimates and the resource-loaded schedule are contained in the CSP. The
resource-loaded schedule in the CSP provides the basis to track project
cost, estimate future labor requirements and financial needs, document
project changes, and estimate the project completion date. Provided
below is a description of the project at WBS level 2.

##################### 5.1 SVXIIb  {#svxiib .unnumbered}

WBS 1.1 includes work to build a new silicon vertex detector, called SVX
IIb. The CDF collaboration has considerable experience with
state-of-the-art silicon detectors. The original SVX was implemented in
a \"radiation-soft\" technology and as expected suffered considerable
radiation damage before the end of Run Ia. Between Run Ia and Ib, the
SVX detector was replaced with a new device, SVX\', of nearly identical
geometry but using AC-coupled silicon detectors and a radiation-hard
readout chip. The SVX\' was replaced for Run IIa (SVX II). The SVX II
detector was designed to address several shortcomings of the SVX\'. The
barrel (central) region is longer to cover the luminous region with
higher efficiency. This substantially increases the b-tagging efficiency
for top decay. The detectors are double-sided to provide *r-z* readout
for pattern recognition.  SVX II was designed to withstand much larger
radiation doses. The readout chip is pipelined for 132 ns bunch spacing.
SVX II, in combination with additional Layer 00 system has six layers
for improved pattern recognition.

Radiation damage from Run IIa will render the inner layers of the
silicon vertex detector inoperable. The main upgrade for Run IIb, a new
inner silicon vertex detector, is needed in order to maintain excellent
*b*-jet triggering and reconstruction. For the Higgs search the key
design goals for this detector are to meet or exceed a 60% *b*-jet
tagging efficiency per taggable jet at high *P~T~*, using secondary
vertex reconstruction, and to maintain high efficiency in the silicon
vertex trigger (SVT).

SVXIIb will consist of single-sided silicon detectors that are easier to
manufacture than the double-sided detectors used in SVX II. The design
uses a single mechanical structure throughout which reduces both
construction time and cost. The readout chip ("SVX4") will be
manufactured in a standard process to minimize costly schedule delays.
Both the DAQ and cooling systems will be retained from SVX II.

![](media/image2.wmf)

##################### 5.2 Calorimeter {#calorimeter .unnumbered}

The Calorimeter work shown in WBS 1.2 includes the Timing upgrades and
the Central Preradiator replacement as explained below.

############################### 5.2.1 Central Preradiator System {#central-preradiator-system .unnumbered}

WBS 1.2.1 is the Central Preradiator (CPR) Replacement. The current
preradiator chamber system is a gas-based chamber with wires running the
length of the wedge. It increases the experiment's power to discriminate
between photons and high transverse momentum π^0^'s. Because the gas
chamber system contains data from several bunch crossings, the high
luminosity environment anticipated for Run IIb will give the CPR an
extremely high occupancy and these chambers will not be able to
effectively deliver useful information. The gas chamber system will be
replaced by a scintillator system whose timing characteristics are more
appropriate for the bunch crossing time used in Run II.

The preradiator plays a key role in high *P~T~* photon and electron
identification, and in correcting for energy lost by particles showering
in the 1.1-interaction-length magnet coil. Studies have shown that for
the electromagnetic fraction (30%) in typical jets, an efficient and
pure preradiator signal can improve electromagnetic resolution by 20%
and may provide an overall improvement in jet mass resolution of a few
percent. This is an important part of the overall 30% improvement over
Run I that is needed. Identification of electrons in jets can also aid
in identifying and correcting the energy of *b* quark jets, which is
crucial for the Higgs search.

The existing crack chambers will also be replaced with
scintillator-based detectors as part of the CPR upgrade. These would add
to the array of information useful to correct the $E_{T}$ measured by
the calorimeter and to correct jet energies for losses in the cracks.

############################### 5.2.2 EM Timing {#em-timing .unnumbered}

WBS 1.2.2 covers instrumentation of the electromagnetic calorimeter with
timing capability similar to that which is already in place for the
hadronic calorimeters. Experience with the Run I data indicated that
timing information is an important technique for reducing backgrounds
due to cosmic rays. Cosmic ray backgrounds can be significant in
searches for exotic final states that contain photons and missing
transverse energy. The EM Timing project will provide a vitally
important handle that helps confirm that all the photons in unusual
events are from the primary collision.

##################### 5.3 Data Acquisition and Trigger Systems {#data-acquisition-and-trigger-systems .unnumbered}

WBS 1.3 includes modifications to the Data Acquisition and Trigger
systems. These modifications are proposed both to maintain the existing
capability of the systems and to upgrade to higher bandwidths for Run
IIb. Replacement of the processors used in the online system, the level
2 trigger, and the level 3 trigger are anticipated just to maintain the
existing system. System upgrades needed in order to handle the Run IIb
instantaneous luminosity include an improvement to our track based
trigger, an upgrade to the event builder switch, and a replacement for
the time-to-digital converters used in the drift chamber (COT).

############################### 5.3.1 Event Builder {#event-builder .unnumbered}

WBS 1.3.1 covers the upgrade of the event builder portion of the data
acquisition system. This system acquires the digitized data from
front-end electronics and delivers it through a high-level processor
farm (Level 3 system) where the final decision is made to write data to
tape and/or the on-line monitoring programs. The upgraded system is
designed to deliver events at the rate of at least 1000 Hz to the Level
3 trigger system with a negligible system dead time beyond that due to
the Level 2 hardware trigger decision time and front-end digitization
time.

The maximum bandwidth theoretically achievable with the existing Run IIa
system is 240 MBytes/s. In practice, about 60% of this limit has been
achieved in benchmarking tests with simulated data sizes corresponding
to the expected detector occupancy. It is possible that the performance
under test conditions can be further improved to about 80% of the
theoretical limit after tuning the system. The performance when
processing real data on the other hand depends crucially on the load
balancing among the various ATM switch inputs and it is desirable to
assume that at best 50% of the theoretical bandwidth can be used.

To match the requirements corresponding to a sustained data rate of at
least 250 MBytes/s the existing system is not sufficient and an upgrade
is necessary. For the upgrade, a sustained bandwidth of at least 400
MBytes/s is required to take into account load imbalance in the ATM
inputs and fluctuations in the data size.

A simple, straightforward upgrade scenario is proposed, in which the
same technology is used. The existing ATM switch uses OC3 connections,
which are upgraded to the four times more powerful OC12 connections.
This also implies a complete replacement of the switch. The main work
will be to rewrite the low level drivers.

############################### 5.3.2 Track Trigger Upgrade {#track-trigger-upgrade .unnumbered}

The CDF Level-1 track trigger (XFT), which can be applied to \~80% of
all Run IIb triggers for high *P~T~* physics, suffers from a rapid
increase in fakes once the number of overlapping minimum bias events
exceeds something like 5-6 interactions per crossing. CDF has applied
the full Level-1 track trigger hardware simulation to a sample of
$t\overline{t}$ Monte Carlo Events. Minbias events are overlapped and
the fake rate is determined. It is found that the fake rate increases
substantially as a function of the number of interactions per crossing.
The impact of an increased number of fakes directly affects the number
of fake single electron and muon triggers, which combine to use 25% of
the trigger bandwidth in Run IIb.

############################### 5.3.3 Replacement of the TDCs {#replacement-of-the-tdcs .unnumbered}

The time to digital converters (TDCs) currently in use for the Central
Outer Tracker (COT) have an inherent limitation to their speed of
readout, that limits their use to a 300 Hz accept rate of Level 2
triggers. We predict that the Run IIb operation conditions will require
the experiment to accept Level 2 triggers at 1000 Hz to maintain the
physics goals of the experiment. Replacing the TDCs will be necessary to
achieve this.

#####################  {#section-1 .unnumbered}

############################### 5.3.4 Replacement of the Level 2 Decision Crate {#replacement-of-the-level-2-decision-crate .unnumbered}

The Level 2 decision crate contains the processors that form the Level 2
trigger decision. This crate and its processors is based on technology
that is no longer commercially supported, and is unlikely to remain
viable for the duration of the run. Replacement of this device during
the course of the run is anticipated.

#####################  {#section-2 .unnumbered}

############################### 5.3.5 Replacement of the Level 3 Processors {#replacement-of-the-level-3-processors .unnumbered}

The computers used in the Level 3 trigger will be replaced in batches
during the course of the run. The new processors installed for this
replacement will have greater capability, which will be required for the
complex events that will be obtained at high luminosity.

#####################  {#section-3 .unnumbered}

##################### 5.4 Project Administration  {#project-administration .unnumbered}

WBS 1.4 includes work required for project administration. The tasks
include but are not limited to technical oversight and management of the
project, cost and schedule estimates, construction of work plans/ MOU's,
planning and assistance in the administration of international funding,
communication and liaison with the Laboratory management, cost and
schedule tracking, funding profiles and projections, contingency
analysis, procurement support, change control documentation, and
preparation for project reviews or status reports. This WBS element
includes the salaries of administrative and management personnel
involved in these tasks and the cost of necessary computing equipment to
support project administration.

Consistent communication on upgrade activities is maintained throughout
the CDF collaboration using Electronic mail, the World Wide Web,
video-conferences, frequent subsystem and collaboration meetings, and
periodic subproject progress reviews (mini-reviews). These ensure good
coordination of the overall project.

########### 6. RESOURCE PLAN {#resource-plan .unnumbered}

The resource plan is included in the Run IIb CDF Detector Cost and
Schedule Plan. A summary of the anticipated funding for the project can
be found in Table 6.1 of the PEP.

##################### 6.1 Equipment Resources {#equipment-resources .unnumbered}

All materials, services and technical labor is included in the cost plan
described in the PEP. The majority of this cost will be covered by the
DOE, although significant contributions are anticipated from Japan and
Italy.

##################### 6.2 Personnel Resources {#personnel-resources .unnumbered}

A significant amount of uncosted labor is required for the project. This
labor pool will come from the physicists within the CDF collaboration.
At the height of the project, the project will require approximately 20
full time equivalent physicists for the construction and testing of new
detector systems. This is well within the capacity of the CDF
collaboration.

########### 7. Technical, Schedule, and Cost {#technical-schedule-and-cost .unnumbered}

The technical description is presented in the CDF IIb Technical Design
Report. Cost and Schedule details are described in the CDF IIb Cost and
Schedule Plan (CSP). The methodology used to develop the project
schedule is to construct a task-based, resource-loaded schedule for each
upgrade subproject and then combine these schedules for the entire
upgrade project. This combined schedule provides the means whereby the
required funding and labor requirements for the entire project can be
assessed and best matched with the resources available from Fermilab,
other collaborating institutions, and other sources. Critical path
analysis is done both at the subproject level and for the project as a
whole.

Value Management (VM) principles are essential to proper program
management and have been incorporated at the early design and
development stages of the technical requirements. These principles have
also employed as the cost and schedule parameters matured over time. Use
of the VM approach provides a systematic framework to analyze the
functions of systems, equipment, facilities, services, and supplies for
the purpose of achieving the essential functions at the lowest life
cycle cost consistent with required performance, quality, reliability
and safety. VM elements have been incorporated as a part of each of the
technical and program reviews to date.

In the CSP, each sub-task is described in a WBS dictionary for each
subproject. The dictionary contains details of the cost estimates and
provides a contingency analysis for that sub-task. The CSP contains a
list of critical milestones. These milestones are incorporated into the
resource-loaded schedule and will be used to track the progress of the
project. DOE Level 0 and 1 milestones are contained in the PEP and Level
2 as an appendix to this document.

Contingency is estimated at the lowest level WBS item within the
project. The level of contingency is established by the Level 2
managers. Basic guidelines for the assignment of contingency are outline
in Table 7.1, although other values will be used as appropriate.

  ----------------------------------------------------- -----------------
  **Description**                                       **Contingency
                                                        Level**

  Item is Completed                                     0

  Purchase Order has been placed                        10%

  Engineering estimate, based on design and vendor      30%
  information                                           

  Physicist estimate, based on a conceptual design.     50%

  Incomplete estimate, based on experience              100%
  ----------------------------------------------------- -----------------

**Table 7.1 Contingency assignment guidelines**

########### 8. Change Control thresholds {#change-control-thresholds .unnumbered}

The thresholds for change control are detailed below for the Run IIb CDF
Detector Project in Table 8.1. The CDF PMG functions as the Change
Control Board for the project. The CDF Project Manager will maintain
current records of each Change Request (CR) and their disposition. DOE
Change Control authorities are outlined in Table 8.1 of the PEP. A
sample CR is shown in Figure 10.2.

+---------------+--------------------------+--------------------------+
|               | **Fermilab               | **CDF RUN IIb**          |
|               | Director/Deputy          |                          |
|               | Director**               | **Project Manager**      |
+---------------+--------------------------+--------------------------+
| **Technical** | Changes that affect ES&H | Changes that do not      |
|               | requirements or impact   | affect ES&H requirements |
|               | accelerator systems.     | and do not change        |
|               |                          | upgrade project scope.   |
|               | Out-of-scope changes to  |                          |
|               | upgrade physics          |                          |
|               | capabilities.            |                          |
+---------------+--------------------------+--------------------------+
| **Cost**      | Any increase in a level  | Any use of contingency.  |
|               | 2 subproject by \$100K.  |                          |
+---------------+--------------------------+--------------------------+
| **Schedule**  | Any change in the        | Any change in a          |
|               | project critical path or | sub-system critical path |
|               | a Level 2 milestone.     | or Level 3 or 4          |
|               |                          | milestone by more than 1 |
|               |                          | month.                   |
+---------------+--------------------------+--------------------------+
| **Personnel** | Any increase in required | Any change in level 2    |
|               | Fermilab project         | subproject personnel of  |
|               | personnel of 10%         | 10% for the year.        |
|               | relative to CSP.         |                          |
+---------------+--------------------------+--------------------------+

# Table 8.1 Baseline Change Approval Thresholds

########### 9. RISK MANAGEMENT ASSESSMENT {#risk-management-assessment .unnumbered}

Detector upgrades are well within the experience and expertise of the
CDF collaboration. Every effort has been made to specify these projects
in a manner that reduces the level of risk to an acceptably low level.
Several steps will be taken to assure that the risk to this project is
low.

##################### 9.1 Technical Risk {#technical-risk .unnumbered}

Preparation of clear and concise specifications, judicious determination
of subcontractor responsibility and approval of proposed lower tier
sub-subcontractors, and implementation of QA provisions will minimize
technical risk. Projects have been designed to further minimize
technical risk by exploiting previous experience to the greatest extent
possible, and minimizing exposure to single vendor failures.

Making deliberately conservative design choices has minimized
technically risky elements of the silicon detector. Use of single sided
sensors, reduction in component variety, and common integrated circuit
technologies will reduce risk.

##################### 9.2 Cost Risk {#cost-risk .unnumbered}

Use of fixed-price subcontracts and competition will be maximized to
reduce cost risk.

##################### 9.3 Schedule Risk {#schedule-risk .unnumbered}

Schedule risk will be minimized via:

-   Realistic planning,

-   Verification of subcontractor's credit and capacity during
    evaluation,

-   Close surveillance of subcontractor performance,

-   Advance expediting, and

-   Incremental awards to multiple subcontractors when necessary to
    assure total quantity or required delivery.

Incentive subcontracts, such as fixed-price with incentive, will be
considered when a reasonably firm basis for pricing does not exist or
the nature of the requirement is such that the subcontractor's
assumption of a degree of cost risk will provide a positive profit
incentive for effective cost and/or schedule control and performance.

##################### 9.4 Risk Analysis {#risk-analysis .unnumbered}

Risk to the project will be evaluated by following a method outlined in
A Guide to the Project Management Body of Knowledge. Two risk related
quantities are estimated for each significant element of the project, an
impact factor, and a risk probability. The impact factors are described
in Table 9.1.

**Table 9.1 Evaluating Impact of a Risk on Major Project Objectives**

+------------+----------+----------+----------+----------+----------+
|            | **Very   | **Low    | **       | **High   | **Very   |
|            | Low      | Risk**   | Moderate | Risk**   | High     |
|            | Risk**   |          | Risk**   |          | Risk**   |
|            |          | **0.1**  |          | **0.4**  |          |
|            | **0.05** |          | **0.2**  |          | **0.8**  |
+------------+----------+----------+----------+----------+----------+
| **Cost     | Insig    | \< 5%    | 5-10%    | 10-20%   | \> 20%   |
| O          | nificant | Cost     | Cost     | Cost     | Cost     |
| bjective** | cost     | increase | increase | increase | increase |
|            | increase |          |          |          |          |
+------------+----------+----------+----------+----------+----------+
| **Schedule | Insig    | Schedule | Overall  | Overall  | Overall  |
| O          | nificant | slippage | Project  | Project  | Project  |
| bjective** | schedule | \< 5%    | slippage | slippage | slippage |
|            | slippage |          | 5‑10%    | 10‑20%   | \> 20%   |
+------------+----------+----------+----------+----------+----------+
| **Scope    | Scope    | Minor    | Major    | Project  | Scope of |
| O          | decrease | areas of | areas of | scope    | project  |
| bjective** | barely   | scope    | scope    | r        | eff      |
|            | no       | affected | affected | eduction | ectively |
|            | ticeable |          |          | unac     | useless  |
|            |          |          |          | ceptable | for      |
|            |          |          |          | for      | mission  |
|            |          |          |          | physics  |          |
|            |          |          |          | ob       |          |
|            |          |          |          | jectives |          |
+------------+----------+----------+----------+----------+----------+
| *          | T        | T        | T        | Deg      | T        |
| *Technical | echnical | echnical | echnical | radation | echnical |
| O          | deg      | per      | per      | of       | per      |
| bjective** | radation | formance | formance | t        | formance |
|            | of       | of final | of final | echnical | of end   |
|            | project  | product  | product  | per      | item     |
|            | barely   | m        | mo       | formance | eff      |
|            | no       | inimally | derately | unac     | ectively |
|            | ticeable | affected | affected | ceptable | useless  |
|            |          |          |          | for      | for      |
|            |          |          |          | physics  | mission  |
|            |          |          |          | ob       |          |
|            |          |          |          | jectives |          |
+------------+----------+----------+----------+----------+----------+

# Table 9.1 Evaluating Impact of a Risk on Major Project Objectives

For each item within the project, an estimate will be made on the nature
of the risk this item presents to the project as a whole. The impact for
each of the four categories given in Table 9.1 will be considered. The
probability of occurrence (cost overrun, schedule slippage, etc.) will
also be estimated. The product of these two quantities will is the risk
factor. Mitigation strategies will be considered for any moderate or
high risk items in the project, currently estimated as a risk factor of
0.15 or greater.

########### 10. PROJECT CONTROLS SYSTEM {#project-controls-system .unnumbered}

This section summarizes the management systems that the CDF Run IIb
Project Manager will use to manage the cost and schedule performance and
the technical accomplishments of the Project. The significant interfaces
that exist among the various management systems are noted in the
individual narrative descriptions below. Although these systems are
described separately they are mutually supportive and are employed in an
integrated manner to achieve the project objectives. As conditions
change during the evolution of the project, the management systems will
be modified appropriately so as to remain responsive to the needs for
project control and reporting. Consequently, while the policy and
objectives of each management system will remain fixed, the methods,
techniques, and procedures that will be employed by the Run IIb CDF
Detector Project may change as conditions dictate, over the life of the
project.

The work authorization and Contingency Management System and the Project
Control System described in this chapter constitute the required
management and control procedures.

##################### 10.1 Guidelines and Policies {#guidelines-and-policies .unnumbered}

The Contingency Management System and the Project Control System
employed by the Run IIb CDF Detector Project will be consistent with the
Fermilab "Project Control System Guidelines", dated May 1, 1994.

The following policies are applicable for the CDF Run IIb:

-   All Project work is organized in accordance with the Work Breakdown
    Structure.

-   Formal (and informal) reviews by experts are used to obtain
    specifications and designs.

-   Established cost, schedule, and technical baselines are used for
    measuring project performance. The technical baseline for the
    project is described in the Technical Design for each system
    included in the scope of the upgrade project.

-   Changes to the approved cost, schedule, and technical baselines
    proceed via a Change Request (CR) process described below.

-   A project management system, which features performance measurement
    and critical-path scheduling, is used to control the project and to
    provide forecast and feedback information to management.

-   The decision-making apparatus employs regular meetings among the Run
    IIb CDF Detector Project organizational elements. These meetings
    serve to identify and resolve interface issues within the project.

-   Quality assurance, safety analysis and review, and environmental
    assessment are integral parts of the Work Authorization and Project
    Control.

##################### 10.2 Work Authorization and Contingency Management {#work-authorization-and-contingency-management .unnumbered}

The Director will make funds available to the Run IIb CDF Detector
Project on an annual basis following the receipt of the Initial
Financial Plan from DOE. These funds will correspond to a financial plan
and a funding profile to project completion as determined by the
Director. The funding profile will include contingency in each year of
the project.

Cost accounting will follow the WBS structure. The accumulation of M&S
costs will be initiated through purchase requisitions originating with
the engineering and scientific staff assigned to the various
sub-systems. Signature authority levels will be provided to the Fermilab
Business Services Section by the CDF Run IIb Project Manager to assure
that only authorized work is initiated. Labor costs are also tracked but
at a higher level of the WBS.

At any time the project contingency is the difference between the
project Total Project Cost (TPC) and the sum of the current Estimates at
Completion (EAC) at level 2 of the WBS. The Project Manager will hold
the contingency and allocate it subject to the project change control
described below.

The principles of contingency management that the Run IIb CDF Detector
Project will follow are as follows:

-   The cost estimate for each sub-system will include contingency funds
    based on an assessment by the preparer of uncertainties and risks
    associated with the budgeted cost.

-   The actual expenditure of contingency will be reflected in a new EAC
    to be updated every 3 months.

-   Contingency funds are allocated as needed throughout the year,
    within the following guidelines:

    -   The PM may adjust the estimated cost of any WBS level 2
        subproject by as much as \$100K, as long as the Project TEC is
        not exceeded. If the estimated costs of any WBS level 2
        subproject increase by more than \$100K, a change request shall
        be submitted, as described in Section 10.5.2 (In-Scope Changes)
        below.

    -   Use of contingency above the amount budgeted for the year
        requires approval of a change request.

    -   Any unused contingency can be used to fund tasks scheduled for
        subsequent years.

##################### 10.3 Baseline Development {#baseline-development .unnumbered}

Baseline Development includes management actions necessary to define
project scope and responsibilities, establish baselines, and plan the
project. Each upgrade subproject prepares a formal cost estimate and
schedule. These are included in the CDF Run IIb Cost and Schedule Plan.
The subprojects all have defined Work Breakdown Structures (WBS) which
are detailed subsets of the WBS presented in Figure 4.1 of this
document. In addition, technical specifications for each subproject are
contained in the CDF Run IIb Detector Technical Design Report.

##################### 10.4 Project Performance Measurement {#project-performance-measurement .unnumbered}

Project Performance includes management actions after work commences
that are necessary to monitor project status, report and analyze
performance and available resources, and manage risk. Project
performance aspects of the Project Control System consist of the
following:

############################### 10.4.1 Funds Management  {#funds-management .unnumbered}

The cost plan for the project is based on the Laboratory's funding
profile. This plan reflects the best estimate of funding levels and the
baseline schedule. Changes in the Laboratory funding profile may affect
the overall cost and schedule for the project. Each year, subproject
budgets are set based on the current funding profile guidance. The
Project Manager and Project Leaders adjust the resource-loaded schedule
so that the available funding is distributed optimally balancing cost
and schedule considerations.

############################### 10.4.2 Accounting {#accounting .unnumbered}

The actual cost of the project is captured in the Laboratory's General
Ledger and is tracked by the Work Breakdown Structure. Summary and
detailed cost reports are prepared each month by the Project Management.
Monthly reports of costs and obligations for capital equipment funds are
submitted to Laboratory management and the Department of Energy through
the Laboratory Financial Information System and the Cost Budget Report
prepared by the Laboratory accounting department. Information for the
Run IIb CDF Detector Project is reported by Budget and Reporting (B&R)
Code and by Budget Reference Number (BRN).

############################### 10.4.3 Performance Measurement and Analysis {#performance-measurement-and-analysis .unnumbered}

The principal functions of performance measurement and analysis are to
identify, quantify, analyze, evaluate and rectify significant deviation
from the baseline plan as early as possible.

############################### 10.4.4 Schedule Variance {#schedule-variance .unnumbered}

At the end of each month, the milestone list and critical path tasks
will be evaluated to identify deviations from the baseline schedule. Any
deviations that have a significant impact on the project, either by
delaying completion or by affecting the cost or labor plan of the
project will be identified. A plan to rectify any delays will be
developed and may include either alteration of the project schedule to
optimize work and reduce delay or allocation of additional resources to
shorten the time required to perform the tasks involved.

Any change that would alter the schedule, cost or required labor
resources will be subject to change control as described in this plan.

############################### 10.4.5 Cost Variance {#cost-variance .unnumbered}

Monthly cost variance will be determined by comparing the actual cost of
work performed at WBS level 2 with the budgeted cost of work performed
as represented in the current EAC. Cost variances that exceed the
established thresholds are formally reported as required in this plan.

############################### 10.4.6 Resource Variance {#resource-variance .unnumbered}

A monthly analysis of the resources available (labor and funds) will be
performed to ensure that shortfalls in either which could lead to
schedule and/or cost variances are identified in a timely manner and
brought to the attention of the PMG.

##################### 10.5 Change Control {#change-control .unnumbered}

Change Management includes management actions necessary to ensure
adequate control of project baselines, including the performance
measurement baseline. Documentation of the changes and their impacts are
recorded as part of the Configuration Management Program found in
Appendix D. Change Management aspects of the Project Control System
consists of the following:

############################### 10.5.1 Out-of-Scope Changes {#out-of-scope-changes .unnumbered}

An Out-of-Scope Change is a proposed change to the Run IIb CDF Detector
Project that would alter the physics capabilities of the detector in a
major way or introduce a new detector system. This will include any
change to the project for subsystems whose scope has not been completely
specified. Any change to the Run IIb CDF Detector Project outside the
Laboratory approved scope must be initiated by a formal proposal to the
Director for consideration. The scope of the project includes the
design, construction, and installation of the collection of systems or
improvements to systems, proposed to the Laboratory for approval as part
of the Run IIb CDF Detector Project, that have been granted Stage I
approval by the Director. The initial scope of the project is described
in the TDR.

The procedure for Out-of-Scope changes is described schematically in
Figure 10.1. An Out-of-Scope Change begins with a CDF note and
presentation at a CDF Run IIb meeting. The Project Manager who, in
general, will seek advice from the Project Leaders and other technical
experts, reviews the proposed change. The PM may also seek advice from a
CDF Godparent committee or Internal Review Committee. The PM may request
that the proponents of the Change prepare an Impact Statement that
identifies the Performance, Cost, and Schedule impact of the proposed
Change. Following the Project Manager's review of the proposed change
the PM makes a recommendation to the CDF Executive Board. If the
recommendation of the PM is to proceed with the change and the Executive
Board ratifies the recommendation, the proposed change, including the
effect on the CSP, is presented to the CDF Project Management Group.

In response to an Out-of-Scope change proposal the Fermilab Director may
seek the advice of Fermilab's Physics Advisory Committee, the CDF PMG or
a Director\'s review. The proposed change can be granted Stage I
approval; deferred for further clarification of the physics potential,
technique, cost and/or schedule; or it may be rejected.

############################### 10.5.2 In-Scope Changes {#in-scope-changes .unnumbered}

Any change to the Run IIb CDF Detector Project that does not alter the
Scope of the Project as defined in 10.5.1 above does not require a new
proposal to be submitted to the Laboratory. Although the scope of the
project is not affected, changes resulting in cost variations, changes
of personnel assignments, or schedule impact are considered In-Scope
Changes. Table 8.1 summarizes In-Scope Change control thresholds and
responsibilities. All changes from baseline cost shall be traceable.
Each In-Scope Changes must have the approval of the CDF Run IIb Project
Manager before Contingency Funds are authorized and allocated to cover
the changes. The CDF Run IIb Project Manager is responsible to maintain
a record of all Change Requests and all records of the Run IIb CDF
Detector Project documentation revision status.

The CDF PMG functions as the Change Control Board for the project. The
Directorate will maintain the records of CDF Run IIb Project Management
Group meetings. In-Scope Changes that result in increases above the
following thresholds will require the approval of the Deputy Director
and/or Director and must be initiated by a Change Request (CR) form.
Each of these requests must be presented at the CDF PMG. Thresholds for
these requests listed below and in Table 8-1:

-   Any increases to the CDF Run IIb Project Estimate at Completion

-   Increases in any level 2 WBS element greater than \$100,000

-   Any increase of Fermilab personnel resources by 10% for any level 2
    system above that indicated by Cost and Schedule Plan

In-Scope Changes that result in a schedule change such that the Baseline
Schedule Objectives for project completion cannot be met must be
reported to the Director. Any proposal that results in a change of a
milestone held by the Director or DOE shall be submitted for approval to
the CDF PMG via the Change Request process and reported to the Director.
The response to such a CR may be to initiate plans to reallocate
resources to recover the schedule, to stage or descope the detector, or
to revise project Schedule Objectives.

![](media/image3.wmf)

##################### 6.56.5610.6 Information and Reporting {#information-and-reporting .unnumbered}

############################### 10.6.1 Project Meetings {#project-meetings .unnumbered}

The Run IIb CDF Detector Project group leaders meet every two weeks to
discuss progress on upgrades and issues of interest across subsystem
boundaries. There is a general upgrade collaboration meeting held
weekly. Minutes of these meetings are kept. The Project Management Group
also meets bi-weekly. Progress on upgrades is presented to the
collaboration at collaboration meetings four times per year. The
individual upgrade projects all have meetings of their own, typically
weekly. Additional meetings will be scheduled as needed.

############################### 10.6.2 Reporting {#reporting .unnumbered}

Project leaders review their schedules monthly. This includes an
assessment of task scheduling and estimated costs. Updated
resource-loaded schedules are submitted by the PL's to the PM. The
Project Manager prepares monthly progress reports to the Director
including a brief narrative technical section and a consolidation of the
subproject cost and schedule status. CDF Run IIb monthly progress
reports will be submitted to the DOE Run II Project Manager by the
Fermilab Directorate.

Run IIb CDF Detector Project subsystem leaders give status reports about
once a month at the collaboration upgrade meeting. Copies of
transparencies presented at these meetings provide a written record of
subproject progress on this time scale. Minutes are also kept for these
meetings. Quarterly written progress reports are submitted to the PM by
the PL. These narratives contain a description of technical progress
that is more detailed than that submitted monthly.

Progress on the Run IIb CDF Detector Project is reported to the Fermilab
Directorate and DOE Project Manager via presentations to the PMG,
director's reviews, and Physics Advisory Committee. Subsequent progress
on the upgrade project will be reported at periodic DOE reviews. The DOE
also provides representatives to the Fermilab PAC meetings.

########### 11. ACQUISITION STRATEGY PLAN  {#acquisition-strategy-plan .unnumbered}

The acquisition strategy is discussed in a separate document:
"Acquisition Execution Plan \[for\] Run IIb CDF Detector Project and Run
IIb D-Zero Detector Project at Fermi National Accelerator Laboratory".

########### 12. ALTERNATE TRADEOFFS {#alternate-tradeoffs .unnumbered}

##################### 12.1 Silicon alternatives {#silicon-alternatives .unnumbered}

Single sided silicon strip detectors will be used in the silicon
project. Early considerations for this detector included silicon pixel
detectors, but those were rejected as being an immature technology,
considering our schedule requirements. Silicon strip detectors are the
only other technology we can consider that will meet our specifications
for performance and radiation resistance. Several variations of the
silicon detector layout have been considered. The detector described in
the Technical Design Report is a compromise between performance and
cost.

##################### 12.2 Central Preradiator Alternatives {#central-preradiator-alternatives .unnumbered}

Scintillator was the only technology considered for the preradiator,
since it will meet the specifications at a reasonable cost. Various
methods of light collection have been studied, and the final design is
based on an optimization, balancing performance and cost.

########### 13. TECHNICAL CONSIDERATIONS {#technical-considerations .unnumbered}

Technical considerations are presented and examined in detail as part of
the Technical Design Report (TDR). A brief summary of the research and
development considerations is presented below as well as the approach
and responsibility for assurance of quality.

##################### 13.1 Technical Reviews and Documentation {#technical-reviews-and-documentation .unnumbered}

The collaboration, through internal reviews and godparent committees,
evaluates the plans for the upgraded detectors. Periodic reports on
prototype and pre-production devices as well as computer-simulated
performance of the final detectors are critically examined to assure
that the upgraded detector will meet the CDF physics goals.

The planned detector upgrades and their performance are documented in
the TDR. This document is controlled as part of the Configuration
Management Program (Appendix D) and defines the baseline upgraded CDF
detector. The TDR is reviewed by the Fermilab Physics Advisory Committee
and by the Department of Energy as part of establishing the baseline
cost and schedule for the upgrades. Work plans and MOU's, which specify
how the work will be carried out and include responsibilities for
testing and documentation, are written and agreed to by participating
entities. QA documentation is considered one of the deliverables for
project components whether built at Fermilab or at other institutions.

##################### 13.2 Research and Development {#research-and-development .unnumbered}

Subsystems and their components are designed to meet the requirements
outlined in the TDR. Research and development is performed on detector
components to ensure that the chosen technology will meet the physics
and engineering requirements of the detector and will achieve the
technical and reliability requirements needed for operation at the
upgraded Tevatron. Designs are documented in design reports and drawings
are checked by peers, senior engineers, and/or managers. Design reviews
are performed as outlined in Section 6. Design reports, specifications,
drawings and other documentation will be delivered to Fermilab to ensure
that detector components can be supported and maintained.

##################### 13.3 Quality Assurance and Tests {#quality-assurance-and-tests .unnumbered}

Quality Assurance and Quality Control (QA/QC) systems are designed, as
part of the Quality Management Program, to ensure that the components of
the detector meet the design specifications and operate within the
parameters mandated by the requirements of the High Energy Physics
Program. The Quality Management Program can be found in Appendix C of
this document. The QA/QC elements currently in place for the Run IIb CDF
Detector Project draw heavily on the experience gained from past
detector construction projects. Senior management recognizes that prompt
identification and documentation of deficiencies, coupled with the
identification and correction of the root causes, are key aspects of any
effective QA/QC Program. The Project Manager endorses and promotes an
environment in which all personnel are expected to identify
nonconforming items or activities and potential areas for improvement.

Detector components are fabricated specifically for CDF by either
commercial vendors, other Department of Energy Laboratories, member
universities within the CDF Collaboration, Fermilab owned facilities, or
some combination of the above. The items manufactured may be individual
components, detector sub-assemblies, or a complete piece of upgraded
equipment being installed as part of the Project. One example of a
complete assembly would be the Electromagnetic Timing Project, or EM
Timing, supplied by Italy and Texas A&M University. It is the
responsibility of the Project Manager and/or Project Leaders to have
adequate verification methods in place to assure that only properly
trained, qualified, and certified personnel are involved in the design,
manufacture, and installation of detector components.

All components must be fabricated to pre-determined design
specifications that will allow them to operate properly when integrated
into the total system. Agreements are in place with each vendor that
explicitly state the operating parameters of the piece or pieces they
construct. These agreements also assign the responsibilities for testing
and verification of the final product. Procured items must meet
established requirements and perform as specified. In some cases, random
testing of a certain percentage of components will be performed and
documented by an independent organization. One example of this approach
for the more specialized and expensive components is the Tsukuba
verification of the Hamamatsu sensor specifications. In the event that
non-conforming items are discovered, they will be documented and
controlled to preclude inappropriate use until compliance with the
applicable technical requirements is demonstrated. Vendor qualifications
are reviewed as part of the bid process and are taken into consideration
prior to bids being awarded. Vendor site visits may be conducted
periodically throughout the duration of the fabrication contracts to
ensure quality requirements are understood and being adhered to
properly.

Within Fermilab facilities, a Traveler will accompany each component
through the assembly process. These information packets are used to
identify, report, correct, and trend non-conformance situations adverse
to quality detector performance. The Travelers will contain whatever
historical information accompanies the equipment, list the specified
operating parameters, and provide a place for testing results to be
entered. The test results and certifications will then be compared to
the required specifications and a determination will be made as to the
final use or disposition of the item. It should be noted that testing
and verification for performance within proper operating parameters will
occur multiple times throughout the construction process as was the case
during past detector construction projects. This multi-tiered testing
approach will ensure that improperly installed, faulty, or failed
components are detected at the earliest possible opportunity and allow
immediate remedial action to be taken without jeopardizing or negatively
impacting detector operation.

########### 14. INTEGRATED SAFETY MANAGEMENT {#integrated-safety-management .unnumbered}

This section describes the policies for ensuring that Environmental,
Safety and Health (ES&H) considerations are adequately addressed within
the Run IIb CDF Detector Project activities. The information below
provides an overview of key issues. Policies, procedures and descriptive
information are contained in the CDF ES&H Implementation Plan. ES&H is a
line management responsibility and will be implemented down through the
sub-system organizations.

##################### 14.1 Overview {#overview .unnumbered}

Fermilab subscribes to the philosophy of Integrated Safety Management
(ISM) for all work conducted on the Fermilab site and requires its
subcontractor and sub-tier contractors to do the same. Integrated Safety
Management is a system for performing work safely and in an
environmentally responsible manner. The term "integrated" is used to
indicate that the ES&H management systems are normal and natural
elements of doing work. The intent is to integrate the management of
ES&H with the management of the other primary elements of work: quality,
cost, and schedule. The seven principles of ISM are as follows:

(1) Line Management Responsibility for Safety: Line management is
    responsible and accountable for the protection of the employees, the
    public and the environment.

(2) Clear Roles and Responsibilities: The roles and responsibilities,
    and authority at all levels of the organization, including potential
    sub-tier contractors are clearly identified.

(3) Competence Commensurate with Responsibility: Personnel possess the
    experience, knowledge, skills and abilities that are necessary to
    discharge their responsibilities.

(4) Balanced Priorities: Resources are effectively allocated to address
    safety, programmatic and operational considerations. Protecting the
    public, the workers and the environment shall be a priority whenever
    activities are planned and performed.

(5) Identification of Safety Standards and Requirements: Before work is
    performed, the associated hazards are evaluated and an agreed upon
    set of safety standards and requirements are established which will
    provide adequate assurance that the public, the workers and the
    environment are protected from adverse consequences.

(6) Hazard Controls Tailored to Work Being Performed: Administrative and
    engineering controls, tailored to the work being performed, are
    present to prevent and mitigate hazards.

(7) Operations Authorization: The conditions and requirements to be
    satisfied for operations to be initiated and conducted are clearly
    established and understood by all.

The ES&H program at CDF is intended to ensure that all relevant and
necessary actions are taken to provide a safe working environment at
FNAL for the design, construction, installation, test, operation and
decommissioning of the CDF detector. The CDF detector was designated a
Low Hazard Radiological Facility and the Safety Envelope was approved in
1995. The Directorate, advised by the ES&H Section, will determine the
need for updates or addenda to the CDF Safety Assessment Document.

##################### 14.2 Objectives {#objectives .unnumbered}

The following general objectives have been established by FNAL for the
ES&H program for detectors:

-   Establish and administer an ES&H program that promotes the
    accomplishment of FNAL ES&H objectives for employees and
    non-employees.

-   Protect the general public and the environment from harm.

-   Comply with federal, state and local laws, rules and regulations.

-   Prevent personnel injury or loss of life during detector-related
    work.

-   Prevent damage to equipment caused by accidents during
    detector-related work.

-   Prevent any environmental contamination during detector development,
    fabrication, commissioning and operation.

##################### 14.3 Organization and Responsibilities; {#organization-and-responsibilities .unnumbered}

The ES&H program for the entire Run IIb CDF Detector Project is the
responsibility of the CDF Run IIb PM. The CDF PM and his designees are
responsible for establishing policies and requirements for ES&H during
development and commissioning of the detector, and related experimental
systems.

The CDF PM has the responsibility for identifying specific ES&H issues
and risks, and for ensuring that PL's establish appropriate safeguards
and procedures for addressing those risks for each subproject. The PM is
responsible for ensuring that CDF Safety documentation is adequate for
operating the upgraded detector. The PM and the appointed Project
Leaders are the laboratory line management on matters of environment,
safety, and health for both the CDF Project and for operations aspects
of the upgraded detector. The resources of the Particle Physics Division
ES&H Department are also available to the Project Manager and Project
Leaders upon request. Ad hoc review committees, reporting directly to
the PPD Head, will be assigned as appropriate.

##################### 14.4 Documentation and Training {#documentation-and-training .unnumbered}

The CDF PM is responsible for providing, as required, specific
requirements and procedures, as well as hazard assessments, and other
documents to comply with DOE and FNAL requirements. CDF ES&H documents
are defined in the CDF Operations Guidelines Manual.

Those who are on the CDF project at the FNAL site will be provided with
the training and information necessary to reduce the risks associated
with their work and to ensure their safety. Briefings and presentations
will be made to all managers and supervisors to communicate ES&H
policies, documentation and information associated with assuring safety
of CDF activities. Job-specific training will be provided on issues
including electrical safety, cryogenic safety, radiation safety and
chemical safety, as well as issues related to detector transportation,
installation and testing activities. Proficiency testing is performed to
gauge comprehension.

All visitors to CDF will be informed of FNAL ES&H rules and procedures
applicable to their visit. In general, visitors will not be allowed to
work in areas without the advance permission of the CDF Project Manager
or his/her designee. All visitors to CDF must be accompanied by a Host
who is familiar with FNAL and CDF ES&H rules and procedures. Hosts are
responsible for the safety of the visitors they accompany.

########### APPENDIX A: List of Referenced Documents {#appendix-a-list-of-referenced-documents .unnumbered}

CDF Run IIb Detector Technical Design Report

CDF Run IIb Cost and Schedule Plan

CDF Memoranda of Understanding and Work plans for each sub-project

Justification of Mission Need

Fermilab Project Control Systems Guidelines, May 1, 1994.

Acquisition Execution Plan \[for\] Run IIb CDF Detector Project and Run
IIb D-Zero Detector Project at Fermi National Accelerator Laboratory

DOE Project Execution Plan for Run IIb CDF Detector Project and D-Zero
Detector Project at Fermi National Accelerator Laboratory

Fermilab Environment, Safety, & Health Manual

A Guide to the Project Management Body of Knowledge, ©2000 Project
Management Institute

###########  APPENDIX B: List of Schedule Milestones {#appendix-b-list-of-schedule-milestones .unnumbered}

The table below lists the Level 2 milestones from the resource loaded
schedules. Level 0 and 1 milestones are contained in table 7.4 of the
PEP.

  ---------------- ----------- -------------------------------------------- -----------
  **WBS**          **Level**   **Title**                                    **Date**

  1.1.5.4.1.13     2           L2MS Prototype stave #1 complete             5-Dec-02

  1.1.2.1.2.4      2           L2MS 2nd chip submission                     20-Feb-03

  1.1.2.10.2.4     2           L2MS Testing #1 complete- go ahead for #2    3-Apr-03

  1.2.2.2.7.4      2           ASD-\>TDC Cables ready for installation      4-Apr-03

  1.3.3.2.3.4      2           Fabrication of Prototype Finder 1/3 board    9-Apr-03

  1.2.2.2.7.2      2           CEM Splitters ready for installation         11-Apr-03

  1.2.1.10.1       2           First phototube order placed                 9-May-03

  1.2.2.2.7.1      2           Prototype Testing Complete                   15-May-03

  1.1.3.1.2.4      2           Production Sensor submission                 16-May-03

  1.3.3.8.1.9      2           Prototype Linker Module available for        9-Jun-03
                               testing                                      

  1.2.2.2.7.3      2           PEM Harnesses ready for installation         2-Sep-03

  1.2.2.2.7.5      2           All cables done and ready for installation   2-Sep-03

  1.1.2.1.3.5      2           L2MS Production chip submission              9-Sep-03

  1.3.5.2.5        2           arrival of 0/10 PCs from the vendor          10-Sep-03

  1.2.1.10.2       2           1st WLS fiber holder finished                7-Oct-03

  1.2.2.2.7.8      2           VME Crate ready for installation             7-Oct-03

  1.1.2.10.3.4     2           L2MS Go ahead for Preproduction              11-Nov-03

  1.3.1.6.7        2           First Prototype TDC available for testing    19-Nov-03

  1.1.6.3.1.1.5    2           Milestone: all tests of stave installation,  5-Dec-03
                               screen mounting, complete                    

  1.2.1.10.4       2           1st CPR module finished and tested           11-Dec-03

  1.2.2.2.7.10     2           Upstairs components ready for installation   7-Jan-04

  1.2.2.2.7.11     2           All EMTiming components ready for            7-Jan-04
                               installation                                 

  1.2.2.2.7.6      2           ASD/TB ready for installation                7-Jan-04

  1.2.2.2.7.7      2           Downstairs components ready for installation 7-Jan-04

  1.2.2.2.7.9      2           TDC boards ready for installation            7-Jan-04

  1.2.1.10.3       2           First set of phototubes tested               30-Jan-04

  1.2.1.10.6       2           1st CCR module finished and tested           12-Feb-04

  1.1.2.3.1.3.12   2           L2MS preProduction hybrid available          25-Mar-04

  1.2.1.10.5       2           Second set of phototubes tested              21-May-04
  ---------------- ----------- -------------------------------------------- -----------

Milestone table continued:

  ---------------- ----------- -------------------------------------------- -----------
  **WBS**          **Level**   **Title**                                    **Date**

  1.1.5.2.2.8      2           L2MS L0 prototype modules complete           26-May-04

  1.3.4.4.1.4      2           arrival of the hardware                      3-Jun-04

  1.2.1.10.7       2           50% CPR Detectors Tested                     4-Jun-04

  1.3.3.10.3.3     2           Begin Preproduction Stereo Association       21-Jun-04
                               Modules                                      

  1.3.4.5.3        2           Production Readiness Review - Event Builder  24-Jun-04

  1.1.2.10.4.6     2           L2MS Goahead for DAQ production              19-Jul-04

  1.2.1.10.8       2           50% CCR Detectors Tested                     30-Aug-04

  1.3.2.6.3        2           Begin production of Level2 Pulsar system     16-Sep-04

  1.3.3.2.6.9      2           Begin Production Finder SL7 boards           12-Oct-04

  1.1.2.3.1.4.9    2           L2MS Production hybrid available             9-Nov-04

  1.3.3.8.3.3      2           Begin Production Linker Modules              13-Dec-04

  1.3.6.5          2           SVT ready for installation                   13-Dec-04

  1.1.5.3.4.8      2           L2MS Production module available             5-Jan-05

  1.3.1.12         2           Beginning of TDC Production                  10-Jan-05

  1.3.4.5.4.4      2           arrival of the hardware                      3-Feb-05

  1.2.1.10.10      2           Final CCR Detector Tested                    24-Mar-05

  1.2.1.10.9       2           Final CPR Detector Tested                    24-Mar-05

  1.3.5.5.5        2           arrival of 70 Level3 and 15 DAQ PCs from the 24-Mar-05
                               vendor                                       

  1.3.5.6.5        2           arrival of 140/20 PCs from the vendor        24-Mar-05

  1.3.5.8          2           Finish Purchase of Computers for Level3/DAQ  14-Apr-05
                               system                                       

  1.1.6.1.11.3.5   2           L0 Supports Complete                         5-May-05

  1.3.4.8          2           Finish Event-Builder Upgrade                 5-May-05

  1.2.1.10.11      2           Final set of phototubes tested               6-May-05

  1.2.1.10.12      2           End of Central Preshower Project             6-May-05

  1.2.3.5          2           End of Calorimetry Project: Level 2          6-May-05

  1.1.5.4.4.11     2           L2MS 100 Production staves complete          26-May-05

  1.3.1.14.16      2           Data Concentrator Production Completed       2-Jun-05

  1.3.2.9          2           Pulsar Level 2 subproject ready for          8-Jun-05
                               installation                                 

  1.1.6.3.1.3.3    2           L2MS Stave Installation Begins               24-Jun-05

  1.3.3.10.4.6     2           Production Stereo Association Modules        6-Jul-05
                               complete                                     

  1.3.3.23         2           XFT Ready for Installation at CDF            6-Jul-05

  1.3.1.13.10      2           Production Board testing complete            30-Sep-05

  1.3.1.16         2           Run 2b TDC Ready for Installation            30-Sep-05

  1.3.8            2           Finish Run 2b Trigger DAQ project            30-Sep-05

  1.1.5.4.4.14     2           L2MS Production staves complete              18-Oct-05

  1.1.6.3.1.3.8    2           L2MS Stave Installation Complete             8-Dec-05

  1.1.6.3.2.3.6    2           L2MS Inner detector complete                 4-Jan-06

  1.1.6.3.1.3.16   2           Outer detector complete                      23-Feb-06

  1.1.6.4.8        2           L2MS SVX2b Ready for Installation into ISL   31-May-06
  ---------------- ----------- -------------------------------------------- -----------

###########   {#section-4 .unnumbered}

########### APPENDIX C: Quality Management Program {#appendix-c-quality-management-program .unnumbered}

1\. PROGRAM

1.1 Run IIb CDF Detector Project Mission

The mission of the Fermilab Run IIb CDF Detector Project is to support
the Fermilab High Energy Physics (HEP) research program by constructing
a new detector for use at CDF during Run IIb. The Directorate approves
HEP experiments and allocates funds to provide the facilities,
personnel, and equipment required to achieve successful completion of
this mission. The Run IIb CDF Detector Project Office is responsible for
ensuring the quality of the support mechanisms, all FNAL fabricated
items, and non-FNAL supplied items that may have either an operational
impact or an Environmental, Safety, and Health (ES&H) impact. This
responsibility includes assuring proper integration of the new detector
into the existing experiment infrastructure as well as establishing and
enforcing Department of Energy (DOE) requirements. The Project Manager
must ensure that the Project structure and organization are appropriate
for effectively carrying out this mission.

1.2 Organization

The Run IIb CDF Detector Project is composed of the Project Management
Office and four main working groups. These four working groups are
organized according to the Work Breakdown Structure (WBS) assigned to
the Project and are listed in the main body of the CDF Project
Management Plan (PMP) and an organization chart is maintained by the
Project Manager. General descriptions of the primary functions for the
groups are also found in the Project Management Plan. Level 2 Managers
set QA goals and objectives pertaining to their work environments and
periodically assess progress toward them.

1.3 Roles, Responsibilities, and Authorities (RRA's) for Quality

RRA's for Quality flow down through the Project as outlined in the
Fermilab Quality Assurance Policy, Section 10 of the *Director's Policy
Manual.* The Project Manager assigns the QA/QC function to the
appropriate manager for the Run IIb CDF Detector Project. Stop Work
Authority related to quality of work has been delegated to all
management and supervisory personnel within the Project. They are
authorized and expected to halt unsatisfactory work being performed by
any of the individuals or organizations reporting to them. The Division
Head and Project Manager may specify other stop work authority outside
of the normal management chain at their discretion.

2\. PERSONNEL TRAINING AND QUALIFICATION

2.1 Scope

The Project supports Fermilab efforts with respect to personnel training
and qualification, and believes that maintaining a trained and qualified
work force is instrumental in ensuring the quality of products and
services provided by the Project. This section describes the
responsibilities and requirements necessary to provide the Project with
qualified personnel who possess the appropriate level of skill,
experience, and academic qualifications to support the achievement of
the Project mission and performance objectives.

The Project Manager requires that all Project personnel be trained and
have the appropriate experience to ensure that they are capable of
performing their assigned work in a safe and efficient manner. This
training must reflect the fact that the Project's scope of work involves
the collaborative effort of personnel who have widely divergent levels
of education, skills, and experience*.*

2.2 Education and Qualifications

Line management will ensure that assigned personnel have the appropriate
level of qualifications. Qualifications may be job related experience or
skills; technical and/or professional society certifications; formal
education; or any combination thereof.

The education that is required for obtaining a university/college degree
(or other professional certification) constitutes qualification for
working within the discipline in which the degree was granted.
Equivalent work experience and technical activity in a related
discipline may also constitute acceptable qualifications.

2.3 Specific Job Related Training

When it is determined that an employee needs specific job related
training in order to effectively and efficiently carry out duties that
are assigned, training will be made available to the employee. In-house
training will be provided to ensure that an appropriate level of skills,
knowledge, expertise, and experience are available to accomplish stated
mission and objectives. Training may come from several sources such as
mentoring, or be provided by physicists, engineers, supervisors, lead
personnel, consulting firms, QA personnel, ES&H personnel, and/or other
sources.

In order to ensure that training skills are maintained at an appropriate
level, an Individual Training Needs Assessment (ITNA) is required for
each employee on an annual basis or whenever a change in job assignment
and/or job hazards occurs. The annual training needs assessment shall be
performed and reviewed with each employee in conjunction with the
Fermilab Employee Performance Review process. This shall include a
review of employee training needs with respect to the work the employee
is expected to perform or hazards to which the employee would be exposed
during the normal performance of the assigned job.

Managers are chosen for their technical and communication skills. The
Project does not specify any further training or education for these
personnel beyond what they initially bring to their positions. However,
the Project Manager may also require further technical training for key
personnel.

Supervisors within the support groups outside of the Project are chosen
by their Department Heads. Supervisory positions include Deputy
Department Heads and Group Leaders. These personnel are selected
primarily for their technical abilities. If deemed useful by the
Department Head, an individual supervisor may be required to attend the
Supervisory Development course taught by Laboratory Services Section
(LSS). The Department Head may also require additional training or
education, oriented toward development of technical and/or supervisory
skills, but there are no generally applicable requirements mandated by
the Project.

3\. QUALITY IMPROVEMENT

3.1 Scope

Achieving quality is a line responsibility. The Project encourages
personnel to eliminate problems and improve performance. Managers are
encouraged to use statistical methods or other management tools to help
make the decisions necessary to improve quality for their operations.
These methods may serve as a basis for trending, for continuous quality
improvement from lessons learned, or to help foster a positive attitude
toward quality initiatives. Managers are also encouraged to document
non-conformances and identify, analyze, resolve, and follow up on
recurring problems.

The Project has a strong commitment to continuous quality improvement in
all areas and activities for which it is responsible. All levels of
personnel are encouraged to report performance problems and maintain a
\"no fault\" attitude toward individuals identifying concerns. Stop Work
Authority related to quality of work is described above in Section 1.3,
Roles, Responsibilities, and Authorities for QA. The objective is to
identify a problem, to promptly report it to the appropriate level of
management for corrective action, and for management to take the
necessary corrective action commensurate with the programmatic
significance or importance of the problem.

3.2 Identification/Reporting of Concerns and Non-conformances by
Employees

A series of regular meetings have been established to allow employees to
report and discuss performance problems. Project management has
regularly scheduled weekly meetings to assess the progress of Project
initiatives. Level 2 and 3 Managers present status reports at these
meetings and free and open discussion of concerns is encouraged. Lessons
learned are thus disseminated and are also utilized for additional
feedback concerning quality improvements. Each Project group has its own
methods for evaluating problems and performance. These include regular
meetings and discussion by appropriate supervisory and technical
personnel.

3.3 Documentation and Reporting

Quality non-conformances identified during operations, inspections, and
design reviews shall be documented as appropriate. For problems with
Fermilab-procured items and services, the Business Services Section
(BSS) Procurement Department should be provided with details regarding
non-conformances as specified below in Section 7.4, Verification of
Acceptable Quality.

Quality non-conformances for products and services procured outside of
the Fermilab system are to be reported to the Project Manager by the
appropriate Level 2 Manager. Procured items that do not meet Project
specifications must not be used. It is the responsibility of the
organization that received the items to properly segregate the material
and decide on its final disposition.

4\. DOCUMENTS AND RECORDS

4.1 Document Control

The Project determines which records require document control as part of
the Configuration Management Program. These records are controlled for
reasons of personnel safety as well as for legal and/or historical
purposes.

4.2 Records Retention and Disposition

Records produced within the Project must be retained. A disposition
schedule must be created and maintained in accordance with Fermilab
guidance. Examples are the Technical Design Report (TDRs), Project
procedures, Basis of Estimate (BoE) documents, survey results,
non-conformance reports, design drawings, QA Travellers, etc. Records
that are not forwarded to Fermilab as part of component shipments are
not subject to Fermilab requirements.

5\. WORK PROCESSES

5.1 Work Process Control

The Project Manager requires that each Level 2 and 3 Manager develop
means for analyzing work processes to determine if the work is
sufficiently complex or hazardous to be performed to written procedures.
The responsibility for determining which work processes require
procedures rests with the Department Head or Group Leader responsible
for the activity. Guidelines for performing these determinations can be
found in the Particle Physics Division Operating Manual as part of
PPD_OPER_004, Integrated Safety Management.

5.2 Maintaining an Effective and Efficient Work Force

The Project Manager requires that each Level 2 and 3 Manager strive to
maintain an effective and efficient work force. The Project attempts to
appropriately utilize personnel skills in the assignment of work
responsibilities. Ensuring that the Project successfully meets its
objectives is accomplished by assigning personnel to particular tasks
who have the appropriate skills, experience, academic qualification, or
professional certification to complete the work. The Project relies on
line management to monitor activities to successful completion and to
take necessary steps to incorporate added expertise and effort when
indicated. More detailed information is provided in Section 2.0,
Personnel Training and Qualification, above.

5.3 Measuring and Test Equipment (MTE) Calibration

The necessity for calibration and control is dependent upon the
application and criticality of the equipment. The Project Manager
requires that each Level 2 and 3 Manager analyze their work process
measuring and test equipment to determine the appropriate calibration
requirements and develop an effective program for the necessary
calibration activities.

6\. DESIGN

6.1 Scope

Equipment designed by Project personnel follows federal codes; the
*Fermilab Environment, Safety and Health Manual*; Laboratory standards;
and accepted industry standards. Relevant personnel are required to
incorporate sound engineering and scientific principles and appropriate
technical standards into designs to ensure that they will perform as
intended.

6.2 Design Interface

In some cases, the Project relies on organizations outside of Fermilab
to generate complete design packages. Examples include the EM Timing
work and the Calorimeter upgrades. Each collaborating institution agrees
to the scope of work they will undertake for the Project by means of a
Memorandum of Understanding (MOU) and specific Statement of Work (SOW).
These documents are generated and kept on file by the Project Office and
reviewed at appropriate times in order to keep them current.

6.3 Project Reviews and Operational Clearances

Hazard assessments are performed by the Project at the initial design
stages. The information from these hazard assessments is used to
determine what reviews are necessary for the experimental apparatus.
These are also used to develop the Operational Readiness Clearance (ORC)
checklists for the Project. The Project must have an ORC completed,
signed, and accepted prior to start-up.

The Project Manager may commission ad hoc technical review panels from
within the Laboratory or the CDF Collaboration to review experimental
apparatus when the need arises. The Project Manager also has the option
to request assistance from the Laboratory Safety Committee for equipment
reviews involving resources outside of the Project. Examples of this
would be cryogenic systems, hydrogen targets, flammable gas systems,
mechanical apparatus, etc.

7\. PROCUREMENT

7.1 Scope

This section describes the Project's program to ensure that procurement
practices are in accordance with established Fermilab policies.
Collaborating universities are only bound to Fermilab's procurement
requirements in cases where Fermilab actually participates in the
procurement process.

7.2 Equipment and Services Procurement

The Run IIb CDF Detector Project procurement guidelines follow the
*Fermilab Procurement Policy and Procedures Manual*. This manual,
produced and maintained by the Business Services Section, includes
instructions for the preparation of purchase requisitions and dictates
responsibility for review and approval.

The Project Manager and the Budget Analyst have established levels of
signature authority for purchase requisitions written against Project
budget codes. The Project is responsible for transmitting this
information to the Procurement Department and for monitoring proper
conformance to the pre-determined signature levels. A review by various
Project personnel may be required, depending on the dollar amount and/or
type of purchase requisition or task order.

7.3 Budget Activity and Documentation

Budget activity and change control for the Project is handled in
accordance with the approved Project Execution Plan (PEP) and Project
Management Plan. The Financial Management System (FMS) in use by
Fermilab allows individual cost codes to be established, where
necessary. The Budget Analyst has the responsibility for establishing
the proper cost codes. The FMS is also used to track and monitor such
expenses as charge-backs from other Divisions/Sections, and other
Fermilab related costs. At the successful completion of each project
phase or WBS task, the Project Manager or designated representative is
required to verify that work was performed and completed in accordance
with acceptable standards before final payment is authorized by the
Business Services Section.

7.4 Verification of Acceptable Quality

At all levels of the Project, QA of purchased material is the
responsibility of the requisitioner. Parts and equipment ordered for use
must include exact specifications where necessary. This may be achieved
by including exact specifications on the purchase requisition and/or by
using a Sole Source document. If the materials received do not meet the
specifications detailed in the original requisition, then the
requisitioner must notify Purchasing to resolve any discrepancies. If
unacceptable parts are discovered through the normal course of use,
Purchasing must be informed of the problem. Purchasing will notify the
vendor involved and bring the situation to final resolution. Departments
are encouraged to document QA non-conformances that may have a negative
impact on system performance.

8.0 INSPECTION AND ACCEPTANCE TESTING

8.1 Requirements

Contracted work, purchased equipment, or items produced in Fermilab
shops requiring formal inspection and acceptance testing must be
identified. When an inspection or acceptance test is to be performed,
the inspection techniques to be used will be defined by the testing
group. Testing requirements and techniques may be referenced in the
resource loaded schedule, a procurement contract, a Memorandum of
Understanding, or a Hazard Assessment document. Level 2 Managers are
required to identify essential safety items or systems that require
formal inspection and testing.

8.2 Documentation

Managers must ensure that the documentation for items that require
inspection and acceptance testing is maintained in accordance with the
appropriate DOE records retention schedules.

9.0 ASSESSMENT

9.1 Project Management Assessments

The Project Manager has the authority to form an ad hoc review team to
investigate quality assurance or quality control non-conformances if the
need arises. These formal reviews would be conducted and documented in
the Fermilab ES&H Database and Tracking System (ESHTRK).

9.2 Independent Assessments

The QA Program is part of the overall project implementation and is
assessed as part of the planned reviews conducted by the Directorate and
selected DOE representatives. It is the responsibility of the Project
Manager to ensure the information necessary for the review is available
and that knowledgeable personnel are available to present the material
to the review committees. The Project Manager would also be charged with
responding to findings from the independent assessments in accordance
with schedules established by the reviewing body and taking action to
correct any deficiencies identified by the independent assessments.

###########  {#section-5 .unnumbered}

########### APPENDIX D: Configuration Control Program {#appendix-d-configuration-control-program .unnumbered}

# 

1\. PURPOSE

This Configuration Management Program (CMP) describes the configuration
management (CM) responsibilities and processes that support the design
and implementation of the Run IIb CDF Detector. The purpose of this CMP
is to identify the organization providing the configuration control,
define what a configuration-controlled item is, describe the change
control process, and identify the plan for configuration status
accounting and verification. This CMP is designed to ensure that:

a.  Baselines are defined and documented,

b.  Documentation is identified, released and controlled,

c.  A Configuration Control Board (CCB) is established and functions
    according to CMP guidelines,

d.  Changes to the baseline are evaluated and controlled,

e.  Approved configuration changes are implemented and tracked, and

f.  Configuration status accounting is accomplished.

Systems and components specific to the Run IIb CDF Detector Project have
been reviewed in accordance with the principles provided in
ANSI/EIA-649-1998, *National Consensus Standard for Configuration
Management*. "Configuration management practices should be applied
selectively, and to a degree commensurate with the application
environment."[^1] We have tailored the degree of rigor employed based on
the functions and importance of each system or component. Table D.1
provides a summary of the principles and a brief description of how each
principle was addressed by the Project.

# 

2\. PROGRAM OVERVIEW

A CMP is employed by the CDF Project to identify and control Run IIb
relationships with respect to design and construction of the Run IIb CDF
Detector. The Project recognizes the importance of maintaining clear,
concise, and accurate records in order to stay on schedule, remain
within cost constraints, and provide complete information for future
operation, maintenance, and decommissioning activities. This Program has
been established to ensure that key functional organizations, both
internal and external to Fermilab, are aware of their roles and
responsibilities during the design, construction, and testing phases of
the Project. Detector design requirements and documents have been fully
established and will be maintained in a way that they will be complete
and accurate throughout the lifetime of the detector.

The main goal of the CDF Project CM Program is to prevent unauthorized
or uncontrolled physical hardware changes to equipment, changes to
controlled documents, and changes to controlled software. The program
integrates the various CM control systems already in place and augments
where needed. It is also meant to focus on the control of active
documents and not on longer-term records management, retention, or
archiving. Records management issues will be addressed according to the
requirements listed in DOE Order 200.1, Information Management Program.

The key elements of CM are Configuration Identification, Configuration
Change Control, Configuration Status Accounting, and Configuration
Verification. Configuration Identification defines the system through
drawings and documents that specify the system components in terms of
functional and physical characteristics, as well as how they will be
manufactured and tested. For convenience, the system is broken down into
Configuration Items (CIs). The CIs are listed in a Configuration Items
Data List (CIDL), which is a database that lists each CI and its
defining documentation. The CIDL is also used to track proposed changes
to CIs. The Change Control process is the vehicle by which proposed
changes are reviewed and approved. It ensures that the technical, cost
and schedule impacts of each major change are considered before approval
is granted. Configuration Status Accounting is a means to track
configuration information and relay it to key personnel in order to
support management decisions and ensure that all work is performed
according to the current design. The Configuration Verification process
ensures that the current hardware and software configurations match the
intended design by verifying the implementation of each approved change
and through periodic configuration audits.

# 

3\. SCOPE AND APPLICABILITY

**3.1 Scope**

This CMP is applicable to all work performed as part of the Run IIb CDF
Detector Project, which includes the design, testing, integration, and
assembly of components. It provides guidance for all personnel on CM
activities in support of the Project, including all subsystem teams,
collaborations, and subcontractors. CM is applied to items selected by
the Project Manager and includes hardware and software components along
with the related design documents, specifications, drawings, procedures
and other support documents. The scope of this CMP encompasses the
lifecycle of the Project.

**3.2 Applicability**

In general, the following classes of documents are included in the
Configuration Management Program:

-   Mechanical and electrical design drawings showing the specifications
    for the equipment and subcomponents

-   Technical Design Report

-   Management documents such as the Baseline Schedule, PMP, MOU's, and
    SOW's.

4\. ACRONYMS AND DEFINITIONS

**4.1 Acronyms**

CCB -- Configuration Control Board

CI -- Configuration Item

CIDL -- Configuration Items Data List

CM -- Configuration Management

CMP -- Configuration Management Program

CR -- Change Request

DCN -- Document Change Notice

ICD -- Interface Control Document

L2 Manager -- Person responsible for activities at Level 2 of the Work
Breakdown Structure

L3 Manager - Person responsible for activities at Level 3 of the Work
Breakdown Structure

PAC -- Physics Advisory Committee

PEP -- Project Execution Plan

PM -- Project Manager

PMG -- Project Management Group

PMP -- Project Management Plan

SiDet -- Silicon Detector Facility at Fermilab

TDR -- Technical Design Report

**4.2 Definitions**

Baseline -- An arbitrary point at which a project design or requirements
are considered to be "frozen" and after which all changes must be
tracked and approved.

Change Classification - All proposed changes to Project documentation
submitted to the CCB for consideration are designated as Class I, II, or
III changes. Configuration changes may affect hardware, software,
verification requirements and the documents, drawings and procedures
which define them.

Class I Change -- A proposed change that impacts the form, fit, or
function of the Detector. Class I changes are Out-of-Scope changes that
would alter the physics capabilities of the detector in a major way or
introduce a new detector system. This is described further in Section
10.5.1 of the CDF PMP.

Class II Change -- A change that does not alter the Scope of the Project
as defined in Section 10.5.1 of the CDF PMP. These are In-Scope changes
and are described in Section 10.5.2 of the CDF PMP.

Class III Change -- A proposed change that is not classified as Class I
or II. This includes changes that affect the design of a subsystem but
do not change the ability of that subsystem to meet its functional and
design requirements. Changes to correct clerical errors or to add
clarification to documents are also classified as Class III. Class III
changes are authorized by the manager of the originating organization.

Configuration Control Board (CCB) -- A board composed of technical and
administrative representatives who recommend approval or disapproval of
proposed changes to a CI's current approved configuration documentation.
This is currently considered to be the CDF PMG.

Configuration Item (CI) -- An aggregation of hardware or software that
satisfies an end use function and is designate for separate CM.

Configuration Items Data List (CIDL) -- A CDF Project-controlled
database that identifies all CIs and contains tracking and status
information for changes to the CIs.

Configuration Management (CM) -- The systematic control and evaluation
of all changes to documentation that has reached a baseline point.

Pending Changes - Pending changes are those for which conceptual design
has been approved, changes that have been approved for implementation,
or approved unincorporated changes that have been implemented in the
field but for which the document revision has not been completed.

Technical Design Report -- Defines the technical specifications,
physical characteristics, and functional operating parameters of the Run
IIb CDF Detector.

5.  RESPONSIBILITIES

**5.1 Project Manager**

Project Manager is responsible to:

-   Oversee and coordinate project configuration control activities,

-   Approve all changes to the project cost and schedule baselines,

-   Notify the Project Management Group of any need to change a document
    or system as soon as that need is identified and determined to be
    valid.

-   Ensure that all project CIs are identified and controlled.

-   Ensure any changes to controlled documents are appropriately
    recorded, tracked, and incorporated into existing drawings or
    documents in a timely manner,

-   Ensure any additional testing or certification required as a result
    of changes are explicitly called out and included in the appropriate
    places,

-   Maintain a database that identifies controlled documents and owners
    of those documents for the Project,

-   Periodically audit the CM Program to determine the effectiveness of
    the Program. This may include reviewing controlled copies of
    documents to ensure their accuracy and their consistency with the
    master copies.

    2.  **Level 2 Managers**

Level 2 Managers are responsible to:

-   Maintain CM control over their areas of responsibility and
    subcontractors,

-   Notify the PM of any need to change a document or system as soon as
    that need is identified and determined to be valid.

-   Ensure the PM is informed of as-built changes and revisions to
    controlled documents,

-   Assess impacts of proposed changes on cost, schedule, resources,
    risk, technical performance, and scientific objectives,

-   Implement approved changes to the project cost and schedule
    baselines.

**5.3 Level 3 Managers**

Level 3 Managers are responsible to:

-   Keep track of progress on work activities under their control,
    including work by subcontractors and collaborations,

-   Notify the Level 2 Manager of any need to change a document or
    system as soon as that need is identified and determined to be
    valid.

-   Ensure that people under their authority use the latest versions of
    documents available,

-   Transmit changes made as a result of field work up the chain of
    command in an orderly and timely manner.

**5.4 Document Control Managers**

Document Control Managers are responsible to:

-   Ensure that only the latest versions of documents are disseminated
    and available for use and outdated documents are replaced throughout
    the system. If outdated documents are requested for any reason, they
    shall be labeled as outdated or obsolete in a clear and distinctive
    manner.

6.  CONFIGURATION MANAGEMENT PROCESS

The CM process consists of four ongoing stages: (1) configuration
identification, (2) change control, (3) configuration status accounting,
and (4) configuration verification.

6.1 Configuration Identification

Configuration identification is the ongoing process of identifying and
documenting the detector's functional and physical characteristics, from
initial requirements selection through design, development, fabrication,
test, and delivery. Configuration identification provides unique
identity to detector components as well as the configuration
documentation.

6.1.1 Baseline Definition

The configuration identification is developed and maintained via the
peer review process and a series of formal technical and management
reviews. The peer review process includes the Physics Advisory
Committee, the CDF Collaboration, and the Project Management Group.
Formal reviews are conducted by the Fermilab Directorate, the Department
of Energy, and outside consulting groups in the employ of the DOE.

6.1.2 Configuration Items

In order to facilitate CM, the detector systems and components will be
broken down into manageable units, called Configuration Items (CIs). CIs
are identified through a top-down analysis that divides the total system
into logically related and subordinate aggregates of hardware and/or
software. The main criteria is to select those items whose performance
parameters and physical characteristics can be separately defined,
tested, and managed.

6.1.3 Configuration Items Data List

All CIs will be listed in a Configuration Items Data List (CIDL). The
CIDL is a database containing relevant information about each CI, such
as item number, title, revision history, responsible organization and
manager, release date, etc. The CIDL will also identify the documents
that define the CI. These documents are controlled through CM and may
include, but are not limited to, specifications, drawings, interface
control documents (ICDs), software description documents, databases, and
procedures. Where the design incorporates commercial off-the-shelf
(COTS) hardware or software, the vendor part number will be used in
drawings and specifications. The design data and documentation owned by
the vendor is not subject to, and therefore not included in, the CDF
Project CMP.

6.2 Change Control

Change control is the process by which the CDF Project Office manages
and approves the release and update of configuration-controlled items.
This process aims primarily at ensuring that only currently approved
revisions of documents are in use. Tracking features support this aim
through the maintenance of information on the current status of
documents and the provision of information on pending changes. The major
features for effective control are discussed below

6.2.1 Initial Release

Drawings and documents are placed under configuration control upon their
initial release. Prior to initial release, the originator should submit
the item to peer or expert review, as applicable. Initial release is
accomplished by submitting a completed and approved Document Change
Notice (DCN) to the Project Manager via the appropriate L2 or L3
Manager. The item is then entered into the CIDL. Secure master files of
the original documents are maintained in the appropriate place. If the
document is created by an off-site facility, the off-site entity may
retain control of the master file with the express authorization of the
CDF Project Manager.

6.2.2 Change Control Process

Updates to released documents are accomplished through the change
control process. This process is used to classify proposed changes and
manage the approval process accordingly. All proposed changes are
assigned a classification of Class I, Class II or Class III based on the
level of impact to the overall system. Refer to Sections 8 and 10 of the
CDF PMP for more detailed information about the specifics of the change
control process.

The change control process is started when a need for change is
identified and the responsible person submits a Document Change Notice
(DCN) to the appropriate manager for approval. Class III changes are
managed and controlled at the subsystem level. The DCN is used to inform
the rest of the team of approved changes and to cause the CIDL to be
updated. If the proposed change requires PMG approval, then the DCN and
an accompanying Change Request (CR) are forwarded. Prior to the PMG
meeting, the PM conducts an informal screening to make sure the CR is
complete and accurate. The PM may request additional support
documentation, reports and/or analyses for the PMG presentation. The PMG
then evaluates the CR and recommends that it be approved or rejected.
Class I changes are then sent to DOE for approval as per Section 8 of
the CDF PMP. When the appropriate level of approval has been granted,
the DCN and CR forms are routed and distributed to the Project team. The
approved CR directs the Project team to implement the change.

A formal, internal technical review panel will be convened by the
Project Manager if dramatic technical changes become necessary during
the course of the Project. This review will address questions relating
to the need for the proposed change, the benefits versus the cost and
schedule impacts, and the availability of adequate resources to
successfully complete the change.

6.2.3 Document Change Notice

A Document Change Notice form (Figure 10.3 in the CDF PMP) is used to
notify the Project team that an approved change has been implemented.
The DCN may announce the release of a new revision or may be attached as
an amendment to the current revision.

6.2.4 Change Request Form

The Change Request form (Figure 10.2 in the CDF PMP) accompanies the DCN
when submitting a proposed change. The CR provides the information about
the technical performance, cost and schedule impacts of the proposed
change.

6.2.5 PMG Operations

The PMG is primarily responsible for reviewing all Class I and Class II
CRs for merit based on the impact to cost, schedule and technical
performance. The PMG may also be called on to evaluate and approve or
reject Collaboration change requests and subcontractor requests for
deviation or waiver.

6.3 Configuration Status Accounting

The CIDL provides the ability to track all changes to CIs. The database
will contain information providing traceability and status of all change
requests. The CIDL will maintain the change history of all CIs so that
the evolution of the system will be documented. The CIDL serves as the
vehicle for communicating the status of configuration through periodic
reports and direct real-time inquiries.

6.4 Configuration Verification

The Subsystem Managers are responsible for implementing and closing the
PMG-approved changes to CIs that are under their control. The DCN serves
as notice that a document change has been implemented and verified. The
verification of hardware changes is reported by signing the bottom of
the CR form and returning it to the PM. In this manner, all changes can
be tracked to completion and easily audited. All CIs will be audited
prior to delivery for integration into the higher-level system to ensure
that the as-built configuration conforms to the configuration
documentation.

![](media/image4.wmf)

![](media/image5.wmf)

**ANSI/EIA-649-1998 Summary of Configuration Management Principles**

**Table D.1**

+---+---------------------------------------------------+---------------+
| * | **Principle**                                     | **How it is   |
| * |                                                   | Addressed**   |
| N |                                                   |               |
| o |                                                   |               |
| . |                                                   |               |
| * |                                                   |               |
| * |                                                   |               |
+---+---------------------------------------------------+---------------+
| 1 | Plan CM processes for the context and environment | In the CMP -- |
|   | in which they are to be performed and manage in   | appendix D of |
|   | accordance with the planning: assign              | the CDF PMP   |
|   | responsibilities; train personnel; measure        |               |
|   | performance; and assess measurements/trends to    |               |
|   | effect process improvements.                      |               |
+---+---------------------------------------------------+---------------+
| 2 | To determine the specific CM value adding         | In the CMP -- |
|   | functions and levels of emphasis for a particular | appendix D of |
|   | product, identify the context and environment in  | the CDF PMP   |
|   | which CM is to be implemented                     |               |
+---+---------------------------------------------------+---------------+
| 3 | A configuration management plan describes how     | In the CMP -- |
|   | configuration management is accomplished and how  | appendix D of |
|   | consistency between the product definition, the   | the CDF PMP   |
|   | product\'s configuration, and the configuration   |               |
|   | management records is achieved and maintained     |               |
|   | throughout the applicable phases of the           |               |
|   | product\'s life cycle.                            |               |
+---+---------------------------------------------------+---------------+
| 4 | Prepare procedures to define how each             | Figure D.2    |
|   | configuration management process will be          | (Flowchart)   |
|   | accomplished                                      |               |
+---+---------------------------------------------------+---------------+
| 5 | Conduct training so that all responsible          | Weekly        |
|   | individuals understand their roles and            | meetings      |
|   | responsibilities and the procedures for           |               |
|   | implementing configuration management processes.  |               |
+---+---------------------------------------------------+---------------+
| 6 | Assess the effectiveness of CM plan               | PM            |
|   | implementation and performance of the             | Res           |
|   | configuration management discipline with defined  | ponsibilities |
|   | metrics (performance indicators).                 |               |
+---+---------------------------------------------------+---------------+
| 7 | Performing configuration management includes      | L2 and L3     |
|   | responsibility for the configuration management   | Manager       |
|   | performance of subordinate activities (e.g.,      | res           |
|   | subcontractors, suppliers).                       | ponsibilities |
+---+---------------------------------------------------+---------------+
| 8 | Configuration identification is the basis from    | PMP Change    |
|   | which the configuration of products are defined   | Control,      |
|   | and verified; products and documents are labeled; | Sections 8 &  |
|   | changes are managed; and accountability is        | 10            |
|   | maintained.                                       |               |
+---+---------------------------------------------------+---------------+
| 9 | Configuration documentation defines the           | Described in  |
|   | functional, performance, and physical attributes  | *The CDF IIb  |
|   | of a product. Other product information is        | Detector      |
|   | derived from configuration documentation.         | Technical     |
|   |                                                   | Design        |
|   |                                                   | Report* (TDR) |
+---+---------------------------------------------------+---------------+
| 1 | The product composition (i.e. relationship and    | Described in  |
| 0 | quantity of parts that comprise the product) is   | the TDR       |
|   | determinable from its configuration               |               |
|   | documentation.                                    |               |
+---+---------------------------------------------------+---------------+
| 1 | All products are assigned unique identifiers so   | Serial #'s    |
| 1 | that one product can be distinguished from other  | and test data |
|   | products; one configuration of a product can be   |               |
|   | distinguished from another; the source of a       |               |
|   | product can be determined; and the correct        |               |
|   | product information can be                        |               |
|   |                                                   |               |
|   | retrieved                                         |               |
+---+---------------------------------------------------+---------------+
| 1 | Individual units of a product are assigned a      | Serial #'s    |
| 2 | unique product unit identifier when there is a    |               |
|   | need to distinguish one unit of the product from  |               |
|   | another unit of the product.                      |               |
+---+---------------------------------------------------+---------------+
| 1 | When a product is modified, it retains its        | Not           |
| 3 | original product unit identifier even though its  | Applicable    |
|   | part identifying number is altered to reflect a   |               |
|   | new configuration                                 |               |
+---+---------------------------------------------------+---------------+
| 1 | A series of like units of a product is assigned a | Not           |
| 4 | unique product group identifier when it is        | Applicable    |
|   | unnecessary or impracticable to identify          |               |
|   | individual units but nonetheless necessary to     |               |
|   | correlate units to a process, date, event, or     |               |
|   | test.                                             |               |
+---+---------------------------------------------------+---------------+

+---+---------------------------------------------------+---------------+
| 1 | All documents reflecting product performance,     | Described in  |
| 5 | functional, or physical requirements and other    | the TDR       |
|   | product information are uniquely identified so    |               |
|   | that they can be correctly associated             |               |
|   |                                                   |               |
|   | with the applicable configuration of the product  |               |
+---+---------------------------------------------------+---------------+
| 1 | A baseline identifies an agreed-to description of | Described in  |
| 6 | the attributes of a product at a point in time    | the TDR       |
|   | and provides a known configuration to which       |               |
|   | changes are addressed                             |               |
+---+---------------------------------------------------+---------------+
| 1 | Baselines are established by agreeing to the      | Described in  |
| 7 | stated definition of a product\'s attributes      | the TDR       |
+---+---------------------------------------------------+---------------+
| 1 | The configuration of any product or any document, | Described in  |
| 8 | plus the approved changes to be incorporated is   | the TDR       |
|   | the current baseline.                             |               |
+---+---------------------------------------------------+---------------+
| 1 | Maintaining product information is important      | Serial #'s    |
| 9 | because time consuming and expensive recovery may |               |
|   | be necessary if records of operational units of a |               |
|   | product do not match the                          |               |
|   |                                                   |               |
|   | actual units (as reported by maintenance          |               |
|   | activities) or such records do not exist.         |               |
+---+---------------------------------------------------+---------------+
| 2 | For product interfaces external to the            | MOU's and     |
| 0 | enterprise, establish an interface agreement and  | SOW's         |
|   | a mutually agreed to documentation of common      |               |
|   | attributes                                        |               |
+---+---------------------------------------------------+---------------+
| 2 | Changes to a product are accomplished using a     | PMP Change    |
| 1 | systematic, measurable change process             | Control,      |
|   |                                                   | Sections 8 &  |
|   |                                                   | 10            |
+---+---------------------------------------------------+---------------+
| 2 | Each change is uniquely identified                | Change        |
| 2 |                                                   | Request and   |
|   |                                                   | DCN           |
+---+---------------------------------------------------+---------------+
| 2 | Changes represent opportunities for improvement   | Change        |
| 3 |                                                   | Request and   |
|   |                                                   | DCN           |
+---+---------------------------------------------------+---------------+
| 2 | Classify requested changes to aid in determining  | PMP Change    |
| 4 | the appropriate levels of review and approval.    | Control,      |
|   |                                                   | Sections 8 &  |
|   |                                                   | 10            |
+---+---------------------------------------------------+---------------+
| 2 | Change requests must be clearly documented        | PMP Change    |
| 5 |                                                   | Control,      |
|   |                                                   | Sections 8 &  |
|   |                                                   | 10            |
+---+---------------------------------------------------+---------------+
| 2 | Consider the technical, support, schedule, and    | PMP Change    |
| 6 | cost impacts of a requested change before making  | Control,      |
|   | a judgment as to whether the change should be     | Sections 8 &  |
|   | approved for implementation and incorporation in  | 10            |
|   | the product and its documentation                 |               |
+---+---------------------------------------------------+---------------+
| 2 | Determine all potential effects of a change and   | See Figure    |
| 7 | coordinate potential impacts with the impacted    | D.2           |
|   | areas of responsibility                           | (flowchart)   |
+---+---------------------------------------------------+---------------+
| 2 | Change documentation delineates which unit(s) of  | Not           |
| 8 | the product are to be changed. Change effectivity | Applicable    |
|   | includes both production break-in and             |               |
|   | retrofit/recall, as applicable                    |               |
+---+---------------------------------------------------+---------------+
| 2 | A changed product should not be distributed until | Not           |
| 9 | support and service areas are able to support it. | Applicable    |
+---+---------------------------------------------------+---------------+
| 3 | Decision-maker is aware of all cost factors in    | PMP Change    |
| 0 | making the decision.                              | Control,      |
|   |                                                   | Sections 8 &  |
|   |                                                   | 10            |
+---+---------------------------------------------------+---------------+
| 3 | Change approval decisions are made by an          | PMP Change    |
| 1 | appropriate authority who can commit resources to | Control,      |
|   | implement the change                              | Sections 8 &  |
|   |                                                   | 10            |
+---+---------------------------------------------------+---------------+
| 3 | Implement an approved change in accordance with   | PMP Change    |
| 2 | documented direction approved by the appropriate  | Control,      |
|   | level of authority                                | Sections 8 &  |
|   |                                                   | 10            |
+---+---------------------------------------------------+---------------+
| 3 | Verify implementation of a change to ensure       | See Figure    |
| 3 | consistency between the product, its              | D.2           |
|   | documentation and its support elements            | (flowchart)   |
+---+---------------------------------------------------+---------------+
| 3 | If it is considered necessary to temporarily      | PMP Change    |
| 4 | depart from specified baseline requirements, a    | Control,      |
|   | variance is documented and authorized by the      | Sections 8 &  |
|   | appropriate level of authority                    | 10            |
+---+---------------------------------------------------+---------------+
| 3 | An accurate, timely information base concerning a | Figures D.1 & |
| 5 | product and its associated product information is | D.2           |
|   | important throughout the product life cycle.      |               |
+---+---------------------------------------------------+---------------+
| 3 | Configuration information, appropriate to the     | Outlined in   |
| 6 | product, is systematically recorded, safeguarded, | CMP           |
|   | validated, and disseminated                       |               |
+---+---------------------------------------------------+---------------+
| 3 | Configuration information content evolves and is  | Outlined in   |
| 7 | captured over the product life cycle as tasks     | CMP           |
|   | occur.                                            |               |
+---+---------------------------------------------------+---------------+
| 3 | Data collection and information processing system | Outlined in   |
| 8 | requirements are determined by the need for       | CMP           |
|   | configuration information                         |               |
+---+---------------------------------------------------+---------------+
| 3 | Verification that a product\'s requirement        | Quality       |
| 9 | attributes have been met and the product design   | Management &  |
|   | meeting those attributes has been accurately      | Reviews       |
|   | documented is required to baseline the product    |               |
|   | configuration                                     |               |
+---+---------------------------------------------------+---------------+
| 4 | Verification that a design achieves its goals is  | Quality       |
| 0 | accomplished by a systematic comparison of        | Management &  |
|   | requirements with the results of tests, analyses, | Reviews       |
|   | or inspections                                    |               |
+---+---------------------------------------------------+---------------+
| 4 | Documentation of a product\'s definition must be  | Quality       |
| 1 | complete and accurate enough to permit            | Management &  |
|   | reproduction of the product without further       | Reviews       |
|   | design effort.                                    |               |
+---+---------------------------------------------------+---------------+
| 4 | Where necessary, verification is accomplished by  | Outlined in   |
| 2 | configuration audit                               | CMP           |
+---+---------------------------------------------------+---------------+
| 4 | Periodic reviews verify continued achievement of  | Quality       |
| 3 | requirements, identify and document changes in    | Management    |
|   | performance, and ensure consistency with          |               |
|   | documentation                                     |               |
+---+---------------------------------------------------+---------------+
| 4 | Apply configuration management principles to      | Document      |
| 4 | ensure the integrity of digital representations   | Version       |
|   | of product information and other data             | Control       |
+---+---------------------------------------------------+---------------+
| 4 | Apply digital data identification rules to        | Document      |
| 5 | maintain document, document representation, and   | Version       |
|   | file version relationships                        | Control       |
+---+---------------------------------------------------+---------------+
| 4 | Apply business rules using data status levels for | Not           |
| 6 | access, change management, and archiving of       | Applicable    |
|   | digital data documents                            |               |
+---+---------------------------------------------------+---------------+
| 4 | Maintain relationships between digital data, data | Document      |
| 7 | requirements, and the related product             | Version       |
|   | configuration to ensure accurate data access.     | Control       |
+---+---------------------------------------------------+---------------+
| 4 | Apply disciplined version control to manage       | Document      |
| 8 | document review electronically.                   | Version       |
|   |                                                   | Control       |
+---+---------------------------------------------------+---------------+
| 4 | Ensure that a transmitted digital data product is | Quality       |
| 9 | usable.                                           | Management    |
+---+---------------------------------------------------+---------------+
| 5 | Effective digital data access fulfills            | Not           |
| 0 | requirements, preserves rights, and provides      | Applicable    |
|   | users with data they are entitled to in the       |               |
|   | correct version.                                  |               |
+---+---------------------------------------------------+---------------+

[^1]: ANSI/EIA-649-1998, *National Consensus Standard for Configuration
    Management*. Page 1