Download:
pdf |
pdfRIG
RESEARCH
INFRASTRUCTURE GUIDE
NSF guidance for full life cycle
oversight of Major Facilities
and Mid-scale RI
NSF Office of Budget, Finance
and Award Management/
Research Infrastructure Office
NSF 25-XXX
June 2025
Summary of Significant Changes
Research Infrastructure Guide
SUMMARY OF SIGNIFICANT CHANGES
The purpose of this revision of the Research Infrastructure Guide (RIG) is to enhance its
clarity, accessibility, and usefulness for a broad audience, including users within and beyond
the U.S. National Science Foundation (NSF). Key updates include eliminating redundancies,
clarifying requirements, and adding essential guidance to better support users. A summary
of specific changes in this revision is provided below.
Chapter 1 – Introduction
•
Section 1.1 Purpose and Scope clarifies the definition of NSF Research Infrastructure
(RI); defines project as referring specifically to the Construction Stage for Major
Facilities and the Implementation Stage for Mid-scale RI; applies consistent
terminology across all life cycle stages; and standardizes the use of should and must
throughout the document.
•
Section 1.3.1 Award Instruments establishes a framework for making the RIG award
instrument neutral.
•
Section 1.4.11 Build America, Buy America – BABA includes applicable legislation
and NSF policy content that aligns with government practices.
Chapter 2 – NSF Life Cycle Oversight
•
Each life cycle stage section has a separate oversight subsection.
•
Section 2.1 NSF Staff Roles and Responsibilities for Management and Oversight
is relocated from Chapter 6.
•
Section 2.2 Internal Management Plan is relocated from Chapter 3.
•
Section 2.7.4 Recapitalization During Operations provides guidance on
recapitalization mechanisms.
•
Section 2.8 Major Facility Disposition Stage introduces the shift in terminology
from Divestment to Disposition for the last RI life cycle stage.
•
Section 2.9 Mid-scale Research Infrastructure Guidance clarifies and
differentiates guidance for Mid-scale RI from Major Facilities and is relocated from
Chapter 5.
Chapter 3 – Research Infrastructure Life Cycle Planning
•
Section 3.2 Tailoring, Scaling, and Progressively Elaborating Plans provides new
contextual guidance for overall planning.
•
Section 3.4 Design Stage Planning contains new guidance for a Design Execution
Plan.
•
Section 3.5 Construction Stage and Implementation Planning provides enhanced
guidance for drafting a Project Execution Plan and the ten components required for
Document Number
1
Summary of Significant Changes
Research Infrastructure Guide
both Mid-scale RI and Major Facility projects.
•
Section 3.6 Operations Stage Planning contains improved guidance on the Annual
Work Plan and Facility Condition Assessment of a Major Facility.
Chapter 4 – Fundamental Elements of Project Management
•
Section 4.5 Monitoring Progress Against Plan provides enhanced guidance to help
Awardees track milestones and ensure alignment with planned goals.
•
Section 4.6 Risk Management clarifies and streamlines recommended practices for
identifying, assessing, and managing risk, ensuring consistent application across all
life cycle stages.
•
Section 4.7 Contingency Estimating and Management expands guidance for
greater clarity and detail and is decoupled from risk management.
Chapter 5 – Supplemental Guidance
•
Section 5.2 Cyberinfrastructure includes guidance on a Cyberinfrastructure Plan for
Major Facilities and Mid-scale RI.
•
Section 5.3 Information Assurance includes guidance on an Information Assurance
Management Plan for Major Facilities and Mid-scale RI. Formerly called Cybersecurity.
•
Section 5.4 Environmental Considerations contains enhanced information on the
Disposition Stage.
•
Section 5.9 Agile Guidance provides new content and guidance on applying Agile
methodologies to NSF awards.
Chapter 6 – References
•
Minor updates made, no significant changes to guidance.
Chapter 7 – Acronyms and Abbreviations
•
Minor updates made, no significant changes to guidance.
Chapter 8 – Lexicon
•
Minor updates made, no significant changes to guidance.
Chapter 9 – Appendices
•
Appendix A – Ranking Criteria for Prioritizing Major Facility Projects, minor
updates made, no significant changes to guidance.
•
Appendix B – Outline of Plans by Life Cycle Stage includes a new List of Plans with
descriptions of plans by life cycle stage.
Document Number
2
Table of Contents
Research Infrastructure Guide
TABLE OF CONTENTS
Summary of Significant Changes ..................................................................................................................... 1
1.0Introduction ................................................................................................................................................. 15
1.1 Purpose and Scope............................................................................................................................. 15
1.2 RIG Document Structure.................................................................................................................... 17
1.3 Document Precedence and Award Instruments ............................................................................ 18
1.3.1 Award Instruments .................................................................................................................. 18
1.3.1.1 Financial Assistance Awards – Grants and Cooperative Agreements ......................19
1.3.1.2 Contracts............... ........................................................................................................... 23
1.3.1.3 Other Arrangements/Other Transactions .................................................................... 24
1.3.1.4 Review of Proposals and Awards .................................................................................. 24
1.4 Applicable Legislation and NSF Policy .............................................................................................. 26
1.4.1 Research Infrastructure .......................................................................................................... 26
1.4.2 Major Research Equipment and Facilities Construction Threshold ..................................26
1.4.3 Major Multi-User Research Facility Project – Major Facility ................................................26
1.4.4 Oversight Requirements ......................................................................................................... 27
1.4.5 Mid-Scale Project and Mid-scale Research Infrastructure ..................................................28
1.4.6 National Science Board Policy on Recompetition ................................................................ 28
1.4.7 NSF No Cost Overrun Policy ................................................................................................... 28
1.4.8 NSF Performance Metrics ....................................................................................................... 29
1.4.9 Legislation on Congressional Notification of Total Project Cost Increases ......................29
1.4.10 Legislation on Congressional Notification of Divestments of NSF-owned Facilities or
Capital Assets ........................................................................................................................... 30
1.4.11 Build America, Buy America – BABA...................................................................................... 30
2.0NSF Life Cycle Oversight ............................................................................................................................ 31
2.1 NSF Staff Roles and Responsibilities for Award Management and Oversight ...........................31
2.1.1 Overview ................................................................................................................................... 31
2.1.2 Coordinating and Advisory Bodies ........................................................................................ 34
2.1.3 Governing and Assurance Bodies ......................................................................................... 35
2.2 Internal Management Plan ................................................................................................................ 37
2.3 Major Facility Process Introduction .................................................................................................. 38
2.3.1 Major Research Equipment and Facilities Construction Account .....................................38
2.3.2 Eligibility for MREFC Funding.................................................................................................. 38
2.3.3 Major Facility Life Cycles ......................................................................................................... 39
2.3.3.1 Development Stage ......................................................................................................... 40
2.3.3.2 Design Stage......... ............................................................................................................ 41
2.3.3.3 Construction Stage .......................................................................................................... 45
2.3.3.4 Operations Stage.. ........................................................................................................... 45
Document Number
3
Table of Contents
Research Infrastructure Guide
2.3.3.5 Disposition Stage... .......................................................................................................... 46
2.3.4 Major Facility Execution Process Summary.......................................................................... 46
2.4 Major Facility Development Stage .................................................................................................... 51
2.4.1 Proposed Major Facility Project Initiation and Development ............................................51
2.4.1.1 Development Stage Oversight and Reporting ............................................................. 51
2.4.1.2 Development Stage Exit.................................................................................................. 51
2.5 Major Facility Design Stage................................................................................................................ 53
2.5.1 Conceptual Design Phase ....................................................................................................... 53
2.5.1.1 NSF Oversight and Conceptual Design Review............................................................ 54
2.5.1.2 Conceptual Design Phase Exit........................................................................................ 55
2.5.2 Preliminary Design Phase ....................................................................................................... 55
2.5.2.1 NSF Oversight and Preliminary Design Review ........................................................... 56
2.5.2.2 Preliminary Design Phase Exit ....................................................................................... 57
2.5.3 Final Design Phase ................................................................................................................... 58
2.5.3.1 NSF Oversight and Final Design Review ....................................................................... 59
2.5.3.2 Final Design Phase Exit ................................................................................................... 60
2.5.3.3 Approval by NSF Director – Transition to Construction Stage...................................60
2.5.3.4 National Science Board Authorization for Construction ............................................60
2.6 Major Facility Construction Stage ..................................................................................................... 62
2.6.1 Construction Award Management and Oversight .............................................................. 62
2.6.1.1 Implementation of NSF’s No Cost Overrun Policy.......................................................62
2.6.1.2 Construction Stage Reporting and Reviews ................................................................. 63
2.6.1.3 Construction Stage Reviews ........................................................................................... 65
2.6.1.4 Re-planning........... ........................................................................................................... 65
2.6.1.5 Re-baselining......... ........................................................................................................... 66
2.6.2 Construction Award Extension and Close-out ..................................................................... 67
2.6.2.1 Project Close-out Process ............................................................................................... 67
2.6.2.2 Schedule Extension ......................................................................................................... 67
2.7 Major Facility Operations Stage ........................................................................................................ 70
2.7.1 Initial Operations Stage Awards ............................................................................................ 70
2.7.2 Operations Stage Awards ....................................................................................................... 70
2.7.3 Operations Stage Reporting and Oversight ......................................................................... 71
2.7.4 Recapitalization During Operations ...................................................................................... 73
2.7.5 Federally Funded Research and Development Center Designation .................................74
2.7.6 Competition, Renewal and Disposition Decisions ............................................................... 76
2.7.6.1 Disposition............ ............................................................................................................ 76
2.8 Major Facility Disposition Stage ........................................................................................................ 77
2.9 Mid-Scale Research Infrastructure Guidance ................................................................................. 78
2.9.1 Introduction .............................................................................................................................. 78
Document Number
4
Table of Contents
Research Infrastructure Guide
2.9.2 Expectations for Mid-scale RI Proposers and Awardees ....................................................79
2.9.3 Mid-scale RI Life Cycle Stages................................................................................................. 82
2.9.4 Summary of NSF Oversight for Major Facilities and Mid-scale RI .....................................85
3.0Research Infrastructure Life Cycle Planning ........................................................................................... 88
3.1 Introduction ......................................................................................................................................... 88
3.2 Tailoring, Scaling, and Progressively Elaborating Plans................................................................. 89
3.2.1 Tailoring .................................................................................................................................... 90
3.2.1.1 Traditional Waterfall Approach...................................................................................... 90
3.2.1.2 Cyclical Approach............................................................................................................. 91
3.2.1.3 Level-of-Effort Approach ................................................................................................ 92
3.2.2 Scaling ....................................................................................................................................... 92
3.2.3 Progressively Elaborating ....................................................................................................... 93
3.3 Development Stage Planning ............................................................................................................ 95
3.4 Design Stage Planning........................................................................................................................ 96
3.4.1 Design Execution Plan ............................................................................................................. 96
3.5 Construction Stage and Implementation Planning ........................................................................ 99
3.5.1 PEP Component 1 – Project Overview ............................................................................... 102
3.5.1.1 PEP Subcomponent 1.1 – Overview of PEP and Executive Summary of Project .. 103
3.5.1.2 PEP Subcomponent 1.2 – Project Mission and Broader Impacts ........................... 104
3.5.1.3 PEP Subcomponent 1.3 – Key Performance Parameters and Scientific
Requirements................................................................................................................ 104
3.5.1.4 PEP Subcomponent 1.4 – Research Infrastructure Description ............................. 106
3.5.2 PEP Component 2 – Project Organization ......................................................................... 107
3.5.2.1 PEP Subcomponent 2.1 – Overview of Project Organization.................................. 108
3.5.2.2 PEP Subcomponent 2.2 – Internal Project Organization ......................................... 108
3.5.2.3 PEP Subcomponent 2.3 – External Project Stakeholders ........................................ 112
3.5.2.4 PEP Subcomponent 2.4 – Partnerships and Subawards ......................................... 116
3.5.3 PEP Component 3 – Performance Measurement Baseline............................................. 117
3.5.3.1 PEP Subcomponent 3.1 – Overview of the Performance Measurement Baseline and
Total Project Definition ................................................................................................ 119
3.5.3.2 PEP Subcomponent 3.2 – Scope ................................................................................. 120
3.5.3.3 PEP Subcomponent 3.3 – Quality Acceptance Criteria ............................................ 124
3.5.3.4 PEP Subcomponent 3.4 – Integrated Master Schedule ........................................... 126
3.5.3.5 PEP Subcomponent 3.5 – Time-Phased Budget ....................................................... 128
3.5.4 PEP Component 4 – Risk and Contingency Management ............................................... 131
3.5.4.1 PEP Subcomponent 4.1 – Risk Management Approach .......................................... 132
3.5.4.2 PEP Subcomponent 4.2 – Risk Management Plan ................................................... 133
3.5.4.3 PEP Subcomponent 4.3 – Contingency Management Plan..................................... 134
3.5.5 PEP Component 5 – Acquisition Plans ............................................................................... 138
Document Number
5
Table of Contents
Research Infrastructure Guide
3.5.5.1 PEP Subcomponent 5.1 – Overview of Acquisition Plans ........................................ 139
3.5.5.2 PEP Subcomponent 5.2 – Scope Acquisition Plans .................................................. 139
3.5.5.3 PEP Subcomponent 5.3 – Systems Engineering and Quality Management Plans 140
3.5.5.4 PEP Subcomponent 5.4 – Resource Management Plans ........................................ 143
3.5.6 PEP Component 6 – Environmental, Safety, and Health Management ......................... 144
3.5.6.1 PEP Subcomponent 6.1 – Overview of Environmental, Safety, and Health
Management......... ........................................................................................................ 146
3.5.6.2 PEP Subcomponent 6.2 – Environmental Protection Management Plans............ 147
3.5.6.3 PEP Subcomponent 6.3 – Safety Management Plans .............................................. 148
3.5.6.4 PEP Subcomponent 6.4 – Occupational Health Management Plans ..................... 149
3.5.7 PEP Component 7 – Project Controls Plans ...................................................................... 150
3.5.7.1 PEP Subcomponent 7.1 – Overview of Project Controls ......................................... 152
3.5.7.2 PEP Subcomponent 7.2 – Performance Measurement and Management Plans 155
3.5.7.3 PEP Subcomponent 7.3 – Change Control Plans ...................................................... 157
3.5.7.4 PEP Subcomponent 7.4 – Reporting and Review Plans ........................................... 164
3.5.7.5 PEP Subcomponent 7.5 – Business and Financial Controls Plans ......................... 165
3.5.8 PEP Component 8 – Cyberinfrastructure and Information Management .................... 167
3.5.8.1 PEP Subcomponent 8.1 – Overview of Cyberinfrastructure and Information
Management......... ........................................................................................................ 169
3.5.8.2 PEP Subcomponent 8.2 – Cyberinfrastructure ......................................................... 170
3.5.8.3 PEP Subcomponent 8.3 – Information Assurance Management ........................... 170
3.5.8.4 PEP Subcomponent 8.4 – Data Management ........................................................... 171
3.5.8.5 PEP Subcomponent 8.5 – Documentation Management ........................................ 173
3.5.8.6 PEP Subcomponent 8.6 – Communications Management ..................................... 174
3.5.9 PEP Component 9 – Project Closeout Plans ...................................................................... 175
3.5.9.1 PEP Subcomponent 9.1 – Overview of Closeout Plans ............................................ 177
3.5.9.2 PEP Subcomponent 9.2 – Technical Closeout Plans ................................................ 177
3.5.9.3 PEP Subcomponent 9.3 – Administrative Closeout Plans ....................................... 178
3.5.9.4 PEP Subcomponent 9.4 – Programmatic/Award Closeout Plans ........................... 179
3.5.10 PEP Component 10 – Post Project Plans ........................................................................... 181
3.5.10.1 PEP Subcomponent 10.1 – Overview of Post Project Plans ................................... 182
3.5.10.2 PEP Subcomponent 10.2 – Concept of Operations Plans ...................................... 182
3.5.10.3 PEP Subcomponent 10.3 – Concept of Disposition Plans ...................................... 184
3.6 Operations Stage Planning ............................................................................................................. 186
3.6.1 Strategic Plan ......................................................................................................................... 186
3.6.2 Facility Condition Assessment of a Major Facility............................................................. 187
3.6.2.1 Facility Condition Assessment Components............................................................. 187
3.6.2.2 Scope of the Facility Condition Assessment ............................................................. 188
3.6.2.3 Conducting Facility Condition Assessment ............................................................... 188
Document Number
6
Table of Contents
Research Infrastructure Guide
3.6.2.4 Creating the Asset Management Plan ....................................................................... 190
3.6.3 Annual Work Plan ................................................................................................................. 191
3.6.3.1 Assumptions.................................................................................................................. 191
3.6.3.2 Components of an Annual Work Plan ....................................................................... 192
3.7 Disposition Stage Planning ............................................................................................................. 200
4.0Fundamental Elements of Project Management ................................................................................. 202
4.1 Introduction ...................................................................................................................................... 202
4.2 Scope and Work Breakdown Structure ........................................................................................ 203
4.3 Cost Estimating and Analysis ......................................................................................................... 208
4.3.1 Introduction to Cost Estimating and Analysis Process .................................................... 208
4.3.2 Characteristics of a High-Quality Cost Estimate ............................................................... 211
4.3.2.1 Comprehensive..... ........................................................................................................ 211
4.3.2.2 Well-Documented. ........................................................................................................ 212
4.3.2.3 Accurate................. ........................................................................................................ 212
4.3.2.4 Credible................. ......................................................................................................... 212
4.3.3 Developing and Estimating Baseline Costs ....................................................................... 212
4.3.3.1 Steps to Develop and Estimate Baseline Costs ........................................................ 212
4.3.3.2 Estimate Documentation ............................................................................................. 217
4.3.3.3 Cost Estimating Plan..................................................................................................... 218
4.3.3.4 Uncertainty, Accuracy, and Allowances ..................................................................... 221
4.3.4 Specific Guidance for Major Facility Construction Estimates ......................................... 224
4.3.4.1 Purpose and Process ................................................................................................... 224
4.3.4.2 Construction Cost Book and Basis of Estimate Overview ....................................... 225
4.3.4.3 Construction Cost Book and Basis of Estimate Additional Details ........................ 225
4.3.5 Specific Guidance for Major Facility Operations Estimates ............................................ 228
4.3.5.1 Purpose and Process ................................................................................................... 228
4.3.5.2 Operations Cost Book and Basis of Estimate Overview .......................................... 228
4.3.5.3 Operations Cost Book and Basis of Estimate Additional Detail ............................. 229
4.4 Schedule Development, Estimating, and Analysis ...................................................................... 230
4.4.1 Introduction ........................................................................................................................... 230
4.4.2 Characteristics of a Reliable Schedule ............................................................................... 231
4.4.2.1 Comprehensive..... ........................................................................................................ 232
4.4.2.2 Well-Constructed.. ........................................................................................................ 233
4.4.2.3 Credible................. ......................................................................................................... 234
4.4.2.4 Controlled.............. ........................................................................................................ 235
4.4.3 Developing and Estimating a Baseline Schedule.............................................................. 235
4.4.3.1 Ten Steps to Develop Baseline Schedule .................................................................. 236
4.4.3.2 Schedule Documentation ............................................................................................ 238
4.4.4 Schedule Maintenance During Construction Stage ......................................................... 239
Document Number
7
Table of Contents
Research Infrastructure Guide
4.4.4.1 Baseline Schedule......................................................................................................... 240
4.4.4.2 Progress Schedule ........................................................................................................ 240
4.4.5 NSF Analysis of Construction Stage Resource-Loaded Schedules ................................. 241
4.4.5.1 Schedule Review Component of Stage-Gate Reviews ............................................. 241
4.4.5.2 Schedule Review Component of Independent Cost Estimate Reviews ................. 242
4.4.5.3 Schedule Review Component of NSF EVMS Verification Review............................ 243
4.4.5.4 Schedule Review Component of NSF Cost Analysis ................................................. 244
4.5 Monitoring Progress Against Plan ................................................................................................. 245
4.5.1 Performance Measurement and Management ................................................................ 245
4.5.2 Essential Qualities of a Progress Monitoring System ...................................................... 247
4.5.3 Allowable Progress Monitoring Systems ........................................................................... 248
4.5.4 Earned Value Management ................................................................................................. 250
4.5.4.1 Earned Value Management – The Seven Principles ................................................. 250
4.5.4.2 Verified Earned Value Management Systems ........................................................... 250
4.5.4.3 Non-Verified EVMS ....................................................................................................... 251
4.6 Risk Management ............................................................................................................................ 256
4.6.1 Step 1 – Plan Risk Management.......................................................................................... 260
4.6.2 Step 2 – Identify and Document Risks ............................................................................... 262
4.6.3 Step 3 – Analyze and Rank Individual Risks ....................................................................... 267
4.6.4 Step 4 – Determine and Apply Individual Risk Reduction / Enhancement Responses 270
4.6.5 Step 5 – Establish Issue Response Plans ........................................................................... 271
4.6.6 Step 6 – Assess Total Risk Exposure ................................................................................... 272
4.6.6.1 Algorithmic Method – Risk Register Exposure Sum ................................................. 273
4.6.6.2 Parametric Method – Risk Factor Analysis ................................................................ 274
4.6.6.3 Probabilistic Method – Monte Carlo Simulations ..................................................... 276
4.6.7 Step 7 – Report, Monitor, and Update Risks ..................................................................... 288
4.7 Contingency Estimating and Management .................................................................................. 289
4.7.1 Allowable Contingencies ...................................................................................................... 289
4.7.2 Contingency Estimating ....................................................................................................... 291
4.7.2.1 Budget Contingency ..................................................................................................... 291
4.7.2.2 Schedule Contingency.................................................................................................. 293
4.7.2.3 Scope Contingency ....................................................................................................... 294
4.7.2.4 Contingency Estimating for Major Facility Design and Construction Stages ........ 296
4.7.2.5 Contingency Estimating for Major Facility Operations Stage ................................. 297
4.7.3 Contingency Management .................................................................................................. 298
4.7.3.1 Contingency Management Controls .......................................................................... 298
4.7.3.2 Contingency Management Documentation .............................................................. 300
4.7.3.3 Contingency Management Forecasting ..................................................................... 301
5.0Supplemental Guidance.......................................................................................................................... 304
Document Number
8
Table of Contents
Research Infrastructure Guide
5.1 Introduction ...................................................................................................................................... 304
5.2 Cyberinfrastructure ......................................................................................................................... 305
5.2.1 CI Plan Requirements ........................................................................................................... 305
5.2.2 CI Plan Purpose and Scope.................................................................................................. 305
5.3 Information Assurance ................................................................................................................... 307
5.3.1 Introduction ........................................................................................................................... 307
5.3.2 Framing Information Assurance Risks in the Contemporary Threat Landscape ......... 309
5.3.2.1 Geopolitics............. ........................................................................................................ 309
5.3.2.2 Specific Research Domains ......................................................................................... 309
5.3.2.3 Regulatory Pressures ................................................................................................... 309
5.3.2.4 Other Attacks and Concerns ....................................................................................... 310
5.3.2.5 IA Program Tailoring and Scaling ............................................................................... 310
5.3.3 Cyber Risks............................................................................................................................. 310
5.3.4 Information Assurance Management Plan ....................................................................... 311
5.3.5 Critical Controls ..................................................................................................................... 313
5.3.6 Building an Information Assurance Program ................................................................... 315
5.3.6.1 Mission Alignment ........................................................................................................ 315
5.3.6.2 Resources.............. ........................................................................................................ 315
5.3.6.3 Governance........... ........................................................................................................ 316
5.3.6.4 Cybersecurity Controls ................................................................................................ 316
5.3.7 Data Management and Curation ........................................................................................ 316
5.3.8 Information Assurance and Cyberinfrastructure ............................................................. 317
5.3.9 Cyberbreach Insurance ........................................................................................................ 317
5.3.10 Program Assessment ........................................................................................................... 318
5.4 Environmental Considerations ...................................................................................................... 319
5.4.1 Environmental Considerations prior to NSF Funding Decision ...................................... 319
5.4.1.1 NSF’s Role in Conducting Environmental Review ..................................................... 319
5.4.1.2 Potential Awardee Role in Supporting NSF’s Environmental Review .................... 320
5.4.2 Environmental Considerations Following NSF Funding Decision .................................. 321
5.5 Property Management .................................................................................................................... 322
5.6 NSF Budget Categories from the Proposal and Award Policies and Procedures Guide ........ 323
5.7 Personnel and Competencies ........................................................................................................ 327
5.7.1 Key Personnel........................................................................................................................ 327
5.7.2 Project Team.......................................................................................................................... 328
5.7.3 Competency Guidance for Major Facility Management .................................................. 329
5.8 Partnerships ..................................................................................................................................... 335
5.9 Agile Guidance ................................................................................................................................. 336
5.9.1 General Agile Guidance........................................................................................................ 338
5.9.2 Agile Documentation ............................................................................................................ 339
Document Number
9
Table of Contents
Research Infrastructure Guide
5.9.3 Specific Agile Guidance ........................................................................................................ 339
6.0References ................................................................................................................................................ 341
6.1 Chapter 1 | Introduction ................................................................................................................ 341
6.2 Chapter 2 | NSF Life Cycle Oversight ............................................................................................ 342
6.3 Chapter 3 | Research Infrastructure Life Cycle Planning ........................................................... 342
6.4 Chapter 4 | Fundamental Elements of Project Management ................................................... 343
6.5 Chapter 5 | Supplemental Guidance ............................................................................................ 344
7.0Acronyms and Abbreviations ................................................................................................................. 347
8.0Lexicon ...................................................................................................................................................... 352
8.1 Lexicon Preface ................................................................................................................................ 352
8.2 Terms and Definitions ..................................................................................................................... 353
9.0Appendices ............................................................................................................................................... 371
9.1 Appendix A – Ranking Criteria for Prioritizing Major Facility Projects ........................................ 371
9.1.1.1
First Ranking – Scientific and Technical Criteria Assessed by Researchers in a Field
or Interdisciplinary Area ...................................................................................................... 371
9.1.1.2
Second Ranking – Agency Strategic Criteria Assessed across Related Fields ....... 371
9.1.1.3
Third Ranking – National Criteria Assessed across All Fields .................................. 371
9.2 Appendix B – Outline of Plans by Life Cycle Stage ...................................................................... 372
9.2.1.1
Design Stage .................................................................................................................. 372
9.2.1.2
Construction Stage and Implementation Planning .................................................. 372
9.2.1.3
Operations Stage .......................................................................................................... 375
9.2.1.4
Disposition Stage .......................................................................................................... 375
Document Number
10
List of Figures
Research Infrastructure Guide
LIST OF FIGURES
Figure 1.3-1 General Hierarchy of Authorities ................................................................................................ 18
Figure 2.1.1-1 NSF Organizational Chart Highlighting Key Staff with Primary Oversight and Management
Responsibilities for Major Facilities and Mid-scale RI, shown in gold with the Core IPT in Darker Gold.......33
Figure 2.1.2-1 NSF Organization Chart of Coordinating and Advisory Bodies for Major Facilities and Midscale RI Indicated in Gold .................................................................................................................................. 34
Figure 2.1.3-1 NSF Organization Chart of Policy and Approval Bodies for Major Facilities and Mid-scale RI
Indicated in Gold ............................................................................................................................................... 36
Figure 2.3.3-1 Progressive Steps in the RI Life Cycle Illustrating High-Level Review and Decision Points for
Exit and Entry; the Design Stage is Broken Down Further into Phases ........................................................... 40
Figure 2.3.3.2-1 Progressive Phases Within the Design Stage Illustrating Review and Decision Points and
NSF Award and Budgeting Authorization ......................................................................................................... 43
Figure 3.2.1.1-1 Waterfall Model of Design Through Construction Stages....................................................91
Figure 3.2.1.2-1 Cyclical Development Process .............................................................................................. 91
Figure 3.5-1 PEP Overview Map .................................................................................................................... 101
Figure 3.5.2.2-1 Functional Project Organization: Capability Area Leads Reporting to Project Manager with
Deliverable Responsibilities ............................................................................................................................ 109
Figure 3.5.2.2-2 Example of a hybrid organization incorporating an Agile structure at lower WBS levels
......................................................................................................................................................................... 110
Figure 3.5.2.2-3 Example of Written Descriptions of Roles and Responsibilities ....................................... 111
Figure 3.5.2.3-1 External Organization Chart: Authority and Communication Lines in a Traditional Project
Structure ......................................................................................................................................................... 113
Figure 3.5.2.3-2 Hierarchical Organization Structure for a Traditional Waterfall Project with Work
Breakdown Structure-Aligned Leadership Positions ..................................................................................... 115
Figure 3.5.5.3-1 Flow Down from Mission Statement to Individual Systems and Components ................ 141
Figure 3.5.7.1-1 Project Controls Process Flow Chart: Interactions Among Subcomponents with Established
Total Project Definition ................................................................................................................................... 155
Figure 3.5.7.3-1 Example Flow Diagram for Change Control Process ........................................................ 160
Figure 3.5.7.3-2 Example of a Change Request Form ................................................................................. 162
Figure 3.6-1 Three Main Deliverables Necessary for Operations Stage Planning and Execution.............. 186
Figure 4.3.1-1 NSF Cost Analysis Process ..................................................................................................... 211
Figure 4.3.3.2-1 Components of a High-Quality Estimate ........................................................................... 218
Figure 4.3.3.3-1 Sample Project Control Systems Relationship Diagram ................................................... 221
Figure 4.3.3.4-1 Accuracy versus Precision .................................................................................................. 223
Figure 4.3.4.3-1 Construction Cost Book Sheet Sample Format ................................................................. 227
Figure 4.5.1-1 Three-Step Framework for PMM Within the Context of Project Controls: Monitoring Progress
Against Plan .................................................................................................................................................... 246
Figure 4.5.3-1 Illustrative Example: Methods for Monitoring Progress Against the Base Plan ................. 248
Figure 4.5.3-2 Burndown Chart Example: Contingency (Red Line) and Total Risk Exposure (Blue Line)
Comparison, Emphasizing Best Practice ....................................................................................................... 249
Document Number
11
List of Figures
Research Infrastructure Guide
Figure 4.5.4.3-1 NSF Scaled (Non-Verified) EVMS Process: Application of 18 of 32 EVMS Guidelines Aligned
with the 7 Basic Principles of EVMS ............................................................................................................... 252
Figure 4.6-1 A Typical Risk Management Process with Seven Steps and Three Outputs ........................... 257
Figure 4.6.2-1 Risk Breakdown Structure Example...................................................................................... 267
Figure 4.6.6.3-1 Graphical Representation of Total Project Duration Using Monte Carlo Simulations Across
Various Iteration Counts ................................................................................................................................ 278
Figure 4.6.6.3-2 Example of an S-Curve Output of Monte Carlo Performed on Risk Register ................... 280
Figure 4.6.6.3-3 Example of a High-Level PMB Schedule for a Design and Construction Project ............. 282
Figure 4.6.6.3-4 Histogram from Monte Carlo Simulations Showing Schedule Risk Impacts on Project End
Date with an 80% Confidence Level S-Curve. Baseline End Date: 11/10/2024; Projected End Date at 80%
Confidence: 7/14/2025, Suggesting an Eight-Month Contingency Requirement ......................................... 283
Figure 4.6.6.3-5 Histogram of Total Project Cost from Integrated Monte Carlo Cost Analysis for Major
Facility Construction. Total Cost: $74.87 M; Contingency: $10.55 M at 90% Confidence Level .................. 285
Figure 4.6.6.3-6 Risk Sensitivity Analysis: Tornado Chart Depicting Contributions to Cost Risk Exposure from
Individual Risks and Uncertainties ................................................................................................................ 286
Figure 4.7.1-1 Methods for Determining Contingency Allocations ............................................................. 291
Figure 4.7.2.3-1 Comparison of Risk Exposure to Available Contingency Over Time ................................ 296
Figure 5.3.2-1 Threats to Major Facilities and Mid-scale RI ........................................................................ 309
Figure 5.3.6-1 Pillars of an IA Program ........................................................................................................ 315
Figure 5.9-1 Agile Development Methods Versus Traditional Development Methods: Emphasized Elements;
Graphic adapted from GAO Agile Assessment Guide Figure 5 (GAO-20-590G) ........................................... 337
Figure 5.9.1-1 Traditional / Agile Hybrid Project Example WBS .................................................................. 338
Document Number
12
List of Tables
Research Infrastructure Guide
LIST OF TABLES
Table 1.3.1-1 NSF Financial Assistance Budget Category Format .................................................................. 22
Table 2.3.4-1 Summary Timeline for Proposed Major Facility Projects in the Development and Design Stages
............................................................................................................................................................................ 48
Table 2.3.4-2 Summary Timeline for Major Facility Projects and Science Support Programs in the
Construction, Operations, and Disposition Stages .......................................................................................... 49
Table 2.6.2.2-1 Sample of a Schedule Extension Tasks Table ........................................................................ 69
Table 2.9.4-1 Requirements for Major Facilities versus Mid-scale RI ............................................................. 86
Table 3.5.1-1 Project Overview Subcomponents, Products, and Documents with References to Further
Material and Related Topics .......................................................................................................................... 103
Table 3.5.1.3-1 Key Performance Parameters and Science Requirements for a Hypothetical Mission to Build
a Next-Generation Ground-Based Optical Telescope ................................................................................... 106
Table 3.5.2-1 Project Organization Subcomponents, Products, and Documents with References to Further
Material and Related Topics .......................................................................................................................... 108
Table 3.5.2.2-1 Example of a Roles and Responsibilities Table .................................................................. 111
Table 3.5.2.3-1 Examples of External Roles and Responsibilities ............................................................... 115
Table 3.5.2.4-1 Example List of Partners: Agreement Types, Lead Contacts, and Areas of
Support/Contributions ................................................................................................................................... 116
Table 3.5.3-1 Performance Measurement Baseline Subcomponents, Products, and Documents with
References to Further Material and Related Topics ..................................................................................... 118
Table 3.5.3.1-1 Example of a Project Summary Table: Level 2 WBS with Costs, Schedule, TPC, TPD, and
Assigned Responsibilities ................................................................................................................................ 119
Table 3.5.3.1-2 Commitment and Funding Profile by Fiscal Year Sample Table........................................ 120
Table 3.5.3.2-1 Illustration of High Level WBS Dictionary ........................................................................... 122
Table 3.5.3.3-1 Traceable Flow of KPP to Science, Engineering, and Quality Requirements in Complex
Projects............................................................................................................................................................ 125
Table 3.5.3.4-1 Sample High Level Schedule Gantt Chart ........................................................................... 127
Table 3.5.3.4-2 Sample Graphical Representation of Key Reporting Milestones ....................................... 127
Table 3.5.3.5-1 High Level Time-Phased Budget Report with NSF Budget Category Mapping Sample Table
by Fiscal Year (FY) ........................................................................................................................................... 130
Table 3.5.4-1 Risk and Contingency Management Subcomponents, Products, and Documents with
References to Further Material and Related Topics ...................................................................................... 132
Table 3.5.5-1 Acquisition Plans Subcomponents, Products, and Documents with References to Further
Material and Related Topics .......................................................................................................................... 139
Table 3.5.6-1 Environmental, Safety, and Health Management Subcomponents, Products, and Documents
with References to Further Material and Related Topics .............................................................................. 146
Table 3.5.7-1 Project Controls Plans Subcomponents, Products, and Documents with References to Further
Material and Related Topics .......................................................................................................................... 152
Table 3.5.7.3-1 Sample Change Request: Approval Thresholds and Authorities for a Medium Complexity
Major Facility Project ...................................................................................................................................... 159
Table 3.5.8-1 Cyberinfrastructure and Information Management Subcomponents, Products, and
Document Number
13
List of Tables
Research Infrastructure Guide
Documents with References to Further Material and Related Topics .......................................................... 169
Table 3.5.9-1 Project Closeout Plans Subcomponents, Products, and Documents with References to Further
Material and Related Topics .......................................................................................................................... 176
Table 3.5.10-1 Post Project Plans Subcomponents, Products, and Documents with References to Further
Material and Related Topics .......................................................................................................................... 182
Table 4.2-1 Example Format of a Construction Stage or Implementation Deliverables-based WBS ........ 205
Table 4.2-2 Example Format of an Operations Functional-based WBS ...................................................... 206
Table 4.2-3 Example Format of an Activity-based Operations WBS............................................................ 207
Table 4.5.3-1 Example of Level-1 Milestone Tracking: Comparison of Actual versus Planned Progress... 249
Table 4.6-1 Risk, Opportunity, and Threat per RIG Definition ..................................................................... 256
Table 4.6-2 Seven Risk Management Process Steps Per RI Life Cycle Stage ................................................ 259
Table 4.6.1-1 Example Risk Management Roles and Responsibilities Table............................................... 262
Table 4.6.2-1 Sample Risk Register ............................................................................................................... 264
Table 4.6.2-2 Known/Unknowns Risk Examples........................................................................................... 265
Table 4.6.3-1 Example Risk Matrix or Heat Map.......................................................................................... 269
Table 4.6.6.1-1 Example Risk Register Exposure Summation ..................................................................... 274
Table 4.6.6.2-1 Example of Risk Factor Tables Used to Calculate Total Project Cost Risk Exposure ......... 276
Table 4.6.6.3-1 Probability Distributions of Schedule Risk Impact Durations Based on Best, Most Likely, and
Worst-Case Duration Estimates ..................................................................................................................... 281
Table 4.7.3.1-1 Baseline Change Control Authority Levels .......................................................................... 299
Table 5.3.5-1 NSF Critical Controls Set ......................................................................................................... 314
Table 5.7.3-1 PMIAA Areas of Program Management Standards and Principles ....................................... 329
Table 5.7.3-2 Competency Assignment Guidance for Major Facility Management .................................... 331
Table 5.7.3-3 Competency Descriptions ....................................................................................................... 332
Document Number
14
1.1 Purpose and Scope
1.0
INTRODUCTION
1.1
PURPOSE AND SCOPE
Research Infrastructure Guide
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
The U.S. National Science Foundation (NSF) invests in Research Infrastructure (RI), which is
essential to the U.S. science, engineering, and education enterprise. NSF defines RI as any
combination of facilities, equipment, resources and services, instrumentation,
computational hardware and software that fosters research and innovation in any field, and
the necessary human capital in support of the same. The user base of RI must include
members of the research community beyond a single lab or institution. Historically, NSF has
supported diverse types of RI, including particle accelerators, detectors, radio and optical
telescopes, remote research stations, research vessels and aircraft, high-performance
computing, and geographically distributed observatories, as well as large-scale surveys and
data sets. In support of RI activities, the Research Infrastructure Guide (RIG) is provided to:
•
Articulate NSF’s oversight policies, processes, and procedures during each Major
Facility and Mid-scale RI life cycle stage. 1
•
Based on accepted program and project management good practices, provide
guidance to interested organizations in support of proposal development and
effective management of the activities funded under the award.
The RIG applies to Major Facilities and Mid-scale RI across all life cycle stages. These
categories of RI are designated based on the cost to construct, acquire, or implement them.
For the purposes of this Guide, the term project is associated specifically with the
Construction Stage for Major Facilities and implementation for Mid-scale RI, even though
project and program management elements may be associated with other life cycle stages.
Likewise, the term Total Project Cost (TPC) is only associated with the Construction Stage or
implementation award. For other life cycle stages, the term is either the proposed project
(Development, Design, and sometimes Disposition) or the Science Support Program
(Operations and Disposition), with the budget to execute the proposed activities referred to
as the award amount, either proposed or authorized. Major Facilities are RI with a TPC of $100
million or more, while Mid-scale RI have a TPC between the upper limit of the Major Research
Instrumentation (MRI) program, currently $4 million, and the lower threshold for a Major
Facility, as determined by statute in the 2017 American Innovation and Competitiveness Act
(AICA).
NSF typically supports RI activities from two appropriations: the Major Research Equipment
and Facility Construction (MREFC) and the Research and Related Activities (R&RA) accounts.
The MREFC account was created in 1995 as the Major Research Equipment (MRE) account to
1 There
are five stages in the Major Facility life cycle – Development, Design, Construction, Operations, and
Disposition. Chapter 2 NSF Life Cycle Oversight of this Guide describes each of these stages in more detail. Midscale RI have analogous stages, but they are less formalized than those for Major Facilities and NSF may play little to
no role in one or more of the stages.
Document Number
15
1.1 Purpose and Scope
Research Infrastructure Guide
fund the acquisition, construction, commissioning, and upgrading of significant science and
engineering infrastructure that Directorates could not otherwise support without a severe
negative impact on their budget for science programs. The R&RA account supports other RIrelated activities that the MREFC account is not authorized to support, including planning
and development, design, operations and maintenance, disposition, and scientific research. 1
There is no prohibition on using R&RA to construct and acquire Major Facilities if adequate
funding is available. Construction and implementation projects with a TPC of less than $100
million are generally supported by the R&RA account. Still, they can also be funded from
dedicated programs within the MREFC account, as determined by NSF and appropriated by
Congress.
The RIG is published by the Research Infrastructure Office (RIO), formerly the Large Facilities
Office (LFO), within NSF’s Office of Budget, Finance, and Award Management. 2 The guidance
flows from statutory requirements, NSF policies, and long-standing practices, including
industry good practices related to project and program management. As a result, the RIG is
updated periodically to reflect any changes in requirements or recommended practices. As
part of its RI Knowledge Management Program, NSF will continue to identify and adopt good
practices to improve agency oversight and Awardee management of RI projects and Science
Support Programs to enable the most efficient and cost-effective delivery of research tools
to the U.S. science, engineering, and education communities. 3 The RIG provides extensive
flexibility based on the size and technical nature of the proposed project or science program
supported by the RI. Proposing organizations are encouraged to use the flexibility provided
and document accordingly in the Design Execution Plan, Project Execution Plan, or Annual
Work Plan, as appropriate.
The terms must and should are used consistently throughout this Guide, adhering to federal
plain language principles. 4 Must conveys an obligatory action or legal requirement by the
Proposer or Awardee, whereas should signifies a strong recommendation or a good practice,
but not a mandatory requirement. This distinction is intended to ensure clarity between
requirements (either statutory or NSF policy), and project/program management good
practices to give appropriate flexibility, where possible, on the various types of RI awards
that NSF funds.
Production-level design and development may be included as part of a Construction Stage or implementation
award. What is considered “production-level design” varies based on the technical nature of the project and the
acquisition strategies used by the Awardee to deliver (i.e., produce) the various components. It can range from
prototyping activities, responses to design-build packages and development of detailed fabrication drawings
depending on what is appropriate for the selected vendors to accomplish the work under their sub-contract or
subaward. Production-level design normally includes some degree of value engineering.
2 LFO was renamed RIO in 2023.
3 https://researchinfrastructureoutreach.com/knowledge-gateway/
4 https://www.plainlanguage.gov/guidelines/conversational/use-must-to-indicate-requirements/
1
Document Number
16
1.2 RIG Document Structure
1.2
Research Infrastructure Guide
RIG DOCUMENT STRUCTURE
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
The RIG is organized as follows:
•
Chapter 1 Introduction. Introduces the RIG's purpose, scope, and historical
perspective, including pertinent legislation, NSF policy, and authorized award
instruments.
•
Chapter 2 NSF Life Cycle Oversight. An outline of the life cycle stages, and the
process and principles NSF uses during each stage for Major Facilities and Mid-scale
RI.
•
Chapter 3 Research Infrastructure Life Cycle Planning. A description of the
Awardee requirements for preparing and following the various detailed management
plans required by each life cycle stage.
•
Chapter 4 Fundamental Elements of Project Management. Expands the
compendium of several NSF key requirements and management principles. It
includes detailed descriptions of planning, acquiring, and managing Major Facility and
Mid-scale RI processes.
•
Chapter 5 Supplemental Guidance. Supplementary information on specific topics
concerning NSF’s role in the planning, oversight, and assurance of Major Facilities and
Mid-scale RI, including important explanatory and procedural information on
technological, financial, environmental, and human resource considerations.
•
Chapter 6 References, Chapter 7 Acronyms and Abbreviations, and Chapter 8
Lexicon. Reference materials and definitions of acronyms, abbreviations, and
terminology used in this Guide.
•
Chapter 9 Appendices. Includes auxiliary information relevant to construction
projects and Major Facilities, and the list of plans for each life cycle.
Document Number
17
1.3 Document Precedence and Award Instruments
1.3
Research Infrastructure Guide
DOCUMENT PRECEDENCE AND AWARD INSTRUMENTS
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
The organization receiving the NSF award, herein referred to as the Awardee, and NSF staff
need to be knowledgeable about the laws, regulations, and policies that pertain to RI awards.
NSF strives to ensure that its policies are consistent with higher authorities and appropriate
delegations of authority. In the event of a conflict between policies issued at a lower tier
versus policies issued at a higher tier, the higher tier policy will take precedence. Awardees
are urged to reach out to their Awarding Official (AO) for guidance as soon as possible any
time a conflict is identified. A general hierarchy of authorities for NSF is as follows:
Figure 1.3-1
General Hierarchy of Authorities
Award Terms and Conditions are typically considered to be in the same tier as NSF Policy
within the General Hierarchy of Authorities. However, Awardees are advised to consult their
AO any time a conflict exists between the terms and conditions of their award and any
regulation, policy, or guidance at any tier.
The Federal Acquisition Regulation (FAR) and the Uniform Guidance (2 CFR 200) are federal
regulations. The Proposal Award Policies and Procedures Guide (PAPPG), NSF Acquisition
Regulation, and the RIG are considered NSF policies, regulations, and guidance and are
publicly available. NSF internal guidance documents, such as the NSF Acquisition Manual, are
not publicly available and are referenced only for information purposes.
1.3.1
Award Instruments
The National Science Foundation Act of 1950 (Organic Act, Public Law 81-507, as amended)
establishes that NSF’s relationship with the scientific community is to fund and facilitate
scientific and engineering research and education programs, and to appraise the impact of
research upon industrial development and general welfare. NSF’s Organic Act further states
that NSF “shall not, itself, operate any laboratories or pilot plants” as other federal agencies do.
NSF makes awards to a variety of external parties (Awardees), including nonprofit
Document Number
18
1.3 Document Precedence and Award Instruments
Research Infrastructure Guide
organizations, universities, and the private sector, to undertake the design, construction and
operation of RI using a variety of award instruments.
NSF has the statutory authority to use a variety of award instruments including financial
assistance (grants and cooperative agreements [CA]), contracts, and Other Arrangements/
Transactions (OA/T) to fund scientific programs, RI, and to otherwise execute the agency’s
mission. The selection of award instruments is based on the primary purpose of the award,
the beneficiary of the award, and other factors. NSF’s responsibility is to oversee the
Awardee’s funded activities and assuring proper and effective use of taxpayer dollars in
support of the scientific enterprise. The Awardee is responsible for managing the day-to-day
activities funded under the award in accordance with the terms and conditions.
Post award requirements in executing the project or Science Support Program are based on
the award terms and conditions where necessary requirements from the funding
announcement (Notices of Funding Opportunities, Request for Proposal, Dear Colleague
Letter, etc.) and other foundational documents in the hierarchy as shown in Figure 1.3-1
above should be incorporated, either expressly or by reference. 1
1.3.1.1
Financial Assistance Awards – Grants and Cooperative Agreements
The Federal Grant and Cooperative Agreement Act of 1977, or Grant Act, (Public Law 95-224)
requires that executive agencies use financial assistance when the “principal purpose” of the
relationship between the agency and a non-federal entity is to “transfer a thing of value” to
the non-federal entity or “to carry out a public purpose of support or stimulation authorized by
a law of the United States.” Individual federal agencies also need to be authorized by law in
order to enter into financial assistance agreements. The NSF authorization to enter into
these types of agreements comes from Section 11(a) of the NSF Act (42 USC §1870).
2 CFR §200, Uniform Administrative Requirements, Cost Principles, and Audit Requirements for
Federal Awards (Uniform Guidance), provides a regulatory set of rules and requirements for
federal financial assistance awards. The NSF PAPPG, in conjunction with other supporting
documents incorporated by reference and the applicable award terms and conditions,
serves as NSF’s implementation of the Uniform Guidance. For example, the RIG is referenced
under the Research Infrastructure Proposals section of the PAPPG, among others.
In general, the reasons underlying the selection of financial assistance as the appropriate
award instrument for RI funded by NSF are when the science community is the primary
beneficiary and is receiving the thing of value, generally property and other deliverables such
as data. In addition, unless specified in the terms and conditions of the award, title to
property should vest with the Awardee. NSF should hold the title to assets as governmentowned property only in circumstances with clear operational benefits or other needs for NSF.
1 Funding
announcement refers to all methods used by NSF to announce a funding opportunity or actively soliciting
proposals, including Notices of Funding Opportunities, Requests for Proposals, Request for Information, Broad
Agency Announcements, Dear Colleague Letters, and Program Announcements. The precise method is specific to
the award instrument.
Document Number
19
1.3 Document Precedence and Award Instruments
Research Infrastructure Guide
Under CA, having a conditional interest in the title to property allows NSF to be involved with
disposition decisions, particularly on long-term Major Facility awards such as the Operations
Stage.
A grant is used when the Awardee is assumed to be able to successfully execute the activities
funded under the award without agency collaboration or participation and in full compliance
with published requirements. CA are to be used when substantial involvement by the federal
agency is expected. 1 While there is no government-wide definition of substantial involvement,
it includes such things as:
•
Participation by NSF in resolving technical, management, or scheduling problems.
•
NSF monitoring to permit specified kinds of direction or redirection of the work
because of relationships with other projects, organizations, or agencies.
•
The existence of established performance goals or agency requirements that need to
be met and reviewed by NSF before proceeding with additional objectives to another
stage of work or before receiving additional funding.
•
NSF approval prior to changes in senior/key personnel.
•
NSF approval and/or involvement in the source selection process or the development
of substantial provisions and resulting documents for proposed subawards and
subcontracts.
Grants and CA allow oversight and accountability mechanisms to be built into the award
terms and conditions, including flexibility to tailor award-specific requirements and add
performance metrics. CA, however, tend to allow for greater oversight due to substantial
government involvement. Under CA, NSF involvement is primarily to monitor the sufficiency
of progress to justify continued funding, ensure appropriate use of funding, often with NSF
approvals, and support adherence to award terms and conditions. However, award
administration and oversight activities may not be conducted for inspection or acceptance,
assuming overall control of the project, or for otherwise directing project activities. In
addition, NSF does not maintain the unilateral right to change or redirect work under the
agreement.
At NSF, many large RI awards consist of a master CA as an umbrella award, establishing the
overall basic provisions of the award and separate cooperative support agreements funded
individually under the master agreement. Each cooperative support agreement has its own
terms and conditions so that NSF can separately monitor the funded activities from the
overall objectives of the master CA. Typical uses include separating design from construction,
operations and maintenance from disposition activities, or other research activities cosponsored by other agencies.
For RI financial assistance proposals, the Awardee’s estimating system must be able to
prepare the budget in two formats: a Work Breakdown Structure (WBS) format and the
1 See
1104
2 C.F.R. §200.1 for CA definition. https://www.ecfr.gov/current/title-2/subtitle-B/chapter-XI/subchapter-A/part-
Document Number
20
1.3 Document Precedence and Award Instruments
Research Infrastructure Guide
standard NSF Budget Category format. The use of a WBS format is described further in
Section 4.2 Scope and Work Breakdown Structure. The NSF Budget Category format is
prescribed in the PAPPG and depicted in Table 1.3.1-1 below. The NSF Budget Category
format allows for entry of the proposed budget into NSF’s award system. For RI, it is the WBS
format that primarily supports the NSF cost analysis in alignment with U.S. Government
Accountability Office (GAO) good practices. In addition, the WBS format allows for monitoring
actual costs against the approved baseline budget and assessing progress against the plan.
If the elements of cost associated with each WBS element are binned and coded by the
appropriate NSF Budget Categories in the Awardees estimating and accounting systems,
then the proposed budget can be organized in both formats simultaneously. The cost data
can be sorted, reported, and analyzed for cost reasonableness in different ways.
Document Number
21
1.3 Document Precedence and Award Instruments
Research Infrastructure Guide
Table 1.3.1.1-1
NSF Financial Assistance Budget Category Format 1
NSF Financial Assistance Budget Categories
A – Senior Personnel
B – Other Personnel
B.1 – Postdoctoral Scholars
B.2 – Other Professionals (Technicians, Programmers, etc.)
B.3 – Graduate Students
B.4 – Undergraduate Students
B.5 – Secretarial – Clerical
B.6 – Other
C – Fringe Benefits
D – Equipment
E – Travel
E.1 – Domestic
E.2 – Foreign
F – Participant Support
F.1 – Stipends
F.2 – Travel
F.3 – Subsistence
F.4 – Other
G – Other Direct Costs
G.1 – Materials and Supplies
G.2 – Publication, Documentation, Dissemination
G.3 – Consultant Services
G.4 – Computer Services
G.5 – Subawards
G.6 – Other
H – Total Direct Costs
I – Indirect Costs
Due to their complex nature, the following requirements in the PAPPG have been or may be
modified through the funding announcement to accommodate Major Facility or Mid-scale RI
proposals:
•
Maximum length of Budget Justification(s) for the Proposal and Subaward: The Cost
Book and Basis of Estimate, including supporting information, are typically much
more extensive than five pages stipulated in Part I, Chapter II.D.2.f.
•
Maximum length of the Project Description and Supplemental Documents.
•
Requirements for certain RI-specific documentation such as the Design Execution
1 This
table does not include the lines for cost-share or fee that may also be relevant categories, especially for larger
awards. These lines don’t display by default but are available, if needed.
Document Number
22
1.3 Document Precedence and Award Instruments
Research Infrastructure Guide
Plan, Project Execution Plan, or Annual Work Plan.
The above list is not intended to be comprehensive. Proposing organizations should consult
the funding announcement for specific programmatic guidance.
1.3.1.2
Contracts
A federal contract is used primarily when supplies, property, goods, or services (including
construction activities) are being acquired for the direct benefit of the government. As a
result, title to all property vests with the agency. Federal contracts can also be used to fund
research and development activities, and for other purposes, where appropriate. The Grant
Act requires that an executive agency use a procurement contract when the principal
purpose is to:
•
To acquire, by purchase, lease, or barter, property or services for the direct benefit or
use of the United States government; or
•
When the agency decides in a specific instance that using a procurement contract is
appropriate.
Common examples of activities that should be considered for the direct benefit or use of the
federal government include, but are not limited to:
•
Construction, acquisition, maintenance, or upgrade of NSF-owned property, including
buildings and equipment.
•
Deliverables necessary for executing NSF’s mission or required for NSF by statute.
•
Training, conferences, or seminars for the benefit of NSF employees.
FAR, 48 CFR 1, is the principal regulation governing procurement activities for executive
agencies. The FAR reflects the codification and publication of uniform policies and
procedures for federal agencies to follow in the acquisition process. NSF supplements the
FAR with procurement regulations, policies, and procedures specific to NSF acquisitions in
its FAR supplement (NSF Acquisition Regulation, 48 CFR 25) and the NSF Acquisition Manual,
which is an internal NSF document. Requirements to follow the RIG are referenced in the
funding announcement and the award terms and conditions. In addition, contracts that
contain construction activities are subject to the Davis-Bacon labor standards and related
Acts.
For RI contracts, at minimum, the budget must be submitted in an appropriate WBS format
(see Section 4.2 Scope and Work Breakdown Structure). The WBS format supports NSF’s
proposal evaluation as well as post-award monitoring of progress against the plan, or
expenditures against the original proposed budget. The budget may also be required to be
presented in other formats as described in the funding announcement (i.e., Request for
Proposals).
Document Number
23
1.3 Document Precedence and Award Instruments
1.3.1.3
Research Infrastructure Guide
Other Arrangements/Other Transactions
Other Arrangements (OA) and Other Transactions (OT) are separate and distinct from
contracts and financial assistance but can be broadly used for scientific or engineering
activities. OA/T are considered non-procurement, non-assistance, contract-like instruments
that are generally executed as legally binding with enforceable terms and conditions. Using
OA/T can potentially enhance the relationship between the Awardee and NSF, broaden the
community response to funding opportunities, leverage investment in technology
development, and facilitate collaboration and innovation. Among other things, OA/T also
grant more flexibility to structure business relationships in numerous ways, including joint
ventures, partnerships, consortia, or multiple agencies joining together to fund an
agreement encompassing multiple providers. However, OA/T should not be considered a
panacea since the benefits described come with potential risks.
As stated above, the NSF’s Organic Act provides the agency with broad authority, within the
limits of available appropriations, to use OA. The Creating Helpful Incentives to Produce
Semiconductors and Science Act (P.L. 117-167) Section 10396 (42 USC § 19116) provided the
NSF Director the authority to use OT in carrying out activities of the Technology, Innovation,
and Partnerships Directorate. OT and OA may be used for similar purposes but are subject
to different statutory requirements. Internal NSF guidance pertaining to OA and OT are
included in the NSF Other Arrangements/Transactions Guide, an internal NSF document.
For all NSF awards, including OA/T, the budget must be submitted in an appropriate WBS
format (see Section 4.2 Scope and Work Breakdown Structure). The WBS format supports
NSF’s proposal evaluation and post-award monitoring of progress against the plan or
expenditures against the original proposed budget. The budget may also be required to be
presented in other formats as described in the funding announcement.
1.3.1.4
Review of Proposals and Awards
Major Facility and Mid-scale RI proposals considered by NSF, regardless of award instrument
type, are subject to appropriate pre- and post-award review and the appropriate internal
management approval process. The review process is generally described in the funding
announcement and/or the PAPPG with internal details for NSF staff included in the Internal
Management Plan for Major Facilities and the Management Plan for Mid-scale RI programs.
Reviews may include merit review (Intellectual Merit and Broader Impacts criteria),
programmatic/technical review, and periodic progress reviews. The level of review and
approval for CA and contracts will differ substantially from that required for standard grants,
as will the level of post-award oversight needed to ensure appropriate progress and proper
accountability for federal funds. This Guide provides additional information on the review
and approval processes for Major Facilities and Mid-scale RI.
Due to the rigor of the review process, funding constraints, changing NSF priorities, and
competing interests within the research community, only a limited number of RI projects and
Science Support Programs can be funded. To improve the chances of success with receiving
NSF support, organizations supporting RI should review any associated funding
Document Number
24
1.3 Document Precedence and Award Instruments
Research Infrastructure Guide
announcements carefully and become familiar with the entire contents of the RIG when
developing their proposals.
Document Number
25
1.4 Applicable Legislation and NSF Policy
Research Infrastructure Guide
1.4
APPLICABLE LEGISLATION AND NSF POLICY
1.4.1
Research Infrastructure
1.4.2
Major Research Equipment and Facilities Construction Threshold
1.4.3
Major Multi-User Research Facility Project – Major Facility
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
NSF defines RI as the combination of facilities, equipment, services, instrumentation, and
computational tools—including both hardware and software—that supports research and
innovation across any field. This also includes the human capital necessary to operate and
maintain these resources. RI must serve a user community that extends beyond a single
laboratory or institution. Major Facilities and Mid-scale RI are subsets of RI. Major Facilities
are RI with a TPC of $100 million or more, while Mid-scale RI currently have a TPC between
$4 million and $100 million. NSF's RI investments are described in the agency's annual
budget request to Congress.
The MREFC threshold for projects and programs is set by NSF and authorized by Congress
as part of the annual budget process.
Per Section 110 of the 2017 American Innovation and Competitiveness Act (AICA), a Major
Multi-user Research Facility project was initially defined as a science and engineering facility
project that:
•
Exceeds the lesser of
o
10 percent of a Directorate’s annual budget; or
o
Is funded by the major research equipment and facilities construction account,
or any successor account.
o
$100,000,000 in TPC; or
This language was subsequently amended by Section 267 of the National Defense
Authorization Act of FY 2021 by striking the text above and inserting the following:
MAJOR MULTI-USER RESEARCH FACILITY PROJECT. The term ‘major multi-user research
facility project’ means a science and engineering facility project that exceeds
$100,000,000 in total construction, acquisition, or upgrade costs to the Foundation.
NSF interprets the above to mean the TPC is defined by the investment in construction or
acquisition, not the operations or associated science program costs. If the TPC for a RI project
is above the Major Facility project threshold as defined by statute, it is considered a Major
Facility throughout its full life cycle.
For the purposes of this Guide, the term Major Facility is used throughout to equate to the
Congressional term Major Multi-User Research Facility.
Document Number
26
1.4 Applicable Legislation and NSF Policy
1.4.4
Research Infrastructure Guide
Oversight Requirements
The policies and procedures established in this Guide and supporting internal NSF guidance
documents fulfill the Major Facility oversight requirements in Section 110 of AICA 2017, as
listed below:
•
Prioritize the scientific outcomes of a major multi-user research facility project and
the internal management and financial oversight of the major multi-user research
facility project.
•
Clarify the roles and responsibilities of all organizations, including offices, panels,
committees, and directorates, involved in supporting a major multi-user research
facility project, including the role of the MREFC Panel. 1
•
Establish policies and procedures for the planning, management, and oversight of a
major multi-user research facility project at each phase of the life cycle of the major
multi-user research facility project.
•
Ensure that policies for estimating and managing costs and schedules are consistent
with the best practices described in the GAO Cost Estimating and Assessment Guide, the
GAO Schedule Assessment Guide, and the Office of Management and Budget Uniform
Guidance (2 CFR. Part 200).
•
Establish the appropriate project management and financial management expertise
required for Foundation staff to oversee each major multi-user research facility
project effectively, including by improving project management training and
certification.
•
Coordinate the sharing of the best management practices and lessons learned from
each major multi-user research facility project.
•
Continue to maintain a RIO to support the research directorates in the development,
implementation, and oversight of each major multi-user research facility project,
including by:
o
Serving as the Foundation’s primary resource for all policy or process issues
related to the development, implementation, and oversight of a major
multiuser research facility project.
o
Serving as a Foundation-wide resource on project management, including
providing expert assistance on nonscientific and nontechnical aspects of
project planning, budgeting, implementation, management, and oversight.
o
Coordinating and collaborating with research directorates to share best
management practices and lessons learned from prior major multi-user
research facility projects.
o
Assessing each major multi-user research facility project for cost and schedule
risk.
The MREFC Panel has been superseded with the Facilities Readiness Panel and the Facilities Governance Board.
See Chapter 2 NSF Life Cycle Oversight of this Guide for the roles and responsibilities of these governing bodies.
1
Document Number
27
1.4 Applicable Legislation and NSF Policy
•
1.4.5
Research Infrastructure Guide
Appoint a senior agency official whose responsibility is oversight of the development,
construction, and operations of major multi-user research facilities across the
Foundation. 1
Mid-Scale Project and Mid-scale Research Infrastructure
Per Section 109 of AICA, a Mid-scale RI project is research instrumentation, equipment, and
upgrades to major research facilities or other RI investments that exceed the maximum
funded by the MRI program and are below that of a major multi-user research facility project
(Major Facility).
Like Major Facilities, NSF interprets the above to mean the TPC is defined by the investment
in construction, acquisition, or implementation, not the design, operations, or associated
science program costs. If the TPC is within the Mid-scale RI project range as defined by statute
(currently $4M to $100M), it is considered Mid-scale RI throughout its full life cycle. Unlike
Section 110 for Major Facilities, Section 109 contains no statutory oversight requirements for
Mid-scale RI. Refer to Section 2.9 Mid-Scale Research Infrastructure Guidance for planning
and oversight requirements of Mid-scale RI as determined by NSF.
1.4.6
National Science Board Policy on Recompetition
National Science Board statement 2015-45 and resolution 2015-46 address competition,
renewal, and divestment of Major Facilities. NSF assesses whether to renew the award,
compete the management of, or otherwise dispose of a Major Facility through non-renewal,
transition, or divestment during the Operations Stage (see Section 2.7 Major Facility
Operations Stage).
1.4.7
NSF No Cost Overrun Policy
NSF’s No Cost Overrun Policy (NCOP) was codified for Major Facility projects in the fiscal year
(FY) 2009 Budget Request to Congress which reads:
NSF is implementing a No Cost Overrun Policy, which will require that the cost estimate
developed at the Preliminary Design Stage have adequate contingency to cover all
foreseeable risks and that any cost increases not covered by contingency be
accommodated by reductions in scope. NSF senior management is developing
procedures to ensure that the cost-tracking and management processes are robust and
that the project management oversight has sufficient authority to meet this objective. As
project estimates for the current slate of projects are revised, NSF will identify potential
mechanisms for offsetting any cost increases in accordance with this policy.
The policy has been continually reinforced in subsequent budget requests to Congress for
the purpose of instilling diligence and rigor in establishing the TPC at award and a strong NSF
oversight position for Major Facility projects. This policy does not apply to Major Facility
1 Chief
Officer for Research Facilities (see Section 2.1 NSF Staff Roles and Responsibilities for Award Management
and Oversight).
Document Number
28
1.4 Applicable Legislation and NSF Policy
Research Infrastructure Guide
Development, Design, Operations, or Disposition Stage awards, or to any Mid-scale RI award.
NSF’s implementation of the NCOP is defined fully in Section 2.6.1 Construction Award
Management and Oversight, but details are based on the award instrument used.
1.4.8
NSF Performance Metrics
In support of the Government Performance and Results Modernization Act (Public Law 111352), NSF has developed goals to measure agency performance based on the Awardee’s
Earned Value Management (EVM) metrics (see Section 4.5 Monitoring Progress Against Plan).
For projects that utilize EVM and are between ten and ninety percent (10-90%) complete, the
performance goal is to maintain overall cost and schedule variances at, or above, negative
ten percent (-10%). 1 When variances exceed negative ten percent, NSF considers what
actions it needs to take, if any, as the funding agency based on the circumstances.
1.4.9
Legislation on Congressional Notification of Total Project Cost
Increases
Congressional notification is required when there is reason to believe the Construction Stage
TPC may increase by 10% or more. Public Law 116-93, Section 518 reads:
If at any time during any quarter, the program manager of a project within the jurisdiction
of the Departments of Commerce or Justice, the National Aeronautics and Space
Administration, or the National Science Foundation totaling more than $75,000,000 has
reasonable cause to believe that the total program cost has increased by 10 percent or
more, the program manager shall immediately inform the respective Secretary,
Administrator, or Director. The Secretary, Administrator, or Director shall notify the
House and Senate Committees on Appropriations within 30 days in writing of such
increase, and shall include in such notice: the date on which such determination was
made; a statement of the reasons for such increases; the action taken and proposed to
be taken to control future cost growth of the project; changes made in the performance
or schedule milestones and the degree to which such changes have contributed to the
increase in total program costs or procurement costs; new estimates of the total project
or procurement costs; and a statement validating that the project’s management
structure is adequate to control total project or procurement costs.
EVM metrics become less meaningful when the project is outside of this percent complete range. NSF generally
monitors milestones to completion when above 90% complete.
1
Document Number
29
1.4 Applicable Legislation and NSF Policy
1.4.10
Research Infrastructure Guide
Legislation on Congressional Notification of Divestments of NSFowned Facilities or Capital Assets
The Science Appropriations Act of 2019 included the following under NSF’s Administrative
Provisions:
The Director of the National Science Foundation (NSF) shall notify the Committees on
Appropriations of the House of Representatives and the Senate at least 30 days in
advance of any planned divestment through transfer, decommissioning, termination, or
deconstruction of any NSF-owned facilities or any NSF capital assets (including land,
structures, and equipment) valued greater than $2,500,000.
This provision has been repeated annually and remains in force. Sections 2.8 Major Facility
Disposition Stage and 3.7 Disposition Stage Planning discuss the Disposition Stage of the
Major Facility life cycle and provide guidance and procedures associated with the divestment
of NSF-owned facilities covered by this legislative language. The disposition of NSF capital
assets valued greater than $2,500,000 is governed by the federal property management
requirements and award terms and conditions.
1.4.11
Build America, Buy America – BABA
When funds are awarded through financial assistance agreements, the requirements of 2
CFR 184, Buy America Preference for Infrastructure Projects, will apply to the project. 2 CFR
184.1(b) states that:
None of the funds made available for a federal award for an infrastructure project may
be obligated unless all the iron and steel, manufactured products, and construction
materials incorporated into the project are produced in the United States.
Additional information on the BABA requirements, including the criteria and necessary
justifications for requesting a waiver for BABA, can be found in the following:
•
CFR 184, Buy America Preferences for Infrastructure Projects
•
Office of Management and Budget Memorandum M-24-02, Implementation Guidance
on Application of Buy America Preference in Federal Financial Assistance Programs
for Infrastructure
Up to date guidance specific to NSF’s implementation of the BABA requirements, and the
process for requesting waivers, can be found on the agency’s website.
Document Number
30
2.1 NSF Staff Roles and Responsibilities for Award Management and Oversight
Research Infrastructure Guide
2.0
NSF LIFE CYCLE OVERSIGHT
2.1
NSF STAFF ROLES AND RESPONSIBILITIES FOR AWARD
MANAGEMENT AND OVERSIGHT
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
2.1.1
Overview
NSF is responsible for conducting pre-award review activities, overseeing the Awardee’s
funded activities, as well as assuring proper and effective use of taxpayer dollars in support
of the scientific enterprise. The Awardee is responsible for managing the day-to-day activities
funded under the award in accordance with the award terms and conditions.
The Research Infrastructure Guide (RIG) outlines the typical processes and expectations for
each life cycle stage of Major Facilities and Mid-scale Research Infrastructure (RI). However,
variations may arise due to the technical requirements and challenges associated with a
project or the objectives and operational characteristics of a specific Science Support
Program. The RIG provides inherent flexibilities so that proposals and awards can be
adapted to the unique nature of each facility while maintaining sufficient agency oversight.
Main Participants. The NSF participants with primary oversight roles and responsibilities,
including award management, are listed below and illustrated in the NSF organizational chart
in Figure 2.1.1-1 NSF Organization Chart of Staff with Primary Oversight of Major Facilities
and Mid-scale RI Projects.
Sponsoring Directorate. The NSF organization that proposes the project to NSF Leadership
and is committed to funding the pre-construction development and design activities,
eventual operations as a Science Support Program, and final disposition. The senior
management within the Sponsoring Directorate considers community inputs, disciplinespecific studies, advisory committee recommendations and internal NSF factors to prioritize
candidate projects, balancing risk with opportunities and competing demands for available
resources.
Program Officer (PO). 1 The NSF technical expert, typically a scientist or engineer, having
primary oversight responsibility for the activities funded under the award. 2 The PO works
within a Division or Section of the sponsoring Directorate. The PO’s primary responsibilities
depend on the award instrument used and include:
•
Acting as the research community’s primary interface to NSF.
•
Developing the Internal Management Plan for a Major Facility project, or the
1 NSF’s
Authorization Act of 2002, 42 U.S.C.1862n-4I, signed into law on December 19, 2002, restricts the choice of
the PO to be regular employees of NSF. The statutory language of the Act states:
“PROJECT MANAGEMENT. No national research facility project funded under the major research equipment and
facilities construction account shall be managed by an individual whose appointment to NSF is temporary.”
NSF has extended this requirement to Major Facilities in all life cycle stages
2 The PO may have a title such as Program Manager or Program Director.
Document Number
31
2.1 NSF Staff Roles and Responsibilities for Award Management and Oversight
Research Infrastructure Guide
Management Plan for a broader program that defines NSF’s strategy for conducting
reviews, managing risk, and providing oversight.
•
Under financial assistance, conducting merit and programmatic/technical reviews of
proposals, including evaluation of proposed costs, and recommending a proposal be
awarded or declined.
•
Participating in source selection activities including the evaluation of proposed costs
when contracts are used.
•
Preparing required programmatic justifications and documentation for review and
approval within NSF.
•
Monitoring Awardee performance post-award,
programmatic award terms and conditions.
including
compliance
with
Chief Officer for Research Facilities (CORF). As required by statute, this senior executive
has oversight responsibility for NSF major facilities across their full life cycle. 1 The CORF
advises the Director on all aspects of NSF Major Facilities and Mid-scale RI, collaborates
across NSF on the oversight of the research infrastructure portfolio, and is a liaison to the
National Science Board (NSB) Committee on Awards and Facilities. The CORF organization
resides within the Office of the Director and is staffed to support these oversight activities.
Research Infrastructure Office (RIO). The statutory role of RIO is to support the research
Directorates in the development, implementation, and oversight of Major Facilities, by:
•
Serving as the agency's primary resource for all policy or process issues related to the
development and implementation of Major Facilities.
•
Providing expert assistance on the nonscientific and nontechnical aspects of project
planning, budgeting, implementation, management, and oversight.
•
Coordinating and collaborating with research Directorates to share best
management practices and lessons learned from prior Major Facility activities.
•
Assessing each Major Facility construction project for cost and schedule risk.
This same role has been extended by the agency to the Mid-scale RI portfolio. Sharing of
lessons learned and good practices has also been extended to the scientific community
through RIO’s Knowledge Management program. 2
Based on its role, RIO is positioned within the Office of Budget, Finance and Award
Management (BFA). The Head of RIO works closely with the CORF Office on a routine basis
to help ensure NSF guidance supports full life cycle oversight of the Major Facility and Midscale RI portfolios. A designated RIO Liaison with subject matter expertise in project
management is assigned to each project and Science Support Program by the Head of RIO.
The RIO Liaison provides assistance in understanding NSF policy, processes, and procedures
American Innovation and Competitiveness Act of 2017, Pub. L. No. 114-329, § 110(a)(H), 130 Stat. 2969, 2975
(2017).
2 https://researchinfrastructureoutreach.com/knowledge-gateway/
1
Document Number
32
2.1 NSF Staff Roles and Responsibilities for Award Management and Oversight
Research Infrastructure Guide
and assures that necessary business-related oversight practices are followed.
Awarding Official (AO). The AO works within the Division of Acquisition and Cooperative
Support (DACS) and holds the responsibility for award planning, formation, and is the
delegated authority to obligate the government. For financial assistance, this is the Grants
and Agreements Officer. For contracts, this is the Contracting Officer (CO). The CO is
supported by a Contracting Officer’s Representative (COR), a role that may be filled by the PO.
The specific responsibilities of the AO are based on the award instrument used, but also
include:
•
Leading the NSF cost analysis and negotiating the final award budget.
•
Ensuring compliance with the award terms and conditions.
•
Providing approval or authorization for major subawards and subcontracts.
•
Acting as the primary point of contact with the Awardee for all business and financial
matters, including acceptance of all business-related submittals and reports.
Figure 2.1.1-1
NSF Organizational Chart Highlighting Key Staff with Primary Oversight and Management Responsibilities for Major
Facilities and Mid-scale RI, shown in gold with the Core IPT in Darker Gold.
Document Number
33
2.1 NSF Staff Roles and Responsibilities for Award Management and Oversight
2.1.2
Research Infrastructure Guide
Coordinating and Advisory Bodies
As shown in Figure 2.1.2-1 NSF Organization Chart of Coordinating Primary Staff with
Oversight of Major Facilities and Mid-scale RI, various groups within NSF provide
coordination and advice that is relevant to the oversight of the RI portfolio:
•
Integrated Project Team (IPT). The IPT provides coordinated agency oversight for
all technical, business, and strategic issues both pre- and post-award. For Major
Facilities, the IPT is formed when a project enters the Design Stage and continues
throughout Construction and Operations. The Core IPT consists of the PO, AO, and
the RIO Liaison who meet routinely, often with the Awardee, to deal with day-to-day
issues. Other members of the IPT are selected by the management of the Sponsoring
Directorate, in consultation with the PO, based on the life cycle stage and the related
agency risks. The IPT is chaired by the PO.
•
Major and Mid-Scale Facilities Working Group. The MMFWG promotes consistent
and effective programmatic oversight related to Major Facilities and Mid-scale RI
across the science Directorates. The MMFWG supports the Head of RIO by reviewing
internal and external agency guidance and promoting good practices and lessons
learned. Its members provide advice to the CORF Office and the Facilities Governance
Board regarding strategy, governance, and implementation issues, including advising
on the sufficiency and appropriateness of guidance documents developed by RIO.
•
Advisory Committees. Advisory Committees, and their subcommittees, which
comprise researchers and educators from the scientific community, advise the
Sponsoring Directorate on a wide variety of programmatic areas, including strategic
issues related to Major Facilities and Mid-scale RI programs when requested.
Figure 2.1.2-1
NSF Organization Chart of Coordinating and Advisory Bodies for Major Facilities and Mid-scale RI Indicated in Gold
Document Number
34
2.1 NSF Staff Roles and Responsibilities for Award Management and Oversight
2.1.3
Research Infrastructure Guide
Governing and Assurance Bodies
There are also governing and assurance bodies, shown in Figure 2.1.3-1 NSF Organization
Chart of Policy and Approval Bodies for Major Facilities and Mid-scale RI, that review and
make recommendations on the suitability and readiness, as well as on the allocation of
resources for the development, design, construction, and operation of Major Facilities,
according to the NSF strategic objectives.
•
Facilities Readiness Panel. Chaired by the CORF, the Facilities Readiness Panel
advises the NSF Director on project and programmatic readiness for advancement of
proposed Major Facility projects within the Design Stage. This includes the transition
from the Final Design Phase to the Construction Stage. Decisions on readiness to
enter the Design Stage and whether to include a proposed project in a future budget
request are strategic decisions made separately.
•
Facilities Governance Board. Chaired by the CORF, the Facilities Governance Board
makes recommendations to the NSF Director on all aspects of strategy and
governance of Major Facility and Mid-scale RI projects and programs. This review
includes significant NSF guidance documents and procedures as well as competition,
renewal, and disposition recommendations.
•
Director’s Review Board. Comprising senior representatives from Directorates and
Offices, the Director’s Review Board reviews materials associated with all topics to be
submitted to NSB, including Major Facilities and Mid-scale RI awards and activities
above certain funding thresholds.
Finally, there are entities also shown in Figure 2.1.3-1 NSF Organization Chart of Policy and
Approval Bodies for Major Facilities and Mid-scale RI that set NSF policy and that approve
the advancement, funding requests, and obligation of funds for the construction and
operation of Major Facility projects and Science Support Programs.
•
NSF Director. Responsible for the implementation of NSF policies and practice for
agency oversight of RI, and for proposing new Major Facility projects to the NSB, the
Office of Management and Budget (OMB), and Congress.
•
National Science Board. NSB advises on strategic-level agency policy for RI, and
reviews NSF’s proposed advancement of Major Facility projects, including budget
requests and Construction Stage awards. The NSB also provides guidance to the NSF
Director on Operations Stage awards that are above certain cost thresholds. By
statute, all projects funded from the Major Research Equipment and Facilities
Construction (MREFC) account require NSB authorization.
Document Number
35
2.1 NSF Staff Roles and Responsibilities for Award Management and Oversight
Research Infrastructure Guide
Figure 2.1.3-1
NSF Organization Chart of Policy and Approval Bodies for Major Facilities and Mid-scale RI Indicated in Gold 1
1 Refer
to Tables 2.3.4-1and 2.3.4-2 for a mapping of the Panels and Boards to the Major Facility life cycle stage and
NSF oversight responsibilities.
Document Number
36
2.2 Internal Management Plan
2.2
Research Infrastructure Guide
INTERNAL MANAGEMENT PLAN
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
The Internal Management Plan is the primary internal agency document that describes how
NSF plans, coordinates, and conducts oversight of a Major Facility during the Design,
Construction and Operations Stages. The Internal Management Plan is written around an
individual facility when in the Design or Construction Stages and either an individual facility
or a collection of facilities when in the Operations Stage. The primary purposes of an Internal
Management Plan are to:
•
Define in detail how NSF will conduct its programmatic and business-related
oversight activities, including internal and external reviews and required agency
approvals.
•
Describe how NSF will manage and mitigate agency-held risks.
•
Provide budget and schedule estimates for each life cycle stage including disposition
liabilities and lay out a strategy for intra-agency coordination.
•
Describe any necessary deviations from NSF policies and procedures based on the
technical nature of the project or Science Support Program, partnership agreements,
or the identified risks.
The Internal Management Plan is considered a living document that is first developed by NSF
during the Design Stage, normally the Conceptual Design Phase, and is used until final
disposition decisions are made. The Internal Management Plan is updated at transition
points between project life cycle stages, or as often as needed, to adjust review criteria and
NSF decision points. These updates include refined strategies for renewal or competition
and any plans for major upgrades or a technology refresh.
An Internal Management Plan is not required for individual Mid-scale RI projects. In
accordance with NSF policy on financial assistance, Mid-scale RI funding programs are
required to have a management plan that describes how the overall program, not the
individual awards, will be executed and overseen. Mid-scale RI programs awarded through
contracts may develop the equivalent of a management plan through the normal acquisition
planning process.
Document Number
37
2.3 Major Facility Process Introduction
2.3
Research Infrastructure Guide
MAJOR FACILITY PROCESS INTRODUCTION
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
This section describes the Major Facility life cycle as well as the major activities conducted by
NSF and the Awardee during each life cycle stage. Although certain steps and approvals are
required, flexibility exists in how each stage is implemented to accommodate the level of
prior investment by the funding partners, the technical nature of the project, and the
methods used to mitigate risks. Application of these flexibilities should be discussed with the
PO before proposal submission and eventually documented in the Design Execution Plan
(DEP), the Project Execution Plan (PEP), and the Annual Work Plan (AWP), as appropriate.
2.3.1
Major Research Equipment and Facilities Construction Account
As stated in Chapter 1 Introduction, NSF can fund Major Facilities and Mid-scale RI from
various funding accounts, but typically either the MREFC or the Research and Related
Activities (R&RA) accounts are used. In 1995, Congress created the Major Research
Equipment (MRE) account which provided funding to establish major science and
engineering infrastructure projects using no-year funding, meaning that funding could be
carried over between fiscal years until expended. The existence of reliable, long-term
appropriations funding enables NSF to maintain partnerships and to prevent cost overruns
due to schedule delays. The MRE account was renamed the MREFC account in 2005, but the
intent is the same. In accordance with legislation, the MREFC account is intended to:
•
Provide a dedicated account specifically for acquisition, construction and
commissioning of Major Facilities and other infrastructure projects, including major
upgrades to Major Facilities.
•
Prevent large periodic obligations from distorting the R&RA budgets of NSF
Directorates and their Divisions/Program Offices.
•
Ensure the availability of funding to complete large projects that are funded over
multiple years.
For Major Facilities, the MREFC account is specifically for the Construction Stage. It cannot be
used to support Awardee activities related to the Development, Design, Operations or
Disposition Stages as defined in this Guide. With Congressional approval, MREFC funding can
be used for activities related to construction, acquisition, commissioning, and other forms of
implementation of Mid-scale RI projects. NSF has used this flexibility, working with Congress,
to create dedicated Mid-scale RI programs within the MREFC account.
The MREFC threshold is set by internal NSF Policy (see Section 1.4.2 Major Research
Equipment Facilities Construction Threshold).
2.3.2
Eligibility for MREFC Funding
To be eligible for consideration for MREFC funding, each candidate Major Facility project
should represent an outstanding opportunity to enable scientific research, spur innovation,
Document Number
38
2.3 Major Facility Process Introduction
Research Infrastructure Guide
support education, and benefit society. Candidate Major Facility projects should also
anticipate developing transformative knowledge that has the potential to shift existing
paradigms in scientific understanding, engineering processes, and technology. Moreover,
each should serve the highest priority research and education needs that will persist well
beyond the often-lengthy processes associated with the Development and Design Stages.
In addition, a candidate Major Facility project should:
•
Be consistent with the goals, strategies, and priorities of NSF.
•
Establish a long-term capability accessible to an appropriately broad community of
users
•
Require large investments for construction/acquisition, over a limited period, such
that the project could not be supported within one or more NSF
Directorate(s)/Office(s) without severe financial disruption of their portfolios of
activities.
•
Have received strong endorsement, based on a thorough external assessment of
scientific merit, broader societal impacts, and prioritization within the relevant
science and engineering communities.
•
Be of sufficient importance that the sponsoring organization is prepared to fully fund
the costs of pre-construction planning, design and development, eventual operation
and maintenance (O&M), and associated programmatic activities with full awareness
of the magnitude of the long-term operations and eventual disposition costs.
•
Have been coordinated with partners to ensure complementarity and integration of
objectives and potential opportunities for collaboration and cost sharing.
•
Be technically feasible with a defined scope and a credible, risk-adjusted cost and
schedule.
Mid-scale RI projects funded through the MREFC account are expected to meet the
expectations outlined above, except where superseded by criteria described in a funding
announcement. Eligibility for MREFC funding for any Mid-scale RI program will be
determined by NSF in advance and specific review criteria will be described in the funding
announcement, if used.
2.3.3
Major Facility Life Cycles
The purpose of this section is to give an overview of the five NSF life cycle stages. Each stage
is expanded upon in the text further below in this chapter. For purposes of NSF oversight,
the Major Facility life cycle is characterized by the following five consecutive stages:
•
Development
•
Design
•
Construction
•
Operations
•
Disposition
Document Number
39
2.3 Major Facility Process Introduction
Research Infrastructure Guide
Each life cycle stage involves different activities as well as certain actions by NSF and the
Awardee that are necessary to advance the project to the next stage. These activities include
budget development, proposal review, internal NSF reviews and approvals to either advance
or request funding, and the creation of awards to support the proposed activities.
Descriptions of what is carried out during each stage, and criteria for entry and exit from
each stage, are described below, including the required documents and deliverables that are
discussed in detail in each life cycle stage section. A high-level graphic of the progression
through the stages is given below in Figure 2.3.3-1.
Figure 2.3.3-1
Progressive Steps in the RI Life Cycle Illustrating High-Level Review and Decision Points for Exit and Entry; the Design
Stage is Broken Down Further into Phases
2.3.3.1
Development Stage
The Development Stage is where initial ideas
Key Takeaway
from the science and engineering community
Approval of transition from Development
emerge, and a broad consensus is built around
Stage to the Design Stage does not imply
the long-term needs, priorities, and general
a commitment to advance any project to
requirements for a new or significantly the Construction Stage.
upgraded Major Facility. Investments in the
Development Stage by NSF, other government
agencies, or private interests can be focused or sporadic, but annual investments are usually
smaller than in the Design Stage. Investments are typically focused on studies, workshops,
evaluating potential partnerships, setting priorities across a broad landscape of potential
users, developing rough order of magnitude cost estimates and rudimentary schedules, as
well as technology development or prototyping. This stage can last ten years or more and
the cumulative investment over this period can be quite substantial.
Transition from the Development Stage to the Design Stage can be challenging to navigate
because it requires the Sponsoring Directorate to make a strategic decision about the
Document Number
40
2.3 Major Facility Process Introduction
Research Infrastructure Guide
priority of one project among many concepts that it is nurturing. In doing so, the Directorate
should carefully consider not only the importance of a proposed project to the research
community, but also the landscape of partnerships, federal and other funding, and risk. To
exit from the Development Stage, the Sponsoring Directorate sends a memorandum to the
CORF recommending that a project is ready to enter the Design Stage, normally at the
beginning of the Conceptual Design Phase. If entrance is proposed at a later phase in the
Design Stage, the recommendation should be to enter prior to the stage-gate review that
aligns with the technical readiness of the proposed project so that the review can be officially
conducted in support of subsequent agency decision making (see Section 2.5 Major Facility
Design Stage). 1 Depending on the point of entry, the CORF may conduct a senior leadership
review focusing on strategic agency, interagency, and science community issues prior to
making a recommendation to the NSF Director. The NSF Director may elect to consult with
NSB prior to acting on the recommendation. Approval of transition to the Design Stage does
not imply a commitment to advance the proposed project to the Construction Stage since
numerous decision points that could end NSF’s involvement in the proposed project (offramps) exist within the Design Stage.
2.3.3.2
Design Stage
The Design Stage is where detailed, risk-adjusted cost estimates, credible schedules,
technical specifications and drawings, and project management processes are developed by
the Awardee and reviewed by NSF. This is also the stage where budget requests to Congress
are considered, partnerships are formalized, and decisions are made to obligate
construction funding, if appropriated. The technology needed to construct RI may be
uncertain, unproven, or immature, requiring substantial refinement over a period of years.
Entrance into the Design Stage occurs following approval by the NSF Director and when the
Sponsoring Directorate obligates the necessary funding, following approval from the NSF
Director, to further refine the estimated scope, schedule, and cost. Although there is no
prescribed timeline, this stage typically lasts four to five years.
The cumulative pre-construction investment that occurs during the Design Stage can range
from five to twenty-five percent of total construction cost, depending on the complexity of
the proposed project, but amounts to about ten percent of the construction cost. The awards
for the Design Stage may be solicited or unsolicited.
Proposed projects may encounter off-ramp decision points that remove them from the
Design Stage due to:
•
Decrease in priority over the long term, or eclipse by other proposed projects.
•
Failure to satisfy milestones or other criteria defined in the DEP or NSF’s Internal
Management Plan.
A stage-gate review is a structured decision point at the end of a life cycle stage, where stakeholders evaluate the
project’s performance against its plan to determine if it should proceed to the next stage, be modified, or be
terminated. This process ensures that each stage aligns with the overall project objectives before advancing.
1
Document Number
41
2.3 Major Facility Process Introduction
Research Infrastructure Guide
•
Collapse of major external agreements.
•
Extensive estimated or actual cost increases.
•
Significant changes in schedule for design readiness or eventual construction.
•
Unexpected technical challenges.
•
Changes in the research community indicating eroding support for the project.
•
Any other reason the Director deems sufficiently well-founded.
As shown in Figure 2.3.3.2-1 below, the Design
Key Takeaway
Stage is divided into three phases: Conceptual
Design, Preliminary Design, and Final Design.
Successful completion of any stage-gate
Each Design phase is managed by the Awardee
review does not guarantee advancement
following the DEP and culminates in a rigorous
to the next phase.
NSF review of the developing and progressively
elaborated PEP to ensure technical and project management readiness for advancement to
the next design phase or into the Construction Stage. The document package submitted for
each stage-gate review should include an updated DEP that includes a proposed budget for
the next phase of the Design Stage to support an award, if approved for advancement. There
is no prescribed length for any of the Design Phases. The duration of the Conceptual Design
Phase and entrance to the Design Stage itself depend on the level of investment during the
Development Stage and the project’s technical maturity. The minimum duration of the Final
Design Phase is set by the federal appropriations process, specifically by the time between
submission of a Budget Request and appropriation of funding for a particular FY.
The Awardee’s successful completion of the current phase is necessary for advancement to
the next phase, but completion of any phase is not the sole guarantor for advancement to a
subsequent phase. NSF decision making following each stage-gate review is always a
potential off-ramp for the proposed project.
Document Number
42
2.3 Major Facility Process Introduction
Research Infrastructure Guide
Figure 2.3.3.2-1
Progressive Phases Within the Design Stage Illustrating Review and Decision Points and NSF Award and Budgeting
Authorization
Conceptual Design Phase. During this phase the technical requirements are refined,
feasibility is determined, and risks are mitigated, often through the development and testing
of prototypes, if not done during the Development Stage. By the end of this phase, the
estimated costs are parametric in nature (i.e., based on proportional comparisons to similar
projects or project components), there is a notional Integrated Master Schedule (IMS) with a
Critical Path based on major milestones, and a rudimentary risk analysis. The primary
deliverables for the Conceptual Design Review (CDR) are an updated and progressively
elaborated PEP along with an estimated cost and DEP for the Preliminary Design Phase. The
NSF cost analysis is conducted primarily to give the Awardee additional guidance on refining
the bottom-up cost estimate needed for the Preliminary Design Review (PDR). This phase
ends with either a decision to off-ramp the proposed project or an approval by the NSF
Director to advance and an award for the Preliminary Design Phase.
Preliminary Design Phase. During this phase, the Project Team produces a bottom-up cost
estimate, a near-final proposed scope, and a robust schedule (together known as the
Performance Measurement Baseline [PMB]), as well as a risk analysis of sufficient maturity
to inform the risk-adjusted Total Project Cost (TPC) necessary to request construction
funding. A FY for construction start is assumed and required annual funding increments are
developed to inform a potential budget request to Congress. The primary deliverables for
the PDR are an updated and progressively elaborated PEP, including the revised estimated
Document Number
43
2.3 Major Facility Process Introduction
Research Infrastructure Guide
TPC, and DEP for the Final Design Phase. The NSF cost analysis, including an Independent
Cost Estimate (ICE), is conducted to inform NSF’s budget request to Congress.
This phase ends with either a decision to off-ramp the proposed project or an approval by
the NSF Director to advance and an award for the Final Design Phase. Inclusion in a future
budget request to Congress is a strategic agency decision made separately from the decision
to advance, the latter being based on technical and project management readiness. In other
words, a proposed project can advance to the Final Design Phase without a decision on
budget inclusion being made. An assessment of a proposed project’s priority relative to other
proposed projects in the Design Stage, as well as a thorough consideration of potential risks
and opportunities, along with other factors, informs the agency’s decision to move forward
with a budget request to Congress.
Final Design Phase. During this phase, the final construction-ready design and PEP are
produced and the risk-adjusted TPC for the Construction Stage is confirmed to be within the
amount requested from Congress. The Awardee further refines the Project Definition (scope,
schedule, cost, and Key Performance Parameters [KPP]) and the PEP submitted at PDR and
also demonstrates that project planning and management processes meet NSF
requirements for readiness to receive funding and begin construction. The Final Design
Review (FDR) can also incorporate events or conditions that were unforeseen when the PDR
was conducted. This phase ends with either a decision to off-ramp the proposed project or
an approval by the NSF Director, in consultation with NSB, to make a Construction Stage
award.
These progressive stage-gate reviews, CDR, PDR, and FDR (see Section 2.5 Major Facility
Design Stage) are conducted via external panels of scientific, technical, and project
management experts. The panel advises NSF on the sufficiency of progress made during the
respective design phase and the technical readiness to advance to the next phase, including
project management capabilities of the Awardee’s team. NSF uses the findings and
recommendations from the external review, together with in-house financial and businessrelated analyses, as appropriate to the phase, as input to an internal NSF review by a Facilities
Readiness Panel. The Facilities Readiness Panel makes a recommendation to the NSF
Director on a proposed project’s readiness for advancement.
For proposed projects that have received previous development and design funding from
NSF, other agencies, or private sources, a Sponsoring Directorate can propose entrance to
the Design Stage at the CDR (bypassing the Conceptual Design Phase), or the PDR (bypassing
the Preliminary Design Phase) based on the technical maturity of the proposed project. The
PDR is the latest point at which a proposed Major Facility project can be considered a
candidate for funding since passing this design review is a requirement for consideration of
inclusion of the proposed project in a future budget request. The Final Design Phase must
always be conducted.
Document Number
44
2.3 Major Facility Process Introduction
2.3.3.3
Research Infrastructure Guide
Construction Stage
The Construction Stage begins when funds are obligated for the acquisition and/or
construction of the Major Facility in accordance with the terms and conditions of the
award(s). The award amount sets the TPC used by NSF under the No Cost Overrun Policy
([NCOP], see Section 1.4.7 NSF No Cost Overrun Policy). The Construction Stage typically lasts
four to ten years depending on the technical nature, scale, and complexity of the project.
This stage has the most stringent requirements for monitoring an Awardee’s performance
in managing the scope, schedule, and budget against the proposed plan, for reporting
progress to NSF and other partners, and for the use of other award oversight mechanisms
by NSF. Progress is reported against the approved PMB described in the Awardee’s revised
PEP, submitted following FDR. The project status is reviewed periodically by NSF and any
other funding partners, generally annually, to assess whether the Project Team is capable of
finishing it within budget and on schedule and what corrective actions, if any, might need to
be taken. The Construction Stage normally includes activities, such as commissioning and
testing, to transition the Facility into the Operations Stage. This stage ends after delivery and
acceptance of the defined scope of work and an initial assessment of a Facility’s performance
against the Key Performance Indicators described in the PEP. Some Major Facilities may not
achieve full performance capabilities until initial operations.
Although the Awardee for the Construction Stage assumes responsibility for initial
operations, this is not a requirement.
2.3.3.4
Operations Stage
The Operations Stage includes the day-to-day activities needed to operate and maintain the
various pieces of infrastructure associated with the Major Facility and to support scientific
research. The term O&M is often used, both of which require strong Awardee management
capabilities. Operations Stage awards may encompass one Major Facility or several and may
also include Mid-scale RI. This collection of RI may also be designated as a Federally Funded
Research and Development Center (FFRDC) if certain conditions are met. How the award(s)
is structured depends on the nature of the Science Support Program and the award
instrument(s) used. The Operations Stage typically lasts 20-40 years, the total cost of which
often greatly exceeds the cost of construction (see Section 3.6 Operations Stage Planning).
During the Operations Stage, the Major Facility is actively collecting, processing, and
distributing data for use by the science community. The Concept of Operations (ConOps)
Plan, as described in Section 3.5.10.2 PEP Subcomponent 10.2 – Concept of Operations Plans,
is refined during the Construction Stage (including robust O&M cost estimates and the
proposed governance model) is finalized in preparation for entering the Operations Stage
and used to inform the first AWP. Initial operations may include activities necessary to
complete the transition from construction to full operational capability. During the lifetime
of the Major Facility, activities will include routine refurbishment, recapitalization, and/or
technical refresh, and may also include major upgrades. The Operations Stage will eventually
include activities that support the transition of the Facility to the Disposition Stage.
Document Number
45
2.3 Major Facility Process Introduction
Research Infrastructure Guide
During the Operations Stage, NSF conducts periodic reviews that assess the performance of
the infrastructure and the Awardee(s). These reviews use external panels to make
recommendations that inform NSF oversight as well as periodic internal NSF decisions on
continued investment, either through award renewal or competition, or disposition.
2.3.3.5
Disposition Stage
The decision to enter a Major Facility or significant RI components of the Science Support
Program into the Disposition Stage is made when NSF, with input from the scientific
community, determines that the Major Facility is no longer a priority for NSF investment.
Disposal of equipment or system components as part of end-of-service life upgrades or
instrument replacements associated with periodic technology refreshes are not considered
entering the Disposition Stage, but rather routine property maintenance activities under the
award. The Disposition Stage is commonly associated with significant government action,
mainly when related to deconstruction (see Section 5.4 Environmental Compliance).
The disposition decision can occur at any time during the Operations Stage. Although the
decision may occur after the Science Support Program’s primary goals have been achieved,
it takes place after many years of operations to maximize the science output. Disposition
options include transfer to another entity’s operational and financial control (with or without
reduction in project scope) or decommissioning. This last option may include complete
removal of the infrastructure and site restoration. NSF periodically assesses the plan for
eventual disposition as part of Operations Stage reviews, Advisory Committee reviews, or
other internal assessments. The first high-level version of this plan is developed as part of
the Construction Stage PEP, but it is refined as the Major Facility nears the Disposition Stage.
Entrance into the Disposition Stage occurs when an award is made to cover the costs of
decommissioning, deconstructing, or transitioning the Major Facility to its new role.
Transitioning from the Operations Stage to the Disposition Stage usually takes the form of
an award that ramps down NSF’s investment over the award duration with the expectation
that no further operations award from NSF will be forthcoming.
2.3.4
Major Facility Execution Process Summary
NSF supports scientific investigation at the frontiers of human knowledge, where the
necessary technologies and methodologies are often not firmly established. The agency is
also responsible for nurturing the various science and engineering disciplines that it
supports. As a result, the various project life cycle stages may best be achieved through the
expertise of different organizations such as educational institutions, non-profits, or the
private sector (industry) depending upon the technical nature of the RI and the award
instrument selected. For example, NSF may provide researchers the funding sufficient to
develop compelling research agendas, to refine and prioritize their technical requirements,
and to complete research and development on prototypes and other needed technologies,
without assuming those researchers will have a direct role in managing either construction
or operations. Following successful research and development by scientists and engineers,
the entire project may then be further designed and constructed through an award made
Document Number
46
2.3 Major Facility Process Introduction
Research Infrastructure Guide
directly to a competent managing organization, including industry.
As the diagrams in Table 2.3.4-1 and Table 2.3.4-2 indicate, the typical process for preconstruction development and design for a proposed Major Facility project progresses
through a sequence of stage-gates with increasing investment, planning, assessment,
oversight, and assurance. These stage-gates help ensure that the technical evolution of a
proposed project is coordinated with science community needs and NSF requirements,
increasing the likelihood that it will qualify for funding of continued planning and eventual
construction.
Document Number
47
2.3 Major Facility Process Introduction
Research Infrastructure Guide
Table 2.3.4-1
Summary Timeline for Proposed Major Facility Projects in the Development and Design Stages
Document Number
48
2.3 Major Facility Process Introduction
Research Infrastructure Guide
Table 2.3.-2
Summary Timeline for Major Facility Projects and Science Support Programs in the Construction, Operations, and
Disposition Stages
Although all Major Facilities progress through the five life cycle stages, there are appropriate
alternate approaches to the Development and Design Stages, such as funding through
another agency or a private entity, and alternate approaches to upgrades during the
Operations Stage.
Facilities at the leading edge of scientific endeavor are always in motion. It is not uncommon
for Major Facilities to be in an almost continuous state of technical refresh or upgrade
following the transition to operations. Therefore, selecting the appropriate management
model and structure that matches the proposed activities is vital. Guidance is provided in
Section 3.2.1.1 Traditional Waterfall Approach and 3.2.1.2 Cyclical Approach, and 5.9 Agile
Guidance on selecting and tailoring the appropriate management method.
NSF upholds the principle that flexibility in managing Major Facility projects does not
compromise the rigor of the agency’s evaluation process. Every Major Facility project,
Document Number
49
2.3 Major Facility Process Introduction
Research Infrastructure Guide
proposed or otherwise, regardless of its specific nature or unique aspects, is held to the
highest standards of review and technical assessment, ensuring quality and accountability
throughout the process. The approach used by NSF and the Awardee to monitor
performance should be identified early in either the Development Stage and documented in
the Design Stage proposal as part of the DEP and eventually in the PEP, as well as in NSF’s
Internal Management Plan (see Section 2.2 Internal Management Plan). Proposing
organizations should discuss the approach envisioned with the cognizant PO.
Document Number
50
2.4 Major Facility Development Stage
Research Infrastructure Guide
2.4
MAJOR FACILITY DEVELOPMENT STAGE
2.4.1
Proposed Major Facility Project Initiation and Development
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
As with many NSF endeavors, inquiry begins with the research communities, whose
members alert NSF program staff to the most promising and exciting questions and the most
critical equipment, facilities, and infrastructure needed to explore them. The PO monitors
the emergence of breakthrough concepts and actively encourages discussion and planning
within the science community and across NSF. In addition, NSF uses National Academies’
studies, community workshop reports, professional society activities, Directorate advisory
committees, and many other methods to identify opportunities and ensure continuous
community input.
Ideas and opportunities identified by the research communities look well into the future and
are brought to NSF in the form of proposals requesting funding to imitate and/or continue
development activities. Considerations for the award might include:
•
Disciplinary trends and identified community priorities.
•
Transformative opportunities to advance science.
•
The portfolio balance between research infrastructure and science within the
Directorate or Division.
•
Availability of funds.
If a Sponsoring Directorate intends to propose a project for entrance into the more formal
Design Stage, then there should be adequate investment during the Development Stage
such that the proposed project is sufficiently well defined and at a level of technical maturity
that justifies entrance at the appropriate phase of Design.
2.4.1.1
Development Stage Oversight and Reporting
POs are solely responsible for most oversight activities during the Development Stage,
including conducting NSF merit review under financial assistance, recommending awards,
and monitoring post-award progress, including attendance at workshops and other
engagements funded under the award. Any required deliverables and reporting will be in
accordance with the terms and conditions of the award.
2.4.1.2
Development Stage Exit
Exit from the Development Stage occurs once the NSF Director approves a proposed
project’s entry to the Design Stage. This process is initiated by a request from the Sponsoring
Directorate to the CORF in the Director’s Office once a proposed project is determined to be
ready to advance and its state of technical readiness, which determines where it should enter
the Design Stage, is understood. Such a request is made when the Sponsoring Directorate
has determined the following.
Document Number
51
2.4 Major Facility Development Stage
•
•
Research Infrastructure Guide
The proposed project is a high priority for the scientific community and NSF, and
includes showing that:
o
The proposed project’s science (research) program will address one or more
science objectives, clearly demonstrating a compelling need for the project.
o
The proposed project has been evaluated by the research community and by
NSF, in consultation with Directorate Advisory Committees as appropriate, and
has been assigned a high priority.
The Sponsoring Directorate commits to invest in more detailed design activities using
Directorate or Division funding.
Regardless of where the proposed project is recommended to enter the Design Stage,
whether CDR or PDR, the formal written request is submitted to the CORF who makes a
recommendation to the Director with input from the Facilities Governance Board and other
senior agency officials. Based on CORF recommendations and other considerations, the
Director then either approves or disapproves the proposed project to enter the Design Stage
as a candidate Major Facility project. 1 The CORF or NSF Director might alternatively advise
the Sponsoring Directorate to look further into any issues identified and return them for
further consideration by the Office of the Director. If approved, no further NSF commitment
is implied beyond the Design Phase recommended.
1 Major Facilities are defined by their cost to construct or acquire, as described in Section 1.4 Applicable Legislation
and NSF Policy, not the account from which they are funded. The Sponsoring Directorate may propose the use of
Major and Mid-scale Equipment and Facilities Construction (MREFC) funding based on the criteria in Section 2.3.2
Eligibility for MREFC Funding, or Directorate funding. Major Facility oversight requirements are the same, regardless
of the funding account.
Document Number
52
2.5 Major Facility Design Stage
2.5
Research Infrastructure Guide
MAJOR FACILITY DESIGN STAGE
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
The Design Stage is divided into three phases, including the Conceptual Design Phase,
Preliminary Design Stage, and the Final Design Stage. However, a proposed project can enter
the Design Stage as late as the PDR based on technical readiness for advancement coming
out of the Development Stage. The following sections describe in more detail the goals,
oversight requirements, and exit criteria for each phase.
2.5.1
Conceptual Design Phase
The goal of this first phase of the Design Stage is the creation of a comprehensive conceptual
design that clearly articulates various project elements that NSF will evaluate when
considering advancement to the Preliminary Design Phase. These include:
•
A description of the RI and technical requirements needed to meet the objectives of
the science community or NSF, including a definition and relative prioritization of the
research objectives and science questions the proposed project will address.
Technical requirements must flow down from the science requirements.
•
A system-level design, including a definition of all functional requirements and major
systems.
•
The concept for eventual operations including an initial estimate of annual O&M
costs, a range of staffing levels, potential governance models, and other science
support activities.
•
An initial risk analysis and mitigation strategy for the Construction Stage, identifying
enabling technologies, high-risk or long-lead items, and research and development
activities needed to reduce project risk to acceptable levels.
•
Initial acquisition strategies that address any unique project considerations, technical
risks, and uncertainties, such as evolving technologies or design activities that would
continue into the Construction Stage.
•
Potential environmental and safety impacts to be considered in site selection (see
Section 5.4 Environmental Considerations. These may be site-independent, sitespecific, or include multiple proposed sites depending on the technical nature and
maturity of the proposed project.
•
The first iteration of the Project Definition to evaluate technical readiness. This
includes budget contingency estimates appropriate to a conceptual design level of
maturity that are based on the initial risk analysis and projections for the construction
and commissioning schedule (see Sections 4.3 Cost Estimating and Analysis and 4.4
Schedule Development, Estimating, and Analysis).
•
A description and proposed cost for the activities to be conducted during the
Preliminary Design Phase, if approved for advancement.
During the Conceptual Design Phase, there may be several coordinated and complimentary
Document Number
53
2.5 Major Facility Design Stage
Research Infrastructure Guide
activities taking place with the Awardee and NSF as shown in Table 2.3.4-1. The Awardee
focuses on executing the activities under the award in accordance with the DEP and the
award terms and conditions, with the primary deliverable being a revised PEP for
presentation at the CDR. NSF forms the IPT and conducts oversight in accordance with the
Internal Management Plan.
2.5.1.1
NSF Oversight and Conceptual Design Review
NSF oversight during the Conceptual Design Phase involves monitoring progress against the
latest DEP and terms and conditions of the award. The Core IPT is formed at this point, if not
done so already. NSF staff on the Core IPT typically attend periodic weekly Project Team
meetings and provide appropriate guidance to enable the Project Team to progress toward
and prepare for CDR. Formal, written monthly project reports are typically required by the
award terms and conditions, which NSF also uses to monitor progress. Use of Earned Value
Management (EVM) is not required during the Design Stage, but depending on the
complexity of the proposed project, the activities being conducted during the Design Stage,
and the desire of the Awardee to build EVM capacity in preparation for the Construction
Stage, and should be discussed with the cognizant PO. Based on progress, NSF may hold an
interim review, either using an external panel or NSF staff only, to provide more formal
recommendations to the Project Team.
The Conceptual Design Phase culminates in a CDR, where the revised PEP, along with a
revised DEP for at least the Preliminary Design Phase, is submitted for NSF review. NSF
subjects the CDR package to external review, applying appropriate NSF review criteria based
on the award instrument as given in the panel charge.
At CDR, the Project Definition is likely to have significant uncertainties. Cost estimates are
commonly parametric in nature. Contingency estimates, representing work scope not yet
fully defined but nevertheless essential to the completion of the proposed project, will be a
significant fraction of the total project budget estimate. Significant unknowns and
uncertainties often remain which will need to be addressed as the design advances.
Nevertheless, the system requirements, supporting budget estimates, risk analysis, and
forecasts of interagency and international participation should be detailed enough for NSF
to assess whether the proposed project warrants further funding.
In conjunction with the CDR, an initial high-level NSF Cost Analysis will be conducted (see
Figure 4.3.1-1). This analysis provides the Awardee with guidance on further refining the cost
and contingency estimates to meet NSF requirements during the Preliminary Design Phase
if approved for advancement. NSF will also conduct the necessary cost analysis of the
Preliminary Design Phase proposal, which is based on the latest DEP.
Document Number
54
2.5 Major Facility Design Stage
2.5.1.2
Research Infrastructure Guide
Conceptual Design Phase Exit
Exit from the Conceptual Design Phase requires:
•
Successful completion of the CDR and a recommendation for advancement by the
Sponsoring Directorate.
•
Facilities Readiness Panel review and recommendation to advance.
•
Approval for advancement to the Preliminary Design Phase by the NSF Director.
•
Sufficient funding and an award to support the Preliminary Design Phase in
accordance with the revised DEP.
2.5.2
Preliminary Design Phase
The goal of the Preliminary Design Phase is to refine the Project Definition to a point where
there is a complete set of KPP to meet science objectives. It should include a clearly defined
site-specific scope (excluding mobile platforms), a PEP, and an NSF Internal Management
Plan that address anticipated risks during design and construction. Additionally, it requires
a realistic cost estimate, based on identified risks, which can be confidently presented to the
NSF Director, NSB, OMB, and Congress for consideration for inclusion in a future NSF budget
request to support the Construction Stage. 1
During the Preliminary Design Stage, the design of the proposed project is developed to a
preliminary design level of maturity, which means that all significant subsystems and their
interconnections are defined, technical specifications and drawings are sufficient to proceed
with bid or the development of final construction drawings, and cost estimates are based on
vendor estimates or bottom-up engineering estimates. The overall project risk analysis is
bottom-up. The Work Breakdown Structure (WBS), Basis of Estimate (BOE), and ResourceLoaded Schedule (RLS) are further refined to reduce uncertainty relative to the earlier
conceptual design. The results of these refinements are reflected in the revised PEP.
Revisions to the PEP should also incorporate guidance or direction from NSF, which may be
informed by CDR panel recommendations and other oversight activities to be conducted
during the Preliminary Design Phase. Some activities may be included in the terms and
conditions of the Design Stage award. Activities and components of the updated PEP that
should receive attention during this phase include:
•
Demonstration that key technologies are feasible and can be industrialized if
required, plus any updated strategies for managing evolving technologies.
•
Environmental Assessments or Environmental Impact Statement, if applicable (see
Section 5.4 Environmental Considerations).
•
A Scope Management Plan that includes de-scoping options and scope opportunities
that can be implemented during construction to augment budget contingency, as
necessary.
1 For
guidance on contingency planning refer to Section 4.7 Contingency Estimating and Management. Confidence
levels must be in the 70-90% range following PDR depending on the technical nature of the project.
Document Number
55
2.5 Major Facility Design Stage
Research Infrastructure Guide
•
Implementation of a Project Management Control System and inclusion within the
preliminary design of an RLS. 1
•
Updated risk analysis including technical risks, partnership risks, regulatory issues
affecting construction, and any risk factors such as inflation, exchange rates and
market volatility of commodities beyond what is included in the BOE.
•
Updated acquisition plans and timeline, including clear milestones, justification, and
risk management considerations for transition to bidding and procurement.
•
Governance model for the proposed project during construction, including
preliminary partnership arrangements and international participation, oversight of
major subawards and contracts, organizational structure, and management of
Change Control.
•
Updated estimates for future operating costs, anticipated future upgrades, and
eventual disposition costs at the end of the Major Facility’s service life.
•
All costs must be in then-year dollars, since Congress typically funds Major Facility
projects of multiple years, an annual funding profile capable of meeting project
requirements is also provided.
The Awardee also provides a revised DEP, including estimated cost and schedule and any
anticipated risks and remaining risk mitigation strategies for the Final Design Phase to inform
a potential Final Design Phase award.
2.5.2.1
NSF Oversight and Preliminary Design Review
NSF oversight during the Preliminary Design Phase involves monitoring progress against the
latest DEP and terms and conditions of the award. NSF staff on the Core IPT typically attend
periodic weekly Project Team meetings and provide appropriate guidance to enable the
Project Team to progress toward and prepare for the PDR. The award terms and conditions
may require formal, monthly project reports, which NSF also uses to monitor progress.
Based on progress, NSF may hold an interim review, either using an external panel or NSF
staff only, to provide more formal recommendations to the Project Team.
The Preliminary Design Phase culminates in a
PDR, where the revised PEP is submitted for NSF
review, along with a revised DEP for at least the
Final Design Phase. NSF subjects the PDR package
to external review, applying appropriate NSF
review criteria based on the award instrument
used and as given in the panel charge.
Key Takeaway
The Preliminary Design Review has the
most stringent requirements and is the
most consequential as it informs a
potential budget request to Congress to
support the Construction Stage.
At PDR, the Project Definition is based on site-specific bottom-up estimates and alignment
with Government Accountability Office (GAO) good practices is expected. A fully resourced
1 See
Figure 4.3.3.3-1 Sample Project Control Systems Relationship Diagram for examples of Project Controls
systems inputs and outputs.
Document Number
56
2.5 Major Facility Design Stage
Research Infrastructure Guide
IMS is also expected, with KPP and science requirements clearly defined. The budget
contingency estimates should be a lower fraction of the total project budget estimate than
seen at CDR, with all significant known risks identified and likelihood and impacts presented
along with a statistical risk analysis and proposed confidence levels. Significant unknowns
and uncertainties may be minimal, and cost and schedule uncertainties may have decreased
since CDR as the design matured. System and sub-system technical drawings and
specifications should be available along with preliminary vendor quotes to the maximum
extent practicable. The management structure to complete Final Design Phase activities and
execute the Construction Stage (if funds are requested and appropriated) should be fully
formed, with the credentials of key staff presented. Interagency and international
participation should be formalized or on the path to formalization. If more than one site is
proposed, the cost for each site and the associated risks must be presented. This level of
rigor is necessary for NSF to assess whether the proposed project is sufficiently defined to
support a budget request to Congress in accordance with the NCOP (see Section 1.4.7 NSF
No Cost Overrun Policy), which requires a robust risk-adjusted TPC at PDR.
NSF will use the Awardee’s technical drawings and specifications to support the ICE required
by statute at the PDR. 1 The ICE is an input to the NSF’s second and more detailed cost
analysis, which informs the TPC for the Construction Stage used for the budget request to
Congress if the proposed project is approved for advancement. NSF will provide guidance to
the Awardee on any necessary refinements to the BOE in preparation for the Final Design
Phase. NSF also typically uses the Awardee’s Project Controls Plans presented at PDR to
begin the Earned Value Management System (EVMS) verification process. NSF will also
conduct the necessary cost analysis of the Final Design Phase proposal, which is based on
the latest DEP.
Depending on the award instrument, NSF may also elect to conduct a pre-construction
Business Systems Review (BSR), financial viability review, accounting system audit, or other
business-related reviews to ensure the Awardee’s processes, procedures, staffing, and tools
are suitable to receive a Construction Stage award. Such reviews and audits may also be
conducted during the Final Design Phase at the discretion of NSF. Processes, procedures,
and staffing are not mature enough during the Conceptual Design Phase to perform these
detailed reviews and audits.
2.5.2.2
Preliminary Design Phase Exit
A proposed project exits from the Preliminary Design Phase and enters the Final Design
Phase after the following have been completed:
•
Successful completion of PDR and support for advancement from the Sponsoring
Directorate.
•
A review and recommendation by the Facilities Readiness Panel for advancement to
1 American
Innovation and Competitiveness Act of 2017, Public Law No. 114-329 (Jan. 6, 2017).
Document Number
57
2.5 Major Facility Design Stage
Research Infrastructure Guide
the Final Design Phase.
•
NSF Director's approval to advance to the Final Design Phase.
•
Award to support the Final Design Phase.
The request for inclusion in a future budget request is commonly associated with
advancement to the Final Design Phase. However, advancement to the Final Design Phase
may be granted without proceeding with a budget request based on strategic agency
considerations.
2.5.3
Final Design Phase
The goals of the Final Design Phase are to develop the construction-ready PEP and confirm
that the latest estimated, risk-adjusted TPC is within the budget estimate provided to
Congress at a confidence level of 70%–90%. The Preliminary Design Phase PEP is further
refined and may incorporate events, conditions, or risks previously unforeseen at the PDR.
Revisions to the PEP should also incorporate guidance or direction from NSF, which may be
informed by PDR panel recommendations and other oversight activities during the Final
Design Phase, some of which may be included in the terms and conditions of the Design
Stage award.
Strategic considerations are not commonly part of the Final Design Phase since they are
considered before inclusion in a future budget request to Congress, which may not happen
in conjunction with the decision to exit the Preliminary Design Phase. As a result, there is no
set duration for the Final Design Phase. However, the first approximation should align with
the federal budget process which is a minimum of eighteen (18) months.
Activities and components of the updated PEP that receive particular attention during this
phase include:
•
Environmental Assessments or Environmental Impact Statement and Record of
Decision, if applicable (see Section 5.4 Environmental Considerations).
•
Final Project Definition including KPP, bottom-up cost and contingency estimates that
are in alignment with GAO good practices as described in Section 4.3.2 Characteristics
of a High-Quality Cost Estimate, and a fully integrated RLS that meets GAO good
practices as described in Section 4.4.2 Characteristics of a Reliable Schedule.
•
Updated Risk Register and risk analysis, including technical risks, partnership risks,
regulatory issues affecting construction, and any risk factors such as inflation,
exchange rates and market volatility of commodities beyond what is included in the
BOE.
•
A final Scope Management Plan that includes de-scoping options and scope
opportunities that can be implemented during construction to augment budget
contingency, as necessary.
•
Updated estimates for future operating costs, anticipated future upgrades, and
eventual disposition costs at the end of the Major Facility’s service life.
•
To the maximum extent practicable, final designs, specifications and work packages
Document Number
58
2.5 Major Facility Design Stage
Research Infrastructure Guide
can be put out for bid by industry. Depending on the technical nature of the proposed
project and the acquisition strategies used, certain bid packages may be timed to
coincide with the FDR and remain open until the planned Construction Stage award.
•
Industrialization of any key technologies or former prototypes needed for
construction.
•
Final acquisition plans and timeline for NSF concurrence, including milestone for NSF
concurrence on source selection.
•
Fully implemented Project Management Control System for project technical and
financial status reporting, including following EVMS EIA-748 guidelines.
•
Mature plans for Quality Assurance and Safety Management during construction and
plans for final acceptance.
•
Finalization of financial commitments with interagency and international partners for
the Construction Stage.
•
Refinement of the governance model for eventual operations with any interagency or
international partners, the ConOps, and budget estimates for the Operations Stage
(including anticipated upgrades) and Disposition Stage, as needed.
•
Completing recruitment and hiring of key staff to manage the Construction Stage.
2.5.3.1
NSF Oversight and Final Design Review
NSF oversight during the Final Design Phase involves monitoring progress against the latest
DEP and terms and conditions of the award. NSF staff on the Core IPT typically attend
periodic weekly Project Team meetings and provide appropriate guidance to enable the
Project Team to progress toward and prepare for the FDR. The award terms and conditions
typically require formal, written monthly project reports, which NSF also uses to monitor
progress. Based on progress, NSF may hold an interim review, either using an external panel
or NSF staff only, to provide more formal recommendations to the Project Team.
The Final Design Phase culminates in FDR
Key Takeaway
where the revised PEP is submitted for NSF
review. NSF subjects the FDR package to Final Design Review delivers the
external review, applying appropriate NSF construction-ready PEP and confirms that
the latest risk-adjusted TPC remains within
review criteria based on the award instrument
the budget request to Congress at a 70as given in the panel charge. Like CDR and PDR,
90% confidence level.
the PO organizes the review in consultation
with the RIO Liaison and AO, who provide
business and project management related inputs to the panel charge, panel membership,
and review agenda.
At the FDR, NSF will use the Awardee’s technical drawings and specifications to support the
ICE required by statute, if not conducted with PDR. If an ICE was conducted at the PDR, NSF
may revisit the ICE as an input to the NSF’s third and final cost analysis to inform the TPC for
the Construction Stage award if the proposed project is approved for advancement. NSF will
Document Number
59
2.5 Major Facility Design Stage
Research Infrastructure Guide
provide guidance to the Awardee on any necessary refinements to the BOE in preparation
for the Construction Stage Award. NSF also uses the Awardee’s Project Controls Plan
presented at PDR to begin the EVMS acceptance process, which is generally completed
complete prior to the start of physical construction in accordance with NSF practice.
2.5.3.2
Final Design Phase Exit
A proposed project exits from the Final Design Phase and enters the Construction Stage after
the following have been completed:
•
The successful completion of the FDR and support for advancement from the
Sponsoring Directorate.
•
A review and recommendation by the Facilities Readiness Panel for advancement to
the Construction Stage.
•
The NSF Director approves advancement and recommends NSB authorization for a
Construction Stage award,
•
A review of the NSB package by the Director’s Review Board.
•
NSB authorizes a Construction Stage award.
•
NSF makes a Construction Stage award.
2.5.3.3
Approval by NSF Director – Transition to Construction Stage
The Director evaluates the Facilities Readiness Panel recommendation and, if satisfied,
recommends to NSB that a Construction Stage Award be authorized. In the event the
proposed project’s construction estimated TPC or funding profile is determined to be
inconsistent with the budget request to Congress or available appropriations, NSF may:
•
decrease the scope of the project, or
•
justify the increase to OMB and Congress and request additional funding as part of
the budget process, or
•
cancel (off-ramp) the project.
2.5.3.4
National Science Board Authorization for Construction
NSB reviews the recommendation and, if satisfied, authorizes the NSF Director to obligate
funds for a Construction Stage Award(s) at their discretion. If it does not authorize the
Construction Stage award, NSB may recommend to the Director that the proposed project
remain in the Final Design Phase or that the proposed project be cancelled (off-ramped).
Following the Director’s subsequent approval to obligate funds, the final award terms are
negotiated between NSF and the Awardee, and the award is made. Construction activities
begin in accordance with the PEP, which is normally incorporated by reference in the award
terms and conditions.
The authorized TPC establishes the not-to-exceed cost under the NCOP. The practices that
NSF uses to implement and manage against the NCOP are described in Section 1.4.7 NSF No
Document Number
60
2.5 Major Facility Design Stage
Research Infrastructure Guide
Cost Overrun Policy.
Document Number
61
2.6 Major Facility Construction Stage
2.6
MAJOR FACILITY CONSTRUCTION STAGE
2.6.1
Construction Award Management and Oversight
Research Infrastructure Guide
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
After Congress appropriates funds for the project, NSF can proceed with a Construction
Stage award with authorization from the NSF Director. The primary document used by the
Awardee to manage the project and for NSF to monitor progress and performance during
the Construction Stage is the PEP. NSF’s primary oversight tool in controlling costs is the
NCOP, as described in Section 1.4.7 NSF No Cost Overrun Policy. The NCOP is intended to
instill diligence and rigor in establishing the risk-adjusted TPC with Congress and give NSF a
strong oversight position during the Construction Stage.
2.6.1.1
Implementation of NSF’s No Cost Overrun Policy
Although the first risk-adjusted TPC is presented to Congress in the initial budget request for
a project in accordance with the NCOP, the Construction Stage award establishes the TPC
against which the agency implements the policy. Mechanisms for offsetting potential cost
increases include, in order of precedence and assuming appropriate use of each mechanism
in accordance with NSF policy and practice:
1. Re-planning. 1
2. Use of budget contingency for known risks. 2
3. De-scoping in accordance with the Scope Management Plan.
4. Use of management reserve for unforeseen events and agency-held risks, if
authorized.
5. Re-baselining and seeking re-authorization of the TPC through either the NSF
Director’s delegated authority or engaging the NSB in accordance with NSF policy
NSF uses the following practices to implement NCOP:
•
The determination of budget and schedule contingencies must include a combined
cost and schedule risk analysis using Monte Carlo methods and selecting a confidence
level in the 70-90% range at the PDR. At the FDR and the award for construction, it is
confirmed that the confidence levels remain within this range when compared
against the budget request and anticipated appropriations.
•
To assess risk exposure, a combined cost and schedule risk analysis using Monte
Carlo methods should be rerun at least annually.
•
NSF Directorates are responsible for the first 10% of cost overruns that exceed the
1 See
definition of Re-planning in Chapter 8 Lexicon. Re-planning is nearly continuous on most projects and may
include rebudgeting between WBS elements in accordance with the terms and conditions of the award.
2 This captures the use of schedule contingency since schedule extensions normally have a corresponding cost
factored into the budget contingency (see Section 4.7 Contingency Estimating and Management).
Document Number
62
2.6 Major Facility Construction Stage
Research Infrastructure Guide
authorized TPC, as determined by the NSF Director.
•
Identified de-scoping options should have a total value equal to at least 10% of the
baseline budget at the PDR.
•
Scope opportunities cannot be added after the start of the Construction Stage. The
Awardee should anticipate NSF de-obligating any unused funds.
•
Although the initial TPC becomes public through the budget request to Congress after
the PDR, the TPC under the NCOP is set at the Construction Stage award (post-FDR).
This allows for further refinement of the Project Definition during the Final Design
Phase.
•
NSF will hold budget contingency through project completion, in an amount up to
100% of the total NSF-approved contingency budget, until it can be justified for
obligation. NSF will obligate and allocate contingencies based on the needs and
performance of the Awardee.
•
The overall status of remaining contingency, future liens on contingency, and all
allocations and returns of contingency funds (as risks are realized or retired) are
reported periodically as specified in the terms and conditions of the award. At a
minimum, balances will be monitored against the total NSF-authorized budget
contingency and the amount of budget contingency obligated and allocated to date.
•
Although use of contingency is traceable as a take from the contingency budget, once
applied, contingency becomes part of the PMB and is no longer separately identifiable
as contingency once incorporated.
If there is reason to believe that re-baselining will require additional funding above the NSFauthorized TPC, the Sponsoring Directorate will notify the CORF. In accordance with statute
(see Section 1.4.9 Legislation on Congressional Notification of Total Project Cost Increases),
NSF is required to notify Congress in writing within 30 days when there is reasonable cause
to believe that the TPC will increase by 10% or more.
2.6.1.2
Construction Stage Reporting and Reviews
During the award period of performance, the Awardee provides periodic financial and
technical status reports to NSF according to the terms and conditions of the award.
Construction Stage reports are typically monthly and include the following:
•
Project Status. A narrative to include the accomplishments and challenges during
the reporting period, including major scientific and/or technical accomplishments and
milestones achieved. Management information such as changes in Key Personnel
(KP), budget issues, subaward/contractor performance, as well as any other
information about which the PO needs to be aware should also be included.
•
Current Photos. Recent photos with a written description and acknowledgments.
•
High-level Depiction of the Integrated Master Schedule. Chart or table of
performance reporting milestones pulled from the IMS, indicating which are on the
baseline Critical Path, the current PMB and forecasted completion date, and other key
Document Number
63
2.6 Major Facility Construction Stage
Research Infrastructure Guide
milestones on which EVM is based.
•
Financial Summary and Projections. A narrative describing the amount of
construction funding obligated by NSF to the Awardee to date and the costs incurred
to date, including a discussion of Earned Value metrics with attention to changes from
the prior month, an estimate of the risk exposure for completing remaining scope
compared to actual remaining contingency funds and a funding summary and
projections indicating actual funding and projected funding by FY.
•
Earned Value Management Data Table. Earned Value metrics (Budget at
Completion, Cost Variance, Earned Value, Actual Cost, Cost Variance, Cost
Performance Index, Schedule Variance, Schedule Performance Index, Estimate at
Completion, Estimate to Complete) extending to at least WBS Level 2; Percent
Complete (Planned and Actual), Scheduled and Budget Spent percentages; PMB and
forecast completion dates, remaining budget and schedule contingencies; and risk
exposure.
•
Total Construction S-Curve. S-curve showing the Actual Cost of Work Performed
(ACWP) with the Budgeted Cost of Work Performed by quarter within each FY up until
the present quarter; and the Budgeted Cost of Work Scheduled for those quarters
and extending to the end of the Construction Stage.
•
Twelve-Month S-Curve. S-curve table depicting the same data as the previous table
in a twelve-month snapshot centered on the month of the report.
•
Schedule Variance/Cost Variance and Cost Performance Index/Schedule
Performance Index Trend Graphs. Cost and schedule variances and performance
indexes (Cost Variance and Schedule Variance, Percent Cost Variance and Percent
Schedule Variance, Cost Performance Index, and Schedule Performance Index) over
a rolling twelve-month period.
•
Discussion of Variances and Corrective Actions. Review of current or anticipated
problem areas and corrective actions in a variance report at an appropriate control
account, work package, or WBS level as agreed upon with NSF for all cost and
schedule variances > ±10%, including explanation of causes, impacts at completion,
and management actions. 1
•
Contingency Balances. Available total balances of budget and schedule contingency,
as a total amount (dollars or calendar days) and for budget contingency as a
percentage of the Estimate to Complete; a Liens List of projected amounts of possible
future calls on contingency; an updated Change Log indicating all contingency use
(puts and takes) and available balances against both the total authorized amount and
the amount obligated and allocated to date.
•
Risk Management. Identify top risks, including the probability-weighted cost
exposure and trigger dates; a narrative on risk updates, including new risks, revised
1 Variance
reports provided by Awardees are used by NSF in its metrics for construction project performance goals, in
accordance with the GPRAMA of 2010 (see Section 1.4.8 NSF Performance Metrics).
Document Number
64
2.6 Major Facility Construction Stage
Research Infrastructure Guide
estimates of impact, mitigation strategies, etc.; update remaining risk analysis results
(at least annually).
2.6.1.3
Construction Stage Reviews
NSF conducts periodic external panel reviews that examine technical progress (including
quality of deliverables) and performance by the Awardee in executing the project on cost
and schedule and within scope. In conjunction with the periodic Construction Stage review,
NSF will conduct an EVMS surveillance review as needed. These reviews are commonly held
at the work site or the Awardee(s) institution and conducted annually. More frequent NSF
reviews may be scheduled based on the project’s expenditure rate or due to any technical
or management issues that arise.
The external panel reports directly to NSF and provides advice to NSF in accordance with the
panel charge. 1 The reviews are organized and conducted by the PO in consultation with the
RIO Liaison and AO. The PO is responsible for organizing the review and, throughout the
review process, acts as the interface between NSF and the Awardee. The PO authors the
review charge and organizes the review panel. The RIO Liaison and AO strengthen the review
process by specifying language for incorporation within the charge and for aspects of the
review agenda pertaining to project management and business-related issues and
recommending panelists able to advise NSF in non-science related areas of the review.
Because panel recommendations are to NSF and not the Awardee, NSF will typically issue
written guidance to the Awardee for subsequent response and action leveraging
recommendations from the panel report.
Change during the Construction Stage is expected to be continuous. However, the Awardee’s
project management team needs to respect the PMB, maintaining each adjustment to the
PMB in adherence to the Change Control process outlined in the PEP. This method allows
the Awardee and NSF to systematically track the evolution of the PMB from its initial release
through all subsequent changes.
2.6.1.4
Re-planning
Modifications to the PMB that are within the defined scope and do not change the Total
Project Duration (TPD) or TPC are referred to as re-planning. Re-planning may be due to
adjustments or re-organization of the project plan and/or may signify that contingency is
being used as expected. If the allocations of budget and schedule contingency are below the
budget or schedule thresholds identified in the award instrument (Cooperative Agreement
or contract agreement) between NSF and Awardee, the Change Requests are approved
unilaterally by the Project Team. NSF approval is required when the Change Control Board
recommends re-planning actions that exceed the agreed-upon budget or schedule
Many Projects conduct internal reviews to advise their senior management, such as the Project Director (PD) or
Project Manager (PM) or other technical leads, on the readiness of plans or technical progress. Such reviews are not
a substitute for NSF-organized external oversight reviews.
1
Document Number
65
2.6 Major Facility Construction Stage
Research Infrastructure Guide
thresholds. Approval levels for scope changes are typically outlined in the award instrument.
Minor changes in scope may also fall under re-planning activities. The Project Team
maintains a Scope Management Plan (see Section 3.5.3.2 PEP Subcomponent 3.2 – Scope),
which describes the process for maintaining control of the scope and outlines scope changes
that can be implemented depending upon the Awardee’s forecast of its ability to complete
the project within the approved TPC and TPD. The Awardee can implement minor de-scoping
options or defer scope through the Change Control Process if necessary to maintain the
contingency amount as part of the strategy to prevent potential cost overruns. It can also
elect to implement project enhancements that are within the existing scope of work
definitions, following the project Change Control Process and approval process as set in the
award or contract terms and conditions.
2.6.1.5
Re-baselining
While Project Managers (PM) typically describe any change to the PMB as a re-baseline, rebaselining from an NSF oversight perspective occurs when the overall boundary conditions
of the award change. These include:
•
Increases in the NSF-authorized TPC.
•
A project schedule extension requiring an increase to the award duration.
•
Significant changes in scope beyond the items listed in the NSF-approved Scope
Management Plan.
When the proposed changes reach the re-baselining level, the approval process may involve
the highest levels of NSF management and leadership, including NSB, in accordance with
NSF policy and practice. For re-authorization of the TPC, refer to the NCOP section earlier in
this section. For changes in the project end date, NSF will follow the award extension policies
based on the award instrument utilized; approval of the Director and notification to NSB may
be necessary. Like the use of budget contingency, the use of scope contingencies should
follow the Change Control Process, including appropriate NSF approval thresholds. NSB may
be consulted on any major changes in scope beyond those listed in the Scope Management
Plan to help determine if the project is still scientifically viable.
Re-authorization of the TPC following a reKey Takeaway
baseline is not guaranteed, and major changes
in scope can negate the project’s original goals.
Re-authorization of the Total Project Cost is
On rare occasions, Major Facility projects under
uncertain, and significant changes in scope
construction may encounter unforeseen
may lead NSF to terminate or substantially
budget, schedule, technical, or programmatic
modify the original project goals.
challenges that are substantial enough to be
considered grounds for termination or significant modification to the original project goals. 1
Joint NSB-NSF Management Report: Setting Priorities for Large Facility Projects Supported by the National Science
Foundation (NSB-05-77); September 2005.
1
Document Number
66
2.6 Major Facility Construction Stage
Research Infrastructure Guide
At an appropriate time, approaching or following completion of construction, NSF will
conduct a final Construction Stage review. This review is intended to assess the extent to
which the required scope was delivered or will be delivered, in accordance with the PEP and
award terms and conditions.
2.6.2
Construction Award Extension and Close-out
2.6.2.1
Project Close-out Process
As the project nears completion, close-out activities will become a regular discussion
between NSF and the Awardee. All NSF awards have final reporting and close-out procedures
to ensure funds have been properly used and the objectives met.
One step in the award-close-out process is for the Awardee to submit a final project report
that should clearly map the accomplishments and deliverables to those articulated in the
PEP and the terms and conditions of the award. The outcome of the final Construction Stage
review may inform the final project report. The final steps will involve the close-out of the
financial and administrative award, which may take up to two years to complete beyond the
project's end date. This period is used to reconcile final invoices and indirect cost rates and
de-obligate any remaining funds.
2.6.2.2
Schedule Extension
Since nearly all schedule changes impact cost,
the Awardee should exercise sound project Key Takeaway
management practices and continually strive to NSF does not have a No Schedule Extension
meet the original project schedule. However,
Policy; therefore, Awardees should utilize
this is not always possible for various reasons.
all available risk management tools to keep
the project at or below the authorized Total
The primary goal is to utilize all available risk
management tools to bring the project in at or Project Cost.
below the authorized TPC. The process of
extending the award duration without increasing the authorized TPC depends on the award
instrument used. NSF does not have a No Schedule Extension Policy, but a project is
technically re-baselined when the award duration is extended as stated above.
Even if the award duration is extended, project management good practice suggests that all
activities that can be closed out by the original award end date should be. In other words, all
risks and contingency liens for those tasks can also be closed out, and no funds should be
carried forward for remediation of risks related to those tasks. The close-out of completed
tasks also allows for a more precise calculation of remaining cost variance and/or
contingency needs, which facilitates good decision-making on the part of the Awardee and
NSF. To help justify the award extension without incurring any additional cost, the
appropriate documentation should be provided to NSF that shows:
•
A list of the tasks to be completed during the extension period and justification that
they are within the approved project scope including:
Document Number
67
2.6 Major Facility Construction Stage
Research Infrastructure Guide
o
Associated WBS element and a short justification of how the tasks fit within
existing project scope.
o
The total burdened estimated cost for each task and any associated risks (by
Risk ID)
o
One or more of the following categories: (1) open purchase orders and
invoices associated with items whose delivery is delayed beyond the current
award period of performance, (2) rework of existing tasks within the approved
scope due to workmanship or performance issues, (3) existing tasks within the
approved scope that have not yet been completed, and (4) activities to address
remaining performance issues of completed tasks.
•
An indication of which tasks are potential late-stage de-scoping options if resources
(time, staff, budget, etc.) become limited. 1
•
An indication of which tasks from the Scope Management Plan are likely potential
scope opportunities, assuming approval from NSF.
•
A description of what funds will be used to complete the proposed tasks, such as
remaining contingency if associated with a known risk and risk mitigation,
unexpended PMB budget, positive Cost Variance, or partner funds.
•
The Estimate to Complete with all tasks included and remaining risk exposure for
comparison to remaining contingency and the authorized TPC, the confidence level
for completing all work within budget, including the use of any scope contingency
options.
•
A summary schedule or schedule highlights of the extended tasks, including
significant milestones and the new project end date.
Table 2.6.2.2-1 further illustrates the information described above.
1
Scope contingency and management is defined in Section 4.7 Contingency Estimating and Management.
Document Number
68
2.6 Major Facility Construction Stage
Research Infrastructure Guide
Table 2.6.2.2-1
Sample of a Schedule Extension Tasks Table
Task #
Task Description
Burdened
Subtotals
($K)
WBS
Justification
1
Modifications to
electronics control
boards
40.5
3.7 Environmental
Systems ADCs
Rework of existing in-scope task;
technology not performing as intended
2
Delivery of 3 cryopumps
114.9
4.2 Vacuums
Systems
Existing in-scope task; Late delivery on
open contract with obligated funds
3
General purpose utility
carts
25.8
2.4.5 Monitoring
and Maintenance
Equipment
Existing in-scope task; Late delivery; One
unit added based on revised needs
estimate
4
Vendor contract to test 32.4
relationship of
performance versus
temperature on sample
size widgets
5.2.3 Systems
Engineering
Integrated testing
Risk mitigation added to address in-scope
performance issues for integrated systems.
Risk Register ID #14-31
5
Labor extensions for
project management
and business offices
1.2 Project Controls Existing in-scope task; revised effort,
salary, and overhead estimates, including
escalation
Total ($K)
Document Number
184.2
397.8
69
2.7 Major Facility Operations Stage
2.7
Research Infrastructure Guide
MAJOR FACILITY OPERATIONS STAGE
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
The Awardee responsible for the Construction Stage is typically the same Awardee that
assumes O&M responsibility of a new Major Facility given its history with the Science Support
Program and connections with the science community. However, the Operations Stage may
be managed by a different entity depending on circumstances, including the determination
of the award instrument used for each stage and the point in the Major Facility’s life cycle.
2.7.1
Initial Operations Stage Awards
As the Construction Stage is nearing completion, the Sponsoring Director may decide to
make an initial Operations Stage award to facilitate the phased transition of staff and any
equipment that is fully commissioned and ready to support science operations separate
from the Construction Stage award or to otherwise ready the Major Facility to reach full
operational tempo. The duration of this award may be less than the typical five years.
However, it can be supplemented and extended in accordance with the award instrument
used and the associated NSF policies. Because these awards may overlap in time and
typically use different appropriations, MREFC and R&RA, the scope of each must be clearly
delineated. The Awardee should follow the process and procedures in their Segregation of
Funding Plan (see Section 3.5.7.5 PEP Subcomponent 7.5 – Business and Financial Controls
Plans), submitted as part of the PEP, to ensure all charges for labor, equipment, operations,
and maintenance, and other services are allowable and allocated to the correct award.
2.7.2
Operations Stage Awards
The Science Support Program, often referred to
as O&M, is typically funded through the R&RA Key Takeaway
account. Operations Stage awards involve all
Operations Stage proposals and awards
day-to-day activities required to manage the
are exempt from following the GAO
Major Facility, including staffing, scheduling of Schedule Estimating Guide, nor does the
activities, maintenance, repairs, and upgrade of NCOP apply.
all associated property, as well as education,
outreach and administration of any research programs. It is the responsibility of the Awardee
and their management team to ensure that the Major Facility is operating efficiently and
cost-effectively, all aspects of it are properly maintained, and to provide technical
enhancements when needed to maintain state-of-the-art research capabilities. The duration
of Operations Stage awards is typically five years but may be renewable for a second fiveyear period. Extension of an Operations Stage award is done in accordance with NSF policy
and the award instrument used.
The content of the first Operations Stage proposal and subsequent award should be aligned
with the ConOps Plan established in the Construction Stage PEP. The proposal structure
should align with the funding announcement, if used, or with guidance provided by the
cognizant PO and will follow the format needed for an AWP as described in Section 3.6.3.2
Document Number
70
2.7 Major Facility Operations Stage
Research Infrastructure Guide
Components of an Annual Work Plan.
While the Awardee is free to use project management good practices internally, NSF does
not conduct its oversight of the Operations Stage with a project management lens as it does
with the Construction Stage. Operations Stage proposals are only required to follow the GAO
Cost Estimating and Assessment Guide as described in Section 4.3 Cost Estimating and
Analysis. 1 Budget contingency may be requested, but it is not expected by NSF, as there are
other ways to account for cost uncertainty and risks during the Operations Stage, such as
allowances (see Section 4.3.3.4 Uncertainty, Accuracy, and Allowances). Although an
Operations Stage award may involve what are considered projects, for example routine
building renovations or system upgrades, Operations Stage proposals are not required to
follow the GAO Schedule Assessment Guide. 2 If project management practices for scope,
schedule, and budget are considered necessary, for example, a significant upgrade to a
building or instrument in the Mid-scale RI range, NSF may fund the activities under a separate
award so that appropriate guidance can be followed, and the necessary terms and
conditions applied. Furthermore, NCOP does not apply to Operations Stage Awards. As a
result, project management terminology such as re-planning, re-baselining, and PEP should
be avoided, and the use of an IMS and EVM are not appropriate.
2.7.3
Operations Stage Reporting and Oversight
There are several key elements that are part of NSF’s oversight of Operations Stage Awards:
•
Periodic and annual reporting by the Awardee.
•
Review of the AWP.
•
Periodic Operations Stage reviews.
•
Facility Condition Assessments (FCA).
•
BSR.
•
Other reviews and audits conducted by the cognizant federal agency.
Periodic and Annual Reports. Periodic reporting to NSF will be required in accordance with
the award terms and conditions. The precise format and details of Operations Stage
reporting are at the discretion of the PO and are based on the size and complexity of the
Science Support Program, including interim reports such as periodic financial reporting of
actual expenses against the proposed budget in operational WBS format and the annual
report. The annual report may be a requirement by NSF policy based on the award
instrument and the AWP may constitute the annual report as determined by the PO. NSF
may request additional reports and information to support agency oversight based on
Awardee performance and other factors, including requests from the Office of the Inspector
General, GAO, OMB, and Congress.
The annual report, if required, should describe in detail the activities of the Major Facility in
1 https://www.gao.gov/products/gao-20-195g
2
https://www.gao.gov/products/gao-16-89g
Document Number
71
2.7 Major Facility Operations Stage
Research Infrastructure Guide
the previous year for NSF to assess performance against the goals described in the AWP.
Due to changing research priorities or external factors, not all performance goals may be
met each year, but an explanation of progress on each goal and the reasons why the goals
were not achieved should be included in the annual report.
Annual Work Plan. Like the PEP in the Construction Stage, the AWP is the primary document
that the Awardee uses to manage the Science Support Program and NSF's primary document
to monitor progress and performance. The elements of the AWP, as described in Section
3.6.3 Annual Work Plan, are intended to describe what the Awardee and the Major Facility
expect to accomplish within the upcoming period of performance. The AWP should include
a series of high-level performance goals, which will naturally vary from facility to facility and
should be agreed upon between the Awardee and the PO.
Operations Stage Reviews. NSF conducts periodic Operations Stage reviews using an
external panel of experts spanning the principal range of functions necessary to sustain
Major Facility operations in accordance with the panel charge. Frequency is at the discretion
of the PO and depends on the scale and complexity of the Science Support Program. The
scope of the review may involve a review of the AWP and the results of a recent FCA, for
example. The external panel reports directly to NSF and provides advice to NSF in accordance
with the panel charge. Whenever possible, the review is conducted at the Major Facility itself.
The reviews are organized and conducted by the PO in consultation with the RIO Liaison and
AO. The PO has overall responsibility for organizing the review and, throughout the review
process, acts as the interface between NSF and the Awardee. The PO authors the review
charge and organizes the review panel. The RIO Liaison and AO help strengthen the review
process by specifying language for incorporation within the charge and for aspects of the
review agenda pertaining to business-related issues and recommending panelists able to
advise NSF in non-science related areas of the review. Because panel recommendations are
to NSF and not the Awardee, NSF will typically issue written guidance to the Awardees for
subsequent response and action leveraging recommendations from the panel report.
When NSF partners with other entities to fund operations, the Memorandum of
Understanding between the partners usually defines the process for oversight and
monitoring.
Facility Condition Assessment. The PO will request a periodic FCA and associated Asset
Management Plan in accordance with the terms and conditions of the award (see Section
3.6.2 Facility Condition Assessment of a Major Facility). The FCA process is intended to help
inform NSF and the Awardee of the anticipated major maintenance and upgrade expenses
that could cause a significant departure from the routine funding profile, allowing NSF, as
part of its budget formulation and allocation process, to proactively address these issues
before they become emergencies that could potentially disrupt operations.
Business Systems Review. While a BSR may be conducted prior to a Design or Construction
Stage award to ensure the Awardee has appropriate business systems in place, BSRs are
routinely used during the Operations Stage under financial assistance awards. Analogous
Document Number
72
2.7 Major Facility Operations Stage
Research Infrastructure Guide
reviews are used for Federal Acquisition Regulation (FAR)-based contracts. Whether to
execute a BSR is based on an internal annual portfolio risk assessment conducted by NSF
with input from the Core IPT for each Major Facility in operations. The scope of the BSR is
adjusted to align with any risks identified. BSRs are intended to assess the Awardee’s
processes, procedures, staffing, and tools to ensure they are suitable to receive or continue
to receive an Operations Stage award.
Incurred Cost Audits: NSF must conduct an Incurred Cost Audit (ICA) at least once during
the Construction Stage. The frequency of these audits is determined by a risk analysis and
the duration of the award, but the interval between audits must not exceed three years.
Additionally, an ICA must be conducted upon the completion of the Construction Stage.
To facilitate this process, awardees must submit financial expenditure (incurred cost) data
to NSF at least annually. These submissions should follow the requirements specified by the
Awarding Official and the terms and conditions outlined in the award.
Awardees are required to use the Financial Data Collection Tool for Major Multi-User
Research Facilities to submit this data. This macro-enabled Excel workbook ensures
standardized reporting of direct and indirect expenditure data. The tool is available for
download at https://new.nsf.gov/bfa/rio/resources.
Other Reviews and Audits. Depending on the award instrument, NSF may also elect to
conduct a Financial Viability review or an Accounting System Analysis prior to the award, or
during the award period of performance. Awardees may also need to respond to audit
requests from NSF’s Office of the Inspector General. Per the American Innovation and
Competitiveness Act, NSF requires an independent cost analysis for Operations Stage
proposals.
2.7.4
Recapitalization During Operations
Recapitalization refers to the process of reinvesting in or upgrading existing assets to
maintain or enhance their performance, extend their service life, and/or ensure they
continue to adhere to operational standards and regulatory requirements. Recapitalization
is an ongoing process that requires careful planning, budgeting, and execution to ensure
that Major Facilities remain safe, functional, and effective in meeting their intended purposes
throughout their service lives.
Effective recapitalization requires a proactive approach to asset management that includes
monitoring operational trends to ensure optimal performance and resilience in dynamic
environments, thorough assessment of funding needs, careful consideration of the
appropriate funding mechanism, and a strategic allocation of resources. As described in
Section 3.6.2.1 Facility Condition Assessment Components, recapitalization needs are
informed by the FCA process, which in turn is used to develop the Asset Management Plan
that outlines the anticipated costs associated with the recapitalization activities. These
estimated future costs have the potential to significantly deviate from the standard routine
maintenance funding profile seen in Operations Stage awards.
Document Number
73
2.7 Major Facility Operations Stage
Research Infrastructure Guide
Ideally, Major Facility recapitalization activities would be addressed as part of the O&M award
(see Section 4.2 Scope and Work Breakdown Structure). At the discretion of NSF, other
mechanisms for support may be offered, such as targeted supplemental funding requests,
dedicated recapitalization programs, and Mid-scale RI programs, since these projects can
include upgrades to Major Facilities (see Section 1.4.5 Mid-Scale Project and Mid-scale
Research Infrastructure). Close consultation with the PO is essential in determining the most
appropriate funding mechanism based on the availability of funds and other factors.
2.7.5
Federally Funded Research and Development Center Designation
FFRDC are defined in FAR 2.1 to mean:
“activities that are sponsored under a broad charter by a Government agency (or
agencies) for the purpose of performing, analyzing, integrating, supporting, and/or
managing basic or applied research and/or development, and that receive 70 percent or
more of their financial support from the Government; and
(1) A long-term relationship is contemplated;
(2) Most or all of the facilities are owned or funded by the Government; and
(3) The FFRDC has access to Government and supplier data, employees, and facilities
beyond that common in a normal contractual relationship.”
An FFRDC is created by a federal agency and receives the preponderance of its resources
from that particular agency. NSF may choose to sponsor Major Facilities in the Operations
Stage and designate them as FFRDCs. FAR Part 35.017 sets forth the federal policy regarding
the establishment, use, review, and termination of FFRDCs and related sponsoring
agreements which NSF adheres to regardless of the award instrument used. In accordance
with the FAR, an FFRDC must meet special long-term research or development needs that
cannot be met as effectively by existing in-house or other contracted resources. They enable
agencies to use non-federal resources to accomplish tasks integral to the sponsoring
agency's mission and operation. To discharge its responsibilities to the sponsoring agency,
an FFRDC has access to government information and resources (including sensitive and
proprietary data, employees, installations, equipment, and real property) beyond that which
is common to the normal contractual relationship. An FFRDC is required to conduct its
business in a manner befitting its special relationship with the government, operate in the
public interest with objectivity and independence, be free from organizational conflicts of
interest, and fully disclose its affairs to the sponsoring agency. An FFRDC cannot use its
privileged information or access to other resources to compete with the private sector,
although it may perform other work under the Economy Act or other applicable legislation
when the work is not otherwise available from the private sector.
While the sponsoring agreement may take various forms and the content may vary
depending on the situation, a FFRDC must be clearly designated through a sponsoring
agreement that addresses the minimum criteria defined in 48 CFR 35.017-1(c) and (d). 1
1
https://www.ecfr.gov/current/title-48/section-35.017-1
Document Number
74
2.7 Major Facility Operations Stage
Research Infrastructure Guide
Establishing, changing, using, review, and termination must follow the requirements defined
in 48 CFR 35.017-2 through 35.017-7. 1
Approval to continue or terminate NSF sponsorship rests with the NSF Director. When NSF’s
need for an FFRDC no longer exists, the sponsorship may be transferred to one or more
government agencies, if appropriately justified. If an FFRDC is not transferred, it will be
considered for disposition or, under financial assistance, considered for award renewal as a
non-FFRDC.
1
https://www.ecfr.gov/current/title-48/chapter-1/subchapter-F/part-35
Document Number
75
2.7 Major Facility Operations Stage
2.7.6
Research Infrastructure Guide
Competition, Renewal and Disposition Decisions
At least two years prior to the end of an Operations Stage award, NSF will begin the process
of making a determination of whether to renew the award with the existing managing
organization, compete for a new managing organization, or otherwise dispose of the Major
Facility and its associated infrastructure through a variety of methods. 1 The results of the
annual Operations Stage reviews and other information, such as inputs from NSF Advisory
Committees, Decadal Surveys, Blue Ribbon panels, National Academies studies, and
professional societies, are used to help inform this decision.
2.7.6.1
Disposition
To remain at the frontiers of science and support new, cutting-edge RI, NSF will consider
decreasing or eliminating investments in existing Major Facilities when the science they
enable is considered a lower priority than science that could be enabled by alternate use of
the funds. Such decisions require careful consideration by NSF in consultation with the
community and other stakeholders. In some cases, where a Major Facility can continue to be
productive, it may be possible to transfer stewardship and final ownership to another
agency, a university, or a consortium of universities. It is the responsibility of the Directorates
and Divisions to periodically review their Major Facility portfolio and to consider which
facilities may have reached the point where disposition is appropriate.
Disposition is the general term that means the act of divesting or transitioning a Major
Facility or capital asset, either in whole or in part, or non-renewal of a Major Facility award. 2
Divestment. The transfer of property ownership from NSF to another entity, including
relinquishing any conditional claims. It can involve a full facility, components, or assets, and
may include decommissioning if necessary. After divestment, the assets are no longer NSFfunded, though NSF may still support research using those assets.
Transition. The change from a Major Facility to another class of RI or scale of activity, but
NSF retains ownership and oversight. Forms of transition include mothballing assets or
leasing property long-term. After transition, the assets are no longer considered NSF-funded
Major Facilities, though new awards and oversight conditions apply.
Non-renewal. The decision not to extend its funding agreement with the managing
organization, without owning or having an interest in the assets. After non-renewal, the
assets are no longer considered part of an NSF-funded Major Facility.
Environmental, historic, and cultural assessment activities may be initiated if the decision is
made to dispose of a Major Facility, or component of a Major Facility (see Section 5.4
Environmental Considerations).
1
See Section 1.4.5 Mid-Scale Project and Mid-scale Research Infrastructure regarding NSB Policy on re-competition.
current threshold for a capital asset is property currently valued at $2.5M or greater.
2 NSF’s
Document Number
76
2.8 Major Facility Disposition Stage
2.8
Research Infrastructure Guide
MAJOR FACILITY DISPOSITION STAGE
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
The purpose of the Disposition Stage is to execute the disposition decision(s) made during
the Operations Stage. The Disposition Stage begins when an award is made to fund the
disposition activities, which could include the transition of all property and equipment to
sponsorship by another entity (federal or non-federal), disposal of some or all property, decommissioning or de-construction of the entire Major Facility or components of the Major
Facility, and other costs related to liabilities such as employee separations. Disposition Stage
awards are seldom competitive in nature unless NSF decides to de-commission or deconstruct a Major Facility itself. Non-renewals, by definition, do not require a Disposition
Stage award.
Major Facility Disposition Plan. Guidelines and requirements for creating disposition plans
are included in Section 3.7 Disposition Stage Planning. Since divestment strategies and
liabilities may influence construction strategy, a divestment plan is a necessary element (see
Section 3.5.10.3 PEP Subcomponent 10.3 – Concept of Disposition Plans) for a Major Facility
and thus, a draft plan should be created early in the Design Stage planning.
Oversight and Reporting during the Disposition Stage. Given the inherent
complexities of disposition, particularly around property and environmental
considerations, engagement by the NSF Core IPT is necessary to ensure that both
programmatic and business-related oversight requirements are met. Reporting and
other deliverables will be defined in the terms and conditions of the award and are
based on the Disposition Plan negotiated with NSF.
Document Number
77
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
2.9
MID-SCALE RESEARCH INFRASTRUCTURE GUIDANCE
2.9.1
Introduction
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
In Section 1.4.5 Mid-Scale Project and Mid-scale Research Infrastructure, Mid-scale RI projects
are defined as RI having a cost to construct, acquire, or otherwise implement, between the
upper limit of NSF’s Major Research Instrumentation (MRI) program and the lower threshold
for what constitutes a Major Facility. 1 Mid-scale RI can be standalone projects or associated
with an NSF-funded Major Facility.
This section should not be interpreted as standalone, comprehensive guidance for Mid-scale
RI. Rather, it should be viewed as a complement to all other applicable sections of this Guide.
A central theme throughout is the expectation that proposers should tailor and scale
proposed management methodologies to the technical nature, complexity and risk profile
of the Mid-scale RI project or operations award. Similarly, NSF will tailor and scale the review
and oversight methodologies to the technical nature, complexity, and risk profile of the
project or operations award.
NSF’s investments in Mid-scale RI may also support development and design activities as well
as operations. NSF funds these investments through multiple funding accounts and
programs, some of which are managed exclusively by the Program Offices and others
centralized at the agency level. 2 In all cases, the intent of Mid-scale RI investments is to meet
the RI needs of the science community on shorter timescales than typically seen for Major
Facility investments.
Although Mid-scale RI proceed through all life cycle stages from development through
eventual disposition, they do not fall under the five life cycle stages for NSF oversight of Major
Facilities as described in Sections 2.2–2.8 (see Section 2.9.3 Mid-scale RI Life Cycle Stages). In
addition, NSF may only be engaged in some of the life cycle stages. NSF typically funds the
design and implementation of Mid-scale RI. O&M may be funded by NSF, in part or in whole,
based on the ConOps described in the proposal. If a Mid-scale RI project is an upgrade to an
existing Major Facility, it is expected that the O&M costs will become part of the Operations
Stage award for that Major Facility.
NSF Programmatic Oversight. At the appropriate point in award formation, each Mid-scale
RI award is assigned to an PO with the responsibility for award oversight as determined by
the award instrument utilized. NSF uses the IPT approach for oversight of Mid-scale RI
awards (see Section 2.1.2 Coordinating and Advisory Bodies). However, the IPT only needs
to consist of the PO, the AO, and the RIO Liaison, i.e., the Core IPT; others may be added to
address various expertise needs. Mid-scale RI implementation projects consisting of
1 The
current upper limit of an NSF award under the MRI program is $4M, which does not consider cost share.
Centralized funding programs include Mid-scale RI Tracks 1 and 2, with Track 1 funded from the R&RA account and
Track 2 from the MREFC account.
2
Document Number
78
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
upgrades to existing NSF Major Facilities are coordinated through the IPT for that Major
Facility.
In accordance with NSF policy on financial assistance, the cognizant PO develops a
management plan documenting the planned oversight approach for the funding program.
The plan is developed in conjunction with the funding announcement and articulates NSF’s
plans for oversight of the program and any resulting awards. For a comparison between a
Mid-scale RI management plan and a Major Facility IMP, see Section 2.2 Internal
Management Plan.
Unlike the statutory requirement that Program Officers (POs) assigned to Major Facilities
must be permanent NSF employees, NSF has greater flexibility in determining the
employment status of POs overseeing Mid-scale RI awards.
Non-applicability of the No Cost Overrun Policy. Although substantial rigor is required in
establishing the TPC for a Mid-scale RI implementation award, these projects are not subject
to the NCOP used for Major Facilities, as defined in Section 1.4.7 NSF No Cost Overrun Policy.
NCOP is based on having a risk-adjusted TPC that is developed at the PDR to support a
potential budget request to Congress on a project-specific basis, and since Mid-scale RI
projects do not go through the formal stage-gate review process, there is no PDR. In addition,
Mid-scale RI projects are often funded under a broader program and not articulated in NSF’s
budget request by individual projects. However, any potential cost increases that could
impact the award amount (i.e., that cannot be addressed through re-planning, use of budget
contingency, or de-scoping) should be discussed with the PO and AO as early as possible and
be addressed in accordance with NSF’s policy based on the appropriation and award
instrument used.
2.9.2
Expectations for Mid-scale RI Proposers and Awardees
Mid-scale RI Management Team. Given the expectation to deliver a certain scope within
cost and schedule, or to provide an on-going Science Support Program to the community,
NSF has different expectations for Mid-scale RI awards compared to research awards which
are often standard grants. Proposers of Mid-scale RI projects should form a Management
Team capable of planning and executing the activities that would be funded under an award.
The expectations for personnel (Section 5.7 Personnel and Competencies), while not
required for Mid-scale RI, may be used to inform the subject matter expertise of individuals
on the Management Team based on whether the award activities are for design,
implementation, or operations; each of which having its own set of challenges and risks. For
example, projects consisting of simple acquisitions of commercially available components
generally have very low risk. The Management Team may only be the Principal Investigator
and their institution’s contracting office.
For more complex Mid-scale RI projects, the PM should be identified and consulted early in
the process, ideally prior to initial proposal submission to assist with interpretation of this
Guide. Some professional organizations provide general guidance on the size and formation
of the Management Team, but a qualified PM can also help ensure adequate, competent
Document Number
79
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
staffing is proposed and hired. 1 Proposing organizations may also be able to leverage
available in-house resources, such as business management, architectural, or engineering
departments, or project management staff in the facilities (non-academic) arm of the
institution. It is also advisable to have discussions with peer organizations in the respective
fields of research and with project management consultants, to help ensure adequate
staffing. Experienced PM can be an asset when considering the tailoring and scaling flexibility
allowed by NSF on Mid-scale RI projects and help avoid over- or under-implementation
during proposal submission and post-award.
Concept of Operations. When NSF is considering an investment in the design or
implementation of a Mid-scale RI, it is essential that the agency understands the proposing
organization’s plan for and cost of O&M as part of the proposal review process. As a result,
Mid-scale RI proposals must include a ConOps Plan that is aligned with the technical
maturity of the RI. For a design proposal, the ConOps Plan should be presented as
envisioned, with the operations cost estimates and funding strategy refined with maturation
of the PEP (see Section 3.5 Construction Stage and Implementation Planning). If
implementation is eventually funded, the ConOps Plan would then be refined further as the
infrastructure moves toward delivery. If NSF commits to supporting long-term operations, a
proposal that includes a detailed AWP would eventually be submitted based on the refined
ConOps Plan developed during implementation (see Section 3.6 Operations Stage Planning).
Tailoring and Scaling the Project Management Approach. Proposers should plan and
Awardees should execute Mid-scale RI projects using well-established project management
methodologies. However, NSF allows flexibility in tailoring and scaling the methodology used
based on the size, complexity, technical nature of the project, and identified project risks.
Project management practices include reliable cost estimating and schedule development,
risk identification and risk mitigation, consideration of needed contingencies, and the ability
to monitor progress against the plan so that corrective actions can be taken. The level of
project management effort and resources employed should be carefully considered such
that the cost does not outweigh the benefit.
Cost Estimating. Budget estimates for Mid-scale RI investments for design, implementation,
and operation awards should be supported by a well-documented BOE developed in
accordance with the four characteristics and the twelve steps of the GAO Cost Estimating and
Assessment Guide, as described in Section 4.3 Cost Estimating and Analysis. However, the
primary focus should be on meeting the four characteristics of a reliable estimate (welldocumented, comprehensive, accurate, and credible) to support NSF’s assessment of cost
reasonableness. The twelve steps should be considered when deemed advantageous to the
Proposer’s estimating process for the given life cycle stage, and NSF will review accordingly
as part of the agency’s cost analysis process. At minimum, the estimate should be easily
understood, describe the methodology, and show calculations traceable to supporting
documentation (well-documented), follow a WBS (comprehensive), be validated to be an
1
e.g., Project Management Institute (PMI)
Document Number
80
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
error-free representation of most likely costs (accurate) and consider risks and uncertainties
(credible).
Schedule Development. Schedules should be tailored to the technical nature and
complexity of the project and the needs of the Project Management Team to monitor
progress against the plan. Schedules can be as simple as a time-sequenced list of significant
milestones or, when using EVM, as complex as a fully developed IMS. No matter how simple
or complex, the schedule proposed should meet GAO’s four characteristics of a reliable
schedule (comprehensive, well-constructed, credible, and controlled). The ten best practices
should be considered when deemed advantageous to the Proposer and Awardee’s
scheduling process for the given life cycle stage, and NSF will review accordingly. At a
minimum, the schedule should establish milestones for all key events at reasonable
durations (comprehensive), be logically sequenced (well-constructed), consider risks and
inclusion of adequate float or schedule contingency (credible), and be updated routinely by
authorized individuals with actual progress to provide a current forecast for comparison to
the planned schedule ([controlled], see Section 4.4 Schedule Development, Estimating, and
Analysis).
Contingencies. Scope, schedule, and budget contingencies are highly encouraged on Midscale RI implementation awards and may be considered on design and operations awards,
in consultation with the cognizant PO. Budget and schedule contingencies give credibility to
their respective estimates. Scope contingency provides pre-vetted options to manage further
risk if budget contingency becomes inadequate during implementation or adds capabilities
if the risk impact isn’t fully realized. In other words, all three contingencies can work together
to provide flexibility to cover risk exposure and deliver the full scientific scope within the
authorized TPC.
If proposed, the budget contingency estimate should be developed using a rigorous risk
management approach as described in Section 4.6 Risk Management. NSF is under no
requirement to award budget contingency and may choose to handle risk realization in other
ways per Section 4.7.1 Allowable Contingencies. If awarded, NSF may hold up to 100% of the
budget contingency until needed.
Since the schedule for a Mid-scale RI project can range in complexity, proposers should
assess the benefit of schedule contingency to their project. If a simple milestone schedule is
used, the use of schedule contingency may add no practical value. The Awardee and NSF
may simply be monitoring milestones and extending the award duration as needed to
complete the project, provided that sufficient funding remains. If EVM and a full IMS are
employed, then schedule contingencies may be added to each major work package in
accordance with project management good practices and following formal Change Control
procedures (see Section 4.7 Contingency Estimating and Management).
A Scope Management Plan is a valuable risk management tool. Scope contingency should be
proposed at a level appropriate to the project and acceptable to the Program Office. It does
not need to have a value equivalent to at least 10% of the baseline budget, as with Major
Facilities projects. If proposed, de-scope options (as well as scope opportunities) should be
Document Number
81
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
well-documented, time-phased, prioritized to minimize or maximize scientific impact and
have an appropriate threshold for NSF approval in the PEP.
The use of contingencies is always managed through the formal Change Control Process as
described in the PEP or AWP. NSF approval thresholds are then codified in the terms and
conditions of the award.
Monitoring Progress Against Plan. Mid-scale
RI projects are required to use an objective NSF Requirement
method of monitoring progress against the
• Major Facilities must use a verified EVMS
plan that is considered sufficient for the Project
to monitor progress against the
Management Team to manage the project. If
Performance Measurement Baseline.
the method used is deemed sufficient to
• Mid-scale RI must have an objective
manage the project during the NSF review
means to monitor progress against the
process, it should be considered sufficient for
plan.
NSF oversight of the award. Any adjustments to
the method will be made during award
negotiation. If EVM is used, tailoring and scaling should be used to balance administrative
burden with sufficient project management insight. Refer to Section 4.5 Monitoring Progress
Against Plan for other means of monitoring progress against a plan and Section 4.5.4 Earned
Value Management for more information on scaling EVM.
2.9.3
Mid-scale RI Life Cycle Stages
Mid-scale RI follows a structured pathway through five life cycle stages, similar to Major
Facilities. These stages cover the entire RI life cycle—from development to eventual
disposition—although NSF may only be directly involved in some of these stages. NSF
distinguishes the oversight and guidance for Mid-scale RI by referring to each stage as an
award. This terminology reflects NSF's tailored approach to supporting the specific needs
and scale of Mid-scale RI, while also emphasizing their distinction from Major Facilities.
•
Development award
•
Design award
•
Implementation award
•
Operations award
•
Disposition award
Mid-scale RI Development Award. Development of Mid-scale RI projects generally happen
on significantly shorter time scales compared to Major Facilities. A vision for a time-sensitive
solution enabling scientific advances might lead directly to the submission of a proposal for
the design of a Mid-scale RI and subsequent award. NSF may also fund activities such as
community workshops to develop ideas and build consensus around the needed
infrastructure. At the appropriate level of maturity, this could lead to the submission of a
formal proposal for design either through a formal program or via an unsolicited proposal.
If the proposed RI is an acquisition, submission of an implementation proposal (bypassing
Document Number
82
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
development and design) may be appropriate. If the project is an upgrade to an existing
Major Facility, the Mid-scale RI development may happen as part of the Major Facility
Operations Stage award with the approval of PO. In all cases, communication with the
appropriate PO is essential to successfully advance the vision beyond an initial idea to a
formal design activity or a potential implementation project.
Mid-scale RI Design Award. Proposed Mid-scale RI projects are not required to undergo the
formal design stage-gate reviews that are mandatory for Major Facilities. However, proposed
Mid-scale RI projects must demonstrate an appropriate level of design maturity before
proceeding from design to implementation. This level of maturity is comparable to that of a
FDR, as described in Section 2.5.3 Final Design Phase.
Mid-scale RI design awards must have a DEP, in accordance with programmatic
requirements, that leads to the submission of the PEP as a final deliverable. To minimize
technical risk, design activities may include prototyping that has its own PEP tailored and
scaled to this level of activity embedded within the DEP. Section 3.4 Design Stage Planning
describes the suggested contents of a DEP. The expected deliverable at the end of design is
a comprehensive PEP ready for consideration of an implementation award.
Mid-scale RI Implementation Award. The implementation activities proposed for a Midscale RI may include construction, acquisition, or a wide variety of other activities necessary
to deliver the intended scope based on the technical nature of the project. Production-level
design activities and prototyping not accomplished during design may also occur during
implementation. Mid-scale RI projects may be all instrumentation, all software, or a mixture,
depending on the needs of the scientific community. This high degree of variability requires
alignment between the project management approach and the needs of the RI type.
Some Mid-scale RI projects approaching $100M may use many of the project management
methods typically used for Major Facilities. Smaller projects, particularly those at the lower
end of the Mid-scale RI cost threshold, are expected to implement project management
methods only to the extent necessary to manage the project effectively. If, during the NSF
review process, the methods are deemed suitable to manage the project, they will generally
be suitable for NSF’s oversight purposes.
As with Major Facilities, the PEP establishes the
Project Definition, documents how progress
Key Takeaway
against the plan will be monitored, establishes
Given the wide range in scale, complexity,
Change
Control
and
contingency
use
and technical nature of Mid-scale RI
procedures, and describes the ConOps and projects, NSF expects greater tailoring and
other Plans described in Section 3.5 scaling on Mid-scale RI PEP components
Construction Stage and Implementation compared to Major Facilities.
Planning. As with Major Facilities projects, all
PEP components and subcomponents should
be considered and addressed unless otherwise noted in the funding announcement. PEP
components and subcomponents may be omitted (tailored) with a brief justification of its
omission. However, if included, they should be scaled (adjusted) to the size, complexity, and
Document Number
83
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
technical nature of the project, as well as the associated project risks. If a PEP component or
subcomponent is omitted, indicating that it is not applicable and a brief description as to why
should be given to indicate it was considered but determined not to be needed. All ten PEP
components are needed for Mid-scale RI projects. However, given the wide range in scale,
complexity and technical nature of Mid-scale RI projects, NSF expects greater tailoring and
scaling on a Mid-scale RI PEP compared to Major Facilities. The extent to which the PEP is
tailored and scaled will be subject to NSF review to guard against both under and over
implementation.
The final NSF-approved PEP is largely incorporated by reference into the terms and
conditions of the implementation award. However, the PEP is considered a living document
and, as such, periodic post-award PEP revisions are expected. The Awardee should submit
revised PEP sections to the PO for approval as described in the terms and conditions of the
award.
As with Major Facilities, both re-planning and re-baselining may occur during
implementation. Scope, schedule, and budget contingencies, if proposed and awarded, are
expected to be used in accordance with the Change Control Processes described in the PEP
and the award terms and conditions.
Mid-scale RI Operations Award. If NSF commits to long-term operation of a Mid-scale RI,
then the Awardee must submit an AWP using an operational WBS (see Sections 3.5
Construction Stage and Implementation Planning and 4.2 Scope and Work Breakdown
Structure). Reporting during operations is based on the terms and conditions of the award.
If the Mid-scale RI operations award is associated with a Major Facility, then the operational
details may be included as part of the AWP for that facility and reporting included along with
the facility reporting requirements. 1 At the Program Office’s discretion, periodic operations
reviews may be used to inform award renewals or competition, assess Awardee’s
performance, inform the need for upgrades to meet emerging science requirements, or
other oversight needs (see Section 3.6 Operations Stage Planning).
Mid-scale RI Disposition Award. As stated above, NSF may not have any long-term
operational investment in Mid-scale RI and, therefore, plays no part in disposition decisions.
Whether the property is government-owned or whether NSF has a conditional interest in the
property funded under the award depends on the award instrument utilized. Under
contracts, all property is federally owned, and eventual disposition would follow
government-wide practices. Under financial assistance, government ownership and NSF’s
conditional interest at the end of the award (if any) is stated explicitly in the award terms and
conditions. The expectation for a Mid-scale RI under financial assistance is that title to
property would vest with the Awardee at the end of the award. Eventual disposition at the
end of service life would be the sole responsibility of the Awardee. Disposition planning with
NSF would only be necessary if the agency had ownership or conditional interest in specific
1 Larger
Mid-scale RI upgrade projects are commonly funded as a separate award with distinct reporting
requirements.
Document Number
84
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
property in accordance with the terms and conditions of the award. For more information
on disposition, refer to Section 2.8 Major Facility Disposition Stage.
2.9.4
Summary of NSF Oversight for Major Facilities and Mid-scale RI
Given the wide range in implementation costs and the kinds of projects funded under Midscale RI programs, management by the Awardee and the oversight by NSF is expected to be
tailored and scaled to the unique characteristics of the RI, such as an assessment of the
associated technical and programmatic risks, the technical scope, and the type and mix of
work being performed. However, NSF is committed to the principle that this flexibility does
not preclude a requirement for appropriate rigor on the part of NSF or the Awardee.
The following table is provided to help clarify the factors influencing NSF oversight and
illustrate the differences in the level of oversight for Mid-scale RI and Major Facilities based
on statutory requirements and agency policy.
Document Number
85
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
Table 2.9.4-1
Requirements for Major Facilities versus Mid-scale RI
Requirement
Major Facilities
Mid-scale RI
Statutory Oversight
Requirements
Yes
AICA 2017; Section 110
Construction and Operations Stages
No
AICA 2017; Section 109 speaks only to
developing a strategy for Mid-scale RI. All
oversight is based on internal NSF policy
and practice.
Life Cycle Stages
Yes
Development, Design, Construction,
Operations, and Disposition Stages
Yes
Primary focus on design, implementation,
and operations awards
Yes
CDR, PDR, and FDR
No
Technical readiness assessed by NSF in
accordance with the funding
announcement or separate assessment, if
unsolicited
NSF NCOP
Yes
Per Section 2.6.1.1
No
The NCOP relates to a risk-adjusted TPC
at PDR to support a budget request to
Congress. Mid-scale projects do not
undergo PDR and budgets requests are
generally formulated at the program level
Use of GAO Good
Practices for Cost
Yes
AICA 2017; Section 110
Yes
Per NSF practice and as described in the
associated funding announcement
Use of GAO Good
Practices for Schedule
Yes
AICA 2017; Section 110
Yes
Per NSF practice and as described in the
associated funding announcement
Budget Contingency
Yes
For Construction Stage, Monte Carlo
simulation methods to demonstrate 7090% confidence
Schedule Contingency
Yes
No, but possible if using more complex
scheduling methodologies and budget
contingency
Scope Contingency
Yes
At least 10% of baseline cost
No
Recommended based on project
complexity and risk profile
Management Reserve
Yes
Authorized by NSF as part of the TPC for
unforeseen events; held by NSF and
awarded as supplemental funding
No
Standard NSF supplemental funding
requests procedures based on the award
instrument and authorization for use of
funds depending on the appropriation
(MREFC vs R&RA)
DEP
Yes
Design Stage
Yes
Design Activities; based on the funding
announcement and other program
requirements
Stage-gate Reviews
PEP
Document Number
No, but highly recommended
Simplified algorithmic method to full Monte
Carlo simulation, if proposed
Yes
Yes
Construction Stage
Implementation award;
All components and subcomponents
All components and subcomponents
should be tailored and scaled to match the should be tailored and scaled to match the
project
project
86
2.9 Mid-Scale Research Infrastructure Guidance
Research Infrastructure Guide
Requirement
Major Facilities
Mid-scale RI
AWP
Yes
Operations Stage
Yes
Operations award, or Operations Stage if
associated with a Major Facility
EVM
Yes
Construction Stage
Scaled to the project
No
Only an objective means to monitor
progress against the plan; if EVM is used it
should be tailored and scaled to the
project
Periodic Construction
Stage Reviews
Yes
Joint PO and RIO
No
At Program Office discretion
Periodic Operations Stage
Reviews
Yes
No
At Program Office discretion
NSF Integrated Project
Team
Yes
Yes
Core IPT members only
Awardee Core
Competencies
Yes
As described in Section 5.7 Personnel and
Competencies and required per the terms
and conditions of the award
Yes
Matched to the technical nature of the
project or program or as required per the
terms and conditions of the award
Disposition of Property
Either federally owned or NSF has
conditional interest, depending on the
award instrument and the award terms
and conditions; NSF is engaged in
property disposition decisions throughout
and at the end of award
Property title generally vests with the
Awardee; disposition planning with NSF is
only necessary if NSF has ownership or
conditional interest, per the award terms
and conditions
Document Number
87
3.1 Introduction
Research Infrastructure Guide
3.0
RESEARCH INFRASTRUCTURE LIFE CYCLE PLANNING
3.1
INTRODUCTION
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
This chapter offers detailed descriptions and guidance for Awardees in developing essential
plans and documents to manage and oversee Major Facilities and Mid-scale Research
Infrastructure (RI). It covers the formulation of key plans such as the Design Execution Plan
(DEP), Project Execution Plan (PEP), Strategic Plan, Annual Work Plan (AWP), Asset
Management Plan, and plans for Disposition activities. The chapter emphasizes the
importance of tailoring, scaling, and progressively elaborating these plans according to the
specific nature of the activities involved.
3.2 Tailoring, Scaling, and Progressively Elaborating Plans. Outlines how plans should
be appropriately tailored and scaled to reflect the nature, scale, and complexity of the RI,
as well as should be progressively elaborated.
3.3 Development Stage Planning. Describes the planning activities involved in the
Development Stage, where early ideas are formulated, so planning needs vary widely
within scientific disciplines.
3.4 Design Stage Planning. Formulates the DEP that outlines the specific tasks,
milestones, resource requirements, timelines, and responsible parties necessary to carry
out the Design Stage.
3.5 Construction Stage and Implementation Planning. Details of the PEP for managing
construction, outlining requirements and development components.
3.6 Operations Stage Planning. Includes the Strategic Plan, Facility Condition
Assessments, Asset Management Plan, and AWP. Covers operational timelines,
maintenance, upgrades, research, and education programs.
3.7 Disposition Stage Planning. Provides guidance for planning RI disposition under NSF
awards, including options like transfer, decommissioning, and site restoration after NSF
funding ends.
Document Number
88
3.2 Tailoring, Scaling, and Progressively Elaborating Plans
3.2
Research Infrastructure Guide
Tailoring, Scaling, and Progressively Elaborating Plans
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
This section gives an overview of the process for tailoring, scaling, and progressively
elaborating Major Facility and Mid-scale Research Infrastructure (RI) management plans for
each life cycle stage based on the nature of the proposed activities, the proposer’s initial
experience and background, and the life cycle stage. The sections dedicated to each life cycle
provide detailed discussions with specific guidelines and best practices for tailoring, scaling,
and progressively elaborating life cycle plans.
NSF recognizes that the unique nature of the activities under these awards and the related
efforts, as described in these plans, should inform how the Awardee approaches its planning
and management. A one-size-fits-all approach to development and management can be
overly burdensome on smaller efforts and might cloud the objectives for more extensive,
complex efforts. Therefore, the ability to select (tailor) and adjust (scale) the proper
management methodologies, which will also aid in establishing the appropriate level of NSF
oversight, should be based on the effort’s characteristics and allow the managing
organization to mature as well. This approach by NSF does not negate the use of project or
program management good practices or any requirements established in the funding
announcement or the eventual terms and conditions of the award. Instead, it allows
Awardees to use their judgment when proposing to NSF and for NSF to apply the appropriate
level of oversight without reducing rigor. Such flexibility is essential to avoid overimplementation and undue burden on the Awardee’s life cycle stage management methods.
The ability to progressively elaborate management methods and life cycle plans helps avoid
falling into over-implementation early on, as well as present documents to NSF for review
that align with project maturity, knowing full well that they will improve with time. This
section provides general guidance for tailoring, scaling, and progressively elaborating
concepts. These concepts are defined as follows:
•
Tailoring: The process of selecting an appropriate framework to define and organize
the scope, management, organization, schedule, cost detail, and performance
measurement methods.
•
Scaling: The process of adjusting the level of detail, degree of formality, tools, and
management processes to the characteristics of the planned work and the
performance processes.
•
Progressively Elaborating: The process of iteratively increasing the level of detail
and sufficiency in a management plan appropriate to the life cycle stage (i.e., the
Design Execution Plan [DEP] for the Design Stage, the Project Execution Plan [PEP] for
implementation, and Annual Work Plan [AWP] for the Operations Stage) as more
accurate information becomes available, commensurate with project or Science
Support Program maturity.
Document Number
89
3.2 Tailoring, Scaling, and Progressively Elaborating Plans
3.2.1
Research Infrastructure Guide
Tailoring
When tailoring, Awardees select management models and structures that match the
proposed activities. For example, a proposed project that consists mainly of design and labor
activities spread throughout the entire period of performance, may need a different
management approach than a project that is mostly made up of acquisition efforts where
purchases are mostly included in the first half of the period of performance. Most life cycle
management plans and methods fall into three major types, but the resulting plans can be
a hybrid of those types. The three types are:
•
Traditional waterfall approach that is product oriented.
•
Cyclical approaches that are team- and process-oriented.
•
Level-of-Effort (LOE) activities that are service-oriented.
All three employ acceptable methods for managing Major Facilities and Mid-scale RI
throughout their life cycles, as long as the methods are well-matched to the activity’s
characteristics, the life cycle stage, and the institutional culture and experience. The sections
below are intended to provide guidance on how the life cycle management plans and
methods should be described and documented.
3.2.1.1
Traditional Waterfall Approach
Traditional waterfall project management methods are suited to efforts that can be divided
into work plans or phases with well-defined deliverables having concrete timelines and
sequencing of events. Significant constraints on time, scope, and cost are well understood
and can be easily documented. Work flows logically from one phase to the next. Teams are
organized hierarchically with clear authorities, roles, and responsibilities and work linearly
toward set goals. Work is complete at the end of each work plan and does not repeat.
One common method of measuring performance against the baseline within the traditional
waterfall approach is Earned Value Management ([EVM], see Section 4.5 Monitoring Progress
Against Plan).
Construction and demolition, for example, are traditionally structured for waterfall project
management practices. The method can also be applied to design and development
activities and to software programming, although cyclical methods are often preferred for
the latter. Still, any shortcomings should be recognized and accommodated with adaptations
that ensure proper management insights and status reporting (see Chapter 2 NSF Life Cycle
Oversight for further information regarding project reporting).
Document Number
90
3.2 Tailoring, Scaling, and Progressively Elaborating Plans
Research Infrastructure Guide
Figure 3.2.1.1-1
Waterfall Model of Design Through Construction Stages
3.2.1.2
Cyclical Approach
Cyclical project management methods are particularly suited when a detailed path toward
the final goal is uncertain or where the significant constraints are not initially well
understood. Cyclical approaches assume that the goal will be achieved in several iterative,
cycles (which may be short or span several years) rather than linear, as in waterfall methods.
Efforts that evolve in time or do not initially have a clear scope and requirements and/or
require teams to work closely on numerous interdependent tasks are good candidates for
cyclical management methods. Examples include RI projects with substantial IT elements, RI
projects that have significant research and development needs where defining the final cost,
scope, schedule and capabilities holds too much risk, and commissioning activities (tests,
trials, and acceptance) as part of the Construction Stage.
Figure 3.2.1.2-1
Cyclical Development Process
Agile is one such cyclical method, initially designed for software development project
management, that can be applied to many projects in some form. Within Agile frameworks,
multi-disciplinary teams work cooperatively in stages to model solutions, incorporate
Document Number
91
3.2 Tailoring, Scaling, and Progressively Elaborating Plans
Research Infrastructure Guide
feedback, and adjust scope as needed throughout the project life cycle. Analysis, design,
implementation, and testing are repeated within very short cycles. Rather than employing
hierarchical organizational structures, an Agile framework is often matrixed, with team
members adapting their roles as needed. Performance management is based on cycles and
delivery of capabilities, rather than discrete physical deliverables.
The Government Accountability Office (GAO) Agile Assessment Guide offers best practices at a
high enough level to be used for any incremental development program, regardless of what
type of product or service is being delivered. 1 Agile is not right in all environments. Managing
organizations should spend time upfront assessing the technical nature of the proposed
project as well as the environment and culture to determine readiness to employ Agile
processes (see Section 5.9 Agile Guidance).
3.2.1.3
Level-of-Effort Approach
LOE is a method in which staff or vendors provide a variety of services that span long time
frames and where progress is typically tracked through monthly salary or periodic invoicing
(also known as cost-weighted milestones), rather than discrete tasks and activities. Since the
performance measurement is focused on cost-weighted milestones, EVM may not be the
most valuable method for performance management if the project or program is composed
mainly of LOE activities. However, almost all projects have some component that is LOE, and
these activities can be a significant part of larger projects that are using EVM. If that is the
case, appropriate earning rules need to be applied to these activities.
When tailoring a management model, consider that the LOE approach can be suited for
project management staff, service contracts, and multi-disciplinary teams that share roles
on a limited number of tasks.
3.2.2
Scaling
When deciding on the appropriate approach to scaling, it is important to consider the project
or program characteristics. The appropriate scaling level will emerge by matching
the characteristics to the level of detail, degree of formality, tools, and management
processes needed for success.
Level of Detail. Simple projects or programs might only develop the Work Breakdown
Schedule (WBS) to Level 3 (see Section 4.2 Scope and Work Breakdown Structure), which is
considered the minimum by industry good practices. In contrast, large construction projects
may extend to WBS Level 10 in some areas to capture the work packages in the appropriate
detail for cost estimating and monitoring performance.
Control Accounts, where scope, schedule, budget, and estimated/actual cost are integrated
and compared to earned value for performance measurement, should be set to minimize
accounting efforts while providing insights into status and issues.
1
https://www.gao.gov/assets/gao-20-590g.pdf
Document Number
92
3.2 Tailoring, Scaling, and Progressively Elaborating Plans
Research Infrastructure Guide
Schedules. Schedules should be developed to track work packages accurately. This right level
for achieving an appropriate or optimal standard for capturing and reporting will vary
depending on the scope of work. For example, procurement efforts might have a less
detailed schedule than those involving design, prototyping, demolition, and construction
activities.
Degree of Formality. The degree of formality built into processes and plans is an important
consideration as excessive process can detract from the real focus of project management.
For example, on a Mid-scale RI design effort an appropriate Change Control Plan might be a
simple Change Log authorized by the Project Manager. On a Major Facility project, it is
generally a formal process with tiered thresholds for authorization (including NSF approval),
Change Request Forms, reviews by Change Control Boards, and controlled implementation.
These are both appropriate given the scale of the project and the size of the project
management teams.
Tools. A spreadsheet with cost-weighted milestones may be adequate for simple,
straightforward project or program for cost and schedule tracking. More complex projects
may need commercial software to develop and maintain Resource-Loaded Schedules (RLS)
and perform variance analysis.
Management Processes. Performance management processes also have varying degrees
of formality. For example, NSF oversight requires a Major Facility to have an EVM system that
is verified, accepted, and has periodic surveillance reviews during construction. In contrast,
a Mid-scale RI project electing traditional waterfall methods can use a system to monitor
progress against the plan using its own institutional standards or something as simple as
weighted-milestone tracking (see Section 4.5 Monitoring Progress Against Plan). For
operations, the management process may be handled though routine activity status
reporting to NSF with actual costs against the proposed budgets for each operational WBS
element.
3.2.3
Progressively Elaborating
The progressive elaboration process refines and advances planning of activities from initial,
high-level, rough plans to detailed, mature plans as they pass through life cycle stages,
review process milestones such as stage-gate reviews during the Design Stage, or internal
readiness reviews. The progressive elaboration of plans is both necessary and expected, not
only because of the maturity of the project but also the nature of the project or program
itself.
For example, in Agile methodology for Performance Measurement and Management (PMM),
prototypes support the concept of progressive elaboration because they are used in iterative
cycles of mock-up creation, user experimentation, feedback generation, and prototype
revision to reduce risk. Rolling wave planning, which involves detailed planning (work
package or equivalent) for near-term efforts and more summary-level planning (planning
packages or equivalent) for subsequent attempts, may also be considered a type of
progressive elaboration that increases detail for near-term work.
Document Number
93
3.2 Tailoring, Scaling, and Progressively Elaborating Plans
Research Infrastructure Guide
Consider design efforts for Major Facilities in the Conceptual Design Phase or a pre-proposal
for a Mid-scale RI based on the funding announcement. The level of detail might have the
following characteristics:
•
Budgets are based on parametric estimates or determined top-down.
•
WBS and schedule might be only at Level 2 or 3.
•
Management processes and organization
implementation may be in early development.
•
Initial risk analysis is quantitative, but not yet comprehensive.
•
A process describing how further plans will be developed or matured should be
outlined in the Design Execution Plan.
for
the
Construction
Stage
or
As the design progresses and the Construction Stage or implementation nears, more details
are provided through the Final Design Phase or the Mid-scale RI full proposal. The Level of
Detail will have been progressively elaborated to show the following characteristics:
•
Detailed WBS and dictionary in the latest PEP.
•
Bottom-up budget estimates with a robust GAO-compliant Basis of Estimate (BOE).
•
Detailed schedules, time-phased budget, and funding profile.
•
In-depth risk analysis and risk exposure estimate are used to set contingencies.
•
Management plans are fully developed (e.g., Change Control, cost estimating and
cyberinfrastructure [CI]), Information Assurance (IA), tailored and scaled to project
complexity.
Some planning cannot be completed until after the Construction Stage or implementation
has begun, for example:
•
Process for Quality Assurance/Quality Control (QA/QC) should be well defined, but
specific plans may need to be developed later.
•
Refined commissioning plans may need to be informed by test results.
•
Some late-stage WBS elements may still be at the planning package level.
•
Progressive elaboration allows Project Managers to gradually develop a clearer
understanding of project requirements, scope, and deliverables, leading to more
accurate planning and better project outcomes. By leveraging progressive
elaboration, Project Teams can adapt to changes, mitigate risks, and make informed
decisions throughout the project life cycle.
Document Number
94
3.3 Development Stage Planning
3.3
Research Infrastructure Guide
DEVELOPMENT STAGE PLANNING
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
There are no standard required plans for the Development Stage. As described in Chapter 2
NSF Life Cycle Oversight, the Development Stage is where early ideas for new or upgrades
to Major Facilities are formulated, so planning needs vary widely within scientific disciplines.
For example, early development activities might require a plan to illustrate how and when
workshops and other outreach activities will bring the science community together to draft
science mission requirements or the Key Performance Parameters (KPP). Developing a
Master Plan is also generally considered to be associated with Development Stage activities.
Late-stage development activities might require a plan to illustrate how the design and
science requirements will be refined, prototypes utilized, and a rough order-of-magnitude
cost estimate prepared to support advancement into the Design Stage. These activities could
also be included in the proposal and would not require a separate plan.
Any formal plans required as deliverables would be described in the funding announcement,
if used, and the terms and conditions of the Development Stage award(s). Consultation with
the Program Officer (PO) is encouraged for Development Stage planning and proposal
submission.
Document Number
95
3.4 Design Stage Planning
3.4
DESIGN STAGE PLANNING
3.4.1
Design Execution Plan
Research Infrastructure Guide
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
The Design Execution Plan (DEP) describes the work to be conducted by the Awardee as part
of a design effort.
For Major Facilities, Awardees must submit a DEP in accordance with the NSF award terms
and conditions. Typically, the DEP is first submitted and reviewed to support an award at the
planned entry point to the Design Stage, typically the Conceptual Design Phase, or soon after
NSF approves entry. A DEP would then be submitted and reviewed at the Conceptual Design
Review (CDR) and Preliminary Design Review (PDR) to support the award of the Preliminary
Design Phase and Final Design Phase, respectively.
For a Mid-scale RI project, Awardees must submit a DEP for NSF review in accordance with
the funding announcement or other program requirements. Like the Project Execution Plan
(PEP), a DEP is considered a living document. If the Design Phase is extended or the proposed
activities change, a revision to the DEP may be appropriate.
Regardless of the scale of the project, the primary deliverable to NSF from the design
activities is a refined PEP for the proposed construction, acquisition, or implementation that
may take place in the future, if awarded. Other deliverables the Awardee could provide to
NSF to document progress during design may include technical designs and specifications,
test reports, prototype assessments, and documentation of actual or planned contributions
from other partners. The DEP helps set expectations for all deliverables to NSF for inclusion
in the terms and conditions of the award.
The DEP leverages the 10-component format of the PEP described in Section 3.5
Construction Stage and Implementation Planning. The Awardee must address all ten DEP
sections outlined below and any proposed subcomponents should be tailored and scaled
appropriately for the proposed design activities. However, some components may not be
applicable for all projects, so it is recommended that the proposing organization include a
brief discussion on why any main component is omitted to facilitate NSF review. The content
of the DEP is at the discretion of the proposing organization and will vary dramatically based
on the size, complexity and technical nature of the proposed project. The scope of the DEP
should reflect the activities necessary to advance the proposed project to the next level of
technical readiness, which may be another phase of design or the start of construction or
implementation. The structure and content of the DEP should be as follows:
•
Design Execution Overview: Overview of the proposed design effort to advance the
proposed project.
•
Organization: Description of the organization supporting design, including all
partner organizations and Key Personnel (KP), and where they fit into the
organizational structure.
Document Number
96
3.4 Design Stage Planning
Research Infrastructure Guide
•
Design Baseline: A Work Breakdown Structure (WBS) format, even for Level-of-Effort
(LOE) activities, must be included to help illustrate the primary deliverables and how
the proposed budget was developed. Describe the activities that will be undertaken
in order to achieve readiness for construction, such as design, prototyping,
manufacturing process validation, vendor qualification, modeling and simulation,
creation of required project management plans, and forming partnerships. The
schedule should be logical and credible, and critical design, review, and deliverable
milestones should be listed. A fully developed Integrated Master Schedule (IMS) may
be appropriate for large, complex design activities. As noted above, one deliverable
from design is always a refined PEP to support eventual construction/
implementation, if awarded. The estimate of the total budget required to complete
the design, including NSF funding and any contributions from partners and other
outside sources, and the planned level of design maturity/detail at major milestones
may also be included.
•
Risk Management: This section should include a Risk Register for the design
activities and describe planned risk mitigations being conducted during design,
including testing and prototyping to reduce risk during construction/ implementation,
if awarded. If contingencies are requested for the design award (budget, scope or
schedule), or allowances are included in the estimate of the design effort, they should
be described here, along with how each was developed or estimated. Statistical
analysis (like Monte Carlo) is not required for estimating budget contingency on
design activities.
•
Scope Acquisition and Delivery: Description of significant procurement activities
supporting design and how quality of any deliverables will be assured.
•
Safety, Health and Environmental Protection: This section would be generally
applicable to design activities that involve laboratory testing, prototyping or field
work. Institutional Health and Safety policies can generally be referenced, but
anything specific to the award activities should be considered.
•
Controls: At a minimum, this section should describe how progress against the
proposed plan for design will be monitored and controlled by the Awardee. For larger,
more complex projects, Configuration Control for the design itself should also be
articulated along with how any internal design reviews will be utilized to advance the
design.
•
Information Management: At a minimum, this section should describe how any
information developed during design (specifications, drawing, test results, etc.) will be
managed and controlled (see Section 5.3 Information Assurance).
•
Award Close-out: This section should describe the proposed method on how the
current award will eventually be closed out, which will depend on the structure of the
award and the overall schedule for design. For example, if associated with a Major
Facility, the design award may be extended several times through supplemental
funding requests and award close-out may not happen until well into the
Construction Stage. Consultation with NSF on the award structure is expected for
Document Number
97
3.4 Design Stage Planning
Research Infrastructure Guide
Major Facility Design Stage awards. For Mid-scale RI, award close-out may happen
before a decision is made to advance to implementation depending on the funding
program.
•
Post-Award Plans and Expectations: Post-award in this case means following the
end of the current design award. For Major Facilities, post-award plans may include
submission of the revised DEP for review and award of a subsequent Design Phase
following successful completion of a stage-gate review (see Section 2.5 Major Facility
Design Stage). For Mid-scale RI projects, it may be planned submittal of the mature
PEP to support a future implementation proposal.
Document Number
98
3.5 Construction Stage and Implementation Planning
3.5
Research Infrastructure Guide
CONSTRUCTION STAGE AND IMPLEMENTATION PLANNING
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
The Project Execution Plan (PEP) is an
organized presentation of the various plans NSF Requirement
describing how a project will be planned,
Major Facilities and Mid-scale RI projects
must
submit a PEP, including all components
managed, executed, and concluded by the
and subcomponents, tailored and scaled
Awardee. The PEP should provide a useful
appropriately
for the Construction Stage or
description of the project, what the project will
implementation.
deliver, how performance will be measured
and reported, details on who will manage the
effort, what resources are required to complete the project, how long the project execution
phase will last, when identified milestones are to be met, and how much risk or uncertainty
is associated with the project plans. Awardees must submit a PEP for all Major Facilities and
Mid-scale Research Infrastructure (RI) projects. The PEP is a living document, and Awardees
are expected to carry out the project in accordance with the plan. However, the details of the
plan and associated complexity will vary markedly and should be tailored and scaled to
match the project characteristics (see Section 3.2 Tailoring, Scaling, and Progressively
Elaborating Plans).
The PEP should contain or reference all project-related documents and be the authoritative
source explaining how and why the plan meets all project objectives. As noted in the detailed
guidance sections, some components of the PEP may be detailed or more extensively
presented in appendices or in separate documents, especially living documents like the Risk
Register or lengthy documents like the full Work Breakdown Schedule (WBS) dictionary and
detailed design drawings. The PEP and all associated files should be presented to NSF as a
current, complete, and consistent set, in both PDF and native file formats (e.g., Excel), and
updated versions shared regularly. It should summarize and reference these separate
documents to convey the complete scope of pre-construction planning and allow for
effective evaluation of the project plans. In addition, it is important to note that the PEP is
expected to be updated or revised throughout the development and conclusion of the
individual project. The PEP should be adjusted to reflect changes in all components
described in the following sections.
Detailed guidance on PEP structure and content for NSF-funded Major Facilities and Midscale RI projects is included in the following sections to ensure proposers understand the
what, why, and how of proper project planning. Figure 3.5-1 provides an overview map of the
PEP components and subcomponents that proposers requesting NSF support for RI projects
should follow unless alternate descriptions or content are specified in a program solicitation
or at the direction of the Program Officer or Officers, who will manage the review of any
submitted proposals. Each PEP component is required, regardless of project size, but
some subcomponents may not be applicable for all projects. Proposers must address
all components and subcomponents and may indicate Not Applicable for any that do
not apply and provide a rationale for that determination. Preparation and presentation
Document Number
99
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
of a rigorous and complete PEP will ensure that proposers can present their ideas in the best
possible light, support effective merit review, and serve as a critical resource to manage and
complete RI projects.
Document Number
100
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Figure 3.5-1
PEP Overview Map
Shading in table is for improved readability.
Document Number
101
3.5 Construction Stage and Implementation Planning
3.5.1
Research Infrastructure Guide
PEP Component 1 – Project Overview
What Does This Component Describe?
This component provides a succinct, clear, and unambiguous overview of the project. It
includes an Executive Summary of the project, including whom the project is intended to
serve, the science objectives and purpose of the project (i.e., the driving why behind the
project), and a summary description of the proposed solution to that purpose. A mission
statement for the project is included, along with a brief recap of any scientific and/or broader
impacts that will result from the project. Also included is a high-level summary of the
deliverables, along with the Key Performance Parameters (KPP) and high-level constraints
and assumptions that will be the boundary conditions for the project.
Why Is This Component Important?
First, the overview helps ensure that everyone involved in the project has a shared vision of
the goals the project is trying to achieve. A shared perspective can help to avoid
misunderstandings and conflicts during project execution. The Project Team and funders
gain direction and mission alignment by articulating the why. Second, the overview is a
guiding beacon throughout the course of the project, helping with decision-making and
prioritization. When issues arise that require a choice between competing solutions,
returning to the formal why of the project will often provide clear direction and guidance.
Additionally, the overview helps to foster better understanding and clarity for external
stakeholders as to why particular decisions were made. Finally, the overview can help to
motivate and engage the Project Team by ensuring everyone understands the ultimate goal
and the impact it will have.
How To Develop and Write This Component
There are four subcomponents included in the Project Overview Component, as listed in
Table 3.5.1-1 below. The subcomponents provide a high-level summary of the PEP and the
project, outline the need and motivation for the project, list the high-level requirements to
be met, and finally, describe the Research Infrastructure (RI) solution to the needs and
requirements. The Project Team and funders should reach a consensus of the contents of
the project description.
Document Number
102
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.1-1
Project Overview Subcomponents, Products, and Documents with References to Further Material and Related Topics
Component
Subcomponent
Documents/Products
References
1.1 Overview of PEP and
Executive Summary of
Project
1.2 Project Mission and
Broader Impacts
For Broader Impacts, in
• Project Mission Statement accordance with the award
instrument used.
1.3 Key Performance
Parameters and Scientific
Requirements
• List of Key Performance
Parameters
• Science Requirements
Table
1. Project Overview
1.4 Research Infrastructure
Description
3.5.1.1
Section 4.2 Scope and
Work Breakdown Structure
PEP Subcomponent 1.1 – Overview of PEP and Executive Summary of
Project
This subcomponent serves two primary purposes.
PEP Overview. This overview should provide a short, high-level overview and understanding
of the purpose of the PEP as the project management document, how it is structured and
used, and how it will be updated during the course of the project.
Executive Project Summary. The summary includes high-level statements of why the
project exists, who it will serve, what the primary science objectives are or how the project
supports multiple science objectives, and what will be created and delivered to meet those
objectives (i.e., the RI). The summary should list the Total Project Cost (TPC) and Total Project
Duration (TPD) as well as the major deliverables. A brief description of the key institutions
and partnerships should be included. The summary should be contained in a page or less.
More specific details on these items are then described in their respective components and
subcomponents that follow.
Good Practices and Practical Considerations
•
The primary purpose of the executive project summary is not to promote the project;
that’s the purpose of the project proposal. Instead, it should clearly and
unambiguously describe who the project serves, what will be created and provided
(i.e., the RI), and why the RI is needed by the scientific community and then act as a
manual for implementing the RI.
•
This component provides the project description that is fully agreed upon by the key
project stakeholders, team members, and other relevant parties. It also serves as a
touchstone during project execution to ensure that plans, decisions, and actions align
with the project’s overarching purpose and mission.
Document Number
103
3.5 Construction Stage and Implementation Planning
3.5.1.2
Research Infrastructure Guide
PEP Subcomponent 1.2 – Project Mission and Broader Impacts
This subcomponent describes the overall high-level purposes, scientific objectives, and
broader societal impacts of the project. Specifically, the following elements should be
described in this subcomponent.
Project Mission. This subcomponent includes a more detailed and complete description of
the scientific objectives motivating the RI project than the overview section (i.e., the driving
why behind the project) and a description of who the project is intended to serve (e.g., the
specific scientific community, end users, and benefactors of the RI in operations.)
Broader Impacts. Regardless of the award instrument used, it is important to describe the
impacts of NSF’s investment beyond simply delivering the infrastructure to technical
requirements. This subcomponent provides a description of any meaningful Broader
Impacts that advance scientific knowledge and that contribute to the achievement of
societally relevant impacts on research communities, the scientific and technical workforce,
and the public and society at large. 1
Good Practices and Practical Considerations
•
The best project mission and science objective statements are relatively concise and
clearly state the project’s goals and purpose. A good rule of thumb is to strive to state
the project’s mission in one or two paragraphs. Overly verbose statements often
suggest that the project purpose is not yet fully distilled, understood, or explainable.
Quantitative objectives should be reserved for the KPP and Quality Acceptance
Criteria.
•
There is a common misconception that Broader Impact activities should only be
separate add-ons related to the eventual research activities, but Broader Impacts can
also be integral to the project baseline activities. For example, development of a
diverse, globally competitive science, technology, engineering, and mathematics
(STEM) workforce trained in RI design, implementation, and commissioning can be
addressed by using project activities as practical training to supplement academic
training.
•
There is a practical cost to meeting Broader Impact goals. The scope of deliverables,
activities, and budget that are related to Broader Impacts should be specifically
identified in the project baseline described in PEP Component 3 Performance
Measurement Baseline.
3.5.1.3
PEP Subcomponent 1.3 – Key Performance Parameters and Scientific
Requirements
This subcomponent provides the quantitative descriptions of requirements which provide
the basis for determining the attainment of the scientific objectives and, therefore, project
For financial assistance proposals see
https://www.nsf.gov/nsb/publications/2022/merit_review/FY_2021_Merit_Review_Digest.pdf
1
Document Number
104
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
completion.
Key Performance Parameters. The KPP are derived from the project mission and science
objectives and should include a descriptive list of the high-level KPP and functional
requirements of the RI. A KPP is a critical feature, function, requirement, or design element
that, if altered, may significantly impact the facility or system’s performance, scope, schedule,
cost, risk, or the ability of a related project to meet its mission requirements.
Threshold KPP encompass the minimum science parameters against which the project could
be considered successful.
Project Teams may choose to include objective KPP that describe the optimal or desired
technical goals of the project, provided performance is sustained and sufficient resources
are available. Objective KPP often enhance operational efficiency or extend science
capabilities. Appropriate parameters are those that express performance in measurable
terms of accuracy, capacity, throughput, quantity, processing rate, purity, reliability,
sustainability, or others that define how well a system, facility, or other project will perform.
The difference between objective and threshold KPP should relate to scope/quality
contingency plans. If the Project Team is forced to de-scope or re-baseline, the threshold KPP
may need to be accepted (see Section 4.7 Contingency Estimating and Management).
Alternatively, the objective KPP may represent an opportunity that can be captured.
Science Requirements. These requirements should include a high-level listing of the
primary science requirements to be fulfilled by the RI, derived from the KPP described above.
Note that these requirements should in turn serve as a basis for the definition of project
scope (deliverables).
Document Number
105
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.1.3-1
Key Performance Parameters and Science Requirements for a Hypothetical Mission to Build a Next-Generation
Ground-Based Optical Telescope
Key Performance Parameters
(KPP)
Description of Scope
Facility Size
Observational Capability
Duty Factor
Facility Lifetime
Threshold KPP
Objective KPP
Threshold spaces plus Admin
Dome building including control room;
building with data storage, meeting
utilities building
room, and 8 offices
Angular resolution capable of
resolving exoplanets orbiting stars
within 70 light years
Angular resolution capable of
resolving exoplanets orbiting stars
within 100 light years.
Observing time in faint object
operating mode: More than 1000
hours per year.
Observing time in faint object
operating mode: More than 1500
hours per year.
Operating lifetime of observatory of
40 years.
Operating lifetime of observatory of
50 years.
Science Requirements
Description of Scope
Threshold Requirement
Objective Requirement
Facility Size
124,000 SF
127,000 SF
Brightness
The telescope must operate at
wavelengths from ultraviolet (200300nm) to near-infrared (11002500nm)
The telescope must operate at
wavelengths from ultraviolet (200300nm) to near-infrared (11002500nm).
Observing resolution of 0.5 arcseconds.
Observing resolution of 0.1 arcseconds.
Science instrument achieving signalto-noise ratios greater than 50:1.
Science instrument achieving signalto-noise ratios greater than 100:1.
Spatial Resolution
Signal-to-Noise Ratio
Good Practices and Practical Considerations
•
3.5.1.4
The key science requirements, constraints, assumptions, and other requirements
included herein this subcomponent should only include very specific, high-level
requirements; the complete list of science requirements, flow-downs to engineering
requirements, and all quality acceptance criteria are described below in PEP
Component 3 Performance Measurement Baseline.
PEP Subcomponent 1.4 – Research Infrastructure Description
This subcomponent describes the infrastructure necessary to obtain research and Broader
Impact objectives. Specifically, the following elements should be described herein in this
subcomponent.
RI Description. This subcomponent should include a high-level overview of NSF-supported
RI, i.e., the project deliverables. The descriptions should correlate directly with the Level 2
product scope (deliverables) of the Work Breakdown Structure (WBS), as described in PEP
Component 3 Performance Measurement Baseline below.
Related Infrastructure. If the project deliverables are to be incorporated into or with other
infrastructure or deliverables not covered under the funding instrument, the goals of the
Document Number
106
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
larger infrastructure should be articulated, along with the relationship of the project
deliverables with the wider goals.
Good Practices and Practical Considerations
•
This subcomponent serves as an Executive Summary and overview of what the
project will create and/or provide; it does not replace the WBS described below in PEP
Component 3 Performance Measurement Baseline. Instead, this subcomponent
provides a high-level overview of the project deliverables, described at Level 2 of the
WBS. The WBS and WBS Dictionary provide the formal definition and description of
the project scope.
•
It is often helpful/useful to describe key exclusions in this subcomponent, that is,
items that are aspects of the RI that might reasonably be expected to be part of the
project deliverables but that are provided by other means/funding/entities. Examples
might include space and site preparations provided by the host institution or spare
equipment to be used and provided by operations.
3.5.2
PEP Component 2 – Project Organization
What Does This Component Describe?
This component describes the internal and external organizational structure necessary for
successful project implementation. It includes a description of the Project Organization and
defines key roles, responsibilities, and communication lines for both external stakeholders
and internal project staff.
Why Is This Component Important?
A Project Organizational structure that matches the characteristics and needs of the Project
Team will facilitate successful management and completion. Well-considered positions and
assignments avoid miscommunications and misunderstandings and ensure that all
stakeholders and project participants are aware of their respective roles, responsibilities,
authorities, and lines of communication during the execution of the project.
How To Develop and Write This Component
There are four subcomponents in Component 2 – Project Organization, as listed in Table
3.5.2-1 below. The first three provide an overview of the organization and detailed
descriptions of the external and internal participants and stakeholders, and the fourth
subcomponent is specific to collaborations or partnerships with other entities and
institutions for the project.
The Project Organization should be structured in a manner tailored and scaled to the type,
size, complexity, and characteristics of the project. The Project Team and funders may be
familiar with the organization and reach consensus of its structure, roles, and authorities.
The organization is typically developed in a progressively elaborated approach, as described
below in Subcomponents 2.2 – Internal Project Organization and 2.3 – External Project
Stakeholders below.
Document Number
107
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.2-1
Project Organization Subcomponents, Products, and Documents with References to Further Material and Related
Topics
Component
Subcomponent
Documents/Products
References
2.1 Overview of Project
Organization
2.2 Internal Project
Organization
• Organization Chart
• Roles and
Responsibilities Table
2.3 External Project
Stakeholders
• Organization Chart
• Roles and
Responsibilities Table
2.4 Partnerships and
Subawards
• List of Partners,
Agreements, and
Contributions
2. Project Organization
3.5.2.1
Section 4.2 Scope and
Work Breakdown Structure
Section 5.7 Personnel and
Competencies
Section 5.8 Partnerships
PEP Subcomponent 2.1 – Overview of Project Organization
The overview provides a summary of the Project Organization, including the general Project
Organizational structure, key participants, external stakeholders, project partners, and any
other important organizational information necessary to explain and execute the project
successfully.
3.5.2.2
PEP Subcomponent 2.2 – Internal Project Organization
This subcomponent describes the internal organizational structure of the Project Team. The
identification of key internal positions and leadership roles should occur early in the project
planning process, along with the selection of an organizational structure that is compatible
with the project characteristics. The chosen organizational structure should be matched
(tailored) to the characteristics of the project and aligned with the key project deliverables as
detailed in the project Work Breakdown Structure (WBS) containing all project scope. The
organizational structure should dictate roles and lines of responsibility and authority.
An internal organizational chart and a roles and responsibilities table are essential for all
implementation and Construction Stage projects in this subcomponent. The organizational
chart is a graphic representation of the internal project Organizational Breakdown Structure
(OBS) and shows key roles and leadership positions within the Project Team and clear lines
of communication and authority. A roles and responsibilities table provides a description of
the roles, responsibilities, authorities, and communication linkages between key leadership
and management positions in the internal organization.
Internal Organizational Chart. The three most common structures for NSF projects are
traditional hierarchical, functional, and matrixed. The chosen organizational structure
should be negotiated with and approved by NSF.
Traditional organization structures are hierarchical in nature and match a traditional (often
called Waterfall) WBS. Project roles are aligned with the deliverables captured in the project
Document Number
108
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
WBS. Lines of authority and responsibility for deliverables in the WBS are one-to-one and
flow from the top levels of the WBS down to lower levels. Roles and responsibilities can be
clearly and simply defined. An example of a traditional Waterfall organization chart is shown
in Figure 3.5.2.2-2.
Functional organizations, where leads and teams are aligned with institutional and support
functions rather than deliverables, are allowed but are less common. Functional leads report
directly to the Project Manager (PM) and manage their staff’s assignments to work on
deliverables across the WBS. The mapping between leadership below the PM and
responsibility for deliverables in functional organizations can be less clear than in traditional
hierarchical structures since one individual or support group may serve the same function
across several WBS elements. In that case, a Responsibility Assignment Matrix (RAM) that
assigns individuals or organizations to all tasks and deliverables becomes essential for
assuring that all project scope has assigned and responsible oversight. A typical RAM may
have four primary assignments: Responsible, Accountable, Consulted, and Informed (and
therefore is also called a RACI matrix). An example of a functional organization chart is given
in Figure 3.5.2.3-1.
Figure 3.5.2.2-1
Functional Project Organization: Capability Area Leads Reporting to Project Manager with Deliverable Responsibilities
Projects that are cyclical in nature or that require flexibility and speed, such as software
projects based on Agile frameworks, may rely on a matrix or non-hierarchical organization.
A matrix organization can be represented by a grid with functional roles on one axis and
hierarchical roles along another. Managers and leaders share authority and responsibility
for deliverables with others, and workers may report to multiple supervisors. Note that NSF
requires a traditional, hierarchical structure down to WBS Level 2 (see Section 3.5.3.2 PEP
Subcomponent 3.2 – Scope) but allows flexibility in organizing below those levels along other,
well-justified structures such as Agile-based Stories, Epics, or other cyclical work packages.
An example of such a hybrid organization that includes an Agile structure at lower WBS levels
is shown in Figure 3.5.2.2-2.
Document Number
109
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Figure 3.5.2.2-2
Example of a hybrid organization incorporating an Agile structure at lower WBS levels
Key positions, organizational structure, relationships, and roles and responsibilities should
be determined as early as possible in the Project Team. Not all positions may be identified
at first, nor will all be filled during early planning. As planning matures and approaches the
start of implementation and Construction Stage, roles will become better defined, and
individuals can be identified and assigned to the positions in the chart. The Resource
Management Plan that is detailed in PEP Component 4–Risk and Contingency Management
should provide details of how any unassigned key positions will be filled in a timely manner
through hiring or other means (for example, hiring plan schedule and actions to ensure that
key personnel (such as a PM) are on board by the start of implementation).
Roles and responsibilities for leadership positions should be aligned with the needs of the
position before any consideration of personnel assignments. Personnel selected for
leadership and key roles in the Project Team should have all the necessary skills, experience,
and qualifications for the assigned position, including scientific, technical, and administrative
qualifications. Awardees may want to consult Section 5.7 Personnel and Competencies for
assistance in defining the roles and responsibilities. Written and tabulated examples of roles
and responsibilities are shown below.
Document Number
110
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Figure 3.5.2.2-3
Example of Written Descriptions of Roles and Responsibilities
Environmental, Safety, and Health (ES&H) Officer:
• An ES&H staff member trained in safety and shop operations will provide weekly guidance and oversight on
safety and compliance. The ES&H Officer will advise on safety-in-design aspects of the design and assembly
plans. The ES&H Officer will visit and assess the safety plans for the assembly site and review the safety plans
for testing.
Project Manager (PM):
• The PM reports to the PI and is responsible for the oversight of the budget, schedule, change management, and
risk management. The PM oversees the work package leads and manages the execution of the project to ensure
that the project is completed within the approved cost, schedule, and technical scope. The PM is responsible for
the development, documentation, and implementation of effective project management systems, cost controls,
and schedule milestones to assess project performance. The PM is responsible for risk evaluation and
management in accordance with the project Risk Management Plan. The PM chairs the Change Control Board
and is responsible for approvals before passing Change Requests to the PI for final approval.
Table 3.5.2.2-1
Example of a Roles and Responsibilities Table
Roles and Responsibilities
Title
Bike Spec and
Design Team
Lead
Name and
Institution
Roles and Responsibilities
Maria Martinez, • The Bike Spec. and Design Lead reports to the PM and is accountable for
Tech Univ. Eng.
meeting designated work package deliverables.
Department
• Responsible for keeping communications open with the PI, the PM, other
team leads, and all Project stakeholders.
• Responsible for planning and maintaining the technical design, scope, cost,
and schedule.
• Supervises the resources and contracts for accomplishing the tasks and
adjusts the schedule to meet stakeholders’ needs.
• Assures compliance with technical requirements, Project configuration
management, and Tech Univ. policies/procedures regarding procurements
and EH&S.
• Monitors and controls risks, tracks progress against the plan, and reports
status and variances on the defined schedule.
• Participates in Change Control Board discussions and follows configuration
controls with respect to changes in scope, cost, schedule, and/or
performance.
Good Practices and Practical Considerations
•
The size and complexity of the organizational chart (the number of leadership roles
and layers of authority) should align with the project's characteristics. For example,
large complex projects may choose to assign a lead and a deputy for a particular
leadership position so that, between the two, both technical and management needs
can be met. Smaller and less complex projects may include only one individual for
each leadership role, and those individuals may serve in multiple leadership
assignments.
•
Whether projects combine the PI and PM roles into one, keep them separate or add
a third role for a Project Director, each role should be clearly and fully described.
•
Carefully consider the number of direct reports to a manager based on the types of
Document Number
111
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
positions and level of supervision and management required.
•
The organizational structure presented in the PEP should be high-level and include
leadership and KP, not every individual working on project tasks. Key positions listed
in the internal project organization should include the PI and Co-PI, the Project
Director if separated from the PI role, the PM, primary Technical Leads and Control
Account Managers (CAM), and any other key leads, such as Safety Officers or Systems
Engineers. The complete listing of all project positions is developed in the Staffing
Plan described in PEP Subcomponent 5.4 – Resource Management Plans.
•
For traditional organizations, it is good practice to include WBS numbers in the
organization chart to easily tie responsibility and authority to work packages and
deliverables.
•
Technical team leadership may be shared between a Lead and a Deputy, with one
assuming leadership in scientific or technical aspects and the other leading day-today activities and project management responsibilities.
•
The focus for the definition of the organizational roles and responsibilities should be
the requirements for the position to be filled. It is not necessary to list all the
experience, positions, and honors of the assigned key and leadership personnel in
this section.
•
If additional Project Team training is planned, it should be included in the Staffing
Plan as described in PEP Subcomponent 5.4 – Resource Management Plans. Examples
may include general project management training as well as specific training for CAM
performance reporting and tracking.
•
RAM and RACI tables are common ways to capture roles and assignments. Many
projects expand their RAM with CAM assignments. The essential goal is to ensure that
all WBS elements or deliverables have an assigned individual with responsibility and
authority to ensure that all scope is completed within budget and schedule while
meeting requirements.
3.5.2.3
PEP Subcomponent 2.3 – External Project Stakeholders
In this subcomponent, key external project stakeholders are identified and described, along
with their connection to the project, their expected roles, and their lines of communication
and authority. External stakeholders are individuals and entities with relationships to, and
interactions with, the project that do not normally involve contributions to day-to-day project
activities or deliverables (e.g., NSF, user groups, host institutions, etc.). The following
products of this subcomponent include:
•
External Organization Chart. A graphical depiction of how the project structure
relates and interacts with all key external stakeholders.
•
Roles and Responsibilities List. A table or list with descriptions of the roles,
responsibilities, authorities, and communication links between the project and all
identified key external stakeholders.
Document Number
112
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Examples of a sample external organization chart and example roles and responsibilities
descriptions are shown in Figure 3.5.2.2-1 and Table 3.5.2.2-1 below. Please note that the
figures and tables are only illustrative, and projects should decide and define the structures
and roles that best match their needs.
Figure 3.5.2.3-1
External Organization Chart: Authority and Communication Lines in a Traditional Project Structure
Generally, external stakeholder relationships start to be identified or formed during the
Project Definition period, with communication and interactions initiated well in advance of
the start of the Construction Stage or implementation. The external organization chart
becomes more refined as planning advances and becomes mature. For stakeholder
relationships not yet established, the Awardee should explain the plans and steps necessary
to set up communications and interactions, including details such as identified contacts,
frequency of meetings, charters, intellectual property provisions, along with others.
The types and number of external stakeholders included in the external organization varies
from project to project, based on project characteristics and needs. External stakeholders
may include, but are not limited to, the following:
•
Funding and Oversight Groups. NSF is typically the primary funding and oversight
entity for projects described in this PEP. For projects that are part of a larger
endeavor, there may also be other external entities with oversight and responsibility
for the overall project, including the NSF-funded portion.
•
Institutional Project Sponsors. These are typically leaders or departments in the
Awardee organization with an interest in the outcome of the project and
organizational authority to provide resources and overcome barriers to the project.
Examples: vice president for research, sponsored research offices, facilities providing
space and resources, institutional business, and administrative services departments,
and so forth.
•
External Advisory Boards. Some projects may have a group of Subject Matter
Experts (SME) that provide ongoing consultation for science and technical matters,
Document Number
113
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
community engagement, programmatic advice, or other relevant topics. The
oversight function is the responsibility of NSF and/or other funders.
•
External Technical Review Boards. These are independent review or readiness
panels, organized by the Project Team, that provide the Team advice on various
technical topics. They are typically composed of SMEs external to the Project Team
but can also include ad hoc internal SMEs from unrelated components of the project.
These external, technical review boards are generally in addition to review panels or
boards used to verify designs or accept quality testing.
•
Research
Community
Stakeholder
Groups.
Projects
may
maintain
communications with representative groups comprised of researchers interested in
using the infrastructure or resultant data and who, therefore, have an interest in the
project deliverables and future operations. Examples of these may include a Science
Working Group or a user’s group. Relationships with these groups are typically for
information exchange only.
•
Public Community Stakeholder Groups. Projects may likely want to establish
relationships with representatives of the public who have an interest in the public
impacts of project implementation and who may, therefore, have influence on project
activities and outcomes. Examples include individuals, communities, organizations,
and anchor institutions such as governments, federal, state, and local agencies,
schools, libraries, health and social service providers, tribal and indigenous-serving
organizations, non-profits, cultural organizations, and businesses.
The most common structure used for an external organization chart for a Mid-scale RI
project is the traditional, hierarchical layout, as shown in Figure 3.5.2.3-2.
Document Number
114
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Figure 3.5.2.3-2
Hierarchical Organization Structure for a Traditional Waterfall Project with Work Breakdown Structure-Aligned
Leadership Positions
Note that relationships between project leadership and external stakeholders are indicated
with clear lines of communication and authority shown on the chart. Arrows, dotted lines,
and position in the chart can indicate the direction of interactions, oversight and authority
versus communications, and primary contacts.
Table 3.5.2.3-1
Examples of External Roles and Responsibilities
External Roles and Responsibilities
External Advisory
Board
User Group Board of
Representative
The Advisory Board is composed of SME, recommended by the project leads, and
appointed by the project PI for the duration of the project. The Board provides advice and
recommendations on project management and technical issues to the PI.
The users’ group is an independent, external coalition of researchers and potential users of
the completed infrastructure, with a stake in the design requirements, performance, and
operations of the infrastructure. A Board of Representatives, comprised of volunteer or
elected members and serving according to the Group’s charter, will meet with the project
PI. During the meetings, the PI will update the Board on the status and plans of the project,
while the Representatives will provide input on the desired usage of the infrastructure and
communicate any concerns or issues that may impact the wider research community.
Good Practices and Practical Considerations
•
Advisory groups (technical advisors or user groups) have no oversight or role of
authority in the Project Team, and the PI has no duty to adjust project requirements
and goals. However, the PI should be responsive to requests and concerns as allowed
by the constraints of the project.
Document Number
115
3.5 Construction Stage and Implementation Planning
3.5.2.4
Research Infrastructure Guide
PEP Subcomponent 2.4 – Partnerships and Subawards
This subcomponent identifies all partners and Subawardees who are essential contributors
to the success of the project, describes their contributions, and identifies the responsible
partner contact/lead. Information on funding sources for each partner, the terms and
conditions of the partner agreement (Memorandum of Understanding [MOU], subaward,
commitment letter, etc.), and details of schedules and interfaces should be provided, and
may include discussions of the criticality of the deliverable, along with backup plans if the
partner struggles or cannot deliver. For subawards, describe how oversight is to be managed
by and through the primary Awardee. This includes specific roles of key partner personnel,
frequency of oversight meetings, how Performance Measurement and Management (PMM)
will be executed, how financial oversight will be managed, how risk and contingency are
managed, and other relevant information necessary to ensure project success. An example
of a partnership summary table with relevant partnership information is shown below.
Table 3.5.2.4-1
Example List of Partners: Agreement Types, Lead Contacts, and Areas of Support/Contributions
Partner Type
Sub-award
Partner
Institution
Jim’s Custom
Bike Builder
Lead
Jim Jones
Area of Support
• Provide space, labor, and tools for bike assembly
• Develop and Deliver Final Manufacturing and Assembly
Plan
• Provide staff to work on the bike design team
• Work with partner on adapting plans to target audience
In-Kind,
SportMoto Parts Mike Malone
Memorandum of Company
Understanding
• Donate 8 moto-bike sand tires for design studies and
prototype use
Sub-award
• Provide input on target community needs
• Provide a team of 5 riders experienced in testing bikes and
components in punishing conditions for up to 100 hours of
testing in designated terrain
• Distribute the final design and Manufacturing and
Assembly Plan to its network of workshops in appropriate
areas in Africa
Buffalo Bicycles Brian Moonkola
Subsidiary of
World Relief
Bicycles
Good Practices and Practical Considerations
•
Key considerations for forming partnerships are given in Section 5.8 Partnerships.
International partnerships, for example, require early planning and communication
of intent to NSF.
•
The body of the section should contain the partnership details in text format, but it is
good practice to provide a summary table with key information for easy reference.
•
If there are external partners, their project roles and responsibilities should also be
described.
Document Number
116
3.5 Construction Stage and Implementation Planning
3.5.3
Research Infrastructure Guide
PEP Component 3 – Performance Measurement Baseline
What Does This Component Describe?
This component describes the Performance Measurement Baseline (PMB) that defines and
documents the four objective measures of project success: scope, quality, schedule, and
budget. These four elements are captured in a suite of documents, including a Work
Breakdown Structure (WBS), WBS Dictionary, Quality Acceptance Criteria, Integrated Master
Schedule (IMS), and a time-phased budget. Additionally, this component provides a summary
view of the Total Project Definition, which includes the contingency associated with each of
the four PMB elements and a yearly funding profile.
Why Is This Component Important?
The PMB is the pre-defined and documented definition of project success. It is the agreedupon objective target upon which all project activities should be planned and directed. A
successful project aims to deliver 100% of the scope as defined in the PMB, meeting all of its
quality acceptance criteria, and doing so on schedule and within budget. One cannot fully
plan, execute, or close a project successfully without a well-defined and stable PMB.
How To Develop and Write This Component
There are five subcomponents to be included in PEP Component 3 – Performance
Measurement Baseline, as listed in Table 3.5.3-1 below. Each subcomponent has several
identified documents or products that should be created during the development of this
component.
The PMB should be structured in a manner that matches the project characteristics and is
agreed upon by the participants and key stakeholders. This entire component should be
tailored and scaled to the individual type, size, complexity, and characteristics of the project.
Further, the subcomponents should be developed in a progressively elaborated approach,
as described in Section 3.2 Tailoring, Scaling, and Progressively Elaborating Plans.
Document Number
117
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.3-1
Performance Measurement Baseline Subcomponents, Products, and Documents with References to Further Material
and Related Topics
Component
Subcomponent
Documents/Products
References
• Total Project Cost (TPC)
3.1 Overview of the
and Total Project Duration NSF Major Facilities–
Performance Measurement • Summary Milestones
Earned Value Management
Baseline and Total Project
Gold Card 1
• Summary Budget and
Definition
Funding Profiles
3. Performance
Measurement Baseline
1
3.2 Scope
• WBS
Section 4.2 Scope and
• WBS Dictionary
Work Breakdown Structure
• Scope Management Plan
3.3 Quality Acceptance
Criteria
•
•
•
•
3.4 Integrated Master
Schedule
• Schedule Basis and
Estimating Plan
• Integrated Master
Schedule
• Reporting Milestone Table
3.5 Time-Phased Budget
• Cost Estimating Plan
(CEP)
• Cost Book and Basis of
Estimate (BOE)
• Time-Phased Budget
Requirements Documents
Specifications
Test plans
Acceptance criteria
Section 4.4 Schedule
Development, Estimating,
And Analysis
Government Accountability
Office (GAO) Schedule
Estimating Guide
Section 4.3 Cost Estimating
and Analysis
GAO Cost Estimating Guide
https://www.nsf.gov/bfa/rio/evm-gold-card
Document Number
118
3.5 Construction Stage and Implementation Planning
3.5.3.1
Research Infrastructure Guide
PEP Subcomponent 3.1 – Overview of the Performance Measurement
Baseline and Total Project Definition
This subcomponent serves as an Executive Summary and overview of the project PMB and
Total Project Definition, providing all the essential high-level features of the project in one
place. The PMB encompasses the four components: scope, quality, schedule, and budget. In
addition to the PMB, the Total Project Definition adds contingencies and fees (the profit
component of a contract, i.e., fixed fee or cost-plus fee, where authorized) to obtain the
TPCAWD and TPD for the NSF award. 1 The Total Project Definition also includes a time-phased
budget for the funding required to execute the project, a funding profile for the NSF TPC,
and any outside funding necessary to execute the project. The following four
subcomponents address the PMB, while contingencies are addressed within PEP Component
4 – Risk and Contingency Management and fees are discussed in Section 4.3 in Cost
Estimating and Management.
The Subcomponent overview should describe the project scope at WBS Level 2 and state the
key elements of the Total Project Definition: the TPCAWD (i.e., PMB budget + budget
contingency + fee), the TPD (PMB schedule + contingency), and the planned start date. The
budget and schedule contingency percentage of the baseline should also be given. The text
should be accompanied by a summary table of the key Total Project Definition elements,
including a list of the Level 2 WBS elements (scope) and associated budgeted costs, schedule
dates, and durations. The table should include overall budget, schedule contingency
amounts, and baseline percentages in summarizing the TPCAWD and TPD.
Table 3.5.3.1-1
Example of a Project Summary Table: Level 2 WBS with Costs, Schedule, TPC, TPD, and Assigned Responsibilities
WBS #
WBS Element Name
WBS Lead
Lead
Institution
Budget
Schedule Dates and/or
(Duration)
1
Project Name
Project
Manager
INST 1
-
Start / End (Months)
1.1
L2 Element
Control
Account
Manager
(CAM)
INST 2
$$
Start / End (Months)
1.2
L2 Element
CAM
INST 3
$$
Start / End (Months)
1.3
L2 Element
CAM
INST 1
$$
Start / End (Months)
Performance Measurement Baseline Budget
$$$$$
Years/months
Contingency Budget (% of Baseline)
$$ (%)
Years/months (%)
Fee (if applicable)
$
Total Project Cost (TPCAWD)
$$$$$$$
Years/months
A time-phased funding profile for the financial resources needed to accomplish the project
1
https://www.nsf.gov/bfa/rio/evm-gold-card
Document Number
119
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
activities is detailed in this subcomponent. This is typically demonstrated in a table, with
accompanying text that explains up and down ramps, along with unusually large peaks and
low points. At a minimum, the table should include the time-phased project PMB
commitment budget (spending plus obligation), the potential yearly contingency allocation
amount, and the TPCAWD. Other funding sources (i.e., non-NSF) should also be included as
distinct, separate elements. An example is shown in Table 3.5.3.1-2. In the event NSFmanaged Other Direct Costs or Management Reserve are a part of the TPCNSF, consult with
NSF on potential additional tables that may be presented in the PEP. 1
Table 3.5.3.1-2
Commitment and Funding Profile by Fiscal Year Sample Table
Item
Year 1
Year 2
Year 3
Totals
Performance
Measurement
Baseline Budget
$15,350,650
$8,500,375
$34,560,180
$58,411,205
Contingency Budget
$2,302,598
$1,700,075
$5,184,027
$9,186,700
Total Project Cost
(TPCAWD)
$17,653,248
$10,200,450
$39,744,207
$67,597,905
Good Practices and Practical Considerations
•
It is good practice to include the responsible lead partner institutions in the project
summary shown in Table 3.5.3.1-1, if any, and the assigned CAM if known.
•
Some projects break the baseline budget in the project summary definition and
funding profile tables down into cost categories to enhance understanding of the
budget flow. For example, early project costs may be mostly equipment and materials
and supplies (M&S) procurements, while later costs may be labor dominated.
Commonly used cost categories include equipment, M&S, labor, and travel, or just
labor and non-labor. Some projects may separate indirect and direct costs in the
summary funding profile.
•
Budgets and funding profiles should include escalation and inflation adjustments for
all project costs in then-year dollars for the planned project spend date, which may be
three to five years after a project proposal is submitted. The justification for all
escalation assumptions and inflation factors may be included in the CEP and used
consistently throughout the BOE.
3.5.3.2
PEP Subcomponent 3.2 – Scope
This subcomponent identifies and describes the baseline scope of the project via two key
documents: a WBS and a WBS Dictionary. The WBS integrates and relates all funded activities
(scope, schedule, and cost) and is used throughout the project management to identify and
monitor project progress (see Section 4.2 Scope and Work Breakdown Structure for detailed
guidelines on developing a WBS). Every project, regardless of type, size, or complexity, must
have a WBS that includes at least specific Level 2 deliverables. Below that level, the details
https://www.nsf.gov/bfa/rio/evm-gold-card
Document Number
120
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
may be dependent on the project specifics. Summaries of these two documents are included
in this PEP subcomponent.
Work Breakdown Structure. The full scope of
the project is identified and listed in a Key Takeaway
deliverables-based WBS, where the deliverables A deliverables-based WBS should be used
are comprised of the project's products, results, to organize the complete scope of the
project.
and services. The project’s WBS is an organized
hierarchical listing by name or title of all scope
in the project. If the complete WBS for the project extends to levels below Level 3, it may be
too large for inclusion in its entirety within the PEP. In that case, the full WBS should be
maintained in a separate document or appendix, and only the first few WBS levels should be
displayed in the PEP. A statement should be made enumerating the number of levels and
providing a reference to the full WBS as a supplementary document.
Note that the WBS structure should be tailored and scaled to the project and organization
characteristics. Most, but not all, NSF projects are usually well matched to a traditional
Waterfall framework, with a hierarchy of elements that sum up to higher levels. Traditional
hierarchical frameworks are most common, but NSF allows other frameworks, depending
upon the project characteristics. Software developers and other organizations accustomed
to cyclical planning and management methods, for example, may be accustomed to an Agile
framework.
If a Project Team elects to use a non-traditional WBS and management framework, it needs
to present a clear justification and description of the terms and methods to be used. For
instance, Agile projects may equate Stories or Epics (see Section 5.9 Agile Guidance) with work
packages in traditional project frameworks.
WBS Dictionary. A corresponding high-level WBS Dictionary summary is also included in this
subcomponent. The WBS Dictionary defines and describes each element of the WBS. Like
the WBS itself, the full WBS Dictionary is typically created as a supplementary document and
referenced within the PEP. The WBS Dictionary that is included in this subcomponent is
limited to the Level 2 or Level 3 WBS determined above. See Table 3.5.3.2-1 as an example.
Document Number
121
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.3.2-1
Illustration of High Level WBS Dictionary
WBS #
WBS Element Name
Element Description (Simplified WBS Dictionary Entry)
1
Project Name
1.1
L2 Element Name
High-level deliverable description, including key subcomponents,
significant exclusions, and other relevant high-level information necessary
to describe the element clearly and unambiguously.
1.1.1
L3 Element Name
High-level deliverable description, including key subcomponents,
significant exclusions, and other relevant high-level information necessary
to describe the element clearly and unambiguously.
1.2
L2 Element Name
High-level deliverable description, including key subcomponents,
significant exclusions, and other relevant high-level information necessary
to describe the element clearly and unambiguously.
1.2.1
L3 Element Name
High-level deliverable description, including key subcomponents,
significant exclusions, and other relevant high-level information necessary
to describe the element clearly and unambiguously.
Scope Management Plan. A Scope Management Plan must be developed for Construction
Stage projects (see Section 4.7.2.3 Scope Contingency), Mid-scale RI should develop one as
part of their PEP. The Scope Management Plan should clearly and concisely describe the
overall strategy and approach to managing scope. It should describe how scope is identified,
defined, described, and documented in the WBS. The Scope Management Plan should
describe specific roles and responsibilities for managing project scope. Further, since scope
change opportunities may not be available throughout the life of the project, the Scope
Management Plan should define how scope is to be controlled over the course of the project,
including the management of scope creep pressures. Finally, the Scope Management Plan
should describe how and how often both de-scope and up-scope options will be identified,
documented, and tracked, as well as how they will be considered, reviewed, and approved
or rejected via Change Control and/or configuration management. Relevant information
such as WBS area estimated cost and schedule impacts, time frames in which the de- and
up-scopes are viable, priorities of these options, and how decision dates will be incorporated
in planning (e.g., inclusion in the IMS) should be included.
If a Scope Management Plan is developed, it should contain the following, at a minimum.
•
De-scope options that:
Are time-phased and identify the early, optimal, and latest date that each option can
be implemented (trigger dates), and the associated project milestones. It should
also note potential schedule impacts and considerations, such as whether it could
be delayed or added later.
Identify the impact to science operations, including any affected KPP,
minimum/threshold technical requirements or performance criteria, and technical
objectives. Indicate the relative priority of options from least to greatest impact.
Include the expected cost reduction of the option and a basis for that amount.
For Major Facilities, per the No Cost Overrun Policy ([NCOP], see Section 2.6.1.1
Implementation of NSF’s No Cost Overrun Policy), should total at least 10% of the
Document Number
122
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
baseline budget presented at PDR. This 10% is then confirmed at FDR and at the
start of construction. If the Awardee does not consider this 10% total achievable
without significant impact, or if options are only available early in the Construction
Stage, then the Scope Management Plan should explain why and what other risk
management alternatives might be available. For Mid-scale RI, this 10% of the
baseline target is a good goal at the time of award, if a Scope Management Plan is
proposed.
•
Scope opportunities that:
Are time-phased and identify the early, optimal, and the latest date that each option
can be implemented, and the associated project milestones. It should also note
potential schedule impacts and any other considerations.
Are directly associated with the general construction project scope as determined by
NSF.
Include the expected cost of the option and a basis for that amount.
•
Define how scope contingency options relate to Quality Acceptance Criteria and
Project Closeout Plans (see Sections 3.5.3.3 PEP Subcomponent 3.3 – Quality
Acceptance Criteria and 3.5.9 PEP Component 9 – Project Closeout Plans).
Good Practices and Practical Considerations
•
While task-based WBS are acceptable in some industries, a product-oriented WBS is
preferred for NSF RI projects. That is, the WBS should capture only deliverables:
products, services, and results. Associated tasks and activities are captured in the
project’s IMS, not the WBS. One simplistic way to think of this is that the WBS includes
nouns while the schedule includes action verbs.
•
The level of detail in the WBS should match the stage, size, and complexity of the
project. The lowest-level elements of the WBS on any branch are called work
packages. Work packages serve as the focus on corresponding activities in the IMS,
that is, the activities in the IMS should be developed and organized around the
provision and delivery of the work package scope. Similarly, work packages are used
as the lowest level budgeting elements in the time-phased budget, that is, the cost
BOE described below in PEP Subcomponent 3.5 – Time-Phased Budget are
established at the work package level.
•
In a hierarchical WBS, lower-level WBS elements roll up to higher levels such that each
high-level WBS is the sum of the lower-level elements and work packages.
•
When naming lower-level WBS elements, add identifiers that link to the higher-level
WBS. For example, Procurement may occur many times in the WBS, but Periscope
Optics Procurement will distinguish between the various other procurements and
avoid confusion when viewing elements out of context.
•
Control Accounts and CAM should also be identified for each high-level WBS element
of scope to ensure proper management and oversight are provided.
Document Number
123
3.5 Construction Stage and Implementation Planning
3.5.3.3
Research Infrastructure Guide
PEP Subcomponent 3.3 – Quality Acceptance Criteria
This subcomponent describes the processes for determining and documenting the
requirements and quality acceptance criteria and plans for the deliverables identified and
included in the WBS. It describes how the key parameters and high-level science
requirements summarized above in PEP Subcomponent – 3.2 Scope flow down to detailed
science requirements, engineering requirements, and Quality Acceptance Criteria and plans.
If all requirements or plans are not fully mature, it describes the process the project will
follow to progressively elaborating documentation and planning.
Typically, requirements are captured in tabular format. One example of this type of table is
shown below in Table 3.5.3.3-1; note, however, that the format of the table will depend
strongly on the characteristics of the project. For complex projects with many cross-linked
requirements, a database or multiple spreadsheets or tables with links to higher-level
requirements may be needed to illustrate requirements’ traceability. If the actual
requirements documents are too large to include in the PEP itself, then this subcomponent
should clearly describe the processes and linkages, and reference them as provided
supplementary requirements documents.
Document Number
124
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.3.3-1
Traceable Flow of KPP to Science, Engineering, and Quality Requirements in Complex Projects
Key Performance
Parameters
Key Parameter A
Key Parameter B
Key Parameter C
Detailed Science and
Engineering
Requirements
Documents
Quality Acceptance
Plans
• High-Level Science
Requirement A
• High-Level Science
Requirement B
• Detailed Science
Requirements
Document
• Associated technical
drawings, specifications,
analyses
• Quality Control (QC) and
Acceptance Plan for
Component
• QC and Acceptance
Plan for Subsystem
• High-Level Science
Requirement C
• High-Level Science
Requirement D
• High-Level Science
Requirement E
• System and Detailed
Engineering
Requirements for
Subcomponent
• Engineering
Requirements for
Subcomponent
• Associated technical
drawings, specifications,
analyses
• QC Plan for
Subcomponent
• Acceptance Plan for
Subsystem
• High-Level Science
Requirement D
• System and Detailed
Science Requirements
Document
• Associated technical
drawings, specifications,
analyses
• Testing Plan for
Component
Science Requirements
Documents
The quality acceptance criteria and requirements for all other lower-level scope listed in the
full WBS should be included as supplementary documents and referenced from within this
PEP subcomponent. Note: At the time of the award, not all Quality Acceptance Criteria
documents, especially for lower-level elements, need to be completed. However, a plan for
progressively elaborating, completing, and approving these requirements, including a
timeline for accomplishing plan elements, should be described.
Good Practices and Practical Considerations
•
Note that science requirements are related to the quality of the science, while
engineering requirements are related to the details of the particular solution or
approach to achieving the science goals.
•
A good practice is to follow the SMARTTT criteria in determining requirements and
acceptance plans: Specific (clear and unambiguous), Measurable (testable),
Achievable (possible within project constraints and parameters), Relevant (suitable
and germane to the project goals), Traceable (derived and flowed down from a higherlevel requirement, KPP, or project objective), Tiered (numbered in a hierarchical [flowdown] manner), and Total (complete and standalone). For example, it is not sufficient
to simply state that software will be robust.
•
The use of compliance matrices is encouraged to track adherence to the acceptance
criteria, identify areas that are pending, and highlight specific requirements that have
Document Number
125
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
not been met. A good practice is to create a compliance matrix for every requirement
document or set of specifications.
•
3.5.3.4
A formalized process requesting waivers for requirements that cannot be met is
encouraged during project execution. The plan for this process is described in PEP
Component 7–Project Control Plans. Depending on the magnitude of the scope
impacted, some proposed waivers may require NSF review and approval, according
to the established Change Control process.
PEP Subcomponent 3.4 – Integrated Master Schedule
This subcomponent describes the development of the baseline IMS, a management tool
used for planning and executing work during implementation and Construction Stage
projects. The IMS addresses both how and when the work is to be performed by identifying
the activities needed to accomplish the scope of work and by time-phasing these activities
with durations and schedule logic. Logical sequencing involves identifying the key
relationships between activities to determine the proper sequence necessary to accomplish
the work. The IMS is based on the WBS hierarchy and includes tasks and activities, project
start and end dates, review dates, and other critical dates and key milestones. This
subcomponent also includes a description of key assumptions, constraints, and other
important information used as the basis of the IMS. Refer to Section 4.4 Schedule
Development, Estimating, And Analysis for detailed guidance on the development of
construction schedules and plans, including the Schedule Basis Document and NSF
expectations associated with the GAO Scheduling Best Practices.
The following products are outputs of this subcomponent:
•
Schedule Basis Document. Provides parameters and underlying assumptions used
in developing the schedule for all project stakeholders’ understanding (see Section
4.4.3.2 Schedule Documentation).
•
Schedule Management Plan. A description of the policies, procedures, tools, and
roles and responsibilities for developing and estimating the project schedule (see
Section 4.4.3.2 Schedule Documentation).
•
Integrated Master Schedule. A series of tasks, summary tasks, and milestones
based on the WBS hierarchy. For the purposes of the RIG, tasks and activities can be
considered equivalent terms.
•
List of Reporting Milestones. A tiered table or list with the different levels of
milestones that will be used to monitor and report progress.
The basis, plan, and milestones can be included in this PEP section if they are not too long.
Otherwise, their key points can be summarized here with reference to either separate and
complete documents or one combined document.
The IMS should be based on the WBS hierarchy, with each specific deliverable identified in
the WBS accounted for in a series of tasks, summary tasks, and milestones. A complete IMS
is typically too large to be included in the PEP document itself and is usually included as a
Document Number
126
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
supplementary document to the PEP. A summary view of the baseline IMS should be
included in this PEP subcomponent, showing a high-level view of the project that
corresponds to the high-level WBS deliverables listed above in PEP Subcomponent – 3.2
Scope. The scheduling approach, tools, and documents should be tailored to project
complexity and characteristics. For very simple projects, the IMS may consist solely of a list
of key activity and milestone dates or blocking in a spreadsheet or diagram, that can be
updated as the project progresses to demonstrate task completion, and forecasts
timeframes for remaining work. For most projects, however, a Gantt-type schedule that is
created with commercial scheduling software is preferred. An example of a Gantt chart is
shown below in Table 3.5.3.4-1.
Table 3.5.3.4-1
Sample High Level Schedule Gantt Chart
Projects need to produce a list of tiered tracking milestones based on the scheduled
activities. At the highest level, this constitutes a short list of milestones that are reported to
NSF. The milestones should be spaced at a frequency that will readily communicate how well
the project is tracking the overall plan without being too inclusive of minor details. The
second tier is typically used by project management to track progress, while lower tiers are
used by CAMs, and work package leads track progress at lower WBS levels. Usually, only the
key reporting and/or tracking milestones need to be displayed in the PEP, with lower levels
referenced in separate supplementary documents. An example of a list of key milestones in
graphical format is shown below in Table 3.5.3.4-2 below.
Table 3.5.3.4-2
Sample Graphical Representation of Key Reporting Milestones
A high-level view or description of the project’s Critical Path should be included in this
subcomponent. Ideally, this is represented graphically in the summary schedule (or
milestone/task list for very simple projects) using color coding. Again, the full IMS with an
identifiable Critical Path is typically included as a supplementary document to this PEP and
updated throughout project execution. The Critical Path shown in the PEP should be a
simplified high-level view that corresponds to the high-level WBS elements described above
in PEP Subcomponent – 3.2 Scope.
Document Number
127
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Good Practices and Practical Considerations
•
The IMS should be logically driven, with all activities and milestones driven by
predecessors and successors. Specific deterministic dates (arbitrary start or stop
dates not driven by related activities) are not good practice and should be avoided to
the extent possible.
•
The baseline schedule should not include built-in buffers or other forms of hidden
schedule contingency, though allowances are allowed if adequately justified.
Approved schedule contingency is held and managed separately from the baseline
schedule, but it can be shown in the IMS as described in Section 4.7 Contingency
Estimating and Management.
•
The IMS should be resource loaded (labor and non-labor). For simple projects, this
may mean assigning budget and staff to key milestones, tasks, or WBS elements.
Projects using commercial scheduling software can use internal tools to add
resources to the IMS.
•
The number of Tier 1 tracking milestones per year will depend upon the project
characteristics, but a good rule of thumb is at least one but not more than six.
•
The TPD includes the baseline duration and schedule contingency, and the milestone
table should reflect the difference between those dates.
•
The project’s IMS should adhere to the GAO Scheduling Best Practices as described in
Section 4.4 Schedule Development, Estimating, And Analysis.
•
The complexity of a schedule typically drives the needed experience level of the
person(s) developing and maintaining the schedule and the selection of a scheduling
software tool.
•
The use of commercial schedule health evaluation tools, accompanied by
explanations of any deviations from standards for quality schedules, is
recommended.
•
Level-of-Effort (LOE) tasks should be minimized to optimize the tracking of spending
against budget and accomplishments against plan in the project's Performance
Measurement and Management reports (see Section 3.2.1.3 Level-of-Effort
Approach).
3.5.3.5
PEP Subcomponent 3.5 – Time-Phased Budget
The planned, time-phased budget necessary to execute the project is described in this
subcomponent. The budget should be developed and aligned with the WBS deliverables
described above in PEP Subcomponent – 3.2 Scope.
The following are the products of this subcomponent:
•
Cost Estimating Plan. A description of the methodology, tools, and processes for
developing and estimating the project budget, including key assumptions and
constraints. The CEP describes how the costs are developed, documented, reviewed,
approved, and managed, and may reference any organizational policies and
Document Number
128
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
procedures followed by the Project Team. Refer to Section 4.3 Cost Estimating and
Analysis for detailed guidance on creating a CEP. The CEP should describe the
expected cost-estimating methodology, maturity, and, if applicable, accuracy range
(e.g., expert opinion, analogy, parametric, engineering build-up, historical data). It
should also explain any ground rules, assumptions, and exclusions that apply broadly
to the estimate, allowances, and other sensitive or significant factors or
considerations, including their rationale and any references. The CEP should serve as
guidance for the project estimators as well as inform NSF and reviewers. Planners
should also discuss any methods used to validate the estimates, including
Independent Cost Estimates (ICE) and reviews. The CEP should be tailored to the
project’s characteristics and may evolve over time as planning matures. Note that the
CEP description within this PEP may only be high-level or an Executive Summary in
nature; reference to and inclusion of a supplementary detailed cost estimating
document is usual.
•
Cost Book and Basis of Estimate. The collection of cost estimate worksheets is
supported by detailed information on the basis of how each estimate was
established. The Cost Book is a comprehensive and well-documented compilation of
budget-related data for the total project scope that organizes and calculates project
management information. The BOE provides supporting documentation outlining the
details used in establishing project estimates, such as assumptions, constraints, and
estimating methods, and referencing the technical information used. Consult Section
4.3 Cost Estimating and Analysis for detailed guidelines and requirements for creating
a Cost Book and BOE. The Cost Book and BOE should be capable of being sorted and
filtered to provide the cost estimate in multiple formats and reports in formats
compatible with necessary reviews and analyses. The estimate structure should have
clear traceability between WBS elements and the BOE correctly roll up to higher WBS
levels and demonstrate compliance with the CEP. Because cost analyses assess the
application of fringe, indirect, and escalation rates (among other things), there should
be clear traceability in the application of all rates (e.g., with lookup tables and
formulas). The budget should map into budget categories, including project-defined
categories and, for financial assistance awards, NSF Budget Categories (as defined in
the standard NSF Budget Form per Sections 1.3.1.1 Financial Assistance Awards –
Grants and Cooperative Agreements and 5.6 NSF Budget Categories from the
Proposal and Award Management Guide). The Cost Book and BOE should be
progressively elaborated as project planning matures. For example, early estimates
may be based on top-down comparisons to analogous projects, while mature
estimates should be based on bottom-up estimates based on vendor quotes and
other substantive sources.
•
Time-Phased Budget. A map of the budget over time as a result of matching the
budget estimates to the scheduled activities. Once the baseline budget has been
established, it needs to be mapped to the schedule activities to create a time-phased
budget that is the basis of the funding profile request and forms the target for cost
Document Number
129
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
performance management as the project is executed. Mapping depends upon the
scheduling tools and should be scaled to the project's needs. For example, a simple
project may maintain a list of tasks or milestones as the schedule, in which case the
budget would be mapped directly to each task or milestone. Most projects use
commercial software that allows resource loading into the application, along with
various codes and notes for sorting and filtering. Projects can scale the granularity of
the mapping by controlling the level to which the budget is assigned: simple projects
may map to WBS Level 2, while more complex projects may map at lower WBS levels
or even at activity levels. A time-phased budget example is shown in Table 3.5.3.5-1.
Table 3.5.3.5-1
High Level Time-Phased Budget Report with NSF Budget Category Mapping Sample Table by Fiscal Year (FY)
Cost Category
FY1
FY2
FY3
FY4
Total
A, B, C –
Personnel
$1,403,000
$5,598,400
$7,610,400
$5,229,700
$19,841,500
D – Equipment
$25,300
$4,296,000
$4,337,500
$2,777,700
$11,436,500
E – Travel
$3,500
$13,500
$13,500
$7,000
$37,500
G.1 M&S
$1,200
$132,500
$130,200
$110,600
$374,500
G.5 Subawards
$280,600
$1,120,000
$1,522,000
$1,046,000
$3,968,600
H – Indirect Costs $155,300
$2,781,000
$3,001,600
$1,970,700
$7,908,600
Total PMB
$ 1,868,900
$13,941,400
$16,615,200
$11,141,700
$43,567,200
G.6 –
Contingency
$262,000
$5,140,000
$6,950,000
$1,020,000
$13,372,000
Contingency %
14.0%
36.9%
41.8%
9.2%
30.7%
Total Project
Cost
$2,130,900
$19,081,400
$23,565,200
$12,161,700
$56,939,200
Good Practices and Practical Considerations
•
The project budget should adhere to NSF and GAO Cost Estimating Best Practices as
described in Section 4.3 Cost Estimating and Analysis.
•
All cost and budget estimates must utilize then-year United States dollars (USD) to
include reasonable estimates of inflation, annual staff salary increases, and other
escalation effects.
•
Although justified allowances are permitted in the BOE (see Section 4.3.3.4
Uncertainty, Accuracy, and Allowances), the Performance Measurement Baseline
budget should not include references to reserves or contingency. Only one method
should be used to handle cost uncertainty. Employing both an allowance and an
identified risk would result in double-counting and unnecessarily increase the
proposed budget. Per NSF policy, budget contingency is held separately to manage
known risks in aggregate and its use is addressed below in PEP Subcomponent – 4.3
Contingency Management Plan.
•
Control Accounts and the assignment of CAM for managing the budget should be
Document Number
130
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
considered both at the creation of the WBS and at resource loading of the schedule.
Accounts may need to be readjusted based on the total dollar amount once the
budget is established.
•
During cost reviews, the application of negotiated fringe benefits, indirect cost rates,
or algorithmic methods (e.g., 3% salary escalation) is frequently assessed. Clear
demonstration and consistent application of such formulas and factors will greatly
facilitate and accelerate the cost analysis.
•
Note that Control Accounts should be assigned to a single WBS element; that is to
say, a WBS can contain multiple Control Accounts, but a control account should be
tied to a single WBS element.
3.5.4
PEP Component 4 – Risk and Contingency Management
What Does This Component Describe?
This component describes the project risk management and the related Contingency
Management Plans. Risk management includes a high-level overview of the risk
management approach in the project Risk Management Plan, a list of identified risks (Risk
Register), and an estimate of the overall project risk exposure. An important aspect of any
risk management approach includes the establishment and management of adequate
contingencies that can be used to control project risks. Contingency management includes
the estimation of those contingency amounts, supported by the project risk exposure
estimates. These contingencies are part of the Total Project Definition that encompasses the
Total Project Cost (TPC) and Total Project Duration (TPD). The Contingency Management Plan
details how contingencies will be controlled and used to offset project risk and successfully
complete the project within the TPC and TPD.
Why Is This Component Important?
A project’s risk management approach identifies and analyzes potential risks, both threats
and opportunities, that could impact the project’s objectives. Identification then allows the
project to take steps to minimize the probability and impact of threats, maximize the benefits
from opportunities, and plan responses if those threats and opportunities are realized. An
essential part of any risk management approach is the estimation of the overall project risk
exposure, and the establishment of contingency amounts needed to support risk responses.
Effective risk management can reduce project delays, avoid cost overruns, and help ensure
the technical and scientific objectives of the project are met. Risk management also can lead
to better decision-making and improved stakeholder confidence during the project.
Performing systematic and effective risk and contingency management will greatly increase
the likelihood of project success.
How To Develop and Write This Component
There are three subcomponents in PEP Component 4 – Risk and Contingency Management,
as listed in Table 3.5.4-1 below:
Document Number
131
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
•
An overview of the risk management approach.
•
Risk Management Plan, Risk Register, and an estimate methodology for total project
risk exposure and the results.
•
Contingency Management Plan that lays out the methodology to calculate and control
contingency amounts.
Note that detailed guidance on creating both Risk Management and Contingency
Management Plans, listed in the references in the table, should be followed when creating
the plans.
The subcomponent plans and deliverables should be organized to align with the project’s
specific characteristics and agreed upon by both the Project Team and the funders. The plans
should be tailored and scaled to the type, size, complexity, and characteristics of the project.
Further, the plan should be developed in a progressively elaborated approach, as described
in Section 3.2 Tailoring, Scaling, and Progressively Elaborating Plans.
Table 3.5.4-1
Risk and Contingency Management Subcomponents, Products, and Documents with References to Further Material
and Related Topics
Component
Subcomponent
Documents/Products
References
4.1 Risk Management
Approach
4. Risk and Contingency
Management
• Risk Management Plan
• Risk Register
4.2 Risk Management Plan
• Estimate of Overall Risk
Exposure
4.3 Contingency
Management Plan
3.5.4.1
Section 4.6 Risk
Management
• Estimates of Cost,
Schedule, and Scope
Section 4.7 Contingency
Contingency Amounts
Estimating and
• Contingency Management Management
Plan
PEP Subcomponent 4.1 – Risk Management Approach
This subcomponent provides a high-level overview of the project plans and approach for the
management of risk. This subcomponent includes a description of the philosophy,
commitment, and approach to risk management on the project, including any specific
standards or institutional policies and procedures that will be followed. The subcomponent
also describes how contingencies will be estimated and used to manage risk. The general
risk tolerance of the Project Organization is also included in this subcomponent.
Good Practices and Practical Considerations
•
If the plans and products expected in this component are not fully mature (e.g., still
undergoing development before implementation), then explain the steps that will be
taken to reach maturity (progressive elaboration).
•
Every project is unique, so the plans, approaches, methods, and risk tolerances will
vary from project to project. That said, the standard seven-step risk management
Document Number
132
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
process described in Section 4.6 Risk Management should serve as the starting point
for planning risk management on most projects. If an alternative scheme or method
is used, a justification for that approach should be included in this subcomponent.
•
3.5.4.2
Contingency estimation and management guidelines can be found in Section 4.7
Contingency Estimating and Management.
PEP Subcomponent 4.2 – Risk Management Plan
This subcomponent includes the Risk Management Plan that should be used to identify and
manage risks. The Risk Management Plan should identify the responsibilities for risk
management and describe the risk management process that will be followed, including
roles and responsibilities, procedures, criteria, tools, and techniques to be used to identify,
analyze, respond to, and track project risks. The level of detail in the plan, and the scope,
timing, and level of risk analysis should be commensurate with the maturity and complexity
of the project and may evolve and change over time. A Risk Management Plan includes the
processes that will be used during project execution to identify, manage, mitigate, and
control risk.
In particular, the Risk Management Plan should describe the risk identification tool used to
capture and document individual risks in a Risk Register. A view of the current Risk Register
of the project should be shown, including all identified project risks with detailed descriptions
and their quantified probabilities and impacts. The Risk Register should also include
response strategies if risks are realized and should identify triggers for each risk. If the Risk
Register is too large to include in the PEP document itself, provide a sample and attach the
full Risk Register as a supplemental document. The Risk Management Plan should also
describe the methodology used to estimate the aggregated total project risk exposure from
threats. The current value of total project risk exposure in terms of cost and schedule should
be supplied. The major risks that contribute most to risk exposure may also be identified.
Detailed guidelines and information on creating Risk Management Plans, Risk Registers, and
overall risk exposure estimates are covered in Section 4.6 Risk Management.
Good Practices and Practical Considerations
•
Risk management should be started early in project development and, like budgets
and schedules, be progressively elaborated to maturity before project execution. As
an example, the creation of an early list of risks in a rudimentary Risk Register will
support planning and allow projects to adjust plans to reduce or eliminate them by
including mitigation plans in the baseline.
•
Risk management includes managing both threats and opportunities. Project Teams
should include and monitor opportunities in their Risk Registers to enable timely
actions to capitalize on and maximize the favorable outcomes opportunities can
provide. (Note that most estimates of total risk exposure, however, do not include
opportunities in the Basis of Estimate [BOE]).
•
On simple projects, the entire Risk Management Plan may be described within this
subcomponent. On larger projects, a summary and reference to an external detailed
Document Number
133
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Risk Management Plan document should be provided.
•
3.5.4.3
Methods for calculating total risk exposure may be tailored and scaled to the project
characteristics. Simple, less risky projects may be able to use algorithmic methods
that require less expertise and administrative overhead to be adequate for project
needs. Note, however, that risk management requirements for Major Facility
Construction projects require the use of Monte Carlo simulation to estimate the
aggregated total project exposure. Additional details on tailoring Risk Management
Plans are included in Section 4.6 Risk Management.
PEP Subcomponent 4.3 – Contingency Management Plan
This PEP subcomponent should describe the estimation and management of project
contingency, which typically comprises three distinct types: budget contingency, schedule
contingency, and scope/quality contingency. Contingency serves as a critical resource for
managing the impacts of risks and uncertainties on project objectives. At least one type of
contingency—and often all three—must sufficiently address relevant project risk. The
Contingency Management Plan details how contingency is controlled, maintained, and
reported, including usage and status updates (see Section 4.7 Contingency Estimating and
Management for comprehensive guidance on requirements and considerations). The
following additional points for each type of contingency should be addressed.
Contingency Estimation. The Contingency Management Plan should describe the
methodologies for estimating the three types of contingencies and state the estimated
amount for each one. An explanation of the BOE and justification of why the calculated
contingency is sufficient should be included. The estimation methods should be tailored and
scaled to match project complexity and other characteristics. Guidelines on contingency
estimating methods can be found in Section 4.7 Contingency Estimating and Management.
Budget Contingency. Budget contingency is an amount of money which, when added to the
baseline budget and any fee, sums up the TPC or award amount. Budget contingency is held
separately from the baseline budget and is used to cover the monetary cost of realized risk,
including cost impacts of schedule delays. Budget contingency should be estimated using a
method that is appropriate for the type, size, and complexity of the project. Budget
contingency can be estimated in a number of ways, depending on the nature of the project,
its size and complexity, and the state of the project. Typical methods include simple
percentage-based methods, summation of identified risk exposure (as captured in the
project’s Risk Register), risk-factored technical/cost/schedule methods, and Monte Carlo or
other probabilistic methods performed on the Risk Register, the budget, and/or the
schedule. Monte Carlo methods must be applied to combined cost and schedule analyses
for Major Facility projects and should assume a confidence level between 70-90% for budget
contingency.
Schedule Contingency. Schedule contingency is an amount of additional time beyond that
of the deterministic (baseline) Integrated Master Schedule (IMS) project end date to obtain
the risk adjusted project end date. Budget contingency is held separately from the baseline
Document Number
134
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
budget and is used to cover the schedule impacts of schedule overruns from realized risks.
Schedule contingency should be estimated using a method that is appropriate for the type,
size, and complexity of the project. Typical methods include expert judgment, comparison to
other/similarly scoped projects that have been completed in the past, and statistical and/or
probabilistic methods. For Major Facility projects, the amount of schedule contingency is
determined by performing probabilistic risk analysis on the baseline IMS and selecting a
commitment finish end date with a confidence level between 70-90%. Note that there may
be costs associated with estimated schedule contingency. Risk managers should ensure that
any such costs (e.g., labor during the extended project duration) are captured in the
estimated budget contingency estimate.
Scope/Quality Contingency. Scope/quality contingency is comprised of elements within the
Work Breakdown Structure (WBS) and/or Quality Acceptance Criteria that can be removed
or reduced without affecting the overall project’s objectives but that may still have an
undesirable effect on the RI’s performance or functionality. They are usually regarded as last
resort actions when options that employ budget and schedule contingency while preserving
project objectives cannot be used. Scope/quality contingency amounts for each reduction in
scope or quality are based on the cost and schedule savings realized by the reduction in the
baseline. The total amount of cost and schedule savings equals the sum of the individual
scope contingency amounts. The total amount of contingency is time sensitive: it declines
over time as opportunities pass their use-by dates without being exercised. Scope options
are typically captured in a Scope Management Plan (see Section 3.5.3.2 PEP Subcomponent
– 3.2 Scope), which may also include scope opportunities that can be exercised when budget
and schedule allow. The project’s Scope Management Plan should list all identified
scope/quality contingency options, along with the estimated monetary value of each option,
time-phased use-by dates, special requirements, and a description of the impact on science,
performance, and/or functionality, operational costs, or sustainability of the RI. The process
for defining when exploiting scope opportunities are allowable should also be defined in the
Scope Management Plan. For Major Facility construction projects, identified scope/quality
budget contingency should have a total value of at least 10% of the project’s baseline budget
until construction commences.
Good Practices and Practical Considerations
•
To provide additional assurance of successful project outcomes, the scope
contingency options must equal at least 10% of the Performance Measurement
Baseline (PMB) at the start of the project. Major Facility projects have more specific
guidelines (see Section 4.7 Contingency Estimating and Management).
•
Scope contingency options should spread through as much of the project
performance period as possible to avoid loss of flexibility too early in the project.
•
Exercising scope contingency will often require NSF approval, so proposers should
communicate and discuss the Change Request well before planned implementation
dates.
Document Number
135
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Contingency Management Plan: Contingency Use Profile. In practice, all projects employ
some sort of contingency, whether it is related to scope/quality, schedule, budget, or
combinations thereof. The Project Team may create and maintain a potential contingency
allocation profile that is reported in the funding profile provided in PEP Subcomponent – 3.5
Time-Phased Budget. Contingency allocation profiles should normally track an estimated
time-phased risk exposure profile and usually do not track the commitment or spending
profiles. For many projects, the highest use of both schedule and budget contingency occurs
during procurement or contract award, and during the final commissioning/integration
phases. A contingency allocation curve for such a project would be bimodal, with one peak
for procurements activities and another for significant contingency amounts held back until
the end of the project, even though the spending curve may be low near the end of the
project. Although risk does reduce over time, there may be significant reworking of
hardware, for example, needed as a result of knowledge gained during integration and
commissioning activities.
Contingency Use and Change Control. The Contingency Management Plan describes how
the Project Team uses the Change Control Plan, (see Section 3.5.7.4 PEP Subcomponent 7.3
– Change Control Plans) to assign contingency to specific WBS elements when risks
materialize and how contingency is reallocated from WBS elements and returned to the
contingency category when underruns occur. The NSF Program Officer (PO) needs to concur
on all Change Requests exceeding negotiated thresholds for allocation of scope, schedule,
or budget contingency, in accordance with the award terms and conditions. Contingency
may only be used to support in-scope work for the approved project baseline or preapproved scope opportunities in the Scope Management Plan (see Section 4.7 Contingency
Estimating and Management).
All Change Control actions that affect the use of contingency – cost, schedule, or technical
performance and scope – should link to an identified and documented risk and indicate the
affected WBS elements. The Project Team should keep a log of all change actions such that
contingency actions, including puts and takes, can be reported, and summarized.
Adjustments to contingency should include taking advantage of opportunities to assign
savings and underruns to contingency. Savings (projected cost under runs) should be left in
associated WBS elements, shifted to other WBS elements, or moved to budget contingency
in accordance with the terms and conditions of the award. However, all such changes must
be made in accordance with the thresholds within the Change Control Plan. Budget made
available through the implementation of planned de-scoping options should also be placed
directly into contingency before being reallocated through Change Control actions.
Liens List: Forecasting and Opportunity Management. The Project Team should maintain
a Liens List of likely future adjustments to contingency as a forecasting tool that tracks
actions that have not yet been incorporated into the Budget at Completion or Estimate at
Completion (EAC). The list may document items such as very high probability risks with
trigger points for action, deferred scope held as contingency until a decision date, realized
risks needing draws on contingency that require more definition for a Change Control action
to be implemented, budget and schedule variances that will not/cannot be mitigated, and
Document Number
136
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
anticipated opportunities for returns to contingency. The Liens List acts as an escrow or
staging account for planned or near-certain contingency allocations.
The list should include a description of the identified risk and the anticipated action, with
estimates of budget and schedule impacts and anticipated decision date for any Change
Control Board action. The affected WBS elements should be identified at the second level (or
the first meaningfully specific level of scope description), where known.
Maintaining Adequate Contingency Levels. The Contingency Management Plan should
describe the process for ensuring that the remaining amounts of budget and schedule
contingency are adequate to cover the Risk-Adjusted Estimate at Completion (RAEAC) by
periodically updating the EAC and the analysis of overall project risk exposure. As time goes
by, risk exposure changes with risk mitigation, new knowledge, and new circumstances. The
amount of remaining budget contingency fluctuates over time with assignments to risk
mitigation and return of any savings. The Project Team should strive to ensure the remaining
available contingency always equates to at least the difference between the TPC minus the
EAC and any liens. If the remaining contingency is judged to be inadequate for project needs,
steps should be taken to restore amounts to adequate levels (e.g., exercising de-scope
options or returning underruns to contingency, or rebaselining the project).
Contingency Status Reporting. The Contingency Management Plan should describe the
requirements for reporting contingency status, issues, and adjustments through the Change
Control Plan in its interim reports (typically monthly reports). NSF generally sets reporting
requirements for interim status. These typically include completed and anticipated Change
Control actions involving the movement of contingency, obligated and authorized
contingency balance, and a comparison of contingency amounts to the need indicated by
the RAEAC.
Good Practices and Practical Considerations
•
It is good practice to re-estimate EAC and risk exposure routinely, unless stated
otherwise in the award terms and conditions. Specific dates may also be appropriate
times for re-evaluation, such as at major milestones dates. The Project Manager (PM)
should periodically assess the current risk status to identify and address any new risks
that arise as the project progresses.
•
Contingency is meant to be used when known risks become realized. Rather than
preserving or protecting contingency funds for use late in the project, projects can
appropriately use budget and schedule contingency to correct variances as long as
their use is clearly documented in accordance with the PEP and the terms and
conditions of the award. Contingency may be used to cover negative cost variances,
as long as those variances are tied to an identified risk(s) that are in turn associated
with the WBS elements related to those variances.
•
If available budget contingency drops significantly below the remaining risk exposure
such that confidence in on-budget completion is below 50%, the Project Team should
take steps to restore contingency (e.g., this is typically done by exercising approved
Document Number
137
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
de-scope options listed in the Scope Management Plan. Moving budget to
contingency due to other cost savings in the performance baseline should be done in
accordance with the award terms and conditions
•
Project Teams may opt not to request budget and schedule contingency but should
always consider the use of scope/quality contingency plans (e.g., de-scope options).
•
Scope quality/contingency can be used to address the remaining uncertainty between
the cost and schedule estimates and the chosen calculated confidence levels of a risk
analysis.
•
De-scope options, when exercised, can be moved into up-scope (opportunity) options
to be brought back into the baseline if resources are available later in the project.
3.5.5
PEP Component 5 – Acquisition Plans
What Does This Component Describe?
This component describes the planned processes, strategies, and methods that will be used
on the project to acquire (i.e., create and provide) and implement the scope, as defined in
PEP Component 3 – Performance Measurement Baseline. Additionally, it refers to plans for
acceptance testing of the scope against the Quality Acceptance Criteria that are also specified
in PEP Component 3 – Performance Measurement Baseline. Finally, it includes plans for
determining, sourcing, and managing all the labor and non-labor resources required for
acquiring and testing the scope.
Why Is This Component Important?
Pre-defining the expectations and approaches to creating the scope, testing it, and resolving
non-compliance issues is necessary to understand the resources needed to carry out these
plans and approaches, which is necessary for complete and thorough planning. Without a
priori and complete consideration of acquisitions, accurate schedule development and cost
estimation are impossible to achieve. A well-considered Acquisitions Plan also provides for
the anticipation of potential challenges and bottlenecks, allowing for a complete review and
assessment of risk. Finally, a complete and accurate Acquisitions Plan improves
communication, minimizes misunderstandings (both with external stakeholders and Project
Team members), and fosters a shared understanding of resource needs and procurement
plans.
How To Develop and Write This Component
There are four subcomponents to be included in Component 5 – Acquisition Plans, as listed
in Table 3.5.5-1 below.
The Scope Acquisition Plan should match the project characteristics and needs and should
be agreed upon by both the Project Team and the funders. The plans should be tailored and
scaled to the individual type, size, complexity, and characteristics of the project. Further, the
subcomponents are typically developed in a progressively elaborated approach, as
described in Section 3.2 Tailoring, Scaling, and Progressively Elaborating Plans.
Document Number
138
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.5-1
Acquisition Plans Subcomponents, Products, and Documents with References to Further Material and Related Topics
Component
Subcomponent
Documents/Products
References
5.1 Overview of
Acquisition Plans
5. Acquisition Plans
3.5.5.1
5.2 Scope Acquisition
Plans
• Scope Acquisition Plan
5.3 Systems Engineering
and Quality Management
Plans
• Systems Engineering
Plan
• Quality Management
Plan
5.4 Resource
Management Plans
• Resource Management
Plan
PEP Subcomponent 5.1 – Overview of Acquisition Plans
This subcomponent provides a brief, high-level description of the approach for acquiring the
scope and ensuring it meets its Quality Acceptance Criteria. Acquisition Plans may include
the approaches to any or all the following activities: development, design, analysis, site
selection and permitting, prototyping, procurement, purchasing, construction, coding,
assembly, integration, testing, commissioning, verification, and/or validation of the scope as
defined in the Work Breakdown Structure (WBS). The Project Team should decide whether
to build in-house, pursue subawards, subcontracts, or purchase commercially available
components or services. The Acquisition Plan should also describe the high-level resource
requirements (labor and non-labor) necessary to carry out the overall project plan and
create, provide, and deliver the scope. Specific details of these topics are described in more
detail below in the relevant subcomponents.
Good Practices and Practical Considerations
•
3.5.5.2
When possible, sourcing from commercially available products or offerings can
reduce project risk and increase confidence in cost and schedule projections.
PEP Subcomponent 5.2 – Scope Acquisition Plans
This subcomponent describes the plans for acquiring all the project scope. Elements to
highlight in these plans should include the following.
Acquisition Approaches. All significant acquisitions should be listed, along with
procurement approaches, subawards, and contracting strategies (e.g., vendor selection and
management plans). This should be time-based and include explicit milestones for creation
and provision of the scope. Also include the planned approval process for all significant
acquisitions (e.g., those that require NSF review), with a year-by-year plan of approvals. The
more detailed related documents (e.g., Request for Proposals, draft Contracts) may be
referenced here.
Production-level Development and Design Work. All development and production-level
design activities necessary for construction, acquisition, or implementation, including a time-
Document Number
139
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
phased plan for performing this work (i.e., schedule), may be included as part of the project
scope. This may include specific pre-design, engineering and design work, prototyping,
manufacturing validation, vendor qualification, modeling and simulation, creation of
specialized acquisition plans, and the like, that are necessary for project success. Also,
provide any estimated budget required to perform the development and design work,
including specific NSF funding and any contributions from partners or outside sources.
High-Risk Acquisitions. Identify all high-risk acquisitions, including new or evolving
technologies, single-source vendor situations, unique procurement concerns, such as long
lead procurement items, and so forth. Describe the management approach to minimize risk
of these and identify elements in the project Risk Register that are related to these
acquisitions.
Site and Environment. Identify all required and/or special site selection criteria, provide a
description of the selected site(s) for the Research Infrastructure (RI), and provide a plan to
manage the associated site-related work. Provide a detailed list of all required site
permitting, Environmental Impact Statements, site assessments, and any others that are
required. The cost and time frame for performing the site selection and permitting activities
should be described (and captured in the project budget and Integrated Master Schedule
[IMS]).
Good Practices and Practical Considerations
•
Within the Acquisition Plan, a defined list of major procurements (purchased items or
services) with expenses and projected timelines can be included to facilitate award
oversight and review. The list should include details of the procurement (e.g., sole
source, fixed price, competitive bids).
•
Every deliverable element included in the WBS should have a clear and unambiguous
acquisitions approach identified and described herein this subcomponent. Often, the
Acquisition Plans for so-called child elements in the WBS are contained at a higher
parent level. Make note of these situations to ensure clarity of the plans.
3.5.5.3
PEP Subcomponent 5.3 – Systems Engineering and Quality Management
Plans
This subcomponent describes the management plans and processes that will be used to
ensure that all acquired scope will meet all specified Quality Acceptance Criteria. Systems
engineering is a fundamental key to successful Acquisition Plans. The Systems Engineering
Plan comprises a unique set of systems and subsystems with associated technical
requirements and interfaces, both internal and external to the facility. Technical
requirements and interface control documentation created during project planning and
design assist in defining the inspection and test regimes necessary for commissioning and
acceptance of the facility. Quality Management includes both Quality Assurance (QA)
processes related to preventing quality issues and Quality Control (QC) processes related to
products and deliverables assessment, testing, or evaluation plans and processes for
reviewing and addressing non-compliant scope should be described herein.
Document Number
140
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
This subcomponent should, where relevant, describe the project’s Systems Engineering
Management Plan, including roles and responsibilities and how requirements are to be
developed, flowed down, tracked, and managed from high-level mission and science
requirements through lower-level requirements. Examples of how requirements might flow
from the mission statement to detailed engineering specifications are given in Figure
3.5.5.3-1. Additionally, this plan should describe how all internal WBS, and external interfaces
are to be specified, documented (e.g., in Interface Control Documents), communicated,
tracked, and managed.
Figure 3.5.5.3-1
Flow Down from Mission Statement to Individual Systems and Components
The Quality Management Plan should describe a clear, straightforward, achievable, and
robust plan for the System Integration, Test, and Commissioning activities that are an
essential aspect of complex RI projects. Successful completion of all inspections and tests
provides validation that the facility meets the science flow down and technical requirements
and therefore passes all acceptance criteria. Failure to plan or perform them well can lead
to project cost and schedule overruns.
Relevant plans for the Integration, Test, and Commissioning of the RI should be described,
including the following.
System Integration. How the various sub-elements and lower-level WBS items will be
brought together and tested as a collective whole. Included in this is the identification of all
physical and performance interfaces within and external to the RI deliverable components,
including how they will be identified, combined, verified, and coordinated.
Testing. How compliance and fitness for the purpose of the deliverable will be assessed (i.e.,
Document Number
141
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
verification testing) and documented (e.g., via compliance matrices) using the criteria
established and documented (above in PEP Subcomponent 3.1 – Performance Measurement
Baseline and Total Project Definition) to measure acceptable performance. Also, how noncompliance will be addressed and managed (e.g., via request for waivers).
Commissioning. How the capability of the RI to function and perform will be verified and
validated, including how the various system components will be brought online sequentially
and in simultaneous operations to study and affirm the interaction among subsystems.
Conditions for Acceptance. Specifying the expected condition of the facility, its
performance attributes, the tests the Awardee will perform, and the data it will consider prior
to accepting the facility or components of the facility and declaring it ready for operations
and maintenance. In some cases, a phased approach to acceptance will be required.
Good Practices and Practical Considerations
•
In some communities, the Integration, Test, and Commissioning activities are referred
to as Assembly, Integration, and Verification/Validation.
•
The ultimate goal of Quality Management is to ensure the RI is capable of
performing/delivering the high-level science that is described above in PEP
Component – 1 Project Overview, and that it is ready for handover to operations at
the appropriate time. All activities and plans, from low-level scope production
through high-level Integration, Test, and Commissioning activities, should be focused
on achieving this goal.
•
The Quality Management subcomponent should describe the plans for specifying the
expected condition of the RI at the project conclusion, its verified performance
attributes, all tests that will be performed, and the data that will be provided prior to
acceptance and declaring it ready for the next life cycle stage (e.g., Operations). In
some cases, a phased approach to acceptance may be required. For example, for
distributed-but-integrated facilities or for facilities with complex instrumentation and
equipment, it may be necessary to demonstrate performance and perform
acceptance procedures for parts of the system prior to proceeding with construction
and/or acquisition of other systems.
•
On longer, more complex projects, it is common for some Quality Management Plans
to change, evolve, or adapt as the project progresses. Further, some Integration,
Testing, and Commissioning activities may overlap with the start of the next life cycle
stage, such as the Operations Stage. How these adaptations and overlaps are to be
managed should be described in this subcomponent. Typical questions that may be
applicable to address include:
o
Will the project have parallel periods of construction/acquisition and
operations, with some components coming online earlier than others?
o
What is the Project Team’s strategy for facility acceptance, operational
readiness review, site safety and security, and training of operational staff and
members of the research community utilizing the facility?
Document Number
142
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
o
What are the project plans for transitioning staff from construction to
operational support activities? Is there a plan to bring in personnel with the
requisite technical skills to operate and support the facility at appropriate
times? Have training needs been addressed?
o
What risks to the project might result from contractor interference during
periods of beneficial use or occupancy as construction activities conclude?
o
What risks to the project might result from operations delays?
o
What contracting strategies are employed to ensure that priority tasks are
completed in a timely way and do not delay operational readiness?
o
What are project plans for obtaining use and occupancy permits or satisfying
other local regulatory criteria?
o
Do the budgets reflect a proper allocation between construction/acquisition
and operations?
Separate awards are generally required for operations activities because NSF Major
Research Equipment and Facilities Construction (MREFC) funding does not support such
costs. Where operational funding will be used for phased transitions to operations prior to
project closeout, the Project Team should ensure that the budget justification clearly
describes the changeover and that the earlier changeover is estimated and budgeted
accordingly, per the Segregation of Funding Plan in PEP Subcomponent 7.5 – Business and
Financial Control Plans.
•
3.5.5.4
Projects should carefully consider issues of warranty, repair, and segregation of
funding, especially when phased transition to operations results in operations activity
overlapping with the implementation and Construction Stage of a project.
PEP Subcomponent 5.4 – Resource Management Plans
This subcomponent describes the Resource Management Plans necessary to successfully
carry out both the Acquisitions Plans and the Quality Management Plans.
Staffing Plan. The project’s Staffing Plan should include time-phased plans and expectations
for project-specific job categories and correlation to scope deliverables. The requisite
expertise and qualifications of key staff should be included. Hiring and Transition Plans
should be included that clearly describe the schedule and requirements for hiring, training,
onboarding, managing staff resources, retaining, and ultimately transitioning resources off
the Project Team of all project staff.
Non-Labor Resource Plan. A Non-Labor Resource Plan identifies essential materials, tools,
workspaces, equipment, software, and other non-labor resources required for the project.
This plan is integral to executing the Scope Acquisition and Quality Management processes.
The Non-Labor Resource Plan outlines the necessary resources, while the Scope Acquisition
Plan and Quality Management Plan manage and ensure the effective utilization of those
resources
Document Number
143
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Good Practices and Practical Considerations
•
Full Resource Management Plans for small, simple projects may be correspondingly
simplified, e.g., the details of hiring and transition plans may be omitted if all staff are
already employed by the Awardee organization.
•
There are often risks associated with resource acquisitions (e.g., hiring for specialist
roles with exacting technical or professional qualifications may require long lead
times in the hiring process); these risks should be identified within the project’s Risk
Register as appropriate and included in the project schedule.
•
Staff retention, especially towards the end of a project, can be difficult. Awardees
should consider and plan for appropriate incentives to improve retention.
•
Resource loading planning for the temporary transition of staff onto and off the
Project Team can help to avoid any costs incurred (e.g., project management or
engineering, non-labor resources) but can create challenges in retaining staff unless
alternate assignments are available for those resources.
3.5.6
PEP Component 6 – Environmental, Safety, and Health Management
What Does This Component Describe?
PEP Component 6 – Environmental, Safety, and Health (ES&H) Management outlines the
strategies, plans, procedures, protocols, and responsibilities for managing environmental,
safety, and health risk aspects throughout the project's life cycle. It typically includes an
assessment of potential environmental impacts, strategies for mitigating these impacts, and
compliance with relevant environmental regulations. It outlines safety procedures, hazard
assessments, and measures to ensure the physical safety of personnel and equipment
during the execution of the project. The health subcomponent describes measures for
promoting the physical and mental well-being of individuals involved in the Project Team,
such as access to medical resources, acceptable ergonomics, and mental health support
during project execution. The ES&H section also includes reporting mechanisms, emergency
response plans, and ongoing monitoring to ensure that the Project Team operates in a
manner that is environmentally responsible, safe, and supportive of the health of all parties
involved.
Why Is This Component Important?
Incorporating ES&H considerations into project planning is of paramount importance. It
helps ensure the safety, protection of human life and well-being by systematically identifying
and mitigating potential safety hazards and health risks. The ES&H Plan safeguards the
Project Team and demonstrates an organization's commitment to its employees and
funders. Integrating environmental aspects into project planning helps mitigate negative
impacts on the environment, fostering sustainability and compliance with environmental
regulations, helping to prevent costly fines, legal issues, and damage to the Project Team’s
reputation. Addressing ES&H concerns from the outset of a project leads to better cost
management by reducing the likelihood of accidents, rework, and delays, ultimately
Document Number
144
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
enhancing project efficiency and its probability of success. It also promotes a culture of
responsibility, sustainability, and ethical practice. The inclusion of ES&H considerations in
the PEP is not just a legal or moral imperative; it's a strategic move that contributes to project
success, risk reduction, and the long-term well-being of both people and the environment.
How To Develop and Write This Component
There are four subcomponents to be included in this component, as listed in Table 3.5.6-1
below.
The ES&H Plans should match the project characteristics and should be agreed upon by both
the Project Team and funders. The plans should be tailored and scaled to the individual type,
size, complexity, and characteristics of the project. Further, the subcomponents should be
developed in a progressively elaborated approach, as described in Section 3.2 Tailoring,
Scaling, and Progressively Elaborating Plans.
Document Number
145
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.6-1
Environmental, Safety, and Health Management Subcomponents, Products, and Documents with References to Further
Material and Related Topics
Component
Subcomponent
Documents/Products
References
6.1 Overview of
Environmental, Safety, and
Health Management
6. Environmental, Safety,
and Health Management
3.5.6.1
6.2 Environmental
Protection Management
Plans
• Environmental Protection
Management Plans
Section 5.4 Environmental
Compliance
6.3 Safety Management
Plans
• Safety Management
Plans
Occupational Safety and
Health Administration
(OSHA) Recommended
6.4 Occupational Health
Management Plans
• Occupational Health
Management Plans
Practices 1
PEP Subcomponent 6.1 – Overview of Environmental, Safety, and H ealth
Management
This subcomponent provides a high-level description of the overall project approach to the
management of ES&H. It describes over-arching policies and objectives, including a
statement of the Project Team’s commitment to ES&H. A description of the ES&H
management structure is described, including roles, responsibilities, and the reporting
structure of all personnel involved in managing ES&H on the project. Communications plans
relating to ES&H are described. Finally, ES&H emergency response plans should be discussed
in detail or referenced if the supporting documents are too long to include. Specific details
of ES&H management topics are provided and described in more detail below in the
respective subcomponents.
Good Practices and Practical Considerations
•
For simple projects, these plans may be aggregated into a single document. But, for
larger, complex, or more specialized projects, there may need to be separate (larger)
supplemental documents that are referenced from within the PEP.
•
The project’s ES&H Plans and approaches should adhere to relevant local, state, and
federal regulations. It is the Awardee’s responsibility to identify and adhere to all such
requirements and regulations.
•
The project’s ES&H Plans and approaches should be tailored and scaled to the needs
of the project but should also follow industry best practices as much as reasonably
possible.
•
If applicable, the project’s ES&H Plans and approaches should refer to and draw upon
any approved home/parent institution’s ES&H Plans and policies.
•
As a good practice and to minimize conflicts of interest, a project’s safety
1 https://www.osha.gov/sites/default/files/publications/OSHA3886.pdf
Document Number
146
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
management structure should be accountable to and report outside of the normal
project management Organizational Breakdown Structure, that is, to avoid even the
appearance of pressure from project management to maintain schedule and budget
performance at the expense of ES&H. For example, on many projects, safety reports
should be made to a level above the Project Manager (PM), for example directly to a
Project Director (PD), Principal Investigator (PI), or other entity.
•
3.5.6.2
As good practice, a project’s ES&H Plans should explicitly empower all Project Team
members to identify and report safety issues, extending to the point of being able to
stop work that they deem unsafe.
PEP Subcomponent 6.2 – Environmental Protection Management Plans
This subcomponent describes specific plans and approaches for managing environmental
concerns during the execution of the project. NSF's proposed funding for the construction
or modification of RI facilities may constitute a federal action that triggers compliance with
several federal environmental statutes designed to consider the proposed action’s impacts
on environmental, cultural, and historic resources as part of the federal decision-making
process. Awareness of and strict adherence to all relevant environmental laws are extremely
important considerations in the Planning, Construction, and Operation Stages of RI. These
statutes include, but are not limited to, the National Environmental Policy Act (NEPA), the
National Historic Preservation Act (NHPA), and the Endangered Species Act. While NEPA and
the NHPA typically focus on proposed activities that take place within the United States,
proposed activities that take place outside of the United States may also be subject to these
federal statutes. In addition, there are international agreements and treaties that require
consideration of potential environmental impacts. It is the responsibility of NSF to identify
and comply with all relevant statutes, regulations, and laws prior to making a funding
decision. If the project is funded, the Project Team may also have responsibilities during the
Construction and Operation Stages to comply with applicable state, federal, tribal, and
international legal authorities.
Typical topics covered in an Environmental Management Plan may include:
•
Environmental Regulations. A list of all relevant environmental regulations and
standards that the Project Team is subject to follow and will adhere to during
execution.
•
Impact Identification. Plans and approaches for the identification, assessment, and
tracking of all relevant significant environmental impacts of the project, both positive
and negative.
•
Mitigation Plans. Plans and approaches for minimizing or mitigating all identified
negative environmental impacts, including measures to protect local ecosystems and
biodiversity, habitat preservation and restoration, reduction of the project’s overall
carbon footprint, reduction of electricity and other energy source usage, and the
reduction of the overall greenhouse gas emissions of the project. Also include waste
management plans, including recycling and disposal methods as appropriate.
Document Number
147
3.5 Construction Stage and Implementation Planning
•
Research Infrastructure Guide
Reporting. Plans and approaches for reporting on environmental performance
throughout the life of the project.
Good Practices and Practical Considerations
•
The primary goal of a project Environmental Management Plan is to protect the
environment during and after the execution of the project; this should be emphasized
in all planning, procedures, and policies.
•
For large and complex projects with significant environmental management concerns
and implications, an external Environmental Management Plan with all the details
defined and described may be required. For smaller and simpler projects, the
Environmental Management Plan can be fully described within the PEP.
•
It is common for projects to use a parent institution's environmental policies, plans,
procedures, and protocols as a basis for ensuring environmental protection on a
project. Every project is unique, with specific needs and requirements that will require
modification, adaptation, and extension of any higher-level institution’s policies.
3.5.6.3
PEP Subcomponent 6.3 – Safety Management Plans
This subcomponent describes specific plans and approaches to managing personnel and
equipment safety during the execution of the project. Typical topics covered in a Safety
Management Plan may include:
•
Safety Regulations. A list of all relevant safety regulations and standards that the
Project Team is subject to follow and will adhere to.
•
Hazard Identification. Plans and approaches for the identification,
assessment/analysis, and tracking for all relevant safety hazards on the project.
•
Hazard Mitigation. Plans and approaches for minimizing and mitigating all identified
hazards and safety concerns.
•
Safety Facilities. Plans for medical facilities, first-aid stations, emergency response
protocols, and communication and transportation plans for injured personnel.
Include plans for and usage of personal protective equipment.
•
Documentation and Reporting. Plans and procedures for monitoring,
documentation, and reporting of safety status, including reporting of all safety
incidents and responses. Plans and procedures for post-incident investigations and
implementation of corrective actions as required.
•
Training. Plans for safety training and awareness education of project personnel.
Good Practices and Practical Considerations
•
The primary goal of the Safety Management Plan is to ensure the safety of workers
and the protection of equipment during the execution of the project; this should be
emphasized in all safety-related plans and procedures.
•
For multi-site projects, the project lead may need to review, verify, and monitor ES&H
the local plans and implementation at remote sites or partner organizations.
Document Number
148
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
•
It is common for projects to use a parent institution's safety policies, plans,
procedures, and protocols as a basis for ensuring safety on a project. Every project is
unique, with specific needs and requirements that will probably require modification,
adaptation, and extension of higher-level institution’s policies.
•
The PEP should also address plans for critical maintenance and inspection
procedures that ensure the safe and efficient operation of RI elements during the
project.
•
For Design Stage proposed projects, the Safety Management Plan should address
safety-by-design approaches to incorporate into the design and analysis process.
•
If the project is subject to periodic reviews, the Safety Management Plan should
ensure that safety is always discussed and included as a standalone topic during
these events.
•
Serious safety incidents, problems, or near-hits need to be reported to NSF, in
accordance with the terms and conditions of the award.
•
Documented and shared lessons learned from the execution of the project can
inform and improve ES&H Plans over time.
3.5.6.4
PEP Subcomponent 6.4 – Occupational Health Management Plans
This subcomponent describes specific plans and approaches to managing personnel health
during the execution of the project. Typical topics covered in an Occupational Health
Management Plan may include:
•
Health Regulations. A list of all relevant health regulations and standards that the
Project Team is subject to follow and will adhere to.
•
Identification, Assessment, and Mitigation. Plans and approaches for the
identification, assessment/analysis, and mitigation approaches for all relevant health
risks on the project, including both occupational and environmental hazards. Include
exposure control plans for hazardous materials.
•
Health Monitoring. Plans and approaches for the ongoing assessment of the health
of project personnel during the execution of the project, including ergonomic
considerations, pre-project health screenings, and ongoing monitoring. Include
protocols and procedures for managing occupational illnesses and injuries of project
personnel.
•
Documentation and Reporting. Plans and procedures for documentation and
reporting, including reporting of health-related incidents and responses.
Good Practices and Practical Considerations
•
The primary goal of a project Occupational Health Management Plan is to protect the
health and well-being of workers during the execution of the project. This includes
both physical and mental health and well-being. Therefore, stress management,
work-life balance initiatives, and access to mental health resources and support
should be considered and implemented as required.
Document Number
149
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
•
It is common for projects to use a parent institution's occupational health policies,
plans, procedures, and protocols on a project. Every project is unique, with specific
needs and requirements that will probably require interpretation of and specific
guidance for suitable implementation of higher-level institution’s policies.
•
Projects being implemented in remote areas or extreme environments should pay
particular attention to health management and monitoring plans.
3.5.7
PEP Component 7 – Project Controls Plans
What Does This Component Describe?
This component describes the plans for Project Controls, the integrated system of tools and
processes that collect, organize, and analyze project data to support understanding and
control of the key project parameters: scope, quality, budget, schedule, contingency, risk,
and resources. Through comparison of actual status against plans, analysis of trends and
variances, and forecasting of future project requirements, Project Controls give managers
the information needed to support decision making. Four major areas of Project Controls
planning are addressed in this component:
•
Performance Measurement and Management (PMM). Methods and approaches
for assessing the state of the project during execution.
•
Change Control. Methods for implementing modifications and changes during the
course of the project.
•
Reporting and Documentation. Ways of capturing and communicating the project
status to key project funders.
•
Business and Financial Controls. Methods and approaches that will be used to
manage all project-related finances and accounting.
Why Is This Component Important?
Managing a Research Infrastructure (RI) project requires regular and accurate assessments
of project status and predictions of future trajectory; it is impossible to successfully manage
and guide a project unless one knows the current state and can forecast the path forward.
Adherence to a defined control process also protects the plan against unauthorized and
unplanned changes (e.g., scope creep) that place unanticipated demands on resources,
budget, and schedule. The use of an integrated Project Controls Plan has been demonstrated
to significantly improve a project’s ability to successfully meet its objectives. When
adjustments to the plan are necessary to keep a project on track, a transparent and
systematic means of making appropriate decisions about the project baseline and/or the
adjustment approach is necessary. Further, a consistent, clear, and accurate means of
documenting and reporting the state of the project (i.e., project status, recent changes,
outstanding risks, and forecasted trajectory) to the key funders (e.g., NSF) ensures maximum
transparency and minimal surprises. Finally, the Project Team should follow its documented
business and financial processes throughout the course of the project. Without sound,
responsible, and appropriate Project Controls that address these factors, projects may miss
Document Number
150
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
goals, requiring unplanned time, money, and effort to return to the plan. In a worst-case
scenario, a project may fail to achieve its objectives.
How To Develop and Write This Component
There are five subcomponents to be included in PEP Component 7 – Project Control Plans.
These five are shown in Table 3.5.7-1 below.
Project Controls Plans should be structured in a manner that matches the project
characteristics and is agreed upon by the Project Team and funders. This entire component
should be both tailored and scaled to the type, size, complexity, and characteristics of the
project. Further, the component should be developed in a progressively elaborated
approach, as described in Section 3.2 Tailoring, Scaling, and Progressively Elaborating Plans.
Document Number
151
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.7-1
Project Controls Plans Subcomponents, Products, and Documents with References to Further Material and Related
Topics
Component
Subcomponent
7.1 Overview of Project
Controls
7. Project Controls Plans
Documents/Products
• Project Management
Control Plan
7.2 Performance
Measurement and
Management (PMM) Plans
• PMM Plan: Process and
Tools
7.3. Change Control Plans
• Change Control Plan
• Change Log
7.4 Reporting and Reviews • Reporting Template(s)
Plans
7.5 Business and Financial
Controls Plans
3.5.7.1
References
Section 4.5 Monitoring
Progress Against Plan
PEP Component 4 – Risk
and Contingency
Management
Section 2.6.1.2
Construction Stage
Reporting and Reviews
• Institutional Policies
• Project-specific financial
plans
• Segregation of Funding
Plan
PEP Subcomponent 7.1 – Overview of Project Controls
This subcomponent serves as an Executive Summary and overview of this entire Project
Controls component. The overview should briefly summarize the methods chosen for the
other four Project Controls subcomponents: PMM, Change Control, Project Documentation
and Reporting, and Business and Financial Controls. The overview should describe how the
plans will be used to manage the project. It should also describe the tools (e.g., spreadsheets,
databases, commercial software products) that will be used for the various Project Controls
functions.
It should be noted that Project Controls form a subset of all project management functions;
the two are not the same. Project Controls tools and processes focus on metrics, tracking,
comparisons to plan, analysis of deviations, change management, and predictions of future
needs and events. Project management serves a broader purpose that includes functions
such as directing work, meeting scope and quality requirements, balancing resources,
making decisions to keep the project on track and managing funder interactions and
expectations. Effective Project Controls are closely tied to all aspects of project management
so that they can inform and support these broader project management functions.
•
A flow chart of typical Project Controls elements and how they are connected is given
in Figure 3.5.7.1-1. The figure shows how Project Controls are used during execution
to compare actual project Status Inputs against the planned Total Project Definition
and to inform management decisions and actions. The Total Project Definition
Document Number
152
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
includes the Performance Measurement Baseline (PMB) described in PEP Component
3 – Performance Measurement Baseline and the contingency amounts established in
PEP Component 4 – Risk and Contingency Management. The Total Project Definition
is established during pre-execution planning, using the appropriate tools used to
create and document the elements of the definition (e.g., Work Breakdown Structure
[WBS], Basis of Estimate [BOE], Integrated Master Schedule, etc.). During execution,
project Status Inputs are updated and compared to the plan using the PMM tools and
methods. Variances and identified issues are analyzed and used to inform
management decisions and actions taken. Changes to the PMB or contingency
amounts are managed according to the project Change Control Plan. Project status,
variances, and changes are then documented and reported to funders, and the entire
process is repeated for each reporting period. Although not shown in An illustration
of standard operating procedures for the implementation of Project Controls is
helpful in communicating the process used for monthly comparisons, analysis,
management, and reporting in a format that speaks to the Project Team members
and emphasizes project-specific details of the steps involved during each reporting
period.
Document Number
153
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Figure 3.5.7.1-1, the institutional Business and Financial Controls ensure that funds are
properly managed and that data on obligations and actual expenditures are correctly
transmitted to the project as Status Inputs.
Good Practices and Practical Considerations
•
Project Control execution and management requires dedicated time from Project
Team members to report and update status, analyze the data, support decisionmaking, and carry out actions. The time and skills to perform various roles and
responsibilities should be included in the consideration of assignments to project
roles and in the calculation of hours and money spent in carrying out Project Controls
functions. These costs should be folded into the budget and staffing/hiring plans.
•
Care should be taken in making sure that the Project Team chooses tools to match its
needs. Many commercial project software available for Project Controls (schedule
platforms, PMM programs, risk managers, etc.) require expertise and experience to
run the software as well as costs for licensing. Expert hire(s) may also be essential to
support these applications.
•
For large, complex projects, a supplementary standalone Project Management
Control Plan document that describes all plans and expectations for Project Controls
may be created and referenced from within this PEP. For less complex projects and/or
nascent projects still under development, all details, and plans for the Project
Management Control Plan can be contained within the PEP document itself.
•
An illustration of standard operating procedures for the implementation of Project
Controls is helpful in communicating the process used for monthly comparisons,
analysis, management, and reporting in a format that speaks to the Project Team
members and emphasizes project-specific details of the steps involved during each
reporting period.
Document Number
154
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Figure 3.5.7.1-1
Project Controls Process Flow Chart: Interactions Among Subcomponents with Established Total Project Definition
3.5.7.2
PEP Subcomponent 7.2 – Performance Measurement and Management
Plans
This subcomponent presents the project PMM tools and methods that describe how the
project will be managed and controlled during execution using information from quantitative
comparisons of status to the planned project. There are two major processes in a PMM Plan
that need to be addressed, as shown in the PMM and Status Input boxes in Figure 3.5.7.1-1
above:
•
Performance Measurement. Comparing and analyzing collected Status Inputs
against the plans in the Total Project Definition.
•
Performance Management. Making management decisions on actions to pursue
based on the comparison analysis.
The selection of Project Controls tools depends upon the chosen PMM method, which should
be tailored and scaled to meet project needs. For example, Major Facilities construction
projects must use verified Earned Value Management (EVM) as the PMM method, which
entails the use of tools such as EVM software applications and involves adherence to NSF
Earned Value Management System (EVMS) guidelines. Simpler projects may find that scaled,
non-verification EVM, or even simple spreadsheet comparisons of cost versus actual
expenditures and milestone tracking, are adequate methods for comparison of plan to
actual status. Further guidance on creating a tailored and scaled PMM Plan is given in Section
4.5 Monitoring Progress Against Plan.
The PMM Plan should describe how the following functions will be addressed:
Document Number
155
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
•
Scope Assessment. Describe how the delivery of scope will be formally assessed,
compared to the WBS and the Quality Acceptance Criteria, and how variances will be
documented. For example, the earned value rules outlined in the PMM Plan will
provide a structured approach to assess progress against the WBS and Quality
Acceptance Criteria.
•
Schedule Progress Assessment. Describe how schedule activity progress inputs will
be collected and formally assessed against the Integrated Master Schedule and how
variances will be documented.
•
Budget Assessment. Describe how expenditure inputs (actuals and estimated
actuals) will be regularly collected (at the work package level) and assessed against
the time-phased budget, as well as how variances will be documented.
•
Variance Assessment. Describe how cost and schedule variances will be evaluated
and how the Project Team will determine what corrective actions will be needed, if
any.
•
Forecasting. Describe the methods and frequency of updates to Estimate at
Completion and Variance at Complete for cost and schedule.
•
Performance Management Process. Describe processes, roles, and authorities for
reviewing the performance measurement analysis and making decisions on which
actions to take to keep the project on track.
Good Practices and Practical Considerations
•
EVM is a commonly used PMM methodology for comparison and analysis of status to
plan. If EVM is selected as the PMM comparison method, the Project Team should
scale the processes and tools used to match project characteristics.
•
For projects using EVMS, aligning the PMM Plans to the applicable EVMS principles,
processes, and guidelines can help demonstrate proper implementation and, for
Major Facilities, facilitate the EVMS Verification Review.
•
A means of qualitative assessment of project performance is encouraged. A good
practice is for project leadership to regularly visit the work sites, talk to the staff doing
the work, and assess progress first-hand, correlating it to the quantitative metrics
gathered in parallel.
•
Conducting both formal and informal status meetings with lead staff, Control Account
Manager (CAM), and others doing the work is encouraged.
•
The PMM Plans should note at what cadence PMM functions will be performed. Most
quantitative PMM functions are conducted monthly. If the proposed cadence is
longer or shorter than one month, explain why this is appropriate for the project.
•
Identified variances by themselves are neither good nor bad; they are simply a form
of information that requires analysis and interpretation. An appropriate means of
systematically evaluating and assessing the significance of variances before corrective
action is applied should be part of the PMM process.
•
All variances, both positive and negative, should be communicated to funders to
Document Number
156
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
ensure a comprehensive and realistic understanding of project status and prospects.
3.5.7.3
PEP Subcomponent 7.3 – Change Control Plans
This subcomponent describes the project’s Change Control Plan, which addresses how the
project manages, controls, and reports changes to the Total Project Definition. There are two
types of project changes addressed in the Change Control Plan:
•
Change Control refers to changes to the PMB and movements/usage of contingencies
(budget, schedule, and scope contingencies).
•
Configuration Control applies to changes to the technical details (i.e., requirements
and design).
Because of the unique and innovative nature of many NSF-funded projects, change is
expected during the RI implementation and Construction Stage. In addition to normal
adjustments that occur with all implementation projects that involve future planned work,
RI projects typically carry significant risks that require adjustments to the plan if realized.
When project performance begins to significantly deviate from the plan due to a risk
occurrence that affects project objectives or the plan needs to change for other reasons,
project management exercises the Change Control process to maintain the overall project
trajectories. Once reviewed and approved, Change Control actions may involve adjustments
as simple as the documentation of a straightforward schedule reorganization or as complex
as a scope change involving changes to design and requirements, cost, schedule, scope,
performance/quality, and contingency amounts.
Change Control Process. The Change Control Plan in the PEP should trace the path from
submission of a Change Request, through the evaluation and approval processes, and end
with implementation and reporting. It should be detailed enough that it can serve as
guidelines for training and directing Project Team members responsible for delivering the
project scope as planned and who are responsible for determining and implementing
changes to the plan when necessary.
The Change Control Plan should include details of the following:
•
The composition of the Change Control Board (CCB) and the roles and responsibilities
assigned to Change Request submitters, reviewers, and approvers.
•
The process for preparing and submitting Change Requests for evaluation.
•
The process for analysis and review of benefits and impacts (e.g., review by a formal
CCB).
•
The thresholds and authorities needed for approval.
•
Change documentation and archival of change materials (Change Requests,
supporting documents, approvals, etc.).
•
Reports and notifications to the Project Team, NSF, and other funders.
An example flow diagram for a Change Control process is shown in Figure 3.5.7.3-1 below,
Document Number
157
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
tracing the path through the process for both Change Control and Configuration Change
Requests. In this example, a single request form is used for both configuration and Change
Control Requests, but they follow separate evaluation processes. A CCB (e.g., comprised of
Project Managers [PM] and work package leads) evaluates changes to the Total Project
Definition: baseline and contingency. A Technical Review Board (e.g., comprised of technical
leads and Subject Matter Experts [SME]) evaluates changes to project configuration:
technical scope, requirements, and design. The CCB makes recommendations on changes
based on impacts versus benefits. If a recommended technical change involves changes to
scope or requirements or affects cost, schedule, and/or contingency, it is transferred to the
CCB for evaluation of the impacts on the PMB and contingency. If it is a request for a waiver
of non-compliance for a completed part so that it can be accepted as still useful, it goes to
the technical approver.
The CCB assesses the Change Request and makes a recommendation to approve or reject a
Change Request based on the project-specific approval thresholds and authorities. The
authorized approvers make the formal decision to approve, reject, return for adjustments,
or place the request on hold. Generally, approvals progress from the lowest threshold level
for CAM approval through higher levels in the project to the PM as the final approver. Others
who may be included as approvers are Environmental, Safety, and Health (ES&H) officers or
systems engineers. When NSF thresholds on project parameters apply, then NSF approval
or concurrence must be sought, in accordance with the award terms and conditions.
If approved, the changes are implemented. Regardless of the approvers’ decision, the
Change Request Form is finalized and archived, and the Change Log is updated. The decision
is communicated to funders who may be impacted (including other work package leads who
may lose the opportunity to use remaining contingency or whose work may need to be
adjusted). Finally, the outcomes of Change Requests are reported to NSF in interim progress
reports and periodic submission of the Change Log.
The example process illustrated here should be modified by each project, keeping scaling in
mind to match project needs. For example, on very simple projects with few WBS levels, the
PM may act as a Change Request evaluator and approver without the use of a CCB. For more
complex projects with many WBS levels, a deep hierarchy of leadership from CAM up to the
PM and /or Program Director (PD), and a wide range of technical capabilities areas, CCB and
Technical Change Board contribute a necessary depth of knowledge to the evaluation
process.
Requirements and guidelines for creating and scaling Change Request Forms and Change
Logs are described below.
Approval Thresholds and Authorities. In addition to internal approval authorities, the
defined Change Control process generally includes provisions for seeking prior written
approval from NSF (i.e., the Program Officer [PO] or higher) depending on the magnitude of
the change and NSF policy. All actions that exceed these thresholds will also be included in
the terms and conditions of the award. The approval thresholds are negotiated with the
cognizant PO and award official before the award. In particular, the PO will concur with all
Document Number
158
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
change actions exceeding thresholds defined in accordance with the award terms and
conditions for use of scope, schedule, and budget contingency. Contingency may only be
used to support the scope included in the approved Total Project Definition or Scope
Management Plan (see Section 4.7 Contingency Estimating and Management).
An example of a Change Control threshold table is shown in Table 3.5.7.3-1.
Table 3.5.7.3-1
Sample Change Request: Approval Thresholds and Authorities for a Medium Complexity Major Facility Project
Type of Change
NSF
PM
CAM
Key Science Objectives
Impact on Key
Performance Parameters
Changes to science
requirements
Changes to engineering
requirements
PMB Budget
(between WBS elements)
Budget changes above
$250,000
Budget changes between
$50,000 and $250,000
Budget changes between
$5,000 and $50,000
PMB Schedule
Change of two months or
Change in project end date less to Tier 1 or 2
milestones
Change of one month or
less to Tier 2 Milestones
Contingency
(to/from contingency
budget and PMB)
Greater than $100,000 or
two months of schedule
Exercising any scope
option
Less than $25,000 or one
month or less to Level 2
milestones
Document Number
Less than $100,000 or two
months or less to project
end date
159
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Figure 3.5.7.3-1
Example Flow Diagram for Change Control Process
Document Number
160
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Change Request and Change Control Log Formats. NSF requires projects to document
and archive Change Requests and maintain a Change Log capturing all requests and
outcomes for changes to project parameters. NSF does not have a specified format or
template for a Change Request Form but does strongly encourage the inclusion of some
common elements. For example, changes should be linked to WBS elements and schedule
IDs, and all Control Accounts should be specified as impacted by budget or schedule
changes. Any contingency adjustments must be linked to an identified WBS and risk ID in
the Risk Register. In addition to these requirements, Project Teams should include the BOE
data and calculations itemized by cost element (i.e., labor, materials, supplies, etc.) as well as
before and after copies of the affected schedule and/or milestones. The final format for
Change Requests, as well as the process and threshold approval levels for implementation,
may be negotiated with NSF at the time of award.
The following is a list of the common elements included in a Change Request Form:
•
Change Request ID, Title, Owner/Proposer, Date of submission.
•
Summary of Motivation and Change Description, including change in risk to project
objectives and any contingency adjustments.
•
Links to impacted WBS elements and identified risks.
•
Impacts on elements of the project PMB.
•
Budget and schedule impacts, including proposed adjustments to contingency.
•
Signatures of reviewers, if required.
•
Acknowledgement of communication to impacted project leads.
•
Project approvals according to authority and thresholds, with NSF approval if
required.
•
Project Controls acknowledgment of completed change implementation.
•
Attachments: expanded schedules, BOE for impacts, technical reports, and any other
pertinent information.
Document Number
161
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Figure 3.5.7.3-2
Example of a Change Request Form
Change Request Form
Change Request #
Date
Change Request Title
Impacted WBS Elements
Associated Risk ID #s
Award #
Originator Name
Originator Signature
Other Personnel
Summary change description and
justification, and impact if change
does not occur
(Include potential alternatives as
appropriate)
NSF Approval Required?
Scope or Technical Impact
Budget Impact
Schedule Impact
Project Acknowledgement and Concurrence
Title/Name
Signature (or attached email
approval)
Date
Budget Impacts by WBS and Control Account
WBS Element
Level 2
Control Account
(WBS Level 3)
Current Budget
Revised Budget
Change Amount
Change
Description
WBS L-2
Subtotal
Total
CCB Review Date (Can be bypassed for
budget changes <$25K)
Date
CCB Review Results
Change Approved or Rejected by PD?
Project Director Signature
(Or attached email approval)
Date
Disposition
Originator Signature
NSF Program Officer Signature (required if >$75K)
(Or attached email approval)
Date
Comments
Project Controls Implementation
(Description)
Project Controls Staff
Implementation Date
Additional Documentation
Document Number
162
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
It is compulsory for Project Teams to keep a complete list of all formal Change Requests,
regardless of whether the Change Request was approved, rejected, or placed on hold, in a
summary Change Log. The Change Log is submitted to NSF on a specified schedule. A list of
the typical elements in a Change Log includes the following:
•
Change Control document reference number, title, review date, and approval dates.
•
Amounts of change in scope, schedule, and budget, labeled at WBS Level 2 or at the
first meaningful level of technical differentiation within the project.
•
Adjustments to contingency, both draws and returns.
•
Running totals for baseline cost, budget contingency usage to date, and remaining
obligated and authorized contingency.
•
Running totals for project baseline duration, contingency usage to date, and
remaining contingency.
•
NSF approval and contingency obligation date if applicable.
Each project should tailor the Change Request Form and Change Log formats to the project
needs. Projects may choose, for example, to use two separate forms for Change and
Configuration Requests, where the information collected for configuration changes may be
based more on test results and requirements compared to Change Requests focused on cost
and schedule.
Change Log. It is essential that historical information be logged and maintained in a manner
that allows NSF to systematically track the evolution of the PMB and the science objectives
from the initial definitions at award through all subsequent changes. For example, PMB
budgets should be traceable through historical records to the initial PMB release.
•
All CCB Change Requests are to be documented and archived by the Project Team,
regardless of the outcome.
•
Subject to the terms and conditions of the award, Change Logs and Change Request
documentation are usually provided on a periodic, pre-determined basis to NSF for
review.
The Change or Configuration Change processes should reference the Contingency
Management Plan for descriptions of considerations for managing scope, schedule, and
budget contingency, including approval and notification thresholds, and how contingency
will be added to/subtracted from the Total Project Definition. When a project approves a
Change Control action that results in allocating or returning underruns to the contingency
budget, the PMB budget will also change. Similar Change Control actions affect the PMB
schedule; they revise the project PMB schedule and the available schedule contingency or
float time - that is, the difference between milestones on the schedule's Critical Path and the
expected completion dates for activities that lead to the accomplishment of those
milestones. When a project exercises up- or down-scopes listed in the Scope Management
Plan (see Section 3.5.3.2 PEP Subcomponent – 3.2 Scope), the PMB budget and schedule will
change, and the contingency budget will either increase or decrease as a result. The Scope
Management Plan will also change, with de-scopes removed from the PMB and documented
Document Number
163
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
in the Scope Management Plan. Up-scope options will involve adding to the PMB scope,
schedule, and budget and retiring the option in the Scope Management Plan. All contingency
requests must be supported by documentation demonstrating that the proposed amounts
and changes to be allocated are considered reasonable and allowable and must reference
the associated WBS elements and the previously identified risk (see Section 4.7 Contingency
Estimating and Management.)
Good Practices and Practical Considerations
•
Modifications to the PMB that are within the defined scope and do not change the
Total Project Duration (TPD) or Total Project Cost (TPC) are referred to as replanning.
Replanning may be the result of adjustments or reorganization of the project plan
and/or may signify that contingency is being used in an expected manner.
•
Re-baselining occurs when the changes involve increases in the authorized TPC, an
extension beyond the TPD, and/or major changes in scope or science goals. When the
proposed changes reach the re-baselining level, the approval process involves NSF
and may involve the National Science Board.
•
Re-planning exercises are not requisite to address minor cost or schedule variances
but may be warranted if there are substantive changes to the PEP during
implementation or Construction Stage.
•
Projects should include both threats and opportunities in the Risk Register from the
very beginning of the project to allow both up- and down-scope actions during the
implementation or Construction Stage.
•
A single combined Change Log with both Change Request information and summary
log inputs may be adequate to meet NSF requirements for simple projects and those
with few or simple anticipated changes.
•
NSF may request submission of native file formats (e.g., spreadsheets, not PDF files)
to facilitate oversight.
3.5.7.4
PEP Subcomponent 7.4 – Reporting and Review Plans
This subcomponent describes how project status and progress will be periodically
documented and reported. This description should address:
Interim Progress Report. At an interval that is specified in the project’s award instrument,
the Project Team will create and submit to NSF an interim progress report. At a minimum,
the interim progress report should include:
•
The current technical status of the project, including progress of scope production
and adherence to quality acceptance criteria.
•
Schedule status, including the current project’s Critical Path, reportable milestones,
and other significant information related to the schedule.
•
Financial status, including the percentage complete, TPC, Budget at Complete,
Estimate to Complete, and Estimate at Completion (if applicable). If EVM is not
required, provide an objective means to monitor progress against the plan.
Document Number
164
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
•
Risk status, including current total risk exposure, response plans, realized risks,
new/changed/retired risks, contingency status, and any other relevant information.
•
The project status report and delivery format will be negotiated with NSF.
Annual/Final Project Report. As required by the project’s Cooperative Agreement (CA), an
annual report will be created and submitted to NSF. This report will generally contain the
same type of information that is included in regular project status reports, but with a focus
on the entire year’s progress against the plan and plans for the next reporting period.
Additional content may be requested by the cognizant PO or negotiated as part of the terms
and conditions for the award, including documenting lessons learned.
Post-Award Reviews. After an award is made, on-going internal or external reviews of
project plans, performance, or activities may occur. Some reviews will be pre-negotiated with
NSF and specified in the terms and conditions of the award instrument (e.g., performance
reviews) or arranged at the request of the Project Team (e.g., assistive reviews). Other review
activities will be activities led by the Awardee (e.g., technical reviews, safety reviews,
acceptance reviews). The number, frequency and type of reviews will vary depending on the
nature and needs of the project. Depending on the specific details, NSF may arrange or
attend such activities to ensure proper award oversight and maintain awareness of project
status.
Good Practices and Practical Considerations
•
The specific plans for progress reporting should be elaborated over time, starting with
a summary of expected reporting elements based on information generated in the
Project Controls Plan and ending with the actual details negotiated with NSF at the
time of the award.
•
In addition to supplying regular status reports in the terms and conditions of the
award instrument, it is essential that project staff inform NSF in a timely manner of
significant issues or significant changes in project status, such as a potential rebaselining, problems with partnerships, or surprising research and development
results.
•
For some projects, more frequent reporting and reviews may be beneficial. For
example, quarterly reviews between Awardees and vendors or service providers may
facilitate understanding of management topics, risks, or other performance aspects.
3.5.7.5
PEP Subcomponent 7.5 – Business and Financial Controls Plans
This subcomponent describes the award management and business, and financial
procedures, policies, processes, and controls employed in executing the project. For projects
involving partner institutions and/or other Subawardees, the host (award institution) acts as
the central financial and accounting system for the project, collecting accounting information
and invoices from the partners’ financial systems.
The following elements should be described in this subcomponent:
•
Identification of the roles and responsibilities for financial oversight, including
Document Number
165
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
decision authority, of proper allocation of expenditure if a question should arise
during execution.
•
Description of financial controls, including accounting practices, business controls,
software tools, and/or award management practices.
•
Stated references to institutional policies for subawards, procurements, and so forth.
•
Description of accounting practices for collection and handling of financial data and
actual expenses from internal and external subaward sources for input to the project
PMM applications.
•
Description of methods and responsibility for collecting various rates (salary, fringe,
indirect costs, etc.) from the host and any partner institutions, including the process
for incorporating rate changes and updates into Project Controls.
•
System assessments and validations, such as audits passed and certifications.
•
If relevant, a Segregation of Funding Plan describing accounting procedures used to
properly delineate and separate expenses for construction activities from concurrent
or related activities supported by other funding (e.g., Construction Stage awards from
Operations or Design Stage awards).
Segregation of Funding Plan. A Segregation of Funding Plan is intended to establish internal
guidelines to be used by the Awardee and to inform a mutual understanding between NSF
and the Awardee of the Awardee’s practices and responsibilities to determine the
appropriate award when allocating expenses, particularly when construction and design or
operations activities overlap in time. 1 The Plan describes the procedures the Awardee will
use to ensure that costs and activities are expensed to the proper award by clearly defining
the separation between the different sources of funding. Funds used on research facilities
often come from sources such as existing ongoing operations, construction awards,
operations start-up awards that include select commissioning activities, research grants,
partner funds, etc. The Segregation of Funding Plan should include the following:
•
Description of how work scope is defined and segregated according to funding source
(e.g., project WBS, operations Annual Work Plan, design scope of work, etc.).
•
Description of any contributions to the project from other funding sources and how
these contributions are financially managed (i.e. separate job/cost accounting
records).
•
Provide a description of how the guidance in the plan will be articulated to all funders
and project staff.
•
Description of materials/services that benefit more than one award (i.e., Construction
and Operations Stage awards) and methodology used to allocate expenses to the
awards.
Various aspects of the Segregation of Funding Plan may be addressed in the Awardee’s
12
CFR 200.413 "Direct Costs" describes the criteria Awardees must use when direct charging costs against a
federal award. https://www.ecfr.gov/current/title-2/section-200.413
Document Number
166
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
internal policies and procedures or addressed in other parts of the subject PEP. In these
cases, the Segregation of Funding Plan should address these aspects by reference in lieu of
duplicating internal documents or text from other components of the PEP.
Good Practices and Practical Considerations
•
Typically, projects utilize the award or host institution’s existing business offices (e.g.,
purchasing and contracting) and financial (e.g., accounting) services to execute the
project. This subcomponent should describe any such framework or relationships,
including how the project will be managed within the larger institution, roles and
responsibilities, authorities, and other relevant information.
•
A description of the institutional entities that provide oversight within the Awardee
organization should be included. For universities and laboratories, this usually
involves an Office of Sponsored Research, Grants, and Awards, a Vice President of
Research, etc. For consortia or collaborative projects, representatives from several
such groups may be managed as a committee. For contract awards, the corporate
structure and NSF oversight details would define the relevant parties. These
relationships may also be represented in PEP Subcomponent 2.3 – External Project
Stakeholders.
3.5.8
PEP Component 8 – Cyberinfrastructure and Information
Management
What Does This Component Describe?
This component describes the project’s Cyberinfrastructure (CI) and Information
Management Plans, which refer to the planned methods and processes for identifying,
generating, gathering, organizing, storing, and sharing information within and external to the
project. The CI described in this PEP component is distinct and separate from project
deliverables for science purposes. When applicable to the project, CI and Information
Management Plans should consist of five key areas of focus: CI, Information Assurance (IA),
data management, documentation management, and communications management. CI, in
this instance, is designed to efficiently connect facilities, data, firmware, software, computers,
and people, with the goal of supporting project execution during the implementation and
Construction Stage. IA includes cybersecurity and other methods to safeguard digital assets
and project information during the planning, execution, and closeout of the project. Data
management involves the handling of data produced during the project, including testing
and prototype data, code development, and related matters. Documentation management
involves the creation, tracking, storage, and retrieval of project documents such as contracts,
plans, drawings, specifications, reports, and Project Control documents. Lastly,
communications management involves planning, execution, and monitoring of information
flow and project communications.
Document Number
167
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Why Is This Component Important?
Effective CI and Information Management
ensures that needed information is available to
Key Takeaway
the appropriate people at the right time. It The CI described in this PEP component is
enables informed decision-making using
distinct from any major computational
equipment or resources that might be
accurate, up-to-date information. It helps
developed as a project deliverable.
Project Managers identify potential risks and
issues early, which can prevent costly delays
and rework. Effective CI and Information Management promote collaboration and
coordination while simultaneously preventing duplication of work, overlooked work, and
general misunderstandings. It also helps maintain institutional knowledge both beyond the
life of the project and with the departure of individual team members during the project.
Effective CI ensures that project data is stored, available, reliable, and backed up. Effective IA
protects against cyber threats, such as hacking, data breaches, and unauthorized access,
ensuring confidentiality, integrity, compliance, and availability of project-related information
(see Section 5.3 Information Assurance for additional detail). Effective documentation
management ensures that project documents are accurate, up-to-date, and accessible to all
relevant and appropriate stakeholders. Effective communications management ensures that
information is routed to the correct people and that stakeholders are properly informed
about project progress and issues.
How To Develop and Write This Component
There are six subcomponents to be included in PEP Component 8 – Cyberinfrastructure and
Information Management, as listed in Table 3.5.8-1 below.
The Information Management Plans should be structured in a manner that matches the
project characteristics and is agreed upon by the Project Team and funders. This entire
component should be tailored and scaled to the individual type, size, complexity, and
characteristics of the project. Further, the subcomponents should be developed in a
progressively elaborated approach, as described in Section 3.2 Tailoring, Scaling, and
Progressively Elaborating Plans.
Document Number
168
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.8-1
Cyberinfrastructure and Information Management Subcomponents, Products, and Documents with References to
Further Material and Related Topics
Component
Subcomponent
Documents/Products
References
8.1 Overview of
Cyberinfrastructure and
Information Management
8. Cyberinfrastructure and
Information Management
3.5.8.1
8.2 Cyberinfrastructure
• Cyberinfrastructure Plan
Section 5.2
Cyberinfrastructure
8.3 Information Assurance
Management
• Information Assurance
Management Plan
Section 5.3 Information
Assurance
8.4 Data Management
• Data Management Plan
8.5 Documentation
Management
• Documentation
Management Plan
8.6 Communications
Management
• Communications
Management Plan
PEP Subcomponent 8.1 – Overview of Cyberinfrastructure and Information
Management
This subcomponent provides a high-level description and overview of the plans for the
management of project information, which includes CI, IA, data management,
documentation management, and project communications management. This
subcomponent describes the overarching CI and Information Management policies and
objectives, the management team structure, key roles and responsibilities, and other
relevant high-level information. It serves as an introduction for the remainder of this CI and
Information Management component, with specific details for each sub-area provided below
in the relevant subcomponents.
Good Practices and Practical Considerations
•
Projects are expected to maximize access, sharing, and transparency of project data
(which is distinct from the scientific data resulting from use of the Research
Infrastructure [RI]) while simultaneously safeguarding privacy, confidentiality,
intellectual property, and cybersecurity. Striking the correct balance between these
two competing goals should be jointly planned with the Project Team, the relevant
science community that the project will serve, and NSF.
•
Project budgets should include adequate resources for CI and IA and other
Information Management activities, including personnel, infrastructure, services, and
storage costs. Project Team members should also be trained in resource planning
and budgeting.
•
In the interest of transparency and as a general good practice as a steward of
taxpayer-funded work, Project Teams should report on and share project activities
and findings regularly via public outlets like websites, publications, conferences, etc.
•
Project Teams should consult the NSF Brand Identity Portal for updated guidance on
Document Number
169
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
logos, signage, and acknowledgment of NSF support. 1
3.5.8.2
PEP Subcomponent 8.2 – Cyberinfrastructure
This subcomponent describes the information to be included in the CI Plan that outlines the
strategy and approach for CI during implementation or the Construction Stage. The CI Plan
provides a structured approach for planning, implementing, and managing the CI aspects of
the RI. Typical topics for a CI Plan include:
•
Enabling the Scientific Mission
•
CI Elements and Requirements
•
Internal and External CI, Facilities, and Resources
•
CI Implementation Approach
•
CI Operational Approach
The CI Plan described in this PEP component is relevant only to implementation or the
Construction Stage.
Good Practices and Practical Considerations
•
Project Teams should consider options for geographically separated duplication of
critical project data, documents, and other information resources to mitigate data
loss resulting from catastrophic incidents.
•
Training materials to support proper usage of project-related CI should be developed
for use by relevant internal or external stakeholders.
•
Wherever possible, project CI elements should be designed for rapid redeployment
across different platforms or service providers if necessary.
•
Project CI resource utilization assessment and benchmarking tests should be
conducted regularly to ensure that system capacity matches workload and does not
impede progress or waste resources.
3.5.8.3
PEP Subcomponent 8.3 – Information Assurance Management
This subcomponent describes specific plans and approaches for the management of project
information during the Construction Stage or implementation. Guidance on the
recommended elements of an Information Assurance Management Plan is provided in
Section 5.3 Information Assurance. Topics covered in this subcomponent’s plans should
include:
Institutional Policies and Procedures. Reference to and compliance with a parent
institution’s cybersecurity management policies and procedures, if available. Identify the
cybersecurity framework and control standard that has been chosen to guide the IA
program. Include compliance with NSF requirements and relevant laws and regulations.
1 https://mediahub.nsf.gov/portals/dnmqqhzz/NSFBrandingPortal
Document Number
170
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Roles and Responsibilities. Identify roles, and responsibilities for planning and
implementing the cybersecurity program. Include roles and responsibilities for responding
to cybersecurity events.
Data and System Security. Plans, framework, and processes for data security, encryption,
access controls, reporting, risk assessments, and security audits for all project websites,
databases, servers, and other IT infrastructure. Includes plans for passwords, data
encryption, multi-factor authentication (MFA), access control, and other security
implementation practices. Include guidelines for software updates and security patching.
Policies for the use of institutional and personal devices and accounts for funded activities.
Response Plans. Plans and protocols for identifying, reporting, and responding to
cybersecurity events. Includes business continuity plans for critical systems, resources, and
project activities. This includes identified individual team member responsibilities and
response hierarchy.
Training. Policies and plans for cybersecurity awareness and implementation training for
project staff. This includes training on phishing, password security, social engineering, and
other means by which nefarious entities may gain access to the RI CI and data.
Good Practices and Practical Considerations
•
Section 5.3 Information Assurance contains guidance on creating a rigorous
Information Assurance Management Plan.
•
Some NSF-funded institutions and projects have come under serious denial of
service, ransomware, and other related attacks. It is the Project Team’s responsibility
to ensure that all appropriate means are applied to deter, minimize the likelihood of,
and otherwise mitigate these attacks and ensure the integrity, security, and
appropriate level of confidentiality for project systems and data.
•
Projects utilizing cloud computing or third-party services should review all relevant
security provisions, agreement terms, and potential risks posed by these entities. This
includes interactions with allied facilities and data archives.
•
The cybersecurity plans should be informed by risk analysis, emphasize data
management best practices, include robust safeguards and regular vulnerability
testing, and include software updates. Training is also very important and should be
an essential component of any IA program.
•
Cybersecurity risk management and incident recovery budgets should be included
the project budget linked to the appropriate Work Breakdown Structure (WBS).
3.5.8.4
PEP Subcomponent 8.4 – Data Management
Plans and approaches for managing project information are included in this subcomponent.
Topics covered in this subcomponent’s plans typically include:
Institutional Policies and Procedures. The plan should reference and describe compliance
with a parent institution’s CI, IT, and/or data management policies and procedures, if
Document Number
171
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
available.
Roles and Responsibilities. Include plans for all IT support, including roles, responsibilities,
and training to support project needs. Plans and processes for training and support to
ensure project personnel are well-versed in using the project’s CI, IT systems, and data
management tools should be included.
Project Data. Policies, plans, protocols for the organization and control, documentation, and
long-term preservation and archiving of project-produced data and models. For example,
Earned Value Management or procurement-related data would be covered in this
subcomponent. Include plans for sharing and access to these data among project
participants. Standards and meta-data requirements and expectations should be described.
The project data referenced here is distinct and different from the science deliverables of
the project.
Software and Code Data-Management Deliverables. Specific plans for software selection
or development, deployment, coordination, benchmarking, documentation, code
repositories, quality testing, version control, release, and issue tracking. Plans and
expectations of key software and data analysis tools to be used during project execution
should be included, along with details on licensing, installation, and other requirements.
Backup. Plans and methods for backup, reporting, and disaster recovery in the event of data
loss or system failures during the execution of the project.
Good Practices and Practical Considerations
•
Where possible, Project Teams should utilize existing and proven CI, repositories,
archives, and community standards rather than developing custom solutions that are
new and/or untried. Open licensing is also encouraged where applicable.
•
Data governance and ownership need to be clearly defined and stated, including
intellectual property rights and data rights for all relevant parties.
•
Data quality assurance and control are key aspects of a Data Management Plan.
Careful consideration, the implementation of best practices, and other means should
be employed to ensure data quality, accuracy, and reliability throughout the
execution of the project.
•
Project Teams should have a comprehensive plan to manage digital assets, including
code, software deployment recipes, hardware and network architectures, 3D designs,
and the like. Management, access, and distribution of these project execution-related
assets needs the same consideration as applied to scientific data and project
deliverables.
•
A digital asset inventory and associated points of contact can facilitate efficient
management and oversight of all resources.
Document Number
172
3.5 Construction Stage and Implementation Planning
3.5.8.5
Research Infrastructure Guide
PEP Subcomponent 8.5 – Documentation Management
This subcomponent describes specific plans and approaches for managing project
documentation. The Project Team is responsible for ensuring that a document management
system is in place that provides for the retention and retrieval of essential and significant
documentation related to the project. A robust document management system will help
prevent miscommunications and misunderstandings and will ensure that future facility
operators have the information required to maintain the facility. This plan should provide
organized and straightforward access to project records as required for NSF oversight,
audits, and post-award monitoring.
Awardees should retain financial records, supporting documents, statistical records, and
other records pertinent to the award instrument employed for at a minimum of three years
after submission of the Final Project Report. In addition, access to any relevant books,
documents, papers, and records should be made available to the NSF Director, Office of
Inspector General, and the Comptroller General of the United States, or any of their duly
authorized representatives to make audits, examinations, excerpts, and transcripts in
accordance with either the Uniform Guidance or Federal Acquisition Regulation (FAR)
requirements, as appropriate.
Essential and significant documentation includes the record of any decision affecting the
cost, schedule, or baseline. At a minimum, the following forms of documentation should be
retained:
•
Memorandum of Understanding (MOU) and any other project agreements or deals.
•
Architectural, engineering, shop, and as-built drawings.
•
Correspondence identifying problems, the resolution process, and the final decision.
•
Contingency use log.
•
Change Requests and approvals.
•
System integration, commissioning, testing, and acceptance plans and results.
Topics covered in this subcomponent typically include:
Institutional Policies and Procedures. Reference to and compliance with a parent
institution’s policies and procedures, if available, for document management, open access,
intellectual property, and other relevant document control policies.
Documentation Development Plans. This plan should include processes for document
creation, review, approval, access, and version control. Specify who is responsible for
document generation, who reviews them, and the approval hierarchy. Include guidelines for
document formats, templates, naming conventions, and styles to ensure consistency.
Document Storage Systems. Document management system(s) to be used for secure
storage, retrieval/access, sharing and archiving documents, records, and data. Include
repository retention, archiving, and backup plans.
Document Security Plans. Document security and confidentiality plans, including access
Document Number
173
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
and distribution permissions and restrictions for confidential or sensitive documents. These
plans should be coordinated with and integral to the overarching cybersecurity plans
described in PEP Subcomponent 8.3 – Information Assurance Management.
Good Practices and Practical Considerations
•
Projects are encouraged to implement a document management system that is
accessible via the Internet rather than paper-based, though some paper records may
be necessary on certain projects. The documentation management system should aid
in identifying the types of documents to retain and contain appropriate controls over
official documents such as drawings to ensure that only the most recent drawings are
being used and that only authorized personnel are able to access and modify them.
•
NSF has specific requirements and expectations for documentation retention on
projects they fund. It is the responsibility of the Awardee to determine the
applicability and specific requirements for their project. This may include
requirements for retention of financial, programmatic, and equipment records and
documents post project. The Project Team is encouraged to work with
representatives at NSF to determine and implement these requirements.
3.5.8.6
PEP Subcomponent 8.6 – Communications Management
This subcomponent describes specific plans and approaches for managing project
communications. Communications can take a variety of forms, including regular all-hands
meetings, regularly updated project websites, and team newsletters and blogs. Successful
communication plans depend strongly upon interactions with project stakeholders,
including NSF and other governmental representatives, Project Team members and
partners, and the public. Awardees are recommended to put in place a stakeholder
management plan that provides for the identification, analysis, and periodic review of project
stakeholders, including an analysis of their needs and expectations. Topics covered in this
subcomponent’s plans typically include:
Institutional Policies and Procedures. Reference to and compliance with a parent
institution’s communication policies and procedures, if available.
Roles and Responsibilities. Plans for management and responsibilities for overseeing and
implementing project communications, including any required approval hierarchies. Any
single point of contact requirements (e.g., for press interactions, crisis management, etc.)
should be identified.
Communication Strategies and Methods. The overarching strategies and specific methods
planned for both internal and external (e.g., NSF) project communication. Specify items such
as the goals, target audiences, communication frequencies, formats, and other planned
methods of formal and informal communication. The communication channels and methods
to be used should be identified, such as emails, regular meetings, software, and social media
platforms. Explain how each channel will be utilized.
Archiving. Plans for how project communications will be documented and archived,
Document Number
174
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
including the retention of emails, messaging apps, meeting minutes, website content, and
other communication records, should be described.
Accessibility. Project Teams should ensure that they support accessibility standards for
publications, events, and information releases.
Good Practices and Practical Considerations
•
Awardees are recommended to put in place a stakeholder management plan that
provides for the identification, analysis, and periodic review of project stakeholders,
including an analysis of their needs and expectations.
•
The Project Team should strive for clear, transparent, and unambiguous
communications, both internal and external to the project.
•
The Project Team should avoid siloing and compartmentalization of information
within a project. Successful projects usually have systems in place to ensure vigorous
and clear flows of information internal to the project to prevent issues related to
siloing. Team members also should be encouraged to ask for project information, and
project leadership is encouraged to freely disseminate such information to the
maximum extent possible.
•
Project Teams are encouraged to create websites, social media, signage, etc., to
communicate project activities and outcomes to the general public during the course
of the project. Project Teams should acknowledge NSF support in all such
communications, publications, presentations, and press releases about the project
using the language provided in the project agreement.
3.5.9
PEP Component 9 – Project Closeout Plans
What Does This Component Describe?
This component describes the plans for closing out the project. Closeout is the last phase of
a project, when the Project Team verifies the completion of all scope contained in the Work
Breakdown Structure, completes all the necessary tasks to validate the technical
performance of the Research Infrastructure (RI), transitions all deliverables to
owners/operations, and shuts down the project. This component comprises three elements
that need to be considered when closing out a project: technical closeout activities,
administrative closeout activities, and programmatic/award closeout activities.
Why Is This Component Important?
The closeout process is an essential part of any project. It ensures that all deliverables have
been completed, key parameters have been met, major stakeholders are satisfied, and all
unused resources have been returned to the funding agencies as required. The closeout
process also provides an opportunity to evaluate the project’s success and identify areas for
improvement in future projects. By following a systematic and structured closeout process,
the Project Team can be assured that all work has been completely addressed and all project
objectives met.
Document Number
175
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
How To Develop and Write This Component
There are four subcomponents to be included in this component, as listed in Table 3.5.9-1
below. Project closeout planning starts early in the project Design Stage and is factored into
the baseline scope of work. Each specific closeout activity should be considered and
incorporated into the Integrated Master Schedule and included in the project budget as
necessary. The Project Team should review and iterate plans with key project stakeholders
(e.g., NSF and operations teams) early in the planning process to ensure all required activities
are identified, planned, and budgeted. The key is to minimize surprises and to manage all
stakeholders’ expectations early and effectively.
The closeout plans should match the project characteristics and needs and should be agreed
upon by the Project Team and funders. The plans should be tailored and scaled to the
individual type, size, complexity, and characteristics of the project. Further, the
subcomponents should be developed in a progressively elaborated approach, as described
in Section 3.2 Tailoring, Scaling, and Progressively Elaborating Plans.
Table 3.5.9-1
Project Closeout Plans Subcomponents, Products, and Documents with References to Further Material and Related
Topics
Component
Subcomponent
Documents/Products
9.1 Overview of Closeout
Plans
9. Project Closeout Plans
In accordance with the
award instrument used.
• Technical Closeout Plan
• Transition to Operations
Plan
• Lessons Learned
Document
In accordance with the
award instrument used.
9.3 Administrative Closeout • Administrative Closeout
Plan
Plans
In accordance with the
award instrument used.
9.2 Technical Closeout
Plans
9.4 Programmatic/ Award
Closeout Plans
Document Number
References
• Programmatic/Award
Closeout Plan
In accordance with the
award instrument used.
176
3.5 Construction Stage and Implementation Planning
3.5.9.1
Research Infrastructure Guide
PEP Subcomponent 9.1 – Overview of Closeout Plans
This subcomponent serves as an overview of the entire closeout component plans. It
provides a brief description of the overall closeout approach and processes. It describes the
high-level approaches for each of the three categories of closeout activities (technical,
administrative, and programmatic/award). Specific guidance and details for each of these
individual closeout categories should be covered in the three other subcomponents included
in this PEP component.
Good Practices and Practical Considerations
•
While closeout in this PEP guidance is described in terms of three distinct categories
of closeout (technical, administrative, programmatic/award), it’s important to
recognize that many closeout activities are typically performed simultaneously.
•
The process of closeout activities often begins well before the end of the project,
particularly with respect to performance testing and verification of compliance with
requirements.
•
A project closeout checklist or compliance matrix can be a valuable component of the
Technical Closeout Plan.
•
Ideally, the details, procedures, documentation, and criteria for closing the project
should be discussed and negotiated with NSF at the time of a received award.
3.5.9.2
PEP Subcomponent 9.2 – Technical Closeout Plans
This subcomponent describes the plans and approaches for the completion of all project
scope. The primary goal of the closeout plan is to demonstrate how the Project Team will
formally complete the project scope, verify compliance with requirements, prepare for, and
finalize transitions, and document all final project deliverables, ensuring that they have been
completed, meet their required quality acceptance criteria, and are ready for
delivery/transition. Note that final validation (NSF or other federal or international partners)
and formal acceptance of the project scope is not part of this subcomponent, that is, funder
approval and acceptance are included as part of the programmatic closeout plans below.
While every project is unique, these technical closeout considerations typically include:
•
Product Scope Completion and Verification Plans. Describe the plans for
completing, testing, verifying, documenting, and handing over all scope deliverables
that are included in the WBS. This may include activities such as plans for performing
final acceptance tests, writing quality control reports, capturing test results, creating
compliance matrices, processing requests for waivers against requirements, and
creating, capturing, and processing all required as-built drawings and specifications.
Specific procedures to accomplish the work for commissioning could be included as
an appendix or separate document. The verification work is a precursor to validation
and acceptance work described below.
•
Project Scope Completion Plans. Describe plans for completing and documenting
compliance with all other non-product-type project scope (e.g., services like project
Document Number
177
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
management, systems engineering, safety management, etc., or a result such as the
creation of a user group)
•
Transition to Operations Plan. Describe the plans for determining operational
readiness of the RI and completing the transition of the deliverables from
construction to operations. This may include elements such as conducting an
operational readiness review and/or operations demonstration. The plan should
address verification of deliverables such as the provision of operations and
maintenance manuals, staff training (if included in the proposal and authorized in the
award), and other appropriate elements such as transfer of title/ownership, as well
as operational readiness of the RI.
•
Project Lessons Learned Plans. A lessons learned document is often included as
part of the technical closeout deliverables of a project to improve a current or future
project. The plans for creating and delivering this document should be described
here.
•
Completion and Archival of Project Documentation. Describe the plans for
completing and filing/storing all relevant project documentation and
communications.
Good Practices and Practical Considerations
•
Commissioning verifies that the substantially complete facility operates over its full
range of intended capabilities as specified in Key Performance Parameters (KPP) and
science requirements. Once the commissioning planning is complete, an operations
readiness review may be held to examine and comment on the plan. This can be
conducted separately or as a component of one of the required project reviews.
•
Project Teams should plan to gather, assess, and incorporate lessons learned during
the entire course of the project, as well as analyzing and documenting those identified
at project closeout. Feedback from NSF (e.g., the Program Officer [PO]) at the closeout
should be included in the lessons learned document.
•
Completing and archiving all project documentation and communications is often an
overlooked project deliverable. It should be addressed in PEP Subcomponent 8.5 –
Documentation Management. Systematically and regularly, using a well-structured
and organized repository for key documentation during project execution will simplify
the effort necessary to archive documents at project closeout. Note that financial
records, supporting documents, statistical records, and all other records pertinent to
the NSF award must be retained by the Awardee as described in accordance with the
terms and conditions of the award.
3.5.9.3
PEP Subcomponent 9.3 – Administrative Closeout Plans
This subcomponent describes the plans and approaches that the Awardee institution will
use to complete the closeout of all institutional administrative activities. Depending upon the
characteristics of the project, this typically includes but is not limited to:
Document Number
178
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
•
Closeout of Project Contracts, Agreement Commitments, and Legal Obligations.
Describe plans for ensuring all project obligations, contractual agreements, and other
commitments are addressed and completed.
•
Financial Reconciliation and Return of Unexpended Balance. Describe plans for
reconciling all financial Control Accounts, including both budget and contingency.
Describe plans for the return of any unspent/unused monies.
•
Release or Transfer of Labor Resources. Describe plans for the release of project
staff at the end of the project and/or transfer to another assignment or role (e.g.,
Operations). This may include the application of existing HR plans and policies but
also may include project-specific plans and methods.
•
Return, Release, or Transfer of Non-Labor Resources. Describe plans for the
return, release, or transfer of non-labor resources (e.g., tools, equipment, computer
hardware/software, office space, etc.). Specific property management policies and
procedures should be addressed.
Good Practices and Practical Considerations
•
Awardees should liquidate all obligations incurred under their awards as specified in
accordance with the award instrument used (e.g., 120 days).
•
NSF does not allow Awardees to keep any unspent money at the end of an award.
•
Contractual obligations and commitments may not be considered fully complete until
lien releases and/or over waivers have been received from external entities like
contractors. The Project Team is encouraged to research and review specific
requirements necessary to ensure that no persistent obligations, liens, or other
commitments extend beyond the period of performance of the project.
•
Project obligations on some RI projects may include environmental and regulatory
commitments and requirements that should be formally completed, agreed to,
documented, and closed out with all relevant parties. Formal documentation in these
situations is critical to gather and include in the closeout documentation.
•
The end of a project usually requires the release or transfer of key project personnel
and staff from the project, and should be planned for in a professional, systematic,
and graceful manner. It’s also a good practice to celebrate success with the Project
Team and recognize their contributions and hard work before the disbursement of
these personnel.
3.5.9.4
PEP Subcomponent 9.4 – Programmatic/Award Closeout Plans
This subcomponent describes the processes and approaches for obtaining validation, i.e.,
the formal affirmation from NSF that all funded activities have been successfully completed
such that the award may be closed. At an appropriate time approaching or following
construction completion, NSF will typically conduct a Final Construction Review. This review
is intended to assess the extent to which the required scope was delivered in accordance
with the PEP and award terms and conditions. Depending upon the characteristics of the
Document Number
179
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
project, programmatic/award closeout usually includes but is not limited to:
•
Validation of Project Deliverables. Describe the process for working with NSF to
validate acceptance of the product scope delivery and formally acknowledge that all
deliverables are complete and available, with no further action required on the part
of the project.
•
Validation of Title/Ownership Transfer. Describe the process to validate readiness
to transfer title/ownership of deliverables to the appropriate entity and verify
completion of the transfer.
•
Validation of Transition to Operations. Describe the process to verify readiness for
operation and validate completion of the transition.
•
Final Report(s). Describe what Final Project Reports are required and will be
provided by the Project Team to NSF at the conclusion of the project. These typically
include but may not be limited to the Final Project Report and Project Outcomes
Report for the General Public.
•
Closeout Review. Describe the plans for conducting a close-out review (e.g., a Final
Construction Review) with NSF at the conclusion of the project.
•
Agreement of Project Completion. Describe the process for working with NSF to
obtain formal written recognition that all funded activities are completed, project
financials have been reconciled, and that the project award may be closed.
Good Practices and Practical Considerations
•
In addition to the Final Project Report and Project Outcomes Report for the General
Public, there may be other requirements contained in the original solicitation, the
award agreement terms and conditions, Federal Acquisition Requirements, and/or
Uniform Guidance (2 CFR 200 Uniform Administrative Requirements, Cost Principles,
and Audit Requirements for Federal Awards the Proposal and Award Policies and
Procedures Guide, and other oversight and requirements documents. The Project
Team may work with NSF to identify all such requirements and ensure they are
appropriately addressed.
•
It is good practice to create an award terms and conditions compliance matrix that
tracks and ensures all requirements have been met or achieved in order to facilitate
the NSF Closeout Review.
Document Number
180
3.5 Construction Stage and Implementation Planning
3.5.10
Research Infrastructure Guide
PEP Component 10 – Post Project Plans
What Does This Component Describe?
This component encompasses the conceptual post-project plans that describe the expected
activities and plans for deliverables after completion and addresses the feasibility and
reasonableness of those plans. Such post-project activities typically include those
undertaken during the operations and maintenance, and those adopted for the transition or
closeout of the facility operation during a Disposition Stage. These plans are generally
credible, high-level, conceptual estimates of the expected key activities, considerations, and
costs that define the characteristics of these future life cycle stages. Note that these
conceptual plans are not the same as the detailed operations Annual Work Plan (AWP)
described in Section 3.6 Operations Stage Planning or Section 3.7 Disposition Stage Planning.
NSF has separate proposal review and acceptance procedures for these life cycle stages. The
creation of the final detailed life cycle proposals and plans for operations and disposition is
the responsibility of the future life cycle operators/owners and is not the intention of these
conceptual plans.
Why Is This Component Important?
There are a number of reasons a PEP includes the consideration of post-project activities.
These include:
•
Ensuring the feasibility and reasonableness of proposed operations, maintenance,
and disposition programs and that the programs are not difficult or too expensive to
accomplish.
•
Ensuring that the operating plans take advantage of the RI capabilities and that access
to the scientific capabilities and outputs meet stakeholder expectations.
•
Alerting stakeholders, including NSF, to the expectations and assumptions that
determine the necessary level of future support and responsibilities for the
remainder of the RI lifetime.
•
Raising awareness of any special considerations, including environmental, handling
of human subjects’ data, or other regulatory requirements that may impact the
achievement of expectations and goals.
How To Develop and Write This Component
There are three subcomponents to be included in this component, as shown in Table 3.5.10-1
below.
The Post Project Plans should match the project characteristics and needs and should be
agreed upon by the participants and funders. The plans should be tailored and scaled to the
individual type, size, complexity, and characteristics of the project. Further, the
subcomponents are typically developed in a progressively elaborated approach, as
described in Section 3.2 Tailoring, Scaling, and Progressively Elaborating Plans.
Document Number
181
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
Table 3.5.10-1
Post Project Plans Subcomponents, Products, and Documents with References to Further Material and Related Topics
Component
Subcomponent
Documents/Products
References
10.1 Overview of Post
Project Plans
10. Post Project Plans
10.2 Concept of Operations • Concept of Operations
Plan
Plans
10.3 Concept of Disposition • Concept of Disposition
Plan
Plans
3.5.10.1 PEP Subcomponent 10.1 – Overview of Post Project Plans
This subcomponent serves as an overview of the two plans included in this component,
providing a brief, high-level description of each plan, and may describe how the plans will be
created and elaborated during planning and how and under what circumstances they will be
modified after the start of the project. Specific guidance and details for each of these
individual Post Project Plans are covered in the two remaining subcomponents below.
3.5.10.2 PEP Subcomponent 10.2 – Concept of Operations Plans
This subcomponent describes the Concept of Operations (ConOps) Plan, which contains
plans and expectations for the post project Operations Stage of the implementation and
Construction Stage. The ConOps Plan is created early in project planning and is a high-level,
conceptual view of expectations. The ConOps Plan is ideally matured by the time of award
and does not need to be revised or modified unless new understanding or issues regarding
key elements of operations and maintenance arise during project execution. The ConOps
Plan is not the same as the Operations Stage AWP (see Section 3.6 Operations Stage
Planning). The AWP is not the responsibility of the Project Team unless the entity executing
the construction or implementation project is also the operator, and NSF has approved AWP
as deliverables within the project scope. In that case, the AWP is treated as any other
deliverable in the WBS and follow the requirements in Section 3.6 Operations Stage Planning,
and it is not included in the ConOps Plan.
The ConOps Plan should:
•
Describe the framework of how the RI will be operated and maintained, who the initial
operator will be and for how long.
•
Describe who has access to the scientific capabilities of the RI and how the output will
be handled, distributed, or published such that operation plans satisfy stakeholder
expectations.
•
Give high-level estimates of the resources and budget needed for annual operations
and maintenance (space, utilities, staffing, services, material/supplies, etc.), with
analysis or justification for the Basis of Estimate [BOE] and reasonableness of
assumptions. To the extent possible, the estimates should align with expectations for
RI performance (e.g., expected uptime or reliability of subsystems).
Document Number
182
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
•
State the expected lifetime of the facility or operations after it becomes operational.
•
Include a listing of expected funding sources and contributors that will support
operations activities and how much support each is expected to give (including any
user’s fees).
•
A key part of a ConOps Plan for RI is a discussion of expected costs for future
upgrades to instrumentation, including cadence of major expenditures (e.g., next-gen
instruments).
•
Include a description of any transition activities and costs that are not the
responsibility of the implementation and Construction Stage (i.e., staff training, initial
start-up).
•
Describe any post project activities required to bring the facility to full science
capability after the transition to the Operations Stage.
Good Practices and Practical Considerations
•
If the plans for operations and maintenance include support and/or contributions
from the operating or other institutions, then letters of collaboration from those
institutions, stating the nature, duration, and level of support, are encouraged for
creating a credible BOE.
•
In some cases, particularly with distributed facility projects or when beneficial
occupancy is allowed in construction, the transition to Operations may be staggered,
with some deliverables moving to operations while others are still in the Construction
Stage. Thus, the availability of operations and project funding will overlap in time.
ConOps Plans should address how Operation responsibilities will be managed during
the staggered transfers and how costs will be managed following the segregation of
funding requirements covered in PEP Subcomponent 7.5 – Business and Financial
Control Plans.
•
For Major Facilities, the ConOps Plan, along with the Transition to Operations Plan
(see Section 3.5.9 PEP Component 9 – Project Closeout Plans) and Segregation of
Funding Plan (see Section 3.5.7.5 Subcomponent 7.5 – Business and Financial Control
Plans) are reviewed during Conceptual Design Review (CDR), Preliminary Design
Review (PDR), and Final Design Review (FDR). The plans are updated as needed during
the Construction Stage. The plans should be updated and provided to NSF for review
in a timely manner before commissioning activities commence.
•
ConOps Plans for Mid-scale RI projects are typically reviewed during the proposal and
award process as well as one year before commissioning or transitions to operations.
•
For Design Stage proposed projects, separate guidance for follow-on plans for
further design or implementation is described in the Design Execution Plan (DEP)
outlined in Section 3.4 Design Stage Planning.
Document Number
183
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
3.5.10.3 PEP Subcomponent 10.3 – Concept of Disposition Plans
This subcomponent describes the Concept of Disposition Plan, which provides a high-level
description of the expectations during the Disposition Stage, the last stage in the RI life cycle.
Disposition options may include the partial or complete transfer of a facility to another
entity’s operational and financial control, mothballing the facility so that operations can be
restarted at a later date, or decommissioning. Decommissioning may include complete
removal of the infrastructure and site restoration and remediation. The Concept of
Disposition Plan is created early in project planning and is a conceptual view of expectations
for divestment or disposition after NSF funding support is terminated. It typically reaches
maturity by the time of the implementation and Construction Stage award and does not
need to be revised or modified unless new understanding or issues regarding key elements
of disposition arise during project execution. Concept of Disposition Plans are not as detailed
or complete as the Facility Disposition Plan described in Section 3.7 Disposition Stage
Planning. Detailed Facility Disposition Plans are usually produced after a period of operations
to reflect circumstances that may change over time.
The Concept of Disposition Plan should:
•
Describe the liabilities, expectations, and plans for transfer of the RI to another
institution or entity, demolition and removal, site remediation, decontamination, and
so forth.
•
Provide a high-level estimate of financial liabilities and costs of disposition activities
at the end of its Operational life or end of NSF support. List assumptions used in
supporting the estimated costs.
•
Describe plans, costs, and assumptions for all potential pathways to Disposition if
more than one is likely.
•
Note any known regulations, laws, permitting, or other requirements that are
expected to be followed and/or adhered to during the Disposition Stage, including
any binding agreements entered into during the construction planning and
execution.
Good Practices and Practical Considerations
•
The Concept of Disposition Plan is a precursor to the Disposition Stage Facility
Disposition Plan and should not include full and specific details, plans, and
expectations for disposition; instead, it’s a high-level, top-down overview that
provides enough detail to ensure a broad but accurate understanding of the
requirements by all stakeholders.
•
For Major Facilities, the Concept of Disposition Plan is reviewed during CDR, PDR, and
FDR. The plans are updated and reviewed as needed during the Construction Stage.
•
The Concept of Disposition Plan for Mid-scale RI projects are typically reviewed during
the proposal and award process as well as one year before commissioning or
transitioning to operations.
•
An explanation of the impacts of site or equipment contamination on disposition
Document Number
184
3.5 Construction Stage and Implementation Planning
Research Infrastructure Guide
planning is essential for a full understanding of the costs and administrative burdens.
•
Awardees should be aware of any legal liabilities for site restoration, remediation or
other obligations that attend final asset disposition.
Document Number
185
3.6 Operations Stage Planning
3.6
Research Infrastructure Guide
OPERATIONS STAGE PLANNING
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Planning for the Science Support Program throughout the Operations Stage involves the
provision of deliverables that address the planning and execution of operations of the Major
Facility, including the Strategic Plan, the Facility Condition Assessment (FCA), and the Annual
Work Plan (AWP), see Figure 3.61. The Strategic Plan communicates the overall vision,
mission, and goals of the Science Support Program, with the other two components nested
within. The FCA evaluates the capital assets that require significant expenditure for periodic
replacement or refurbishment, which helps, in part, to inform upcoming AWP. The AWP
presents the annual goals, milestones, deliverables, and performance metrics and indicators
that are executed to meet the mission. The quarterly and annual reports outlined in Section
2.7 Major Facility Operations Stage complement the AWP by tracking performance against
the AWP throughout the period of performance.
Figure 3.6-1
Three Main Deliverables Necessary for Operations Stage Planning and Execution
3.6.1
Strategic Plan
The Strategic Plan, or another comparable document, serves as a guided roadmap for the
Awardee to communicate strategic goals, objectives, and activities to meet the mission of the
funded Science Support Program. The Strategic Plan may be revisited as necessary, at least
every five years, or at a cadence applicable for the period of performance in consultation
with an external advisory body when appropriate. It serves as a foundational framework
aligned with the objectives that enable the effective allocation of resources and program
evolution.
Strategic Plans apply to any given program or a portfolio of programs that looks at the longterm evolution of capabilities enabled by the infrastructure. The document may include a
mission statement, vision, or another high-level statement of the goals of the program that
may be informed, in part, by goals outlined in appropriate level strategic documentation
(such as National Academies of Sciences, Engineering, and Medicine, Decadal Surveys, etc.).
Further, it may present a roadmap of how the facility will support the advancement of the
research landscape and scientific discoveries, its contribution to workforce development,
and the development and fostering of partnerships and collaborations. Strategic goals
Document Number
186
3.6 Operations Stage Planning
Research Infrastructure Guide
should be selected based on priorities for the award period and tailored to the type, size,
complexity, and maturity of the Science Support Program. This document, along with the
Asset Management Plan (see Section 3.6.2 Facility Condition Assessment of a Major Facility),
serve as a base for the development of the AWP (see Section 3.6.3 Annual Work Plan).
3.6.2
Facility Condition Assessment of a Major Facility
An FCA evaluates capital assets requiring significant expenditures for periodic replacement
or refurbishment and having a lifetime longer than the usual five-year award cycle. An Asset
Management Plan, a strategic plan for dealing with these issues, accompanies the FCA and
informs NSF and the facility management of anticipated major and infrequent maintenance
expenses that cause a significant departure from the routine funding profile.
The Operations Stage for a Major Facility typically lasts 20-40 years. NSF expects that
upgrades, refurbishment, and renewals of various components will be necessary over time
in order to support the evolving scientific mission. The FCA assists with planning of these
activities, including replacing obsolete instruments, refurbishment, or renewal of structural
components, electrical and cooling systems or upgrading cyberinfrastructure (CI) and data
storage/distribution networks.
As part of periodic Operations Stage reviews, NSF will use the outputs from the FCA process
to evaluate the condition of each Major Facility to help inform long-term budgetary planning
(see Section 3.6.2.1 Facility Condition Assessment Components).
An FCA, or equivalent assessment as discussed with the cognizant Program Officer (PO),
must be conducted in accordance with the terms and conditions of the award. In general,
they are conducted every five years, starting in year-five after the initial operations award
and should encompass both critical support infrastructure and scientific components,
including risks and mitigations associated with resilience to natural hazards. An FCA may be
conducted more frequently based on risk and NSF’s oversight needs.
3.6.2.1
Facility Condition Assessment Components
The FCA process includes two main components:
•
FCA Report: A comprehensive evaluation of the condition of all capital assets
requiring significant expenditure for periodic replacement or refurbishment. Capital
assets include land, structures, equipment (including portable equipment such as
vehicles, ships, and aircraft) and intellectual property (including software) that have
an estimated useful life of two years or more, and/or exceeds the typical Operations
and Maintenance (O&M) award duration. 1
•
Asset Management Plan: Elaboration of the proposed strategy for addressing the
issues identified in the FCA Report specifying the corresponding timeline and
1 Modifications
and Supplemental Financial & Administrative Terms and Conditions for Major Multi-User Research
Facility Projects and Federally Funded Research and Development Centers May 20, 2024,
https://www.nsf.gov/bfa/dias/policy/cafatc/cafatc_modsandsup_mfandffrdc0524.pdf
Document Number
187
3.6 Operations Stage Planning
Research Infrastructure Guide
resources needed.
The FCA Report and Asset Management Plan informs NSF and the Facility Management Team
of anticipated major and infrequent maintenance expenses that may cause significant
departure from the routine funding profile and should, therefore, be addressed proactively
and sometimes separately.
The timely identification of needs, and subsequent planned renewal and modernization of
capital assets is essential to supporting the scientific mission. Well-maintained Major
Facilities have a positive impact on working conditions and reflect NSF’s commitment to the
scientific endeavor. Proper long-term maintenance can have measurable improvements in
operational performance criteria such as ensuring scientific excellence, improving uptime,
reliability, equipment availability, and downtime due to corrective maintenance. Renewals
will also result in facility wide energy efficiency improvements and carbon footprint
reduction, and associated reduction in annual operating costs.
Finally, a well-executed FCA process will contribute to the protection of the health and safety
of employees and of members of the public from hazards and to minimize danger to life and
property, including resilience to natural hazards.
The FCA Report and Asset Management Plan may be compiled using a priority ranking based
on risks that include personnel health and safety, operations sustainment, and
enhancement of the scientific mission.
3.6.2.2
Scope of the Facility Condition Assessment
In accordance with the terms and conditions of the award, and collaboration with the PO,
the FCA must include the federally owned/Awardee-titled property and capital assets
necessary to support the Major Facility’s mission under the award.
The FCA should use industry standard practices, as appropriate, but should be tailored to
the specialized technical nature of the Major Facility and cover both the supporting
infrastructure (i.e., substructure, shell, interiors, HVAC, electrical, plumbing, site, etc.) and, if
not addressed separately, the major scientific instrumentation. 1
The specific scope of the FCA and the timing of the submittal, including submittal of any
assessments conducted by other entities, will be determined in collaboration with the PO to
support agency oversight of the award.
3.6.2.3
Conducting Facility Condition Assessment
The steps to conduct an FCA are presented as follows:
List of Capital Assets: The Major Facility will provide a list of the capital assets to be included
in the FCA process. For most Major Facilities these can be separated in three main categories:
1 For example, ASTM standard E1557-09(2020)e1 Uniformat II Classification for Building Elements- classifying
building specifications, cost estimating, and cost analysis. https://www.astm.org/e1557-09r20e01.html
Document Number
188
3.6 Operations Stage Planning
Research Infrastructure Guide
•
Science Support Equipment and systems
•
Infrastructure (non-science equipment and systems; for example: specialized cranes
and safety equipment, specialized environmental conditioning, vacuum systems,
power conditioning, control, and communication systems).
•
Buildings and building systems, including grounds, roads, fences, flood control etc.
Once negotiated with the PO, the list of capital assets will serve as a baseline for the FCA
scope.
Establish Process to determine Asset Condition: The process to compile information for
the FCA Report and Asset Management Plan will be established by the awardee and agreed
by the PO. The process by which the Major Facility will conduct the FCA on the agreed list of
capital assets could include:
•
Gather information already available through regular inspection or monitoring
reports conducted by the host institutions and local, state, or federal entities.
•
Conduct on-site inspections and evaluations by qualified outside contractors.
•
Conduct on-site inspections and evaluations by the Major Facility maintenance team.
•
Have an independent entity evaluate the complete package of available information
before submittal to NSF for review.
The FCA Report should use industry-standard practices, where appropriate, to break down
the elements into major components common to most buildings and sites. Regardless of the
standard used, a systems approach should be employed that uses a hierarchical structure of
cost elements and assets.
The FCA Report and Asset Management Plan should provide documentation to include, but
are not limited to:
•
When the asset was put into service and estimated remaining useful life of the asset.
•
The estimated full replacement cost of the asset.
•
Current and projected maintenance requirements and effectiveness of past
maintenance performance.
•
A determination of requirements (i.e., an emergent scientific need or a deficient
condition that should be addressed), including deferred maintenance, code issues,
functional requirements, repair, partial replacement, full replacement, and/or capital
investment or further in-depth study, analysis, or specialized inspection.
•
A recommended action for each requirement, which is a remedy for the condition
that includes itemized cost estimates.
•
For each requirement, an asset-level estimation of annual asset repair or renewal or
replacement funding needs projecting over the expected life of the Major Facility, or
various components required to support the evolving scientific mission, and at a
minimum covering the next five, ten and 15-year intervals.
•
Estimate of energy efficiency improvements and associated reduction in annual
Document Number
189
3.6 Operations Stage Planning
Research Infrastructure Guide
operating costs and carbon footprint associated with renewal and modernization of
significant facility assets.
3.6.2.4
Creating the Asset Management Plan
The Asset Management Plan elaborates a strategy for addressing the issues identified in the
FCA Report by specifying the corresponding timeline and resources needed. The Awardee
can use data from the FCA Report for future maintenance management, capital planning,
and budgeting and report generation.
The steps to create an Asset Management Plan are as follows:
•
Analyze and Prioritize Requirements. The baseline FCA Report list assumes all
requirements are equally important and have equal weight, so further refinement is
needed to develop a meaningful plan. The items should be prioritized based on
urgency and the need to be completed within specific timescales (i.e., in one, two-tothree, and five years).
•
Weigh and Rank Requirements. With time priorities developed, refine a model that
weighs and ranks requirements to be adjusted in alignment with the scientific mission
of the Major Facility. Safety, impact on science mission, and sustainment of essential
operational activities should have the highest weightings.
•
Develop Project Strategy. The Facility Management Team will develop and mature
a strategy for addressing the ranked requirements, specifying the corresponding
timeline and resources needed. The strategy will be managed to de-conflict with
science mission and essential operations.
•
Identify Funding Needs. Identify the annual cost of executing the Asset
Management Plan projecting over the expected life of the Major Facility and, at a
minimum, covering the next five, ten, and 15-year intervals, based on rough-order-of
magnitude or feasibility level cost estimates.
•
Determine Deferred Maintenance. The Facility Management Team will keep an
updated list of deferred maintenance. These are considered FCA requirements that
still need to be projectized and scheduled.
The Asset Management Plan, along with the FCA Report and supporting maintenance
documents, will be reviewed as part of regular external panel reviews so that priorities can
be established, and potential funding avenues identified. The Program Office may choose to
have the documents peer-reviewed and vetted by maintenance professionals from other
Major Facilities.
Once agreed upon, the Asset Management Plan Work Breakdown Structure (WBS) elements
will be prioritized and progressively elaborated, and the planned refurbishment and
preventative maintenance projects will be incorporated into the AWP. As the Asset
Management Plan WBS elements are further detailed in the AWP, the estimated costs will
have a sound, fully justified, and documented, and sufficiently detailed Basis of Estimate
(BOE), if funded through the Operations Stage award (see Section 4.3 Cost Estimating and
Document Number
190
3.6 Operations Stage Planning
Research Infrastructure Guide
Analysis). The same level of detail will be provided if funded through a separate award.
3.6.3
Annual Work Plan
The AWP describes what the Science Support Program expects to accomplish in the
upcoming period of performance. The Science Support Program for operations planning
requires the annual submission of a forward-looking AWP (also known as a Program
Operating Plan) that details the O&M, education and outreach activities and deliverables, as
well as management activities necessary for a Science Support Program to fully perform to
its intended scope for the upcoming period of performance. It may include annual technical,
operational, managerial, and scientific goals, objectives, activities, milestones, performance
targets, assumptions, and risks pertinent to the successful operation of the Science Support
Program and its mission. The AWP may also incorporate activities with completion
milestones in response to annual reviews and include a detailed budget for the upcoming
period of performance.
The AWP serves as the baseline for assessing differences between planned and completed
activities, and management thereof, within each program, laying out metrics and/or
anticipated milestones and Key Performance Indicators (KPI), for the upcoming period of
performance. The AWP enables planning for, and management of known operational risks.
The AWP is typically submitted annually for review and approval by the PO in consultation
with the Core Integrated Project Team (see Section 2.1 NSF Staff Roles and Responsibilities
for Award Management and Oversight). Submission of an AWP that satisfies the
requirements articulated above, in part, informs NSF’s release of annual funding increments.
The AWP is distinct from quarterly and annual reports (see Section 2.7 Major Facility
Operations Stage) that are backward looking, and document progress against the AWP.
Overall, the AWP should, in totality, describe how the Awardee will comply with the terms
and conditions of the award, as well as describe their plans for the upcoming period of
performance.
3.6.3.1
Assumptions
The AWP should be aligned with the strategic operations documents such as the Strategic
Plan or the Concept of Operations Plan if transitioning from the Construction Stage. It should
be developed in communication and consultation with the PO. The following section
provides an overview of typical components that may be included in the plan and should be
used as a guideline for structure and content. It is not intended to be prescriptive.
When writing the AWP, the Awardee should ensure that it is tailored and scaled specifically
to the type, maturity, and complexity of the Science Support Program, and progressively
elaborated as the program matures (see Section 3.2 Tailoring, Scaling, and Progressively
Elaborating Plans).
The period of performance may align with the government FY, the managing organization’s
FY, or some other time frame, depending on when the award was initiated. The priorities
Document Number
191
3.6 Operations Stage Planning
Research Infrastructure Guide
and initiatives should facilitate the delivery of the intended scope and align with the longterm Strategic Plan.
3.6.3.2
Components of an Annual Work Plan
The specific components of an AWP will be determined by the PO in consultation with the
Awardee. Recommended components of the AWP are as follows with detailed guidance on
each given below. The applicability of the sections outlined in the AWP should be tailored
and scaled to the needs of the award's type, size, complexity, and maturity, particularly as it
relates to smaller-scale awards. The PO may also use the AWP outline to inform the most
appropriate approach for award oversight.
1. Overview
2. Program Management
3. Risk Management
4. Management Support Services
5. Science and Science Support
6. Cyberinfrastructure and Information Assurance
7. User Support: Community Education, Outreach, and Engagement
8. Proposed Budget and Financial Details
9. Performance Evaluation and Measurement
10. Operations and Maintenance Plan
Depending on the scope, size, complexity, and maturity of the Science Support Program, not
all the components may be appropriate for all Operations Stage programs. The Awardee is
encouraged to discuss specific requirements with their PO. Required sections will be
specified in the funding announcement and subsequent award terms and conditions.
Whenever possible, metrics or performance indicators to measure progress through the
period of performance should be specified.
The AWP, informed by the Strategic Plan, should likely not change significantly from year to
year other than providing updates as they relate to certain O&M requirements to maintain
an operational program. For example, it may include:
•
Work required to support and conduct research and educational activities.
•
Data to demonstrate the facility is operating efficiently and cost-effectively.
•
Small- and intermediate-scale technical enhancements when needed to maintain
state-of-the-art research capabilities that reflect the continued relevance to the
community of users.
This document is not intended to be onerous but to provide guidance and accountability for
the RI investment.
Document Number
192
3.6 Operations Stage Planning
Research Infrastructure Guide
1 – Overview
The Overview (or Executive Summary) provides an outline of the intended program
outcomes for the upcoming period of performance and the planned objectives and
associated activities to support them. These outcomes, objectives, and activities may be
directly informed by the long-term Strategic Plan (see Section 3.6.1 Strategic Plan). Significant
challenges, risks, and opportunities may be highlighted. Changes to organizational structure
and major budget issues may also be summarized.
The goals and metrics will vary among programs and will be agreed upon between the
Awardee and the PO. The PO will review the AWP goals to ensure they are aligned with the
long-term scientific objectives of the program and meet the terms and conditions of the
award. The annual goals of the Science Support Program should be outlined as they relate
to the delivery of the intended scope, and presented as Specific, Measurable, Attainable,
Relevant, Traceable, Tiered, and Total (SMARTTT) when possible. Milestones used to reach
that goal and help manage the work, where possible, should be credible, visible, and have
an accountability threshold.
2 – Program Management
Facility management concerns the management of scope, schedule, and cost of the Science
Support Program’s O&M. The AWP addresses management approaches to the following subcomponents.
Management & Organizational Structure. Defining operations management and
illustrating the organizational structure of the Science Support Program is an essential
component of any AWP. This subcomponent may provide a brief description of the
leadership and management team and highlight program management practices and overall
oversight of operations. If appropriate, the methodology associated with allocation of staff
in a matrixed structure where staff effort is shared across programs, should be described.
Existing and new tools, processes, and procedures as well as changes and improvements the
Awardee plans to implement in the upcoming period of performance may also be outlined.
•
Infrastructure and Human Capital. A high-level overview of the primary physical
infrastructure and human capital that enables the provision of science services to the
community should be outlined and associated with the WBS. This sub-component
includes milestones and anticipated outcomes regarding human capital management
and physical infrastructure maintenance; however, an Integrated Master Schedule
approach is not required. Operations management impacts on program budgets and
delivery of science services, if any, should be specified.
•
Human Capital and Workforce Development. This section should highlight current
and future workforce related needs of staff managing and operating RI, to enable
completion of the funded activities, including efforts to develop the research and
technical workforce. It should also articulate how the management team meets
Section 5.7 Personnel and Competencies.
•
Physical Infrastructure. This section should highlight the planned maintenance and
upgrades for the upcoming period of performance of the primary physical
Document Number
193
3.6 Operations Stage Planning
Research Infrastructure Guide
infrastructure (including facilities, RI, etc.), to support the funded activities of the
Science Support Program.
Planned Procurements. Any major planned procurements should be noted in the AWP and
be reflected within the WBS and budget line. It may be appropriate to include this section as
an appendix. The Awardee may execute subcontracts and subawards in the upcoming
period of performance that are above NSF approval thresholds given in the terms and
conditions of the award.
3 – Risk Management
NSF expects Awardees to engage in routine risk assessment and management throughout
the duration of the award to enhance program success by decreasing the likelihood of
threats and increasing the probability of opportunities. The Awardee’s approach to risk
management should be summarized in the AWP, with top risks reported annually and, in
some cases, quarterly (see Section 2.7 Major Facility Operations Stage) as determined by the
PO and required per the terms and conditions of the award. This description may be
presented as a formal Risk Management Plan, developed in consultation with the PO, and
should be tailored and scaled according to the nature and complexity of the RI (see Section
4.6 Risk Management).
Risk management entails developing a reliable course of action to address known events
that are likely to impact operations. Such planning is intended for responding to risks by
reducing the negative impact of threats and increasing realization of opportunities during
operations. Risk response planning entails selecting and applying appropriate methods that
minimize the threat’s likelihood and/or impact or maximize the opportunity’s likelihood
and/or favorable impact. After a risk has been realized, it becomes an issue and requires a
different set of response plans to deal with the event. Issues are handled differently in the
Operations Stage (see Section 4.6 Risk Management). Operations Stage awards generally use
the following mechanisms to address the impacts of realized risks in the following order:
•
Routine risk impacts are included in the BOE as part of the most likely cost.
•
Re-budgeting authority is used by the Awardee per the award terms and conditions.
•
The Awardee reduces the level of science support effort (with NSF approval if
significant).
•
The Awardee requests supplemental funding; assuming proper justification,
availability of funds, and recommendation by the PO.
•
The Awardee requests contingency funding; assuming proper justification, availability
of funds, and recommendation by the PO and Awarding Official (AO).
A budget contingency separate from construction or implementation may be proposed for
Operations Stage awards to handle identified risks documented in the Risk Register, in
aggregate for either the entire award or components of the award by WBS. For example, a
separate contingency budget may be advantageous if the AWP includes a significant upgrade
that should be managed as a separate sub-project. That said, proposing budget contingency
carries additional management and oversight responsibilities for the Awardee and NSF,
Document Number
194
3.6 Operations Stage Planning
Research Infrastructure Guide
respectively. Any request must utilize a formal risk management approach that is tied to a
Risk Register and the WBS (see Section 4.7 Contingency Estimating and Management). If
funded, and based on the type, size, complexity, and maturity of the program, thresholds for
NSF approval on contingency use and periodic reporting may be given in the terms and
conditions of the award including reporting actual costs against the draws on contingency
by WBS. Award of budget contingency is subject to NSF approval. Given the additional
requirements with developing and managing budget contingency, other mechanisms listed
above may be sufficient to manage the impacts of known operational risks.
Funding and use of budget contingency should align with the award instrument used. In
addition, since contingency has a specific meaning under the Uniform Guidance and the
Federal Acquisition Regulation, and management reserve cannot be held by the Awardee
under financial assistance awards, these terms must not be used by the Awardee in the
BOE.
4 – Management Support Services
Performance Management. In consultation with the PO, performance management
activities planned to take place in the upcoming period of performance, including
performance metrics, should be outlined. Processes in place to verify and validate systems
requirements for the Science Support Program operations, including data product and
service delivery to the user community, may be highlighted. These activities should be
tailored and scaled to reflect the type, size, complexity, and maturity of the Science Support
Program.
Asset Management. To preserve the long-term operational integrity of a Science Support
Program, the Awardee should outline activities to be performed in the upcoming period of
performance for tracking, maintaining, and maximizing the value of the Science Support
Program’s physical assets including preventative and predictive maintenance and
technology refreshes (see Section 3.6.3 Facility Condition Assessment of a Major Facility).
Shared Business Services. Where applicable, the Awardee should describe any key
administrative needs and services that are shared across multiple organizations, whether
funded by NSF or other sources, which may be needed to complete the scope for the
upcoming period of performance.
Environment, Safety, and Health. The Awardee should describe the execution,
management, and compliance verification activities to ensure facilitation of Environmental,
Safety, and Health in support of research. Based on the award type, size, complexity, and
maturity, the Awardee may detail how they will comply with the award requirements for the
upcoming period of performance as specified in the terms and conditions.
5 – Science and Science Support
Scientific Research. For Science Support Programs that have an embedded program that
directly supports scientific research, for example if investigators at the facility undertake
research activities using the RI that are funded through O&M, anticipated scientific highlights
for the period of performance should be summarized, as appropriate. If Awardees scientific
Document Number
195
3.6 Operations Stage Planning
Research Infrastructure Guide
activities are supported by O&M funds, the processes used for review, selection, and
prioritization of proposed activities should be described. Accordingly, the metrics and
milestones being used to assess the scientific impact, i.e., KPI, of the Science Support
Program described should be presented and used to track progress. Additional specific
requirements that may be in place for the award should also be presented.
Science Services. Science support activities facilitate the collection and delivery of highquality data and samples through the provision of services and support to science,
engineering, and CI processes. Include activities implemented to meet the intended science
services that will be delivered to the community in the upcoming period of performance.
These could be detailed in the Asset Management Plan.
Research Support Services. Research support services facilitate the accessibility, usability,
and interoperability of data and infrastructure delivered and provided by the Science
Support Program. Any support services that will be available to the community in the
upcoming period of performance, such as assignable asset or research support services
programs, research coordination, instrumentation loans, etc. (if applicable and not described
elsewhere in the AWP), should be briefly outlined.
6 – Cyberinfrastructure and Information Assurance
CI and Information Assurance (IA) are central components of most Science Support
Programs. The Awardee may discuss any operations activities, and updates and changes to
CI and IA that will be implemented in the upcoming period of performance to meet the
scientific data management needs and maximize the production, delivery, accessibility, and
usability of the Science Support Program infrastructure and data products and, ultimately,
the scientific impact.
Performance metrics for data quality and delivery (such as completeness, conformity,
validity, and integrity) should be outlined to inform O&M needs and outreach strategies and
can be used to monitor the level-of-effort required to deliver data product delivery and
supporting CI, at the discretion of the PO.
Cyberinfrastructure Management. Independent of the AWP, the Awardee must maintain
a current and comprehensive CI plan, outlining the strategy and approach for CI
management (see Section 5.2 Cyberinfrastructure). The AWP should articulate objectives and
activities outlined in the plan that will be implemented in the upcoming period of
performance. Data are vital to the missions of many Science Support Programs, and the CI
Plan should refer as appropriate to the project's relevant documents addressing data-related
requirements, design, and performance metrics. Relevant CI-related risks and issues should
be carried forward from the Construction Stage and managed in the operations Risk Register
per the Risk Management Plan, if applicable. If the Mid-scale RI is an upgrade to a Major
Facility, it can leverage the Major Facility’s CI Plan.
Information Assurance. Maintenance and development of IA objectives and activities to be
implemented in the upcoming period of performance should be articulated in the AWP,
including risks and issues to continue into operations from construction. Independent of the
Document Number
196
3.6 Operations Stage Planning
Research Infrastructure Guide
AWP, the Awardee must maintain a current and comprehensive plan for IA management,
the Information Assurance Management Plan (IAMP), which should be summarized in the
AWP – with updates to practices and procedures highlighted in the AWP (see Section 5.3
Information Assurance). If the Mid-scale RI is an upgrade to a Major Facility, it can leverage
the Major Facility’s IAMP.
7 – Community Education, Outreach, and Engagement
Community engagement, education, and outreach activities are designed to empower and
value the community’s role in using and understanding data products. The Awardee should
describe new objectives and activities to be implemented in the upcoming period of
performance related to how they may monitor the community’s scientific publications and
users of the RI’s data and infrastructure, the scientific productivity of the observatory, and
the degree of community outreach, to ensure that data use is equitable across the user
community. Performance metrics of the user support activities should be included, where
applicable, and reflect the type, size, complexity, and maturity of the program. Performance
metrics should include a record of facility use for research and education, including the
name, affiliation, funding agency, award number, and annual award amount for each user.
This description may be presented as a formal Community Engagement, Education, and
Outreach Plan, developed in consultation with the PO, and should be tailored and scaled
according to the nature and complexity of the RI.
Education. The Awardee, where applicable, should describe ongoing and new educational
objectives and activities aimed at the community and to be conducted during the upcoming
period of performance, with performance metrics clearly articulated.
Outreach. Similarly, outreach activities with the scientific user community and the general
public to be implemented in the upcoming performance period should be articulated along
with the associated performance metrics. These initiatives and activities should include
enhancing the usability of the data being collected, democratizing the science being served,
increasing the user base.
Engagement. Additional engagement activities in the form of collaborations and
partnerships, and long-term efforts to build sustainable relationships with the scientific and
community at large should be highlighted along with the associated performance metrics.
Broadening participation. Awardees should demonstrate prior experience and current
capabilities in an effort to employ the best practices in broadening participation in science
and engineering. Highlight objectives and activities that comply with award terms and
conditions and demonstrate capabilities for broadening participation in the upcoming
period of performance should be presented.
8 – Proposed Budget and Financial Details
The Awardee should present the budget in a WBS format that is tailored and scaled to the
type, size, complexity, and maturity of the Science Support Program to aid in NSF’s evaluation
of the proposed budget, monitor progress, and facilitate discussions with NSF on
rebudgeting, if needed. The number of levels in the WBS depends on a program’s complexity
Document Number
197
3.6 Operations Stage Planning
Research Infrastructure Guide
and risk. The WBS needs to be expanded to a level of detail sufficient for planning and
successfully managing all the proposed activities as negotiated with the PO, in consultation
with the NSF IPT and in alignment with the terms and conditions of the award.
The AWP should include the approved budget amounts by WBS as required by the award
instrument and in a budget format to facilitate obligation of funds. Any shared costs or
matrixed services should be articulated, and indirect cost rates should be summarized,
noting how these apply to program budgets. Any forecast for the carry-forward (residual
funds) from the previous year must be clearly presented for ongoing operations to support
discussions between NSF and the Awardee. A summary of how the carry-forward funds will
be utilized must also be included in the AWP, as applicable (see Section 4.3 Cost Estimating
and Analysis).
9 – Performance Evaluation and Measurement
The Awardee must have a process for evaluating and tracking their performance in
delivering on program and scientific goals and objectives and in supporting and meeting the
user community needs. The performance metrics outlined in the AWP should link to the
goals outlined in the Strategic Plan and a Performance Evaluation and Measurement Plan,
as appropriate, to inform the Science Support Program’s forward-looking and retrospective
annual reporting. While objectives and activities for the upcoming period of performance are
not likely to change significantly from year to year, any proposed new approaches, initiatives,
and efficiencies should be captured in the performance evaluation and measurement
activities highlighted in the AWP to reflect the evolution of the Science Support Program.
Where applicable, updates to the performance evaluation and measurement activities
should be captured annually in the annual progress report and be reviewed in conjunction
with the AWP for the upcoming award year.
KPI and metrics should be clearly described in the performance evaluation and
measurement activities and used to track progress in annual (and, if appropriate, quarterly)
reports and reflect the intended goals and objectives of the Science Support Program. The
metrics should be quantifiable (SMARTTT) whenever possible so the Awardee can track
progress (such as operating time, and scheduled and unscheduled downtime, etc.). Current
performance should be compared to the previous year’s performance and, where applicable,
historical performance, including historical record of costs related to maintenance
(preventive, deferred, repairs, and/or emergency). All aspects of management and
operations, scientific output, education, outreach, and workforce development efforts will
be included where appropriate. This description may be presented as a formal Performance
Evaluation and Measurement Plan, developed in consultation with the PO, and should be
tailored and scaled according to the nature and complexity of the RI.
10 – Operations and Maintenance
The O&M component of the AWP formally describes in-depth strategies and approaches
used to operate and maintain the Science Support Program and ensure it delivers its
intended scope. Typically, the plan includes the program's day-to-day operations, as well as
Document Number
198
3.6 Operations Stage Planning
Research Infrastructure Guide
planning, managing, and executing operations, maintenance, change management, and
improvement needs. While the AWP is likely to remain mostly the same from year to year, it
details the primary management components responsible for delivering the program
activities funded under the award. The O&M description should be included as part of the
AWP, even for awards with less complexity. This description may be presented as a formal
Operations and Maintenance Plan, developed in consultation with the PO, and should be
tailored and scaled according to the nature and complexity of the RI. The FCA Report and the
Asset Management Plan (see Section 3.6.2 Facility Condition Assessment of a Major Facility),
based on the periodic FCA, may be included or referenced here.
Document Number
199
3.7 Disposition Stage Planning
3.7
Research Infrastructure Guide
DISPOSITION STAGE PLANNING
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
During the Operations Stage, NSF may recommend that a facility enter the Disposition Stage,
which may involve divesting or transitioning Research Infrastructure (RI) or the non-renewal
of the award (see Section 2.8 Major Facility Disposition Stage). Once a decision for disposition
is made regarding the transition or closeout of the facility operation under an NSF award,
the current operations management should start the preparation for the divestment. This
preparation involves consulting stakeholders and the Program Office to appoint appropriate
personnel or a management team responsible for overseeing the transition activities. The
Awardee must develop and submit a Disposition Plan to the NSF Program Officer (PO).
The current operations management should be involved and integral to the Disposition
Plan’s development to ensure a smooth and successful transition. Below is an overview of
the key components of a Disposition Plan. Project Teams should tailor and scale the
Disposition Plan to meet the needs and nature of the disposition (see Section 3.2 Tailoring,
Scaling, and Progressively Elaborating Plans).
•
Overview. The overview of the Disposition Plan should identify the RI slated for
disposition. The goal of the transition should be clearly defined, whether it involves
establishing a new operation model under a different funding mechanism or
decommissioning the facility. If transitioning to a new operation model, the
Disposition Plan should describe the model, NSF's role, and the associated costs. A
detailed handover procedure should also be included in the new management
organization. For dispositions involving decommissioning, the Disposition Plan
should outline the procedures and costs for proper equipment disposal and site
remediation.
•
Scope. The scope of the Disposition Plan should define the transition requirements,
including engineering aspects and estimated costs (see Section 4.3 Cost Estimating
and Analysis). The Disposition Plan should provide a comprehensive cost estimate for
the transition, covering labor and material costs. The target date for completing the
transition should be clearly indicated. If applicable, the Disposition Plan should also
detail the procedures for properly disposing of equipment.
•
Roles and Responsibilities. Partner organizations involved in managing the
transition activities at each stage should be clearly described. Each organization's
roles, responsibilities, and authority levels should be explicitly defined. It is essential
to identify the individuals or management team responsible for overseeing the
disposition activities and detailing their specific responsibilities. Additionally,
consulting with stakeholders and the NSF Program Office is necessary to appoint the
appropriate personnel to manage these activities effectively.
•
Risk Management. A detailed description of the risk management strategy and its
execution during the Disposition Stage should be included (see Section 4.6 Risk
Management). Identifying and documenting potential risks associated with the
Document Number
200
3.7 Disposition Stage Planning
Research Infrastructure Guide
divestment transition is crucial. Additionally, it is essential to continuously monitor
and update risks in the Risk Register and report these updates to NSF as determined
by the cognizant PO.
•
Contracts and Award Management. Describe the plan for resolving and closing
contracts and sub-awards, including the review process for all existing contracts and
sub-awards to identify terms, obligations, and termination clauses. Contractors and
service providers should be notified about the disposition and potential contract and
sub-award termination, with sufficient notice given to avoid penalties. Detailed
records of all contract and sub-award terminations must be maintained, and
contracts archived for future reference in accordance with the award terms and
conditions and Awardee internal policies. Funders, including the NSF Program Office,
should be kept informed about the status of contract and sub award terminations,
with regular updates and a final report provided. This systematic and legally
compliant approach ensures smooth contract resolution and should be included in
the Disposition Plan submitted to the NSF Program Office for review and approval.
•
Environmental Impact Analysis. A comprehensive plan for evaluating and
mitigating the environmental impact of the proposed transition activities should be
addressed. It is essential to identify and consider all potential environmental impacts
resulting from these activities. Additionally, the plan must determine the appropriate
level of environmental review in accordance with the National Environmental Policy
Act. 1
•
Pension and Healthcare Responsibilities. A detailed description of how pension
and healthcare obligations post-divestment will be managed and funded should be
included.
A comprehensive, well-documented Disposition Plan must be created to ensure
transparency, accountability, and the successful execution of the RI disposition process. The
Awardee should submit the Disposition Plan to the cognizant NSF Program Office for review
and approval, ensuring alignment with NSF policies and guidelines.
42 U.S.C. § 4332. NSF regulations governing compliance with NEPA are found at 45 CFR § 640. NSF regulations
supplement the Council on Environmental Quality’s regulations, published at 40 CFR §§ 1500-1508.
1
Document Number
201
4.1 Introduction
Research Infrastructure Guide
4.0
FUNDAMENTAL ELEMENTS OF PROJECT
MANAGEMENT
4.1
INTRODUCTION
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
This chapter offers in-depth insights into key project management components that
Awardees should integrate during the Design and Construction Stages of Major and for
design and implementation activities for Mid-scale RI. These elements are essential for
upholding the principles set forth by NSF, facilitating effective planning, execution, and
project completion. Unless otherwise noted in the funding announcement or the award
terms and conditions, these principles should be used during the other life cycle stages only
to the extent that project management principles would benefit the activities funded under
the award.
4.2 Scope and Work Breakdown Structure. Defines project goals, deliverables, tasks,
costs, and deadlines. Breaks down the project into manageable sections, facilitating
detailed cost estimation, scheduling, and risk management
4.3 Cost Estimating and Analysis. Predicts financial resources needed for the project,
covering all potential costs such as materials, labor, contingencies, and fees. Analysis
ensures realistic budgeting, effective resource allocation, and financial planning,
maintaining project viability and adherence to budget.
4.4 Schedule Development, Estimating, and Analysis. Develops a detailed timeline
outlining activities, milestones, and deliverables. Guidance to ensure tasks are completed
in an organized manner by understanding task sequences, durations, and dependencies.
4.5 Monitoring Progress Against Plan. Continuously monitors project progress against
the initial plan. Uses key performance indicators and milestones to identify deviations
and implement corrective actions, ensuring alignment with scope, schedule, and budget
4.6 Risk Management. Proactively identifies, analyzes, monitors, and reports potential
risks throughout the project life cycle. It begins early and addresses uncertainties that
could impact project success.
4.7 Contingency Estimating and Management. Includes estimating and setting aside
resources to handle unforeseen events or challenges. Provides flexibility for the project
to adapt and proceed despite disruptions, minimizing delays and cost overruns.
Document Number
202
4.2 Scope and Work Breakdown Structure
4.2
Research Infrastructure Guide
SCOPE AND WORK BREAKDOWN STRUCTURE
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Scope refers to the detailed description of a project's deliverables, objectives, boundaries,
and requirements. It outlines what needs to be accomplished, the work that will be
performed, and the specific outcomes or products the project will deliver. The scope defines
the parameters and constraints within which the project will be executed and provides a
clear understanding of what is included and excluded from the project.
The Work Breakdown Structure (WBS) is a hierarchical decomposition of the project scope
into smaller, more manageable components called work packages. It organizes project work
into a structured framework of components and deliverables, providing a systematic and
visual representation of its scope and objectives. The WBS serves as a foundational tool for
project planning, scheduling, resource allocation, budgeting, and control, enabling the
Project Team to manage and execute project work effectively.
For Major Facility and Mid-scale RI projects, a Scope Management Plan and Change Control
Plan should be included as part of the Project Execution Plan (PEP) to formally control scope
(see Section 3.5.3.2 PEP Subcomponent 3.2 – Scope, Section 3.5.7 PEP Component 7 – Project
Controls Plans, Section 4.7.2.3 Scope Contingency, and Section 4.7.3.1 Contingency
Management Controls).
For projects in Design or Construction Stages, the WBS is a deliverables-based and
hierarchical framework structure that provides specific, manageable, and schedulable work
packages and may be composed of products, materials, equipment, services, data, and
support facilities that the project should yield. See Table 4.2-1 for a WBS example of a project
in the Design or Construction Stages. Level-of-Effort (LOE) tasks may be confined to only
those tasks that are not easily definable as deliverables for better tracking of spending
against budget and tracking of accomplishments against the plan.
Depending on the type of work, an operational WBS may be functional, activity, and/or
deliverables based. See Table 4.2-2 and Table 4.2-3 for Operations WBS examples.
The WBS provides a consistent framework for planning, estimating costs, developing
schedules, identifying resources, and determining where risks may occur. The WBS is a
valuable communication tool and provides the means for measuring program status, e.g.,
via using Earned Value Management (EVM) for construction. WBS are developed at varying
levels of detail but should typically include at least three levels. The number of
decomposition levels varies depending on the project’s size and complexity, technical
maturity, organizational constraints, acquisition and construction strategies, and
management’s assessment of need.
A WBS Dictionary is a companion document to the WBS that provides detailed information
about each work package or component of the WBS. It serves as a reference guide for
understanding the scope, requirements, and responsibilities associated with each element
of the WBS. The WBS Dictionary can include as much, or as little, descriptive information as
Document Number
203
4.2 Scope and Work Breakdown Structure
Research Infrastructure Guide
required to fully and correctly plan and execute the project. It can also include requirements,
exclusions, associated key schedule milestones and risks, and should name the person
accountable for each element.
Guidance and examples of common WBS elements can be adapted from the Government
Accountability Office (GAO) and other guidance and tailored for NSF projects, as depicted in
Table 4.2-1 and Table 4.2-2. The intent of providing these typical WBS elements is to provide
a standard format that is feasible to the vast array of different facility types while noting that
additions and/or alterations to this list are likely due to the unique nature of each specific RI.
The benefits of developing similar WBS across the portfolio of RI within an organization
include:
•
Consistent, clear, and familiar reporting structures and organizational relationships.
•
Improved efficiency and effectiveness of NSF cost analyses.
•
Better characterization of project scope, schedule, and cost.
•
Ease of judging completeness and reasonableness.
•
Enhanced collection and sharing of data and analysis methods across multiple
contractors and projects to support future cost estimates.
•
Better cost tracking over time and identification of major cost drivers and systemic
problems across contractors and projects.
•
Facilitate sharing of approaches, data, and best practices between Awardees and NSF.
Good Practices and Practical Considerations
•
Deliverables-based WBS elements should be nouns, not verbs.
•
Each high-level WBS must include 100% of the scope in the lower-level elements, and
each element of scope should appear only once in the WBS.
•
Generally, the number of levels employed should be sufficient to identify and
measure progress towards achieving deliverables, assign responsibility, and enable
effective management and reporting.
•
The WBS Dictionary can also be used to define the boundaries of the work and what
is excluded from the scope.
While all WBS aim to organize and structure tasks within a project or operation, they differ
significantly in their focus, structure, and application.
Construction Deliverables-based WBS: This type of WBS centers on achieving specific
deliverables or outputs within a construction project. It breaks down the project into a
hierarchy of deliverables, sub-deliverables, and work packages. This approach is beneficial
for construction projects where the focus is on tangible outcomes and specific deliverables,
see Table 4.2-1.
Document Number
204
4.2 Scope and Work Breakdown Structure
Research Infrastructure Guide
Table 4.2-1
Example Format of a Construction Stage or Implementation Deliverables-based WBS
Deliverables-based WBS for the Construction Stage or Implementation
1.0 Project Administration and Management Office
1.1 Project Management Office
1.2 Site Office
1.3 Science Office
1.4 Education and Public Outreach
1.5 Safety and Environmental Assurance
2.0 Facility Infrastructure and Civil Construction
2.1 Sub-element X
2.2 Sub-element Y
2.3 Sub-element Z
3.0 Scientific Equipment and Instrumentation
3.1 Subcomponent X
3.2 Subcomponent Y
3.3 Subcomponent Z
4.0 Cyberinfrastructure and Information Assurance
4.1 Data Infrastructure
4.2 Data Products
5.0 Systems Integration, Testing, and Commissioning
5.1 Common Utilities and Support Equipment
5.2 Early System Assembly, Integration, and Testing
5.3 Acceptance Testing
5.4 Training
5.5 Science Verification
Operations Functional-based WBS: Emphasizes major functions or activities required to
sustain operations, focusing on the work that needs to be performed, rather than the end
products or deliverables. This type of WBS breaks down each function into smaller subfunctions or tasks, creating a hierarchical structure while clearly understanding the overall
scope of work, see Table 4.2-2.
Document Number
205
4.2 Scope and Work Breakdown Structure
Research Infrastructure Guide
Table 4.2-2
Example Format of an Operations Functional-based WBS
Functional-based WBS for the Operations Stage
1.0 Project Director, Management, Administration Office
1.1 Director’s Office
1.2 Project Management Office
1.3 Site Office
1.4 Education and Public Outreach
1.5 Safety and Environmental Assurance
1.6 Administrative Services
2.0 Science Operations
2.1 Research Planning
2.2 Experimental and Operations Support
2.3 Data Analysis
2.4 Calibrations and Data Quality
2.5 Special Projects
3.0 Significant/Important Infrastructure Modernization, Overhaul, Upgrade, Replacement, Expansion
3.1 Equipment
3.2 Facilities/Infrastructure
3.3 Computer Systems, Instrumentation
3.4 Information Technology, Communications, Information Assurance
4.0 Facility and Equipment Operations, Maintenance, Engineering, and Support Services
4.1 Operations
4.1.1 Scheduling
4.1.2 Operating
4.1.3 Testing
4.2 Maintenance
4.2.1 Corrective Maintenance
4.2.2 Preventative Maintenance
4.3 Utilities
4.3.1 Energy (e.g., electricity, natural gas, central heating, central cooling)
4.3.2 Security
4.3.3 Water
4.4 Other/General Support Services
5.0 Contingency (if justified and supported by appropriate risk analysis and management)
Document Number
206
4.2 Scope and Work Breakdown Structure
Research Infrastructure Guide
Operations Activity-based WBS: This type of WBS details the specific tasks and activities
needed to sustain operations, focusing on the sequence and interdependencies of activities
rather than the deliverable. It breaks down the project into a hierarchy of activities, subactivities, and tasks and is particularly useful for projects where the sequence and execution
of activities are critical to the project or program's success, see Table 4.2-3.
Table 4.2-3
Example Format of an Activity-based Operations WBS
Activity-based WBS for Operations
1.0 Lab Directorate/Oversight
2.0 Lab Operations
2.1 Control Room
2.2 Detector Operations and Maintenance
2.3 Facilities Operation and Maintenance
2.4 Environmental, Safety, and Health
2.5 Cyberinfrastructure and Cybersecurity
2.6 Science Center
3.0 Data Science
4.0 Advanced Technology Research
5.0 Infrastructure Upgrades
6.0 Education, Public Outreach, Collaboration, and Community Activities
Each type of WBS serves its unique purpose, providing a structured approach tailored to
different aspects of project and operations management.
Document Number
207
4.3 Cost Estimating and Analysis
Research Infrastructure Guide
4.3
COST ESTIMATING AND ANALYSIS
4.3.1
Introduction to Cost Estimating and Analysis Process
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Section 1.3 Document Precedence and Award
Instruments notes that award instruments can NSF Requirement
be financial assistance awards, such as grants Awardees must adhere to the GAO Cost
and cooperative agreements (CA) or contracts. Estimating and Assessment Guide, while
Unless otherwise noted, the guidance in this also complying with NSF policies and
section applies to Major Facilities and Mid-scale practices. They should tailor and scale the
RI at all stages, regardless of the award guidance to suit specific needs of their RI.
instrument employed. Proposed budgets must
comply with the applicable federal regulations, in accordance with the funding
announcement and the terms and conditions of the award as implemented by NSF, and any
requirements associated with the particular award instrument. Section 1.4.4 Oversight
Requirements notes that Awardees must follow the GAO Cost Estimating and Assessment
Guide in accordance with the funding announcement and the terms and conditions of the
award. Additionally, portions of GAO or NSF guidance may be tailored and scaled depending
on what is relevant to the particular project or program. Accordingly, Awardees must note
any departures from the Research Infrastructure Guide (RIG) and GAO Cost Estimating and
Assessment Guide and explain their rationale in the Cost Estimating Plan (CEP). 1 Section 4.2
Scope and Work Breakdown Structure provides additional guidance on how to apply the
relevant practices from the GAO Cost Guide and examples of potential deviations.
This section provides guidance on NSF expectations for the format, content, supporting
justification, and good practices for Awardee cost estimates. It also explains the NSF cost
analysis process and timeline. By following this guidance, Awardees should expect a more
robust estimate and, therefore, a more efficient review by NSF, contributing to the likelihood
of the science mission's success. The Awardee should consult the cognizant NSF Program
Officer (PO) for existing awards.
NSF may use internal staff, outside experts, and panel reviews to analyze estimates.
However, the NSF Awarding Official (AO) is responsible for the pre-award business and
financial review process and making the final determination regarding costs estimated for
the award. The Awardee’s estimates must meet two sets of criteria that also serve as the
basis of the NSF cost analysis:
•
The cost principles associated with the award instrument used.
•
The four GAO characteristics of a high-quality cost estimate, namely well-
1 Definition
in Lexicon is adapted from AACE International Recommended Practice No 36R-08, Development of Cost
Estimate Plans – As Applied in Engineering, Procurement, and Construction for the Process Industries, Rev. June 12,
2009.
Document Number
208
4.3 Cost Estimating and Analysis
Research Infrastructure Guide
documented, comprehensive, accurate, and credible.
For financial assistance, the estimates must be allowable, allocable, and reasonable per the
2 CFR §200, Subpart E, and must be adequately supported in accordance with the standards
set forth in the NSF Proposal and Award Policies and Procedures Guide. 1 NSF also considers
cost realism important for all estimates. To meet the four characteristics of a high-quality
estimate, proposers should develop them following the 12 steps of the GAO Cost Estimating
and Assessment Guide, as appropriate (see Section 4.3.2 Characteristics of a High-Quality Cost
Estimate).
As described in Chapter 2 NSF Life Cycle Oversight, Awardees will be expected to develop
acceptable cost estimates for the design, construction, operation, and disposition of RI. It is
understood that cost estimates will undergo progressive elaboration at each stage-gate
review, and the materials required herein will evolve accordingly. NSF will review estimates
at an appropriate level as the RI progresses through the various life cycle stages.
Figure 4.3.1-1 depicts the general NSF cost analysis process performed for construction and
operations awards. The PO, AO, Research Infrastructure Office (RIO) Liaison, and Cost
Analyst from NSF’s Cost Analysis and Pre-Award Branch conduct a detailed analysis of the
Awardee cost estimate. NSF may also utilize Independent Cost Estimates (ICE) and cost
estimate reviews done by external panels and independent contractors or agencies to
inform the analysis. The AO and Cost Analyst review includes detailed sub-elements, NSF
budget categories, and supporting Basis-of-Estimate (BOE). 2 The PO review includes the
technical scope, risks, planned resources, schedule, and assumptions. The RIO Liaison
supports the analysis of any risks and proposed contingency budget as well as compliance
with the RIG and GAO Cost Estimating and Assessment Guide. The inputs from the various
sources are integrated and addressed with the Awardee, potentially resulting in a revised
cost estimate or additional documentation. The PO ultimately recommends the budget,
funding profile, and internal and external sources of funds based on the project's technical
scope and the funds' availability. The AO approves the Awardees’ cost estimate, and
ultimately, the proposal and approved budget are awarded based on the cost analysis
results.
For construction awards, the NSF cost analysis is done at the end of each Design Stage phase,
in conjunction with the Conceptual Design Review (CDR), Preliminary Design Review (PDR),
and Final Design Review (FDR) to support stage-gate reviews. For operations awards, the NSF
cost analysis is done on operations and management proposals for initial operations,
renewal, and competition of awards. NSF may also perform cost analyses at other times, as
necessary, based on a risk-based assessment. For example, cost analyses may be needed
1 Allowable costs are defined by federal guidelines and relevant cost principles. Allocable costs must be logically
related to the particular award. Reasonable costs are what a prudent individual would pay in a competitive
marketplace (i.e., costs are not too high). Cost realism defines whether the costs are realistic for the work to be
performed, reflect a clear understanding of the requirements, and are consistent with the methods of performance
and materials described in the Awardee’s technical proposal (i.e., costs are not too low).
2 See Sections 1.3.1.1 Financial Assistance Awards – Grants and Cooperative Agreements and 5.6 NSF Budget
Categories from the Proposal and Award Policies and Procedures Guide.
Document Number
209
4.3 Cost Estimating and Analysis
Research Infrastructure Guide
during construction or operations to support significant scope, schedule, cost, risk, or
complexity changes. These latter types of analysis may only require a review of targeted
subsets of information for specific changes. NSF typically requires 90 to 180 calendar days
to complete a full review and detailed cost analysis of a proposal budget before proceeding
to the next design phase or before award for operations or construction. This time will vary
depending on project scope, cost, risk, complexity, and relative importance. It will also
depend upon whether revisions to the estimate due to errors or cost re-categorizations, for
example, are needed.
If the information provided is incorrect, the PO, AO, RIO Liaison, Cost Analysts, and/or
external or independent reviewers may require additional documentation, justification, and
further interaction with the Awardee before completing the analysis. Communication among
all parties and a sound initial BOE are essential for timely and successful completion.
When submitting estimates for cost analysis, Awardees must submit the following, tailored
and scaled to the project or program, as a minimum:
•
A CEP per Section 4.3.3.3 Cost Estimating Plan.
•
A WBS, as described in Section 4.2 Scope and Work Breakdown Structure.
•
Cost Book, BOE, and supporting information.
For proposals that contain subawards, each subaward must include a separate budget
justification. 1
1 See
Chapter 8 Lexicon for the difference between a subaward, which transfers significant effort from the Awardee to
another entity, and a contract, which involves the purchase of materials and supplies, equipment or general support
services allowable under the award.
Document Number
210
4.3 Cost Estimating and Analysis
Research Infrastructure Guide
Figure 4.3.1-1
NSF Cost Analysis Process
4.3.2
Characteristics of a High-Quality Cost Estimate
The GAO Cost Estimating and Assessment Guide identifies four characteristics of a high-quality
estimate – comprehensive, well-documented, accurate, and credible. Each of the 12 steps in
the GAO cost-estimating process aligns with one of these four characteristics. Refer to the
GAO Cost Estimating and Assessment Guide for details on each step, best practices, and
mapping best practices to the characteristics. 1 NSF and independent reviewers use these
GAO criteria, and other methods when analyzing Awardee cost estimates to determine
whether to make an award. The application of the GAO Schedule Assessment Guide is
discussed further in Section 4.4 Schedule Development, Estimating, and Analysis.
4.3.2.1
Comprehensive
The cost estimate must completely define the infrastructure by WBS and reflect the current
schedule and technical baseline. It is structured with sufficient detail to ensure that cost
1 See 2020 GAO Cost Estimating and Assessment Guide Chapter 16 (GAO-20-195G); Table 25 from the 2009
version (GAO-09-3SP) also provides a concise mapping.
Document Number
211
4.3 Cost Estimating and Analysis Infrastructure Guide
elements are neither omitted nor double-counted. Where information is limited and
judgments should be made, assumptions and exclusions on which the estimate is based are
reasonable, clearly identified, explained, and documented.
4.3.2.2
Well-Documented
Thorough documentation explicitly identifies the estimating methods, sources of the data,
calculations, results, assumptions, and sources of the data used to generate each element’s
cost. The cost estimate must be well-structured, easily understood, and the data traceable.
4.3.2.3
Accurate
The cost estimate must be developed by estimating each cost element using the best
methodology from the collected data, with appropriate escalation adjustments. Their
underlying mathematical formulas, databases, and inputs are validated, and the resulting
estimates contain few minor mathematical mistakes. Accurate estimates are based on a
historical record of cost estimating and actual experiences from comparable programs.
Finally, they are updated regularly to reflect significant changes in the program. Any
variances between estimated and actual costs are documented, explained, and reviewed.
4.3.2.4
Credible
The cost estimate must discuss and document any analysis limitations, including uncertainty
or bias surrounding source data and assumptions. The estimate’s major assumptions are
varied to determine how sensitive it is to changes. Credible cost estimates include an analysis
of risk and uncertainty. In addition, high-value cost elements are often cross-checked with
alternative estimating methodologies to validate results. Finally, the estimate can be
compared with an ICE conducted by a group outside the acquiring organization.
4.3.3
Developing and Estimating Baseline Costs
4.3.3.1
Steps to Develop and Estimate Baseline Costs
Each of the GAO twelve steps are highlighted below to help show how they can be applied
or tailored to RI, including potential deviations, and how they should be integrated with NSF
processes.
Step 1 – Define the Estimate’s Purpose
•
•
The purpose should be clearly defined. There are typically two general purposes:
o
To help managers evaluate affordability and performance against plans and
select alternative systems and solutions, including value engineering and
scope management.
o
To support the budget and award processes by estimating the required
funding.
Defining the purpose helps clarify the intended use and package the estimate to
facilitate review by various audiences, including managers and independent
Document Number
212
4.3 Cost Estimating and Analysis Infrastructure Guide
reviewers. Reviewers not familiar with the facility will need a standalone document
with both the appropriate high-level perspective and the detailed CEP, BOE, and
linkages via WBS so that someone unfamiliar with the program can understand and
be able to determine if it meets the GAO’s 12 steps and four characteristics of a highquality cost estimate.
•
Defining the purpose also helps determine its scope and level of detail, identify
appropriate performance measures for benchmarking progress, address the benefits
it intends to deliver, and link the estimate to NSF’s mission, goals, and ideas.
Step 2 – Develop a Cost Estimating Plan
•
A CEP must be developed and address the details described in Section 4.3.3.3 Cost
Estimating Plan.
Step 3 – Define Program Characteristics
•
Characteristics of the program being estimated should be defined for proposed
design projects per Section 3.4.1 Design Execution Plan, for construction projects per
the PEP in Section 3.5 Construction Stage and Implementation Planning and for
operations awards per the Proposal and Work Plan in Sections 2.7 Major Facility
Operations Stage and 3.6 Operations Stage Planning.
Step 4 – Determine Estimating Structure
•
All estimates must be organized by the WBS described in Section 4.2 Scope and Work
Breakdown Structure. Financial assistance awards must also organize the data by
NSF budget categories, as described further in Section 1.3.1.1 Financial Assistance
Awards – Grants and Cooperative Agreements.
•
The estimate structure must have clear traceability between WBS, CEP, and BOE,
correctly roll up to higher levels, and readily map between the WBS and NSF Budget
Categories.
•
The estimate is built up from the individual WBS elements and sub-elements. If the
costs associated with each WBS element are binned into the appropriate NSF Budget
Categories, data can be easily sorted and organized for different purposes. For
example, costs can be coded with NSF budget format letters (Letters A–I per Table
1.3.1-1) to populate rolled-up NSF budget format summaries and the Cost Book
organized by WBS.
Step 5 – Identify Ground Rules and Assumptions (GR&A)
•
The ground rules (a common set of agreed estimating standards that provide
guidance and minimize conflicts in definitions) and assumptions (a set of judgments
about past, present, or future conditions) should be clearly defined and documented
in the CEP, as described in Section 4.3.3.3 Cost Estimating Plan.
•
The GR&A should be developed by estimators with input from experienced program
and technical personnel, based on information in the technical baseline and WBS
Dictionary, vetted and approved by upper management, documented to include the
Document Number
213
4.3 Cost Estimating and Analysis Infrastructure Guide
rationale behind the assumptions, and backed up by historical data.
•
GR&A may be global, which applies to the entire estimate and should be clearly and
consistently used throughout. GR&A may also be program-specific or WBS elementspecific, driven by the particular technical requirements.
•
The potential impacts of changing GR&A should be considered when developing the
sensitivity and risk analysis.
•
GR&A often include schedule or budget constraints, acquisition strategy, participation
of other agencies or governments, level of technology maturity, and required
research and development (R&D). GR&A also often define what is included and
excluded from the estimate, such as use of existing or multi-purpose equipment and
facilities.
•
Assumptions for escalation should be clearly defined. Awardees are not limited to
using only broad and publicly available economic assumptions for cost estimates. NSF
encourages organizations to use escalation information appropriate for known
situations or a particular industry as long as they can be justified. For example,
specialized data from the Department of Energy, Department of Defense, Bureau of
Labor Statistics, industry metrics, and/or historical experience with similar items may
be available. Escalation for raw materials and equipment in technological projects
often runs higher than broad measures of inflation (e.g., the consumer price index)
due to inelasticity in pricing (i.e., there are few or no substitutes available in the
marketplace, and demand remains constant). The justification for all escalation
assumptions and inflation factors (including the use of standard Office of
Management and Budget [OMB] inflation factors) should be included in the CEP and
used consistently throughout the BOE.
Step 6 – Obtain Data
•
The estimating methods, level of detail, accuracy range, and availability of historical
and current cost data will evolve and improve through the design phases and
Construction and Operations Stages. Current data should be routinely collected,
documented, and included in estimates.
•
Data should be collected from multiple sources, normalized, and assessed for
convergence and sensitivity. Cost drivers, trends, and outliers should be explored and
carefully analyzed for reliability and relevance. Primary data sources, obtained from
the original source and usually traceable to an audited document, should be used
when possible. Backup data should be collected and used to help identify cost drivers
and cross-check results.
•
Awardees should carefully consider data sources and their applicability, potential
limitations, allowances, risks, and uncertainty. This is especially true for NSF Major
Facilities, where estimates often include research and development, prototypes,
university work, software and cyberinfrastructure (CI), and unique, complex, new,
and/or evolving technologies.
•
The most appropriate estimating method should be chosen for each WBS element.
Document Number
214
4.3 Cost Estimating and Analysis Infrastructure Guide
The following cost-estimating methodologies should be used, in order of preference,
if the data exists:
•
o
Actual/historical data for the systems or operations being estimated.
o
Detailed engineering build-up.
o
Parametric data with adjustments to reflect differences (e.g., technical, size,
weight, quantity, location, schedule).
o
Analogous data with adjustments to reflect differences.
o
Expert opinion, only if a secondary methodology is used to substantiate.
Data sources, content, time, units, calculations, results, explanations for choosing a
particular estimating method or reference, and circumstances affecting the data
should be clearly documented in the CEP and Cost Book BOE.
Step 7 – Develop a Point Estimate and Compare it to an Independent Cost Estimate
•
Awardees are encouraged to obtain an ICE and cost estimate reviews to help validate
and improve the quality of the estimate before submitting proposals to NSF.
Awardees should address this as part of the CEP, as described in Section 4.3.3.3 Cost
Estimating Plan. Operations proposals do not typically warrant an ICE since analogous
historical costs are readily available, or the BOE will typically not have the breadth and
depth of technical and cost detail expected for a construction award.
•
As noted in Section 4.3.1 Introduction to Cost Estimating and Analysis Process, NSF
utilizes ICE and ICE Reviews from external panels and independent contractors or
agencies. An ICE is required before construction awards. An ICE Review of some type
is required of operations proposals before initial operations, renewal, and
competition of awards. These ICE and ICE Reviews are used to validate the Awardee
estimates, negotiate awards, check for compliance with GAO best practices and
Uniform Guidance Cost Principles, and inform the NSF cost analysis. Far before
reviews, the PO, AO, RIO Liaison, and Cost Analyst determine the type, timing, scope,
and team required. Awardees should be prepared to support these efforts, including
consolidating all technical information, responding to questions, participating in
reconciling proposals with ICE, and addressing any findings.
Step 8 – Conduct Sensitivity Analysis
•
Done to test the sensitivity of cost elements to changes in estimating input values and
key assumptions so that key cost drivers and the range of potential costs can be
identified and highlighted for Awardee management and NSF, and a strategy can be
developed to deal with them. Sensitive elements are those where small changes in
variables can create the greatest changes in cost.
•
Can be done rigorously and quantitatively by examining the effect of changing one
assumption, ground rule, or cost driver at a time while holding all other variables
constant to understand which variable most affects the cost estimate. The changes
should not be arbitrary or subjective (e.g., +/-%) but rather determined by subject
matter experts (SME) based on available data.
Document Number
215
4.3 Cost Estimating and Analysis Infrastructure Guide
•
Sensitivity analysis tries to isolate the effects of changing one variable at a time, while
risk or uncertainty analysis examines the effects of many variables changing
simultaneously. Therefore, the sensitivity analysis results can be used to help identify
and quantify risks, which are then used in a probabilistic risk assessment to develop
the contingency budget and confidence level.
•
The sensitivity analysis results can also inform decisions when analyzing design,
acquisition, construction, operations, and maintenance alternatives. Analyses can
also drive actions to avoid, mitigate, transfer, or accept risk.
•
For operations estimates that may consist largely of LOE work, a more qualitative
sensitivity review could be performed, and justification could be provided that there
are no particularly sensitive elements and, therefore, little or no potential impact.
•
The major contributing variables within the highest percentage cost elements are the
key cost drivers that should be considered in the analysis. They may be GR&A,
especially those least understood or most at risk of changing. For NSF RI, sensitive
elements may include electricity, fuel, major commodities, escalation specific to
certain cost elements, requirement changes, location, domestic versus foreign
sources/procurements, and acquisition strategy.
Step 9 – Conduct Risk and Uncertainty Analysis
•
If a contingency is requested, risk management, Risk Register data, BOE, assumptions,
and the detailed methodology used to calculate contingency budgets must be
documented and provided (see Section 4.6 Risk Management).
•
These analyses are not typically required for operations awards unless a separate
contingency budget is requested for facility or instrumentation upgrades or
replacement projects (see Section 4.2 Scope and Work Breakdown Structure).
However, a summary of key operational risks and uncertainties, their potential cost
impacts, and mitigation strategies may be beneficial to articulate as part of the
proposal. These could also be handled as part of the sensitivity analysis described in
Step 8 – Conduct Sensitivity Analysis.
Step 10 – Document the Estimate
•
Described in Section 4.3.3.2 Estimate Documentation.
Step 11 – Present the Estimate to Management for Approval
•
Described in Chapters 2 NSF Life Cycle Oversight and 3 Research Infrastructure Life
Cycle Planning.
Step 12 – Update the Estimate to Reflect Actual Costs and Changes
•
Described in this section and in the guidance on generating the Estimate to Complete
(ETC) and Estimate at Completion (EAC) in Sections 4.4.4.2 Progress Schedule, 4.5.4
Earned Value Management, and 4.7.3.3 Contingency Management Forecasting.
Typically, updating the estimate to reflect actual costs and changes is not required for
operations awards, though work plans and budgets may be adjusted annually to
Document Number
216
4.3 Cost Estimating and Analysis Infrastructure Guide
reflect actual work done and updates to planned work.
4.3.3.2
Estimate Documentation
This guidance supplements, not duplicates, the
GAO Cost Estimating and Assessment Guide and
industry good practices and standards. The four
components of a carefully planned and justified
cost estimate include a CEP, a Cost Book, a BOE
and supporting documentation.
Key Takeaway
The four components of a carefully
planned and justified estimate include
•
CEP
•
Cost Book
The CEP serves as a detailed framework that • BOE
outlines and describes the major estimating steps, • Supporting documentation
methods, and assumptions. It should be
generated early in the estimating process to help ensure the estimate will meet NSF
expectations and to avoid rework. This plan is crucial for setting the foundation of the cost
estimate and ensuring that all necessary elements are considered and properly
documented.
The Cost Book is the mathematical tabulation of cost data across all WBS elements and, for
financial assistance awards, NSF budget categories, providing a comprehensive view of the
estimated costs. Complementing the Cost Book, the BOE is the narrative explanation
detailing how and why the Awardee determined the proposed Cost Book numbers. It
provides context and justification for the figures presented, ensuring that the estimates are
grounded in well-documented assumptions and methods. Supporting documentation
includes all evidence required to justify the numbers and narratives, ensuring transparency
and credibility in the estimating process. This comprehensive approach ensures that the cost
estimate is not only accurate but also defensible and aligned with NSF standards.
Document Number
217
4.3 Cost Estimating and Analysis Infrastructure Guide
Figure 4.3.3.2-1
Components of a High-Quality Estimate
4.3.3.3
Cost Estimating Plan
In accordance with the funding announcement and the terms and conditions of the award,
Awardees must develop and submit a CEP for new construction and operations awards to
establish and communicate how the estimate's preparation, development, review, and
approval will be or was completed. The Awardee should consult with the PO regarding the
CEP for existing awards. Ideally, the CEP will be developed and discussed with NSF far before
submission (e.g., one year for Major Facility awards) to ensure that the Awardee’s plans are
aligned with NSF expectations and requirements outlined herein and sufficient time is
available to collect and package data. The CEP is the cornerstone of the estimate, and it, the
BOE, and supporting documentation are critically important for generating a high-quality
estimate to facilitate management decisions and NSF cost analysis. Awardees may contact
their PO, AO, RIO Liaison, and/or Cost Analyst for more information or guidance.
Document Number
218
4.3 Cost Estimating and Analysis Infrastructure Guide
The CEP must state the purpose(s) of the estimate and describe how the guidance will be or
has been implemented. Awardees must note any departures from these NSF and GAO
Guides and explain their rationale in the CEP. The CEP should also include the following, at
minimum, to help ensure the estimate is well-documented:
•
Outline the schedule of specific tasks, due dates, roles and responsibilities, practices,
systems, and calculations used to develop the cost estimate.
•
Describe the expected cost estimating methodology, maturity, and, if applicable,
accuracy range at each stage or phase (e.g., expert opinion, analogy, parametric,
engineering build-up, actual data). 1
•
Explain any ground rules, assumptions, and exclusions that apply broadly to the
estimate (e.g., assumed work hours and days).
•
Quantify explicitly any applied burdens, including the labor, escalation, indirect, and
fringe cost rates that are used and explain why they are appropriate.
•
Document where and how allowances are used and highlight any other sensitive or
significant factors or considerations, including their rationale and any references.
•
Discuss the ICE and reviews they are planning to validate the project estimate.
•
Provide a detailed narrative explanation of how the estimate was built up and how to
navigate through the files provided, from the supporting documentation through the
BOE and Cost Book and any roll-ups into higher level documents (e.g., PEP). Assume
the reader has no prior knowledge of the RI, organization, software used, etc. and
explain in a way that is easily understood.
•
Address specifically how the estimate will be well-documented through either:
o
Confirming the estimate will allow for mathematical checks of the proposal
budget calculations and should contain actual formulas that allow
manipulations to check calculations (i.e., the model should not display just the
results of the application of formulas or be locked such that calculations
cannot be verified in real-time), or
o
Providing a narrative explaining in detail how the cost estimating software
performs calculations, including sample formulas for different elements of
cost (e.g., labor, non-labor, travel), and provide examples tracing through
documentation.
The CEP should be tailored to the stage of the RI life cycle and address the most relevant
costs at that point in the life cycle stage. The CEP should explain how the cost estimate may
evolve over time. For example, the CDR should initially identify the expected level of funding
needed for the Operations Stage. Operating cost estimates should be refined and updated
throughout the design and construction process, as further discussed in the Concept of
1 For
example, via classification levels in AACE International Recommended Practice No.18R-97, Cost Estimate
Classification System – As Applied in Engineering, Procurement, and Construction for the Process Industries, Rev.
November 29, 2011
Document Number
219
4.3 Cost Estimating and Analysis Infrastructure Guide
Operations (ConOps) Plan, developed as part of the PEP described in Section 3.5
Construction Stage and Implementation Planning. The CEP presented in an operations
proposal, whether submitted by the Awardee of the construction award or by a separate
entity, should be informed by appropriate excerpts from the ConOps Plan developed in the
PEP or successor documents.
A Cost Model Data Set is the cost data used as input to software tools and/or project reports
to organize, correlate, and calculate different management information. The CEP should
explain how the Cost Model Data Set will meet the various needs of the RI. Figure 4.3.3.3-1
provides an example of how a Cost Model Data Set, WBS, and an Awardee’s institutional
accounting systems can be used as inputs in conjunction with scheduling, earned value, and
risk analysis tools to generate various output reports for project purposes. The CEP is
included as part of the PEP as described in Section 3.5 Construction Stage and
Implementation Planning.
Document Number
220
4.3 Cost Estimating and Analysis Infrastructure Guide
Figure 4.3.3.3-1
Sample Project Control Systems Relationship Diagram
Key
1.
For construction and operations
2.
For construction and Major Facility Upgrades funded through operations based on the technical nature of the
proposed activity
4.3.3.4
Uncertainty, Accuracy, and Allowances
Definitions for uncertainty, contingency, allowance, as well as the application of accuracy,
and precision requirements, can vary widely throughout industry and federal agencies, and
some of the terms are often used interchangeably. The complete definitions applied to NSF
RI are contained in Chapter 8 Lexicon, and brief explanations are provided in the text below.
Document Number
221
4.3 Cost Estimating and Analysis Infrastructure Guide
Uncertainty. Uncertainty is the inherent variability in predicting the outcome of future
events. Accuracy is a measure of correctness and specification closer to the true value. An
accurate cost estimate predicts the final actual cost with little error. Precision is a measure
of exactness and specification to more digits. A precise cost estimate is expressed to the
nearest cent or dollar, whether it accurately predicts the true cost or not.
All cost estimates have uncertainty, as they are an approximate forecast of the most likely cost
of future work based on information available at the time. 1 The precise costs will be unknown
until the actual costs are realized. 2 The degree of uncertainty decreases for projects as the
Project Definition matures, technical details are better defined, and engineering build-up
estimates, and vendor quotes replace earlier rough estimates. This is often referred to as a
cone of uncertainty, and correlations are available for the expected level of Project Definition
and associated accuracy range at different design phases. 3
Accuracy Over Precision for Credibility. In
cost estimating, accuracy holds greater Key Takeaway
importance than precision. It is preferable to be Accurate and credible are characteristics of a
approximately correct rather than precisely high-quality cost estimate, not precise.
incorrect. Excessive precision can undermine
credibility, as it suggests a misleading level of
certainty and exactness regarding costs and activities projected years into the future.
Credibility requires acknowledging the inherent limitations of future predictions, analyzing
the uncertainty, risk, and sensitivity of data, and performing cross-checks and independent
estimates using different methods to produce similar results. Considering all these factors
helps to validate that the estimate is reasonable and realistic (neither too high nor too low),
and believable.
Example:
Overly Precise: $1,239,876,543.21
Accurate and Credible: $1.25B, including a contingency budget at 90% confidence.
Below is a list of industry-trusted resources supporting the model that accuracy is more
important than precision when estimating costs.
1 Examples
of uncertainty include inexactness and changes in quantities or durations, fluctuating prices, faulty
assumptions, undefined details, requirement changes, economic factors, supply chain volatility, human error, bias,
differences in individuals and organizations.
2 Per GAO Cost Estimating and Assessment Guide, GAO-20-195G, March 2020: “uncertainty cannot be defined
because of ambiguity… uncertainty is always present” and “because risks and uncertainty occur, there is always a
chance that the actual cost will differ from the estimate. Thus, cost estimates are forecasts based on the best
information available at the time.” Per the GAO Cost Estimating and Assessment Guide, GAO-09-3SP, March 2009:
“cost estimating is difficult. It requires both science and judgment. And, since answers are seldom if ever precise, the
goal is to find a “reasonable” answer.”
3 For example, see Association for the Advancement of Cost Engineering International (AACEI) Recommended
Practice (RP) 18R-97, Cost Estimate Classification System – As Applied in Engineering, Procurement, and
Construction for the Process Industries, August 7, 2020, which the Department of Energy (DOE) correlates to their
critical decision stage gates in DOE Cost Estimating Guide, DOE G 413.3-21A, June 6, 2018. DOE’s Critical
Decisions 1, 2, and 3 are akin to NSF’s Conceptual, Preliminary, and Final Design Reviews.
Document Number
222
4.3 Cost Estimating and Analysis Infrastructure Guide
•
•
Per GAO Cost Estimating and Assessment Guide, 2020:
o
“More detail, though, does not necessarily provide greater accuracy. Pursuing
too much detail too early may be detrimental to an estimate’s quality.”
o
“Uncertainty cannot be avoided… Credible cost estimates clearly identify
limitations resulting from uncertainty…”
Per AACEI Recommended Practice 104R-19, Communicating Expected Estimate
Accuracy, February 22, 2021: “every estimate presented as a single value of cost or
duration will likely deviate from the final outcome (i.e., statistical error). In simple
terms, this means that every base estimate value will likely prove to be wrong… a
point value for an estimate… is in actuality just one point on a probability distribution
curve that represents the range of potential cost outcomes.”
Figure 4.3.3.4-1
Accuracy versus Precision
Allowances. Risks are differentiated from uncertainty as discrete events that have the
potential to occur. The potential costs of risk and uncertainty can be accounted for in
different ways, depending on the RI stage, complexity, and size. Specifically identified
uncertainties can be included in the BOE for base costs. Broad, macro-level uncertainties can
be included in the calculation of risk exposure and can also be covered with budget
contingency, as discussed in Sections 4.6.2 Step 2 – Identify and Document Risks, 4.6.6 Step
6 – Assess Total Risk Exposure, and 4.7 Contingency Estimating And Management. 1
Allowances are one way to estimate and account for uncertainty. A cost estimate allowance
is an amount of money permitted for anticipated but as-of-yet undefined details or
requirements. Allowances are a part of the most likely base costs and are included in the
BOE. Allowances are often estimated from statistical correlations, discipline rule-of-thumb
practices, predictive indices, or professional experience with past actual costs. Some
1 RI
that includes uncertainty in the budget contingency calculation must also explicitly include uncertainty in the Risk
Register for tracking purposes to allow the use of contingency when encountered.
Document Number
223
4.3 Cost Estimating and Analysis Infrastructure Guide
examples of common cost-estimating allowances include: 1
•
Design Development, Material Take-offs, Undefined Scope – when there is a lack of
complete RI definition, or it might not be cost-effective to quantify and cost every
small item.
•
Overbuy, Scrap, Waste, Damage – e.g., concrete, plywood sheets, floor tiles.
•
Services – e.g., inspection, testing, training, shipping.
•
Custom Engineered Equipment – e.g., for tightening tolerances and changing finishes.
•
Repair, Replacement, Preventive Maintenance, and Technical Refresh – routinely
needed for operating RI.
•
Other factors – e.g., potential increases in fuel costs, escalation rates, operating days.
For NSF, if appropriate, allowances could include uncertainties associated with cost
estimating (as part of the BOE) in lieu of a defined risk, where the cost impacts would be held
in aggregate as part of the budget contingency.
4.3.4
Specific Guidance for Major Facility Construction Estimates
4.3.4.1
Purpose and Process
As discussed in Section 4.3.1 Introduction to Cost Estimating and Analysis Process, NSF
utilizes internal staff, outside experts, and expert panels at the CDR, PDR, FDR, and during
the Construction Stage to ensure that proposed construction budgets meet expectations,
incorporate relevant GAO cost and schedule guides best practices, and are allowable,
allocable, reasonable, and realistic. The CEP, Cost Books, and BOE should be updated
through progressive elaboration during each phase in preparation for the reviews described
in Section 3.4 Design Stage Planning. NSF documents all the cost analysis work, technical
reviews, audits, etc., for cost analysis as part of its oversight and assurance roles.
The construction PDR estimate, and subsequent NSF analysis and independent reviews, are
expected to be sufficient to give NSF confidence in the estimated Total Project Cost (TPC) that
advances for National Science Board (NSB) authorization and potential inclusion in a future
budget request. The FDR estimate and subsequent analysis are expected to be sufficient to
give NSF confidence in constructing and commissioning the facility within the TPC and in
adherence to NSF’s No Cost Overrun Policy (NCOP) per Sections 1.4.7 NSF No Cost Overrun
Policy and 4.7 Contingency Estimating and Management.
1 Many
examples and associated percentage of other costs can be found in AACEI Skills and Knowledge of Cost
Engineering, 6th Edition, 2015.
Document Number
224
4.3 Cost Estimating and Analysis Infrastructure Guide
4.3.4.2
Construction Cost Book and Basis of Estimate Overview
Construction Cost Books and BOE are necessary at the CDR, PDR, and FDR, at minimum, to
provide a comprehensive, consolidated estimate of construction costs.
The CEP, Cost Book, and BOE provide assumptions, calculations, and detailed information to
support the proposed budget. The following additional high-level information should be
provided as an overview and Executive Summary (see Section 3.5.3.5 PEP Subcomponent 3.5
– Time-Phased Budget to assist with the review process described in Chapter 2 NSF Life Cycle
Oversight). Awardees should consult with the PO and AO as necessary to identify any other
specific cost reports and content required to support the review.
•
Overall high-level cost summary charts, tables, profiles, and reports depicting total
and annual costs in then-year dollars, reported by WBS and in NSF budget format.
•
A comparison of the current TPC to past estimates and an explanation of any major
changes, including impacts to scope or design.
•
Explanation of how project costs by WBS map to the NSF budget format, including
detailed traceability or crosswalk matrix, described further below.
•
Other reports, as needed, e.g., costs by resource types (subcontract, labor, materials,
travel), cost profiles (total, labor, non-labor, by WBS sub-element), personnel profiles
(full-time-equivalents by WBS sub-element).
4.3.4.3
Construction Cost Book and Basis of Estimate Additional Details
This section discusses additional detailed information needed for a high-quality Awardee
cost estimate and NSF cost analysis. This information supplements the standard GAO best
practices and industry standards. 1 The guidance aims to improve project execution, clarify
NSF expectations, assist Awardees, facilitate NSF review with fewer iterative resubmissions,
and prevent recurrent issues. It is understood that this information will be refined further as
the design stage advances.
Presentation and Linkages. Individual WBS element costs should have a sound, fully
justified, documented, and sufficiently detailed BOE. Figure 4.3.4.3-1 provides an example of
a construction Cost Book sheet depicting the format and content typically needed to
consolidate the cost model dataset and provide appropriate detail and BOE. This sheet
includes the following information:
•
WBS and activity codes and descriptions, per the WBS Dictionary, to index the cost
estimate to a specific deliverable.
•
Statement of Work describing the scope.
•
Estimator Name and Date of Estimate.
1 Examples: AACEI Recommended Practice No. 18R-97, Cost Estimate Classification System – As Applied in
Engineering, Procurement, and Constructions for the Process Industries, August 7, 2020; and AACEI Recommended
Practice No. 34R-05, Basis of Estimate, October 5, 2021
Document Number
225
4.3 Cost Estimating and Analysis Infrastructure Guide
•
Resource Descriptions.
•
Cost Basis Codes describing the estimating methodology (e.g., expert opinion,
analogy, parametric, engineering build-up, historical data).
•
Direct Costs with Units and Hours.
•
Associated Fringe and Indirect Costs.
•
The NSF Budget Category Code corresponds to the budget categories described in
Section 5.6 NSF Budget Categories from the Proposal and Award Policies and
Procedures Guide, which allows mapping between WBS sub-elements in the
Construction Cost Book and NSF Budget Categories on NSF Budget Forms.
•
BOE source data, with a breakout of sub-elements, typically including direct input
from technical experts in that area with calculations using material and labor
quantities and unit prices, with clear assumptions and sources referenced.
•
Supporting information associated with the use of allowances, if any (see Section
4.3.3.4 Uncertainty, Accuracy, and Allowances).
Estimates must have clear traceability, including the following, as appropriate, for CDR, PDR,
FDR, and Construction:
•
The total estimated cost should correlate to current drawings, specifications, and
schedules to the maximum extent practicable.
•
Lower levels of the WBS must correctly roll up to the higher levels, and the application
of rates and factors must be consistent with the CEP, BOE, supporting rate
agreements, and Awardee accounting practices.
Cost estimates may be directly linked to scheduling tools to allow automatic cost updates
with schedule changes.
BOE Refinement Process. Because of the hierarchical nature of the WBS, it is possible, over
time, to refine the level of detail at which the project scope, schedule, and task-based costs
are captured. Throughout the Design Stage, the task and cost fidelity will increase, and
eventually, during the project's construction, the plans should be fully detailed. As the project
moves through the phases, detailed engineering build-up estimates using current quotes
and prices should be collected to reduce the proportion of estimated costs based on expert
opinion, analogy, or parametric estimates. As the Project Team finalizes plans for the start
of construction, the BOE should include more vendor catalogs and quoted or proposed
contract prices.
Direct labor rates, quantities, and skills mix should be justified, including information from
subawards.
Cost estimates should include adequate project management funding, including the use of
appropriate project management tools such as project management control software and
associated staff support.
The Major Facility Construction Cost Estimate may include commissioning (i.e., integration,
testing, acceptance, and operational readiness), including funding for staff to perform these
Document Number
226
4.3 Cost Estimating and Analysis Infrastructure Guide
activities and train the operations personnel. Roles change as a project progresses from
construction through commissioning and eventually to operations; time and staffing
requirements need to be carefully calculated in advance, with a clear demarcation between
the construction-funded scope and the operations scope, as discussed in PEP
Subcomponent 7.5 – Business and Financial Controls Plans.
CI technical requirements and costs (both the initial and continuing costs of hardware,
software, maintenance, upgrades, and operations) should be carefully considered and
periodically validated. Rapid advances in computing may require upgrades as often as every
three to five years.
The cost of evolving technologies should be considered during budget development and
acquisition planning. For example, it may be appropriate to include higher allowances in the
BOE or higher impacts as part of the budget contingency development and plan for
procurement late in the Construction Stage.
Figure 4.3.4.3-1
Construction Cost Book Sheet Sample Format
Document Number
227
4.3 Cost Estimating and Analysis Infrastructure Guide
4.3.5
Specific Guidance for Major Facility Operations Estimates
4.3.5.1
Purpose and Process
In addition to the specialized scientific expertise required for operations, award solicitations
can include expectations for estimating budgets, business systems, and operational and
financial reports. These systems and reports help ensure that the science mission can be
met cost-effectively (see Sections 2.7 Major Facility Operations Stage and 4.2 Scope and Work
Breakdown Structure).
NSF utilizes internal staff, outside experts, and panel reviews to ensure cost estimates and
budgets meet expectations, incorporates relevant GAO Cost Guide best practices, and are
allowable, allocable, and reasonable. The NSF Cost Analysis document is used as an award
decision tool that captures all the cost analysis work, technical reviews, audits, etc., for cost
analysis as part of its oversight and assurance roles. It is incumbent on NSF to plan and
budget for effective research and educational use of facilities and the costs of operating and
maintaining the facility in the long term. It is incumbent upon the Awardee to ensure their
operations proposal is well-documented, accurate, comprehensive, and credible.
Operating budgets should include, when appropriate, resources to provide a continuing
program of advanced R&D that will enable a facility to evolve and best meet the research
community's needs. Funding for these kinds of upgrades may also come from separate
equipment and/or instrumentation programs within the Directorate or Division.
4.3.5.2
Operations Cost Book and Basis of Estimate Overview
In addition to the guidance for the Annual Work Plan (AWP) described in Sections 3.6
Operations Stage Planning and 2.7.2 Operations Stage Awards, the PO or via the operations
and management award solicitation may request additional information. Awardees should
consult with the PO, AO, or CO as necessary to identify any other specific cost reports and
content required to support the review.
Periodic plans may include an Executive Summary, narrative overview, strategic and annual
objectives correlated to NSF mission needs, and an annual operating budget focusing on any
significant changes from previous plans. Plans may also include expected scope, milestones,
outcomes and impacts, developments, challenges, and opportunities.
Explanation of how program costs within functional areas are coded or otherwise related to
the NSF Budget Categories depicted in Section 1.3.1.1 Financial Assistance Awards – Grants
and Cooperative Agreements.
Other reports, such as annual cost by resource types (subcontract, labor, materials, travel),
cost profiles (total, labor, non-labor, by sub-element), and personnel profiles (full-timeequivalents by sub-element).
Document Number
228
4.3 Cost Estimating and Analysis Infrastructure Guide
4.3.5.3
Operations Cost Book and Basis of Estimate Additional Detail
This section discusses additional detailed information typically needed for a high-quality
Awardee estimate and NSF cost analysis for Operations Stage award proposals. This
information is intended to supplement the standard GAO best practices. The guidance
should improve execution, clarify NSF expectations, assist Awardees, facilitate NSF review
with fewer iterative resubmissions, and prevent recurrent issues. For existing awards, the
Awardee should consult with the PO.
Multiyear budgets should take escalation into account, using factors discussed in Section
4.3.3.1 Steps to Develop and Estimate Baseline Costs, specifically step five, and documenting
assumptions in the CEP. The Awardee should articulate the assumptions made to modify the
LOE or science support capabilities for expected efficiency gains or for other adjustments if
used to offset escalation.
The program should also explain the following:
•
Key assumptions, sensitivities, risks, uncertainties, or other elements driving
estimated costs, scope, and schedule.
•
The associated potential impacts to science.
•
Plans on how to routinely reassess cost drivers and actual costs and adjust at least
annually.
•
When power costs are significant and volatile, a strategy for dealing with price
fluctuation should be developed as part of operations planning. Other examples of
items that may require separate consideration are expendables – such as cryogens,
gases, and spare parts – and ancillary equipment such as refrigerators and IT
equipment.
•
Separate funding sources and revenue streams (e.g., visitor center fees) should be
clearly delineated.
•
Education and Public Outreach costs should be explicitly identified and explained.
If contingency is requested, it must comply with Section 4.7 Contingency Estimating and
Management.
Document Number
229
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
4.4
SCHEDULE DEVELOPMENT, ESTIMATING, AND ANALYSIS
4.4.1
Introduction
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
A schedule is a management tool used for planning and executing work during any stage of
an RI life cycle. Schedules address both how and when the work is to be performed by
identifying the activities needed to accomplish the scope of work and by time-phasing these
activities with durations and schedule logic. Time-phasing involves identifying the key
relationships between activities to determine the necessary sequence to accomplish the
work.
A project schedule, also referred to as a schedule model, identifies the necessary activities
with interdependencies along a timeline to complete a specific deliverable or defined scope
of work with a beginning and an end. Project schedules are typically used to manage work
during the Design and Construction Stages or implementation of an RI’s life cycle. While NSF
does not have a schedule overrun policy similar to the NCOP, a reliable schedule is critical
for the Construction Stage or implementation. Schedules used for the Operations Stage of a
facility’s life cycle are generally performance goals defined as events or milestones on a
timeline and may or may not have activities with identified interdependencies. An
operation’s Science Support Program may use separate schedules to manage upgrades or
renewal projects.
The GAO Schedule Assessment Guide is intended to improve project schedules and identifies
ten best practices associated with creating and maintaining reliable Critical Path Method
(CPM) schedules. 1 Refer to the GAO Schedule Assessment Guide for a discussion of concepts
associated with CPM and the specifics of each best practice. Awardees are required to utilize
the GAO Schedule Assessment Guide in the development of Construction Stage schedules for
Major Facility projects, regardless of the award instrument employed. Awardees should also
tailor and scale the GAO Schedule Assessment Guide when developing schedules to manage
design activities or for Mid-scale RI implementation, per Section 2.9 Mid-Scale Research
Infrastructure Guidance. The GAO scheduling best practices have limited application to the
schedules typically used for operations, such as bar charts or milestone charts, and are not
required guidance for Operations Stage schedules.
The guidance in this section applies to the development of construction schedules for Major
Facilities and Mid-scale RI projects and provides NSF expectations associated with the GAO
scheduling best practices, considering NSF’s policies and practices. This guidance also
explains NSF’s schedule analysis practices aligned with the Design stage-gate reviews
discussed in Section 2.5 Major Facility Design Stage and the format and supporting
justification for Awardee schedules. By following this guidance, Awardees can expect to
1 U.S. GAO Schedule Assessment Guide: Best Practices for Project Schedules (GAO-16-89G December 2015, or
subsequent revision)
Document Number
230
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
develop a high-quality and reliable schedule, enabling an efficient review by NSF.
Development of a construction schedule starts during the Conceptual Design Phase, evolves
during the Design Stage, and is expected to be ready to support construction by the end of
the Final Design Phase. For a Major Facility project, an activity-based Resource-Loaded
Schedule (RLS) with network logic is required for advancement to the Construction Stage.
This RLS provides the basis for the Performance Measurement Baseline (PMB) to be used to
monitor the project performance and forecast future milestones during the Construction
Stage (see Section 3.5.3.4 PEP Subcomponent 3.4 – Integrated Master Schedule). The RLS is
also used to develop the time-phased construction budget plan during the Design Stage.
A high-quality and reliable schedule that is effectively controlled is a key element to
successful project execution. A project’s RLS is the foundation that integrates scope,
schedule, and budget. Therefore, it is used to establish the budget and schedule
contingencies, to develop the time-phased funding needs, and to measure and forecast
performance. At the PDR, NSF requires a funding profile by fiscal year (FY) that includes the
commitment and obligation of funds, plus anticipated contingency needs. The profile should
be developed using the Construction Stage RLS and the quantitative assessment of risks and
estimating uncertainties (see Section 4.6 Risk Management). Following the FDR, the RLS
establishes the PMB and, when combined with schedule contingency and additional time for
administrative purposes (generally six months), informs the award duration authorized by
NSF.
Developing a high-quality and reliable schedule requires the knowledge and experience of
both the activity owners and the project scheduler(s). Activity owners are responsible for
managing the work, and the most experienced team members performing the work should
be responsible for estimating the resources and identifying the interdependencies of the
activities to execute the work. The complexity of a schedule typically drives the experience
level of the person(s) developing and maintaining the schedule and selecting a scheduling
software tool. A Construction Stage schedule for a Major Facility project usually requires a
scheduler to be properly trained and experienced in CPM scheduling and the scheduling
tool. Different scheduling software packages have different select features that require
someone experienced with that software tool to ensure a reliable schedule. Various
scheduling software packages use different terms to define a component of work performed
during the course of a project – activity and task. The use of the term activity in this guidance
is interchangeable with the term task.
4.4.2
Characteristics of a Reliable Schedule
The GAO Schedule Assessment Guide identifies four high-quality, reliable schedule
characteristics: comprehensive, well-constructed, credible, and controlled. Each of the GAO
ten Scheduling Best Practices (see Section 4.4.3.1 Ten Steps to Develop Baseline Schedule)
aligns with one of these four characteristics. Various other industry scheduling good
practices can also generally align with one or more of these characteristics. Refer to the GAO
Schedule Assessment Guide for details on each of the best practices and the mapping of best
Document Number
231
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
practices to the characteristics.
As discussed in Section 1.3.1 Award Instruments, NSF does not directly construct or operate
the facilities it supports. NSF’s responsibility is to oversee the Awardee’s performance. The
Construction Stage schedules are developed and managed by the Awardee and do not
include government activities. The discussion below provides NSF expectations associated
with the GAO Scheduling Best Practices grouped by characteristic for Awardee-developed
construction schedules.
4.4.2.1
Comprehensive
The schedule must include all the activities to complete the full scope of the project to be
funded by an NSF construction award, if authorized, including all subaward and subcontract
efforts. The schedule must be clearly aligned with the WBS. Section 4.2 Scope and Work
Breakdown Structure provides guidance and examples for developing the WBS elements.
The schedule should be resource-loaded with all the labor, materials, equipment, and travel
assigned to detailed activities and planning package activities. Detailed activities should be
developed to allow discrete progress measurement. A planning package activity contains a
defined scope of work, typically under the responsibility of one organization, without
detailed schedule activities, and typically will occur in the distant future.
With the long duration of Major Facility projects, the use of planning packages in the RLS is
an efficient method to ensure the budget is allocated for a work scope that doesn’t yet have
the level of information to define the detailed activities to perform the work. For example, at
the beginning of a project, the scope associated with commissioning is commonly identified
as one or more planning packages near the end of the schedule. As the project progresses,
planning packages are broken into detailed activities. Incremental conversion of work from
planning packages to detailed activities is commonly known as rolling wave planning.
Increments for rolling wave planning may be event-driven (test, review, milestone,
procurement) or time-based, such as every six months. If a project uses incremental
planning, the process should be defined as managing and controlling the schedule.
The duration assigned to each schedule activity should be the most probable duration,
factoring in the planned level of resources. Activities should have relatively short durations
and be consistent with information provided in the BOE (see Section 4.3 Cost Estimating and
Analysis). For activities that do not lend themselves to a short duration, it may be necessary
to document the activity’s scope in steps or use another measurement method to evaluate
progress. Planning package activities will normally reflect longer durations until broken into
detailed activities. Planning packages need to be of sufficient detail to establish a credible
sequence of execution for the overall project. Duration of LOE activities, such as
management and other oversight efforts, may be time-based or derived from the span of
other discrete activities. The planning package and LOE activities should be identified in the
schedule.
The schedule should include sufficient milestones to manage decision points and interfaces
(internal and external) and monitor technical progress at different levels of the project.
Document Number
232
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
External milestones may be associated with collaborative partnership efforts, reviews,
funding, facility operations, etc. Typically, external milestones are constrained within the
scheduling tool. The Awardee should consult with the PO to identify programmatic
milestones and high-level milestones for reporting to NSF. Lower-level milestones will
facilitate more frequent tracking of the project's progress. Milestones should be coded to
reflect their level of significance.
4.4.2.2
Well-Constructed
The attributes of a well-constructed schedule are primarily associated with the logic used to
define the interdependencies of all the schedule activities and establish the Critical Path. The
Critical Path is the longest path of activities between a project’s start and its finish and is used
to establish the PMB duration. Projects with multiple deliverables or collaborating with
external partners may need to identify additional sequential activities considered critical to
achieving project objectives and high-level milestones. All activities necessary to accomplish
the project deliverables should be logically sequenced, typically with the predecessor activity
finishing before its successor activity starts.
Minimize the use of constraints and lags to fix start or finish dates, as they reduce schedule
logic clarity, complicate schedule management, and make it harder to provide accurate
forecast dates as the project progresses. Schedule visibility tasks (SVT) or schedule calendars
may be used to help minimize constraints and lags. SVT are schedule activities with no
resources assigned, with a duration greater than zero, and typically represent external effort
that is not part of the PMB. SVT may also be used to increase management visibility to items
otherwise represented as lag or constrained milestones. Constraints and/or lags may be
necessary to manage a project effectively based on the project parameters. The basis for
constraints and lags used in a schedule should be explained in the Schedule Basis Document
as discussed in Section 4.4.3.2 Schedule Documentation.
During schedule development, Awardees should perform schedule health assessments to
analyze the integrity of the schedule. Schedule health metrics contain checks designed to
indicate potential activity interdependency issues. At a minimum, a schedule health
assessment should include missing predecessors-successors, relationship types, leads and
lags, and hard constraints. Other potential checks to consider in the schedule assessment
include logic density, high free float, Critical Path tests, path convergence, and resource rates.
All schedule health assessment checks should be used to assess the construction quality of
the schedule, optimize the schedule, and should not be used as a pass or fail test.
The activity durations and the logic sequences should be validated by activity owners and
technical experts. A valid Critical Path is calculated by the scheduling tool, fully vetted,
accepted by the activity owners and the Project Team, and aligned with the project execution
strategy. The Critical Path represents the sequence of the activities that drive the earliest
possible project completion date and establishes the PMB end date milestone. The Critical
Path should include allowances for specific uncertainties as well as contain float,
contingency, or margin. If the Critical Path runs through management activities, the schedule
Document Number
233
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
should be carefully examined to confirm the schedule logic.
Schedule contingency (see Section 4.7 Contingency Estimating and Management) is needed
to provide time for uncertain activity durations and schedule impacts due to risks. Schedule
contingency is typically estimated using statistical analysis or judgment based on past
experience. The project end date is based on the PMB duration plus the established schedule
contingency. The award end date is generally the project end date plus additional time for
the closeout of the award. The award duration is less than or equal to the NSB-authorized
duration. While NSF does not have a schedule overrun policy, Awardees are expected to
exercise discipline to keep projects on schedule and follow the no-cost schedule extension
practices in Section 2.6.2 Construction Award Extension and Close-out.
4.4.2.3
Credible
The schedule should align with the project execution approach and show how the work will
be integrated to achieve project objectives, including activities performed by Subawardees
and contractors. The schedule should clearly define the sequence of activities and be
horizontally and vertically traceable through the activity relationship logic. If lower-level,
more detailed schedules are utilized in addition to the project schedule (e.g., more detailed
subcontractor activities may be bundled into the Awardee’s higher-level Integrated Master
Schedule [IMS]), milestone linkages should be established to show the vertical traceability
between the project schedule and the lower-level schedule(s). The schedule should utilize
milestones with predecessor activities to define the completion of major components and/or
deliverables, hand-offs between different organizations, key events, etc. The PO may define
specific milestones for the Awardee to include in the project schedule.
For Major Facility projects, the amount of schedule contingency is determined by a
probabilistic risk analysis and selecting a finish date with a confidence level between 70%
and 90%. The schedule risk analysis should be based on the project Risk Register, with
identified schedule impacts and probabilities and activity duration uncertainty. In addition
to the project end date, the total float or schedule margin for major deliverables should be
reviewed and evaluated.
For further discussion on Risk Registers and schedule risk analyses, refer to Section 4.6 Risk
Management. Before conducting a schedule risk simulation, the schedule should be
assessed against GAO’s comprehensive and well-constructed best practices and
systematically checked to confirm the dependability of the risk analysis model. As noted in
Section 4.6.6.3 Probabilistic Method – Monte Carlo Simulations, the risk analysis may use a
summary schedule derived from the IMS if it has a large number of activities. The results
from the schedule risk analysis, including the contingency amounts, method of calculation,
project end date, and confidence level, should be documented in PEP Subcomponent 4.3 –
Contingency Management Plan as articulated in Section 3.5.4.3 (also see Section 4.7
Contingency Estimating and Management). Schedule contingency is held separately from the
PMB, and allocations of schedule contingency to and from the PMB are managed through
formal Change Control.
Document Number
234
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
4.4.2.4
Controlled
The baseline schedule used to establish the PMB is set post-FDR with the construction award.
The RLS is the basis for the PMB. Every project will have changes to the plan as it is being
executed; therefore, effective Change Control and disciplined schedule maintenance
procedures are necessary. The baseline schedule logic changes due to detailed planning or
re-planning should be managed through formal Change Control. This includes schedule
changes that do not use budget and/or schedule contingency. The different levels of
milestones used to monitor technical progress will typically correspond to approval
thresholds in the Change Control Plan, as discussed in Section 4.7.3.1 Contingency
Management Controls. As schedule contingency is used and placed into the baseline, the
PMB end date is revised.
The schedule should be updated regularly to record actual project progress and forecast
activity and milestone dates of the remaining work for comparison with the baseline
schedule, typically referred to as the progress or status schedule. The projected milestone
dates reported in the Construction Stage performance reports should be generated using
the progress schedule with the same logic as the baseline schedule, not arbitrarily
constrained or adjusted. This comparison identifies the specific activities and events that are
the source of current schedule variances or impending problems in meeting milestone dates.
If lower-level schedules are utilized to manage the project scope, including major
Subawardees and contractors, the project needs to establish a process to maintain vertical
traceability and ensure consistency between the project schedule and the lower-level
schedules.
The Project Team reviews schedule updates to verify and assess effects and identify actions
as needed. The Awardee’s Project Director reports the project status, including a narrative
on accomplishments and challenges, to the PO on a periodic basis. For Major Facility projects,
the update period is monthly, and EVM is required (see Section 4.5 Monitoring Progress
Against Plan).
4.4.3
Developing and Estimating a Baseline Schedule
The Total Project Duration (TPD) for the Construction Stage is set post-FDR and is defined in
the construction award as two components: the PMB schedule duration and the schedule
contingency. The construction award duration should be based on the TPD plus additional
time for project closeout as determined by the AO. For further discussion, refer to the NSF
EVM Gold Card, a guideline document that outlines key concepts for managing NSF-funded
projects that require Earned Value Management System (EVMS). It helps measure project
performance in terms of cost, schedule, and scope, allowing stakeholders and NSF to
effectively monitor and control projects, ensuring adherence to established project goals. 1
The development of the PMB is an iterative process as the PEP matures through the Design
1 https://www.nsf.gov/bfa/rio/evm-gold-card
Document Number
235
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
Stage. Developing a reliable schedule would generally follow the steps described below. First,
a project would select a schedule method, technique(s), and tool(s). For Major Facility
projects, CPM, rolling wave planning, and Monte Carlo simulations are commonly used.
4.4.3.1
Ten Steps to Develop Baseline Schedule 1
Step 1 – Define the total scope of work into deliverables and manageable parts or
phases.
•
The total scope of work is defined in the WBS and provides structure to the schedule.
WBS are developed at varying levels of detail but should be at least to a level of
manageable deliverables that can be assigned to one responsible organizational
element. The WBS used in the schedule is the same as that used in the cost estimate.
Refer to Section 4.2 Scope and Work Breakdown Structure.
Step 2 – Identify project goals and major internal and external interfaces.
•
In discussions with the various project stakeholders, the Project Team identifies major
internal and external interfaces and develops the project goals, including high-level
milestones and target dates. If the NSF-funded project scope is a part of a larger
overall project, the technical interfaces and the organizations of the overall project
may affect how the NSF part of the scope should be executed. Equipment may be
furnished by external entities, or there may be other hand-offs with external partners.
There could also be interfaces and hand-offs of components between collaborating
institutions within the NSF-funded scope. Operational facilities may have target dates
for shutdown periods for facility modifications or a required sequence of deliverables
to minimize impacts to operations. Establishing such interface milestones will provide
clear visibility to the project’s overall approach and ensure better project schedule
management in execution.
Step 3 – Develop schedule activities and technical milestones.
•
Schedule activities represent the specific actions to be performed to produce a
specific scope of work. The level of detail of these actions becomes more defined as
the project proceeds through the Design Stage. The Project Team works with the
activity owners to ensure that all work scope has been identified at the appropriate
level of detail. The use of long-duration activities to reduce schedule complexity needs
to be balanced with the ability to manage the project and measure progress. The
schedule should also include lower-level milestones that will facilitate more frequent
project progress tracking. Milestones are also useful to track the progress of
externally funded activities that are included in a project schedule.
•
Planning package activities are commonly used for work in the distant future.
Baseline schedules should have activities for the near-term work defined to a level to
1 Note
these steps are slightly modified from GAO’s sequencing in GAO Schedule Assessment Guide, GAO-16-89G,
December 2015
Document Number
236
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
execute the work and measure progress. Projects that use planning package activities
should be identified in the scheduling software and have a process to ensure they are
promptly converted to detailed plans. For Major Facility projects, the conversion of
planning package activities during the Construction Stage should be managed
through the change control process established in the Design Execution Plan (DEP) or
PEP.
Step 4 – Determine durations for each activity.
•
Activity durations should be the most likely estimate considering the available or
planned level of resources. Activity durations should not factor in risks or nonwork
periods but may include allowances for specific uncertainties. Calendars in the
scheduling software should be used to account for nonwork days and/or periods. The
duration of planning package activities should be based on analogies to historical
projects, experience, or productivity rates.
Step 5 – Logically sequence activities.
•
The Project Team and activity owners identify the predecessor-successor logic
relationships between activities and milestones utilizing three types of scheduling
relationships (Finish-to-Start, Start-to-Start, Finish-to-Finish), along with required lead
or lag times. 1 The majority of relationships within the schedule should be Finish-ToStart relationships. For reliable forecasting in progress schedules, planning package
activities need to be detailed enough to maintain a proper sequence of work, and the
use of lags should be minimized.
Step 6 – Define and assign resources to activities.
•
Scheduling software broadly categorizes resources as either labor or materials and
supplies (M&S). M&S is any cost other than labor and includes materials,
procurements, contracted labor, subcontracts, travel, etc. A project may use a
Resource Breakdown Structure to organize a list of the resources required to
complete the scope of work. The RLS defines the PMB and reflects the activities'
expected (planned) accrual or actual costs. An obligation baseline can also be created
based on resource spreads or obligation activities. A fund obligation profile is only
used to match time-phased funding when the PMB is established and is not used for
earned-value analysis.
•
The BOE and project cost estimates are the supporting documentation for the
resources loaded into the schedule activities. The scheduling software may be used
to tag resources and generate the cost data for the NSF Budget Format. For more
information on the NSF Budget Categories and construction proposal formats, refer
to the following sections
o
1.3.1.1 Financial Assistance Awards – Grants and Cooperative Agreements
1 Refer
to GAO Schedule Assessment Guide [https://www.gao.gov/products/gao-16-89g] for additional information
regarding activity relationships.
Document Number
237
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
o
o
4.3.4 Specific Guidance for Major Facility Construction Estimates
5.6 NSF Budget Categories from the Proposal and Award Policies and
Procedures Guide
Step 7 – Perform schedule calculations.
•
Schedule calculations are performed using scheduling software. Early and late dates,
Critical path, and activity float are determined. Calculations can be performed at
various times during the schedule preparation to allow for preliminary reviews and
resource leveling.
Step 8 – Review and analysis.
•
The Project Team and the activity owners should actively participate in reviewing the
results of the schedule calculations. The review should consider the project
objectives, milestone completion dates, critical and near-critical paths, float values,
and required resources (compared to resource availability) to determine the
schedule's acceptability. Where alterations are required, changes are made to the
schedule logic, resource allocations, and/or durations, and then the schedule is
reanalyzed.
Step 9 – Assign risk-based schedule contingency.
•
Part of the scheduling process includes the Project Team determining the risk-based
schedule contingency that is derived from the estimated duration uncertainty and
risks associated with a set of activities and/or the overall project. Schedule
contingency, like budget contingency, is used to accommodate approved baseline
changes and resultant schedule impacts without impacting overall project schedule
objectives (see Sections 4.6.6 Step 6 – Assess Total Risk Exposure and 4.7.2.2 Schedule
Contingency for more information on the development of schedule contingency).
Step 10 – Prepare schedule information.
•
4.4.3.2
The scheduling software is used to produce various reports and graphics such as
critical path, milestone summary, time-phased budget, and profiles of resources
utilized over the project duration to confirm adequate resource-leveling. A summary
of the baseline schedule and schedule contingency are part of the Project Definition
and are included in the PEP (see Section 3.5.3.4 PEP Subcomponent 3.4 – Integrated
Master Schedule or 2.6.1 Construction Award Management and Oversight for the
specific schedule information to be provided in the PEP).
Schedule Documentation
The baseline schedule is accompanied by a basis document that provides parameters and
underlying assumptions used in developing the schedule for all project stakeholders’
understanding. A well-written Schedule Basis Document will also help oversight groups
assess a schedule’s validity and reliability. For Major Facility projects in the Design and
Construction Stages, the Schedule Basis Document should include the following components
Document Number
238
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
at a minimum:
•
General description of the overall approach to achieving the project goals that gives
a high-level framework of the schedule network logic, the external dependencies, and
key drivers of the Critical Path.
•
Identify key dates used in the schedule development, such as life cycle, decision,
hand-off, etc.
•
A list of schedule assumptions, such as external constraints, procurement durations,
construction calendar/seasons, operations integration requirements, funding
parameters, any significant resource limitations, items excluded from the schedule,
etc.
•
Basis for the constraints, lags, leads, and open-ended activities used in the schedule.
•
An explanation of how the Project Team followed the best practices in the GAO
Schedule Assessment Guide to ensure the schedule meets the four characteristics of a
reliable schedule from the GAO Schedule Assessment Guide.
•
For the well-constructed characteristic, the assessment should include the results
from a software quality assessment tool with explanations for elements that exceed
standard metrics.
•
Schedule contingency analysis and results.
A Schedule Management Plan or estimating plan typically describes the policies, procedures,
tools, and roles and responsibilities to be used to develop and manage the schedule. It is not
the same as the Schedule Basis Document but may include some similar components or be
combined with it in one document. The following components could be included in the
Schedule Management Plan that may be useful in an independent review of the Awardee’s
schedule:
•
Identification of scheduling software options used, i.e., calendars, activity
identifications (LOE, task-dependent, schedule visibility, planning packages, etc.),
project-specific coding used, calculation of Critical paths, progress override
contrasted with retained logic, progress updates with duration updates, etc.
•
Method(s) used for resource-leveling – an explanation of how the project determined
that the time-phased workforce requirements from the schedule are aligned with the
project staffing plans.
•
The process used to update the status and record progress of the project during
execution.
•
Provide a description of the process of converting planning packages to detailed
packages or rolling wave planning, if used. This may be included in an EVMS
Description Document.
4.4.4
Schedule Maintenance During Construction Stage
The baseline schedule used to establish the PMB maintains the original agreed-upon
activities and milestone dates unless altered in accordance with the project’s Change Control
Document Number
239
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
procedures. Work progress is measured regularly by the Project Team and maintained in a
progress schedule, also referred to as a working forecast or status schedule. A comparison
of the progress and baseline schedules indicates the extent to which the project is ahead of
or behind schedule. This comparison also identifies the specific activities and events that are
the source of current schedule variances or impending problems. If the earned value is used,
the schedule status cycles must coincide with the accounting month's end used by the
Awardee to ensure consistency of earned value calculations and reporting.
4.4.4.1
Baseline Schedule
During project execution, a baseline schedule is maintained to compare it against the
progress schedule. The Project Team should document and approve all changes to the
baseline schedule, including activity durations, logic, resources, etc. The Change Control
process and approval thresholds should be documented in the PEP and/or the EVM
procedures for Major Facility and Mid-scale RI projects.
The PMB end date is based on a technically driven schedule within funding limitations and
does not include schedule contingency. The TPD establishes the project risk-adjusted end
date. A project may want to use schedule buffers to manage or monitor interim milestones
or external deliverables to the project, such as subcontract work. These schedule buffers
should be identified as schedule margins with SVT instead of lags. If a schedule margin
(buffer) activity is used in the baseline schedule, its duration should be zeroed out before
running a schedule risk analysis. By doing so, the schedule analysis can be used to determine
the margin durations needed to achieve specific milestones or deliverable requirements. The
schedule margin activity should not drive the PMB end date. Schedule contingency amounts
are not included in the PMB due to NSF’s requirement that contingency is held and managed
separately from the baseline. Allowances may be used in the schedule, as defined in Chapter
8 Lexicon, if adequately justified.
4.4.4.2
Progress Schedule
The progress schedule records the project progress status and forecasts activity and
milestone dates of the remaining work. The PMB end date should be constrained to create
float calculations and identify high-level milestones with negative float. If a delay is deemed
significant, the Project Team should develop a plan to examine options for schedule
recovery. If the negative float cannot be mitigated, the use of schedule contingency may be
necessary to update the baseline milestone date.
The Project Team regularly reviews planned and completed activities to determine progress.
Various methods are used to assess the status of different kinds of activities to ensure that
progress is being determined objectively. Status information from the activity owners
typically includes activity start and finish dates, percentage complete for ongoing activities,
forecast completion dates, and milestones achieved. The Project Team should vet the
progress schedule results and forecast dates before status reporting. It is important to note
that progress information is not used to modify dates in the baseline schedule. The baseline
dates, duration, resources, etc., are only changed utilizing the baseline Change Control
Document Number
240
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
process, including appropriate approval thresholds, as described in Sections 3.5.4.3 PEP
Subcomponent 4.3 – Contingency Management Plan and 4.7.3 Contingency Management.
For work performed under subawards and contracts (referred to as subcontracts), the
Project Team should identify appropriate reporting inputs to ensure objective progress
measurement. Subcontracts may be based on milestones or require the subcontractor to
develop a schedule that supports the project schedule. The Project Team needs to establish
procedures to ensure accurate progress reporting and reliable forecasting from the progress
schedule.
When progress schedule updates forecast significant changes in the schedule and cost to
complete, associated revisions should be made to the ETC to develop a new EAC. Significant
changes to the ETC should be considered for a baseline change or, at a minimum, tracked as
a lien against budget contingency. Prudent maintenance of the Control Account-level EAC
ensures that the EAC reflects a valid projection of project costs. The EAC should be based on
performance to date and new estimates for remaining work but does not include risks and
opportunities within the project’s Risk Register unless they are realized (see Section 4.7.3.3
Contingency Management Forecasting).
4.4.5
NSF Analysis of Construction Stage Resource-Loaded Schedules
NSF uses various oversight tools to assess the reliability of the Awardee’s schedule and
inform NSF stage-gate decisions. The discussion below describes at a high level how these
tools are used to review the Awardee’s schedule against the GAO Scheduling Best Practices
and the documentation needed to conduct these reviews. Questions about these reviews
should be directed to the PO and/or the relevant AO. Appendix II of the GAO Schedule
Assessment Guide identifies qualitative information and key documentation that GAO
Auditors use to assess a schedule. 1
4.4.5.1
Schedule Review Component of Stage-Gate Reviews
The construction schedule develops as the project moves through the Design Stage to
readiness for construction. Section 2.5 Major Facility Design Stage describes each stage-gate
review and NSF expectations for readiness for a project to advance. Figure 2.3.3.2-1
illustrates the progressive phases within the Design Stage and NSF Decision Points. At the
CDR, the schedule is high-level with key milestones and typically based on analogy with
similar projects and/or experience of technical experts. At PDR, an RLS is required at a
sufficient level to develop a time-phased budget and estimate contingencies. As the design
matures toward FDR, the schedule is refined with more detailed activities to be ready for
construction and to be baselined for the EVMS.
Based on internal guidance for PDR and FDR, the schedule should be reviewed for complete
work scope (GAO Best Practice 1), sufficient resources and duration to execute the project
(GAO Best Practices 3, 4, and 7), credible sequence of work (GAO Best Practices 2, 5, and 6),
1
https://www.gao.gov/products/gao-16-89g
Document Number
241
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
and appropriate schedule contingency for risks and estimating uncertainties (GAO Best
Practice 8). The external panel provides expert experience to review the credibility of the
schedule sequence, logic, duration, and resource requirements of activities. Based on the
CDR and PDR results, NSF should provide guidance to the Awardee for implementation into
the FDR schedule relating to the GAO Scheduling Best Practices. At the end of the Final
Design Phase, the Awardee needs to have a reliable construction-ready schedule as defined
by the GAO schedule characteristics to advance to the Construction Stage.
To support the schedule review at PDR and FDR, the Awardee should provide the following
PEP subcomponents further defined in Section 3.5 Construction Stage and Implementation
Planning:
•
WBS Dictionary
•
Full schedule sorted by the WBS - Gantt chart
•
Critical Path and near-Critical Path schedule(s) – Gantt chart
•
List of project milestones by WBS
•
Schedule Basis Document
•
Risk Register with schedule impacts identified
•
Schedule contingency analysis and results
4.4.5.2
Schedule Review Component of Independent Cost Estimate Reviews
NSF may utilize independent cost estimates and cost estimate reviews, in some cases
performed by independent contractors or other government agencies, to inform the NSF
Cost Analysis (see Section 4.3 Cost Estimating and Analysis). In conjunction with an
independent cost estimate review, NSF may include an independent review of the Awardee’s
schedule and schedule contingency analysis using GAO Scheduling Best Practices or
developing an independent schedule and schedule contingency. NSF’s selection of the type
and scope for an independent cost estimate review should follow internal guidance.
An independent review of an Awardee’s schedule would typically include an assessment of
the GAO schedule characteristics, comprehensive (GAO Best Practices 1, 3, and 4) and wellconstructed (GAO Best Practices 2, 6, and 7), in accordance with NSF expectations as
described in Section 4.4.2 Characteristics of a Reliable Schedule. This review may also assess
the methodology used by the Awardee for the schedule contingency analysis (GAO Best
Practice 8). The external panel for a stage-gate review would usually provide expert
experience in reviewing the schedule risks and associated impacts used in the schedule
contingency analysis.
To support the development of an independent schedule and schedule contingency, the
Awardee will need to provide the same detailed technical information that was used to
develop the schedule, such as the following PEP subcomponents further defined in Section
3.5 Construction Stage and Implementation Planning:
•
Technical specifications and requirements
Document Number
242
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
•
System design drawings and technology selections
•
Key assumptions
•
WBS
•
Schedule Basis Document
•
Schedule Management Plan, if used
To support an independent review of the Awardee’s schedule and schedule contingency
analysis, the Awardee should provide the following supporting files in addition to the stagegate review PEP subcomponents further defined in Section 3.5 Construction Stage and
Implementation Planning:
•
Baseline RLS source file
•
Schedule contingency analysis source file(s)
•
Major subcontractor schedule, if applicable, and the associated terms and conditions
4.4.5.3
Schedule Review Component of NSF EVMS Verification Review
As part of NSF’s EVMS verification review, discussed in Section 4.5.4.2 Verified Earned Value
Management Systems, the Awardee’s processes for maintaining a PMB schedule (GAO Best
Practice 10) and updating the progress schedule (GAO Best Practice 9) are assessed per EIA748 EVM guidelines for implementation of EVMS. 1 This review specifically addresses the
status of the schedule and measuring performance, Change Control processes and
documentation, and vertical traceability with lower-level schedules (i.e., subcontractor
schedules) as applicable (GAO Best Practice 5). The EVMS verification review is informed by
other NSF reviews, including the FDR stage-gate review for assessment of EIA-748 EVM
guidelines associated with other Scheduling Best Practices such as complete work scope in
the schedule (GAO Best Practice 1) and resources assigned to all the activities (GAO Best
Practice 3).
To support an EVMS verification review, the Awardee should provide the following
documents in addition to the FDR project documents for assessment of the GAO Scheduling
Best Practices:
•
EVM System Description
•
Change Control process description
•
Project Controls’ schedule procedures for schedule progress and maintenance
•
Baseline RLS source file
•
Major subcontractor schedule, if applicable, and the associated terms and conditions
•
Schedule Management Plan, if used
1 https://www.ndia.org/-/media/sites/ndia/divisions/ipmd/division-guides-andresources/ndia_ipmd_intent_guide_ver_d_aug282018
Document Number
243
4.4 Schedule Development, Estimating, and Analysis Infrastructure Guide
4.4.5.4
Schedule Review Component of NSF Cost Analysis
As part of the NSF Cost Analysis, conducted following internal guidelines, the Awardee’s
schedule will be assessed for alignment with GAO Scheduling Best Practices to determine if
the schedule meets the four characteristics of a reliable schedule as discussed in Section
4.4.2 Characteristics of a Reliable Schedule. This schedule analysis will be led by the RIO, will
include a technical evaluation from the stage-gate review, and may include input from an
independent schedule review and/or EVMS verification review (see Section 4.3 Cost
Estimating and Analysis).
Document Number
244
4.5 Monitoring Progress Against Plan Infrastructure Guide
4.5
MONITORING PROGRESS AGAINST PLAN
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Every RI project is required to undergo periodic and accurate assessments of its current state
and forecasted trajectory towards the planned future state. These assessments are required
to facilitate reporting to NSF and inform and facilitate sound decisions and changes
necessary to ensure the project's success.
There are a variety of approaches to monitoring
progress against a plan that may be NSF Requirement
appropriate to implement on a project. For • Major Facilities must use a verified
example, a common and well-accepted method
EVMS to monitor project progress
against the PMB.
is the application of an EVMS. Major Facility
Awardees must employ a verified EVMS during • Mid-scale RI must have an objective
means to monitor project progress
construction (see Section 4.5.4.2 Verified
against the plan.
Earned Value Management Systems). For Midscale RI, other monitoring methods may also be
acceptable depending on the project type, size, and level of complexity.
Monitoring progress against a plan specifically focuses on tracking the actual progress of
tasks and activities compared to a planned schedule, budget, or other predefined metrics. It
involves regularly reviewing project performance data to assess whether the project is on
track and identifying any deviations from the original plan. This process helps project
managers and stakeholders stay informed about the project's status and make informed
decisions to address any risks and issues that may arise.
4.5.1
Performance Measurement and Management
Performance Measurement and Management (PMM) is a component of the broader Project
Controls process (see Figure 4.5.1-1) and provides the framework for evaluating overall
project performance. Monitoring progress against the plan is a specific activity within that
framework focused on tracking the actual execution of tasks compared to a planned
schedule, budget, or other metrics.
Performance measurement refers to measuring, comparing, and analyzing performance
against the PMB, which monitors the progress of planned tasks toward specific
predetermined goals and objectives. Performance Management involves monitoring the
variances identified through performance measurement and then implementing corrective
actions, as needed, to ensure the successful progress of the project.
Document Number
245
4.5 Monitoring Progress Against Plan Infrastructure Guide
Figure 4.5.1-1
Three-Step Framework for PMM Within the Context of Project Controls: Monitoring Progress Against Plan
Methods for monitoring progress against a base plan typically follow a three-step
framework, as shown in the Project Controls Process figure above. These steps are:
Measure and Compare Actuals Against the Total Project Definition. The first step of any
good progress measurement system is to gather inputs that reflect the current state of the
project and compare these against the Total Project Definition (PMB + Contingency and
Fees). For example, Actual Expenditures associated with a specific WBS element should be
compared against the Time-Phased Budget profile of that element. The difference between
the Actuals and the associated PMB element is a variance against a plan. Variances can be
positive or negative, meaning the current state of the project is ahead or behind a plan. 1
Variances that should be measured include Scope Production Status, Adherence to Quality
Acceptance Standards, Schedule Performance, Budget Performance, and Risk-vs.Contingency status. Further, forecasted variances for future performance (such as an
updated EAC) should also be included. Finally, as part of this Measure and Compare step, all
1 Note that variances in and of themselves are neither good nor bad; they are simply information to be used to
understand and make informed decisions.
Document Number
246
4.5 Monitoring Progress Against Plan Infrastructure Guide
variances should be documented in a variance report (e.g., in a Cost Performance Report) at
the appropriate level.
Analyze Variances. The second step in monitoring progress is to review and analyze the
current variances (including trends from previous reporting periods). The goal is to
understand each variance, including the root cause(s) of variance and the impact and/or
expected ramifications if the variance is not addressed.
Identify and Decide Upon Corrective Actions as Required. The third step in monitoring
progress is to identify and decide upon corrective actions for each variance that may be
necessary to adjust the trajectory and ensure the project remains on track to a successful
outcome. There are typically four actions that can be taken.
•
No change is required, and the monitoring should continue.
•
Minor plan adjustments that don’t require formal change control.
•
Re-plan via formal project change control.
•
Re-baseline the project. 1 Every project should approach this step uniquely.
The specific processes should be defined within a management plan appropriate to the life
cycle stage (DEP, PEP, or AWP). For example, this includes, but is not limited to, roles and
responsibilities, the metrics, thresholds, and authorities to make decisions in place, required
notification and approvals, documentation requirements, etc.
4.5.2
Essential Qualities of a Progress Monitoring System
Monitoring progress against a plan should not be viewed simply as producing static metrics
or as a compliance report. Instead, the project's progress monitoring system should be
implemented to provide the Awardee’s management team with a reliable basis for
objectively assessing performance against plan, identifying potential issues, forecasting
future trends, and initiating corrective action. When selecting a PMM method for an RI
proposed project or project, the following qualities and characteristics should be addressed:
•
Identified and Documented Process. The selected progress monitoring method
should be a recognized documented process with explicit and established procedures
and plans and may include specific roles, responsibilities, and lines of authority.
•
Comparison of Actuals Against PMB. The progress monitoring method should
provide defined metrics and accurate assessments (i.e., variances) of Scope
Production, Quality Status, Schedule Performance, Budget Performance, and Risk
Exposure-vs.-Contingency Status.
•
Accurate Forecasting Predictions. The progress monitoring method should allow
for accurate predictions or forecasting of future project performance, providing early
warning of potential issues.
1 Re-Baselining is appropriate only when significant changes to the project are required. This includes increases in
the NSB-authorized Total Project Cost (TPC), a schedule extension beyond the total project duration, and/or
significant changes in scope. Re-baselining requires approval of NSF and may involve the NSB.
Document Number
247
4.5 Monitoring Progress Against Plan Infrastructure Guide
•
4.5.3
Compatible Reporting. The variance reports generated by the progress monitoring
method should be compatible with NSF processes and organization (i.e., the plans
and reports NSF expects to see).
Allowable Progress Monitoring Systems
All Major Facilities and Mid-scale RI Awardees must implement an appropriately tailored and
scaled progress monitoring method for construction or implementation. The selected
progress monitoring method should match the project’s characteristics, size, and complexity,
and should describe in detail how PMM will be conducted.
The selected progress monitoring method should be compatible with the chosen project
framework (e.g., traditional, Agile, hybrid, etc.) Similarly, the method should be scaled to the
size and complexity of the project. For example, on small, simple projects, the progress
monitoring system may consist of simple metrics and comparison charts and spreadsheets
of actual expenditures-vs-budget and risk-vs-contingency, milestone tracking and/or
percentage complete charts for scheduled activities, and a basic compliance matrix for scope
production. EVM is often the preferred approach for more complex projects. For Major
Facility construction projects, Awardees must implement a formal verified EVMS; see Figure
4.5.3-1.
Figure 4.5.3-1
Illustrative Example: Methods for Monitoring Progress Against the Base Plan
Document Number
248
4.5 Monitoring Progress Against Plan Infrastructure Guide
Figure 4.5.3-2
Burndown Chart Example: Contingency (Red Line) and Total Risk Exposure (Blue Line) Comparison, Emphasizing Best
Practice
Table 4.5.3-1
Example of Level-1 Milestone Tracking: Comparison of Actual versus Planned Progress
Level 1 Tracking Milestones
Activity (Milestone) Name
Planned Date
Finished Date
Delta
Utility Building Beneficial Occupancy Date (BOD)
19-Dec-24
16-Dec-24
3
Major Earthwork and S&O Foundations Complete
24-April-25
29-April-25
-5
Instrument Final Designs Complete
22-May-26
28-Aug-26
-98
Primary Mirror Blank – Polishing Complete
15-Nov-27
15-Oct-27
30
Enclosure Weather-tight, Ready for TMA
20-Jan-27
24-Feb-27
-34
TMA Installation Complete
2-Oct-28
First Light Achieved
15-Jan-30
Start of Operations
30-Sep-31
If EVM is used as the progress monitoring method for a Mid-scale RI, it should be tailored
and scaled to the project's needs (see Section 4.5.4 Earned Value Management). Regardless,
the selected progress monitoring approach is subject to NSF approval before project
execution activities commence.
All progress monitoring plans should be documented in a management plan appropriate to
the life cycle stage, describing the details, approaches, and expectations of the system,
including:
Document Number
249
4.5 Monitoring Progress Against Plan Infrastructure Guide
•
Metrics and how measurable data will be gathered.
•
How comparisons to the PMB and analyses will be conducted.
•
The WBS level at which analysis will be performed.
•
What specific variances and indices will be reported.
•
What reports will be generated.
•
The cadence of analysis and reporting.
•
How corrective actions will be identified and decided upon.
4.5.4
Earned Value Management
4.5.4.1
Earned Value Management – The Seven Principles
EVM is a common methodology for progress monitoring. There are two levels of rigor for
EVM used by Awardees. For Major Facilities, Awardees must use a fully verified EVMS that
follows EIA-748 guidelines. For all other RIs, a non-verified version of EVMS that follows NSF
requirements may be employed. The requirements for each of these EVM approaches are
described below. Regardless of approach, however, all EVMS should comply with the
following seven principles:
•
Plan the project's scope to completion using discrete work packages and planning
packages.
•
Break down the project work scope into finite pieces, assigning each piece to a
responsible person or organization to control technical, schedule, and cost objectives.
•
Integrate project work scope, schedule, and cost objectives into a performance
measurement baseline plan against which accomplishments are measured. Control
changes to the baseline.
•
Use actuals incurred and performance attained in accomplishing the work
performed.
•
Objectively assess accomplishments at the work performance level.
•
Analyze significant variances from a plan, forecast impacts, develop corrective
actions, and prepare an EAC based on performance to date and the remaining work
to be performed.
•
Use the EVMS information in the project's management processes.
4.5.4.2
Verified Earned Value Management Systems
Major Facility Awardees must use an NSF-verified EVMS that follows EIA-748 guidance for
successful project planning and execution. To ensure that the Awardee’s EVMS data provide
timely, accurate, and reliable performance information, NSF conducts RI EVMS Verification,
Acceptance, and Surveillance (VAS) based on the processes recommended in the National
Defense Industrial Association (NDIA) Earned Value Management Guides as part of the RI’s
Document Number
250
4.5 Monitoring Progress Against Plan Infrastructure Guide
oversight and monitoring activities. 1
As part of the VAS process, the Awardee should demonstrate it has a structured
management process that follows the principles of EIA-748 EVMS standards and provides a
sound basis for performance measurement, problem identification, corrective actions, and
management re-planning activities as required. NSF's VAS process is intended to ensure that
the implementation of EVMS is appropriately scaled and applied to the project's
management needs. For the Awardee to utilize the full benefits of EVMS and aid the
successful execution of the project plan, the EVMS should address all nine processes, and all
32 guidelines applied in a way that reflects the size, complexity, risk, and nature of the work,
as noted in the NDIA EVMS Guideline Scalability Guide. NSF's verification and acceptance of
an Awardee’s EVMS is not intended to be a certification of an Awardee’s EVMS. As a result, it
should not be used by other government or contracting agencies, nor can it be extended to
other NSF projects managed by the Awardee. If an Awardee has a current EVMS certification
or equivalent verification from another federal agency, the NSF EVMS verification review may
be modified. However, NSF acceptance will still need to be documented, and ongoing
surveillance will be performed.
The award EVMS verification is performed through an NSF review process (see Chapter 2 NSF
Life Cycle Oversight). NSF strongly encourages projects to utilize EVMS to the extent
practicable during the Design Stage to prepare for full implementation during
implementation or the Construction Stage. NSF aims to complete the EVMS verification
review before awarding construction funds. NSF also aims to accept the project's EVMS
before actual physical construction or major acquisitions commence, based on acceptable
resolution of the findings from the EVMS verification review.
RIO has responsibility for EVMS VAS process. After acceptance and during execution,
periodical surveillance reviews may be conducted to ensure that the accepted EVMS is being
maintained and followed and that the EVM data and information are being used to inform
management decision-making. The frequency and focus of surveillance reviews are
determined by the PO in consultation with the RIO via the RIO Liaison but are generally
conducted as part of the annual construction review to minimize burden. The scope of the
surveillance reviews can include all EIA-748 guidelines or concentrate on specific areas of
interest. Targeted surveillance reviews may result from corrective actions, new procedures,
and/or demonstration of practice.
4.5.4.3
Non-Verified EVMS
NSF recognizes that a fully verified EVMS subject to VAS may add unnecessary administrative
burden to Mid-scale RI. To allow the benefit of EVM without adding extra burden, NSF uses
a more flexible EVM framework to assess smaller and less complex projects that encourages
use of the seven key principles but only four of the processes and 18 specific identified
guidelines. That is, a properly implemented EVMS should be no more complex than is
1 https://www.ndia.org/divisions/ipmd/division-guides-and-resources
Document Number
251
4.5 Monitoring Progress Against Plan Infrastructure Guide
necessary to inform sound project management decisions and provide required reporting
data to NSF.
Figure 4.5.4.3-1
NSF Scaled (Non-Verified) EVMS Process: Application of 18 of 32 EVMS Guidelines Aligned with the 7 Basic Principles of
EVMS
Process 1 – Define and Organize the Project (Principles 1 and 2)
This process aims to ensure that the project scope is well-defined, and that responsibility is
clearly assigned for each component. This will allow the organization of the project to meet
EVMS Basic Principles 1 and 2. EVMS Guidelines 1, 2, and 5 are the primary reference
guidance for this process, which is broken down into three key steps:
Define project scope in terms of WBS. Refer to Section 3.5.1.4 PEP Subcomponent 1.4 –
Research Infrastructure Description for the explanation and guidance for WBS and an
accompanying WBS Dictionary. The more detailed levels of WBS, the more details are
required and need to be managed. The key to a properly scaled EVM is to set the WBS level
details at a reasonably high level but detailed enough to provide sufficient visibility of the
project's work scope for management control.
Define the project organization via an Organization Breakdown Structure (OBS). Refer to
Document Number
252
4.5 Monitoring Progress Against Plan Infrastructure Guide
Section 3.5.2.3 PEP Subcomponent 2.2 – Internal Project Organization for guidance on the
project organizations. To ensure the project will benefit from EVM, the project's internal
organization breakdown should link to the WBS, and the responsibility for each WBS element
should be clearly identified.
Identify organizational responsibility for work, including significant subcontractors, for
sufficient management/control. The Project Team should identify and assign the person or
organization unit responsible for each WBS element's scope, schedule, and budget
management. For efficient control, one group is typically responsible for the full scope at the
lowest level of the WBS.
Process 2 – Establish Project Cost, Schedule, and Contingencies (Principle 3)
This process aims to establish the project's cost and schedule baseline against which the
project's progress is measured during execution. This process ensures the project meets the
expectations of the EVMS Basic Principle 3. In addition to setting the project's cost and
schedule baseline, the budget and schedule contingencies should also be estimated. Project
milestones should also be defined and identified in the project baseline schedule. EVMS
Guidelines 6, 7, 8, 9, 13, and 14 are the primary reference guidelines for this process, broken
down into four key steps.
•
Schedule the work with logical sequencing and task dependencies. Refer to Section
4.4 Schedule Development, Estimating, and Analysis for guidance in the development
of an RLS as part of the project baseline. The level of detail should be suitable for the
management control needed. For a less complex project using a non-verified EVM,
the activity breakdown for scheduling can be less detailed, and summary-level
activities/ tasks could be used when the measurement for progress is clear.
Identify technical milestones and/or other methods for progress measurement. Refer to
Section 4.4 Schedule Development, Estimating, and Analysis for guidance on identifying
milestones in the development of the baseline schedule. Technical milestones are important
indicators for progress measurement. Milestones with assigned monetary value can be used
in conjunction with summary-level tasks to calculate earned value. For some projects,
appropriately time-spaced milestones can be sufficient for the sole progress measurement
method.
Establish a time-phased budget by WBS and incorporate indirect costs. Based on the
resource assignment for activities in the baseline schedule, a time-phased budget can be
established for each WBS element. Refer to Section 4.4 Schedule Development, Estimating,
and Analysis for more guidance on developing time-phased budgets.
Assess project risks and estimate uncertainties to establish budget and schedule
contingency. The Project Team should identify technical, cost, and schedule risks and
develop a Risk Register and Risk Management Plan to manage identified risks. The
contingency estimates should be based on the total estimated project risk exposure. Refer
to Section 4.6 Risk Management for guidance on developing a Risk Register and Section 4.7
Contingency Estimating and Management for establishing the budget, schedule, and scope
contingencies. A probabilistic risk analysis is typically not used on smaller scale and less
Document Number
253
4.5 Monitoring Progress Against Plan Infrastructure Guide
complex projects.
Process 3 – Progress and Performance Monitoring (Principles 4, 5, 7)
This process aims to ensure the Project Team uses the EVM concept for quantitative
measurement of progress and that the progress data is reliable and used by management
to achieve project goals. EVMS Guidelines 17, 18, 22, 23, and 26 are the primary reference
guidelines for this process, broken down into five key steps.
Define Control Accounts based on the project's WBS and Organization Breakdown Structure
(OBS). The Project Team should set up Control Accounts at the appropriate level of WBS. The
higher the WBS level for Control Accounts, the less earned value data detail. Proper EVMS
sets the Control Accounts at the WBS level to suit the management control needs. Each
Control Account should have a clearly assigned responsible person as the Control Account
Manager (CAM) and the organization unit responsible for delivering the scope under this
Control Account. This should be consistent with the OBS established in PEP Subcomponent
2.2 – Internal Project Organization. The CAM is accountable for completing the
corresponding WBS element's work scope within the Control Account's planned budget and
time duration according to the baseline.
Record and summarize actual costs by Control Accounts. After the Control Accounts are
established, the Project Team should record monthly actual costs by Control Accounts. The
actual cost should be reconciled periodically with the financial system's accounting
statements. The Project Team should have a process to ensure the actual cost report
includes estimated costs consistent with completed work to accurately compare actual costs
to planned values.
Record task progress and summarize earned value for completed work by WBS. The Project
Team should assess each work activity's progress to calculate the earned value for all
activities and then summarize the earned value for each Control Account. The CAM is
primarily responsible for providing input on the progress assessment for all activities.
Summarize schedule and cost performance at select levels of the WBS and perform variance
analysis. Periodically, the Project Team should summarize earned value and compare it with
the baseline plan and actual costs, which typically occurs in a Cost Performance Report. The
Project Team should establish a variance threshold for the CAMs to analyze variance,
describe schedule, and cost performance variances, understand their root causes, and
describe their impacts if left unchanged.
Management actions using information from variance analysis. Based on the information
from the variance analyses, the Project Team should take corrective actions and mitigate
threats to ensure the project execution meets the cost and schedule goals.
Document Number
254
4.5 Monitoring Progress Against Plan Infrastructure Guide
Process 4 – Management Analysis and Control (Principles 6 and 7)
This process aims to ensure the Project Team uses earned value data and forward-looking
metrics to forecast the project's cost and schedule performance and to allow for early
detection of potential issues. The forward-looking metrics are valuable input that EVM can
provide, in addition to reporting on past performance. The Project Team should use forwardlooking metrics to inform management decisions and make timely adjustments to the
project planning necessary for its success. The changes to the project's PMB should be
controlled to ensure the integrity of the baseline and the reliability of the earned value data.
EVMS Guidelines 25, 27, 28, and 32 are the primary reference guidelines for this process,
broken down into four key steps.
Incorporate major changes to the project plan with Change Control. When the Project Team
makes major changes or adjustments to its plan, those changes should be incorporated into
the PMB through an established Change Control Process (CCP). The Project Team should
identify approval authorities and define thresholds for different levels of change and timely
incorporate such changes into the baseline upon approval. The changes should be forwardlooking and not be used to modify performance to date.
Periodically update estimates of remaining work. The Project Team should perform cost and
schedule estimate updates for the remaining work, especially when new information is
available. Depending on the task complexity and TPD, the Project Team can decide the
frequency of such updates to suit the management needs. The process for updating the
estimates for each WBS may also help identify potential threats and upcoming issues. The
forecast and identified potential issues can be used to inform the management decision
process. The Project Team should also forecast EAC based on the updated estimates for the
remaining work and compare the EAC to the TPC. If the EAC exceeds the Total Project Budget,
management may need to consider descope options.
Update risk assessment and assess the remaining contingencies. The Project Team should
update the Risk Register, assess the total risk exposure, and evaluate the remaining
contingencies against the remaining exposure.
Summarize project status and forecast milestones for NSF reporting. The Project Team
should summarize performance narratively and provide earned value data, forecast EAC,
and forecast milestones in a status report to NSF.
Document Number
255
4.6 Risk Management
4.6
Research Infrastructure Guide
RISK MANAGEMENT
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Risk Management includes the processes and methods used in planning, identifying,
analyzing, responding to, monitoring, and reporting risks. This section provides information
on risk management methodologies and strategies that can be adapted and applied by
Awardees during all RI life cycle stages.
Risk is an inherent aspect of the unique, highly technical, and scientifically ground-breaking
research supported by NSF. Failure to adequately identify and manage risks increases the
likelihood that the Awardee may not meet its objectives. Successful risk management entails
early recognition, proactive planning, and rigorous execution of all risk management
processes. Ideally, risk management begins as early as the Development Stage of the RI’s life
cycle and continues during Design, Construction / implementation, Operations, and
Disposition Stages.
Table 4.6-1
Risk, Opportunity, and Threat per RIG Definition
Item
RIG Definition
Note/Comment
Risk
A potential event that, if it
occurs, may have either a
positive or negative impact
on objectives.
Contrary to our everyday idea of what risk means, a project risk
could have either a positive or a negative effect on progress
toward project objectives. There is also often confusion between
risks and hazards; risks are programmatic concerns (e.g.,
impacting RI scope, schedule, or budget), while hazards are
safety concerns (e.g., posing a physical danger to RI equipment
or personnel.)
Opportunity
A risk that, if it occurs, may
have a positive impact on
objectives.
The goal of risk management is to enhance opportunities by
increasing either their likelihood of occurring and/or their impact
if they do occur.
Threat
A risk that, if it occurs, may
have a negative impact on
objectives.
The goal of risk management is to diminish threats by
decreasing either their likelihood of occurring and/or their impact
if they do occur.
The risk management strategy and process outlined in this Guide are based on standard
project risk management principles adapted by Awardees. While many guides for risk
management exist, the most effective approaches and processes are those that are tailored
and scaled to the size, characteristics, organizational culture, structure, and circumstances
of each RI. For example, risk management plans suitable for operations may differ from
plans for construction of facilities. Simple, low-risk projects may use basic tools and methods
implemented by Project Team members, while more complex, high-risk projects may
necessitate sophisticated tools and employ risk management experts. Further, risk
management planning is often best served via a progressively elaborating approach: simple
methodologies and procedures adopted early in the RI planning may be replaced with more
sophisticated approaches as planning matures or as a need for new or changed approaches
becomes apparent.
The typical risk management process entails seven key steps and three key outputs, as
Document Number
256
4.6 Risk Management
Research Infrastructure Guide
shown in Figure 4.6-1.
Figure 4.6-1
A Typical Risk Management Process with Seven Steps and Three Outputs
The steps of the process are repeated on a regular cadence to ensure all relevant risks are
captured, documented, analyzed, and appropriately responded to, until all risks are retired.
A summary explanation of the seven steps of the risk management process is as follows. For
more detailed information, see the seven respective sections below.
•
Plan Risk Management. The primary output of this step is a documented Risk
Management Plan. The Risk Management Plan lays out the overall approach to how
risk will be addressed in the effort, including overall risk tolerance and strategies. The
Document Number
257
4.6 Risk Management
Research Infrastructure Guide
Risk Management Plan also describes the methods and processes to be used during
the management of risk, roles and responsibilities, reporting cadences, etc.
•
Identify and Document Individual Risks. The purpose of this step is to identify and
document all relevant RI risks. The primary output of this step is the creation of a Risk
Register that is populated with all relevant identified risks. The Risk Register is a living
document used as a basis for all tracking, analysis, and reporting.
•
Analyze and Rank Individual Risks. The purpose of this step is to assess each risk
in terms of its current probability of occurrence, the impact that would result if the
current risk were to occur, and the calculated exposure of the risk.
•
Apply Individual Risk Responses to Reach Acceptable Level. The purpose of this
step is to review the risk and determine if it can or should be accepted in its current
state. If it can’t or should not be accepted, then risk responses should be applied until
acceptable. For threats, response typically means avoidance, transference, or
mitigation of the risk to decrease its likelihood and/or impact. For positive risks
(opportunities), response typically means exploitation, sharing, or enhancement of
the risk to increase its likelihood and/or impact. After risk reduction/ enhancement
responses are applied, Step 3 is repeated to analyze the residual risk exposure and
further reduce the threat (or increase the opportunity). The process is repeated until
the risk is accepted.
•
Establish Individual Issue Response Plans. This step develops initial response plans
if/when individual risks are realized, i.e., if the risk occurs and changes from a
potential event to an actual issue.
•
Assess Overall Project Risk Exposure. This step assesses the residual risk exposure
of all existing risks combined in the aggregate. This residual exposure should then be
covered by RI contingency or some other source of means.
•
Report, Monitor, and Update Individual and Overall Project Risk(s). This step
communicates the current risk status to key stakeholders (e.g., NSF). It also ensures
regular monitoring of existing risks, identifies new risks, retires expired risks, and
updates the status of all risks captured in the Risk Register.
The three key outputs or products of the risk management process that apply to NSF life
cycle management plans are:
•
Risk Management Plan. A documented plan that describes the process by which the
RI will follow to perform the seven risk management steps above.
•
Risk Register. A document used to capture all identified risks.
•
Total RI Risk Exposure. An estimate of the total cost and schedule vulnerability of
the RI if/when identified risks are realized. This exposure estimate may then be used
to quantify the necessary amount of contingency (budget, schedule, and/or
scope/quality) necessary to allay and offset overall RI risk.
Awardees should conduct risk management on all awards. The minimum risk management
process step requirements for each individual life cycle stage are shown below in Table 4.6-2.
Document Number
258
4.6 Risk Management
Research Infrastructure Guide
The individual elements should be tailored and scaled to match the size, complexity, and
nature of the award. The elements should also be discussed and agreed upon with the
cognizant PO. Also note that if a budget contingency is included in the RI award, then risk
management must be implemented.
Table 4.6-2
Seven Risk Management Process Steps Per RI Life Cycle Stage
Risk Management Process Per Life Cycle Stage
Development
Stage
Design Stage
Implementation
or Construction
Stage
Operations
Stage
Recommended.
Tailored & scaled
as appropriate for
complexity of
design.
Required. Formal
Risk Mgmt Plan
that is placed
under
configuration
control.
Required, if
contingency is
used, otherwise
recommended.
Recommended.
Tailored & scaled
as appropriate for
planned activities.
2. Identify &
Recommended.
Recommended.
Document
E.g., a written list Tailored & scaled
Individual Risks of significant risks. as appropriate.
E.g., simple Risk
Register.
Required.
Systematic risk
identification and
creation of Risk
Register.
Required.
Systematic risk
identification and
creation of Risk
Register.
Recommended.
Tailored & scaled
risk capture
document as
appropriate.
1. Create Risk
Management
Plan
3. Analyze &
Rank Risks
Recommended.
E.g., a simple “1page” Risk Mgmt
Plan.
Disposition
Stage
Recommended.
E.g., qualitative
heat map of all
identified risks.
Recommended.
Tailored & scaled
as appropriate.
E.g., estimated
likelihood and
impact.
Required.
Likelihood (%)
and Impact ($)
calculated for
each identified
risk.
Required.
Likelihood (%)
and Impact ($)
calculated for
each identified
risk.
Recommended.
Tailored & scaled
as appropriate,
ranging from
qualitative heat
map to
quantitative % &
$.
4. Develop Risk Recommended.
Responses & i.e., respond to
Implement
significant (red)
risks.
Recommended.
i.e., respond to all
appropriate risks
as required.
Required. All
identified risks
reduced to
accepted state.
Required. All
identified risks
reduced to
accepted state.
Recommended.
At minimum,
respond to
significant risks.
5. Develop Issue Recommended.
Responses
Develop issue
response plans
for significant
risks.
Recommended.
i.e., develop issue
responses as
required.
Recommended.
i.e., develop issue
responses as
required.
Recommended.
i.e., develop issue
responses as
required.
Recommended.
Develop issue
response plans
for significant
risks.
Not Required.
Not Required.
Required. Total
risk exposure
calculated and
covered by
contingency.
Required, if
Not Required.
contingency used,
otherwise
recommended.
Total risk
exposure
calculated and
covered by
contingency.
Recommended.
Update on
appropriate
cadence.
Recommended.
Update on
appropriate
cadence.
Required. Risk
status reported
and monitored
and updated on
appropriate
cadence.
Required. Risk
status reported
and monitored
and updated on
appropriate
cadence.
6. Calculate
Overall Project
Risk Exposure
7. Report,
Monitor, and
Update Risks
Document Number
Recommended.
Update on
appropriate
cadence.
259
4.6 Risk Management
4.6.1
Research Infrastructure Guide
Step 1 – Plan Risk Management
The objective of Step 1 of the risk management process is to create a Risk Management Plan
that describes an agreed-upon framework and approach the Awardee will employ. At a
minimum, the Risk Management Plan should address each of the seven process steps
outlined above. The development of a Risk Management Plan starts early during the planning
stage of a life cycle. It is iterative and continuous, and the Risk Management Plan may need
to be re-addressed and updated throughout the life of the RI.
A typical Risk Management Plan includes, but is not limited to, the following elements:
•
Introduction. Summarizes the purpose, scope, goals, and objectives of the Risk
Management Plan. Also addresses the Awardee’s overall risk tolerance (i.e., risk
appetite) and other high-level considerations, such as the availability of contingency
resources and how they will be managed.
•
Risk Management Organization. Includes a list of RI staff who manage risk on the
award. A list of their roles and responsibilities is included, along with a corresponding
organizational chart and/or Responsible, Accountable, Consulted, and Informed
(RACI)-type matrix that describes who is responsible, accountable, consulted, and
informed on risk activities. (See Table 4.6.1-1 Example Risk Management Roles and
Responsibilities Table for typical risk management roles and responsibilities.)
•
Risk Management Framework. Describes and explains the approaches, methods,
and tools that will perform the iterative steps of the risk management process (i.e.,
identification and documentation, analysis and ranking, risk responses, issue
response plans, risk exposure estimation, and monitoring/updating/reporting).
•
Additional Sections. Includes supplemental information needed to explain how risk
is managed on the award. Depending on the nature of the RI, these sections may
include appendices, templates, checklists, a glossary of terms and acronyms, and so
on as required.
Good Practices and Practical Considerations
•
Maintaining a Risk Register is a beneficial practice for all life cycle stages, even when
contingency is not involved, and a formal Risk Management Plan is not required.
•
When developing a Risk Management Plan, several factors should be considered,
including how sophisticated and detailed it needs to be. The risk framework
(methodologies and tools) should be tailored and scaled to the RI’s characteristics,
including scope, complexity, and overall risk appetite. For example, a construction
project that includes several challenging procurements and complex in-house tasks
may require commercial risk management software and the employment of a
specialized risk manager, while a simpler operations-type of award that entails
oversight of largely repetitive tasks may be adequately served by in-house
spreadsheets and simple algorithmic or scaled contingency estimations.
•
After drafting and approval, the Risk Management Plan is typically kept under
Document Number
260
4.6 Risk Management
Research Infrastructure Guide
configuration management. It should be periodically reviewed but only formally
revised as strictly necessary, such as during a project re-baseline or major change in
project plans and assumptions. In contrast, a Risk Register is continuously updated to
reflect the project’s current status and evolving knowledge and understanding of the
RI’s risks.
•
Good practice is to assign a single risk manager who is responsible for the Risk
Management Plan and leads the ongoing execution of the risk management process.
For smaller, less complex RIs, this assignment is typically given to an existing staff
member with other duties and responsibilities (e.g., project manager or system
engineer). In contrast, for large and complex RIs, the risk manager may solely be
responsible for risk-related duties and overseeing the Risk Management Plan. A
focused risk management team may also be formed. Outsourcing or contracting risk
management may also be preferred, depending upon the nature of the RI.
•
Proper risk management is vital to RI's success. As such, the activities and associated
costs related to risk management should be captured during planning and accounted
for in the RI budget and schedule. These costs should include team member time
focused on risk during the execution of the RI, as well as discrete costs such as
commercial risk management software and licenses and the hiring or contracting of
risk management experts.
•
Proposed Design project Awardees should note that the Risk Register covering the
design award activities is distinct from the Construction Stage Risk Register included
in the PEP as a Design Stage deliverable. The risks in the Design Stage are not the
same as those that will be encountered under a separate construction award.
Document Number
261
4.6 Risk Management
Research Infrastructure Guide
Table 4.6.1-1
Example Risk Management Roles and Responsibilities Table
Position
Roles and Responsibilities
Project
Management
Encourage all levels of the project organization to participate fully and openly in the risk
management process.
Make project decisions based in part on the results of risk analysis and authorize risk
response implementation.
Risk Manager
Oversee the Identification and documentation of new risks (threats and opportunities) in the
Risk Register and assign risk ownership.
Oversee the Project Team’s analysis of risks and work with them to develop initial and
remedial response plans.
Monitor and update risks and identify lessons learned.
Recommend and champion response implementation strategies to the Project Manager (PM)
and/or Change Control Board (CCB) on behalf of the risk management team.
Maintain the Risk Register and report risk status to stakeholders.
Oversee Project Risk Exposure estimation.
Change
Control Board
Members
Review and approve proposed changes to ensure alignment with project objectives and
minimize risks to project success.
Provide input and guidance on change prioritization, resource allocation, and impact
assessment to facilitate informed decision-making and effective change management.
Typically chaired by a senior project manager, project sponsor, or another high-level
stakeholder with authority to make decisions regarding changes to the project.
Project Team
Members
Participate in risk identification, analysis, and response planning on a daily basis, as well as in
risk workshops, status meetings, and interviews to provide risk data.
Assist the risk manager and risk owner with monitoring and updating risk status.
Risk Owner
Assist the risk originator (project manager, risk manager, project team member, etc.) with the
development of the risk descriptions, analysis, and development of risk response plans.
Implement or be responsible for the implementation of risk response plans.
Monitor assigned risk triggers and status and update the Risk Register as needed.
Attend project status and risk review meetings, as needed, and assist the PM with reporting
risk status.
Contribute lessons learned.
4.6.2
Step 2 – Identify and Document Risks
The objective of Step 2 of the risk management process is to discover and formally capture
all relevant risks (both threats and opportunities) that impact the RI’s successful execution.
Risk identification should follow a regular, logical, and systematic approach for ascertaining,
describing, and documenting all relevant and specific events that might impact an RI’s goals,
constraints, and objectives (such as scope, schedule, budget, and performance). Note that
the availability and use of NSF-awarded contingency depends upon the existence of a
complete and accurate listing of risks, i.e. any Change Request that draws on contingency
must be tied to specific identified risks in a Risk Register.
Risk management guidelines typically divide risks into identifiable discrete risk events and
Document Number
262
4.6 Risk Management
Research Infrastructure Guide
Estimate Uncertainties (EU). Discrete risks are unplanned events that are either threats
(negative impact on project parameters) or opportunities (positive impact on parameters.)
EU represent designers’ and estimators’ uncertainty in capturing all scope, completely
understanding all the work required to execute the scope and accurately predicting cost and
schedule for work in the future. Unlike discrete risks, EU can be simultaneously potential
threats or opportunities. As an example, the duration for completing a task is uncertain,
ranging between 20 days and 50 days. If the Project Team uses 35 days as the most likely
duration in the baseline schedule, then there would be a time savings (opportunity) if the
task is completed in 25 days or a delay in completion (threat) if it takes 42 days. In contrast,
an identified discrete risk event of late delivery of a key component from a vendor is always
a threat. Some projects may choose to treat the EU as they treat discrete risks and include
them as threats (ignoring the opportunity aspects) in the Risk Register and analysis as cost
and schedule drivers. Others may choose to treat the EU via a different process and carry
them separately (e.g., as allowances in the BOE, see Section 4.3.4.2 Construction Cost Book
and Basis of Estimate Overview). The Risk Management Plan should describe how EU will be
identified and managed (see Section 4.3 Cost Estimating and Analysis). Note that each risk in
a Risk Register should have a single root cause; thus, EU captured in the Risk Register should
not be conflated or bundled with discrete risks to create single group of similar risks, also
called omnibus Risk Register entries, i.e., EU should be treated separately as standalone risks.
As risks are identified, they should be captured and documented in a Risk Register, which is
an itemized listing of all identified threats and opportunities that currently exist within the RI
life cycle stage. Depending on the nature of the RI, the Risk Register can take a variety of
forms, ranging from simple lists to detailed spreadsheets to commercial database programs.
Regardless, for each identified risk, the Register should capture at a minimum:
•
Unique Identifier: A unique code or number for effective reference and tracking
throughout the project life cycle. Once assigned, the identifier should never be
changed for an individual risk, nor be deleted or re-used after a risk is retired.
Example: 0045.
•
Risk Title: A brief narrative-type name or title for risk. Example: Rocket launch
weather delay.
•
WBS Element: For awards with a WBS, the risk must be associated with at least one
WBS element.
•
Ownership: Clear assignment of the individual responsible for assessing and tracking
the risk and implementing any required responses. Example: Joanne Smith.
•
Risk Description: A concise yet informative explanation of the potential issue, devoid
of ambiguity, and usually includes an if-then statement. Example: If a storm with either
nearby lightning or sustained winds over 25 mph occurs on the rocket launch day,
then we will have to scrub the launch and reschedule, which will delay subsequent
work and cost additional unplanned money.
Document Number
263
4.6 Risk Management
Table 4.6.2-1
Sample Risk Register
Risk Description
Risk
Status
Risk Statement
Research Infrastructure Guide
Probability of
Impact of
Occurrence
Occurrence
Trigger Qual Quan Qual Quan
Date
(%)
($)
Open
There is a possibility
of inclement weather
delaying transport of
the widget to the
construction site. If
this happens, then it
Mod
would delay
June 1
Likely
installation of the
widget into the facility,
which pushes the
project end date out,
costing time, money,
and stakeholder
frustration.
50%
Open
There is a high
likelihood the state-ofart widget will fail the
first time we test it. If
this happens, then it
July 9
could clog the
downstream
equipment, causing a
shut-down of the
entire system.
90%
Very
Likely
There is a possibility
the kazoo union will
strike. If this happens,
Closed then it would shut
Jan 15 Unlikely 10%
down construction
site until the situation
is resolved.
Risk
Exposure
Qual
Quan
($)
Notes / Comments
/ History
3/3/2026: We’ve
reviewed this risk with
Khalid, Sally, & Joe. We
recognize we have no
control over the
probability of a weather
event, and then impact is
Major $300,000 High
$150,000
fixed by marching army
costs. We also looked at
accelerating the delivery,
but the vendor assures
us they can’t finish before
the scheduled FOB date
in contract.
4/4/2025: This isn’t a very
serious risk, as the
widget test is not on the
Critical path, and we
have a lot of schedule
Minor $10,000 Medium $9,000 float. This will need to be
dealt with if it happens,
so perhaps we can
purchase a backup
widget now, so impact is
minimized.
10/4/2025: Union vote
date is the trigger date.
We will meet with the
union rep and offer bonus
pay.
Major $300,000 Medium $30,000 10/22/2025: We met with
union, and they expect
low probability.
1/16/2026: Union voted
not to strike. Risk can be
retired.
Additional entries that are typically included in the Risk Register for each identified risk are
described below in Steps 3, 4, and 5. Because the risk management process is iterative, new
risks may be recognized over time, requiring immediate identification, assessment, and
incorporation into the register. The Risk Register is thus a living document, meaning that it is
continuously evolving in tandem with the RI’s maturation and progress.
Note that not all risks are the responsibility of the Awardee. High-impact, difficult to predict,
and rare events (unknown-unknowns) that are outside the control of a project may be noted
if recognized, but they are not included in the risks under project management and control.
Table 4.6.2-2 Known-Unknowns lists the different categories of risks and the responsible
party, with examples of typical risks in each category.
Document Number
264
4.6 Risk Management
Research Infrastructure Guide
Table 4.6.2-2
Known/Unknowns Risk Examples
Known/Unknown Risks
Known-Knowns
Definition
Responsibility
Known-Unknowns
Unknown-Unknowns
Established elements of the Recognized risks and uncertainties
project scope, captured in
with unknown specific outcomes or
the project WBS, scheduled, details.
and budgeted, typically
developed from bottom-up
estimates. There may be
some residual uncertainty
tied to the estimates of these
elements.
Significant threats to the
project that are either
unknowable during the
project planning process or
are unreasonably too large
to carry as a managed risk
in the project's Risk
Register.
Awardee
Awardee
NSF
Handled
Through
Standard day-to-day
management of the baseline
(scope, quality, schedule, &
budget).
Formal project Change Control
implemented via use of budget
contingency, schedule contingency,
reductions in project scope and/or
quality acceptance criteria.
Formal re-baseline process
and the requested use of
management reserve,
project schedule extension,
and/or significant project
scope changes.
Example
A project to build a scientific
instrument. Scope and
quality requirements are
developed by way of
progressive elaboration by
project subject matter
experts (SME) and
documented in WBS and
technical specifications.
Integrated project schedule
and budgets are then
developed bottom up. There
is some uncertainty of cost
and schedule estimates;
these are included as
specific line items in the
project Risk Register and will
be covered by use of project
contingency if/as required.
A performance risk exists with an
important aspect of the scientific
instrument being built in-house: E.g.,
"If our team cannot meet the
wavelength coverage requirements in
time, then instrument will not be able
to achieve full scientific capability." If
this happens, the Project Team has a
choice of issue responses, such as:
write a Change Request to replan and
hire an external vendor to expedite
and improve performance; and/or
write a Change Request to slip the
project schedule to accommodate the
delay while the team continues to
work; and/or write a Change Request
to change the technical specifications
and accept the reduced science
capability of the instrument.
An earthquake hits the
construction site and
knocks out the production
of critical components of
the science instrument. The
vendor doing this work is a
sole-source supplier, so
there are no reasonable
alternatives available. A
major re-plan, extension of
the project schedule, and/or
cost increases would be
required. As a result, a
supplemental funding
request would be submitted
to NSF asking for
management reserve
monies and a formal
extension of the award end
date.
Good Practices and Practical Considerations
•
Early in RI initiation and conceptual planning phases, risks that should be formally
tracked are often hard to distinguish from less-well defined and/or general worries
and concerns. It may be enough to create a list of major concerns and consequences
in a simple text document at the start of the RI and then transition to a formal Risk
Register as planning matures.
•
Maintain a single register, update it with the particulars of the current state of the
risks (pre- or post-mitigation), and periodically archive to maintain a record of
mitigation plans and risk management. Pre-mitigation impacts and probability are
included until a risk reaches acceptance, at which point the Register should be
updated to reflect the residual risk probability and impacts.
Document Number
265
4.6 Risk Management
Research Infrastructure Guide
•
If a risk passes its trigger threshold or is otherwise no longer applicable, then the risk
is marked as retired but remains in the register for record keeping.
•
A Risk Register should include only single root cause risks. If the risk is common to
several unrelated project deliverables, the risk may be raised to a single, higher-level
project management category risk or similar. If there are several root causes, the risks
should be separately listed for each root cause.
•
Stating and describing risks in very specific if-then formats with corresponding root
causes should be emphasized and encouraged by all participants in the risk process,
as it helps fully understand the likelihood and impact of each risk in clear,
unambiguous terms.
•
EU can be handled in a multitude of ways. For EU included as threats in the Risk
Register, some projects use Maturity Level or Cost Estimate Classification tables to
assign threat probabilities and impact levels to project elements based on design
maturity and technical demands, while others use SME judgment. For Monte Carlo
simulations, some projects assign EU to elements as 100% probable risks that retain
their dual opportunity and threat natures, with a plus or minus range around the
point estimate. The latter is most often used by large projects to include the
cumulative impact from many low-level EU, while EU with high consequences is
included in the Risk Register as impact drivers.
•
It’s a common mistake for RI teams to focus solely on the identification of threats, not
opportunities. Opportunities, especially high-impact ones, may be low-hanging fruit
that can provide significant benefit to the project, increasing its likelihood of success.
•
A Risk Register should be readily available to be filtered and sortable by WBS, risk
type, ID, owner, likelihood, impact, and other categories.
•
Ideally, identification is performed by all RI personnel and available SME, the
Awardee’s director and manager, and external stakeholders. Additionally, the PO and
AO often have useful input to add that is based on their unique positions,
perspectives, and experience.
•
To ensure all relevant risks are identified, the RI team should adopt a multi-pronged
approach. This may involve:
o
Facilitated brainstorming sessions; risk identification meetings; focused riskbased interviews; specialized strength, weakness, opportunity, and threat
assessments; reviews of documented lessons learned on similar projects;
leveraging historical data from analogous projects.
o
A structured review of key project stages, objectives, and WBS deliverables.
Also, standardized Risk Breakdown Structure and/or classification/category
lists and frameworks to ensure a comprehensive assessment, covering
categories like technical, schedule, cost, resource, and external risks (see
Figure 4.6.2-1). Note also that the OMB provides guidance on risk categories
that can be used. See also the GAO Cost Estimating and Assessment Guide, GAO09-3SP, Chapter 14.
Document Number
266
4.6 Risk Management
•
Research Infrastructure Guide
The RI Risk Register should generally be accessible to all RI team members (e.g., in
read-only access format). The primary objective of this is to keep the team thinking
proactively about threats and opportunities, risk responses, and the like. Further, a
means by which RI team members may readily comment on existing risks or submit
new risks should be included in the Risk Management Plan.
Figure 4.6.2-1
Risk Breakdown Structure Example
4.6.3
Step 3 – Analyze and Rank Individual Risks
The objectives of Step 3 of the risk management process are to analyze each individual risk
in the Risk Register, assign a specific likelihood and impact, and calculate the resulting
individual risk exposure value. These values are then added to the Risk Register as additional
related data for the risk. With this information, the risks can be ranked according to their
consequences, providing a guide for strategically focusing resources and mitigation efforts
on the most critical risks.
At the end of Step 3, each identified risk in the Risk Register should have the following
information, with a supporting basis of estimate, added:
•
Likelihood Assessment: A data-driven or expert-informed evaluation of the
probability of the risk occurring. Example: Based on historical weather data, there is
a 35% chance of bad weather on the launch day.
Document Number
267
4.6 Risk Management
Research Infrastructure Guide
•
Impact Assessment: A thorough evaluation of the severity of potential
consequences if the risk occurs, usually expressed in time and/or monetary units.
Example: The impact of a launch delay is calculated to be three months at a total cost
of $1M.
•
Risk Exposure Assessment: The mathematical expected impact value of the risk is
the probability-weighted risk exposure, obtained by multiplying the risk likelihood
and impact together. Example: The calculated risk exposure is 35% x $1M = $350K.
•
Trigger Date: A date(s) on which the risk might occur. Sometimes also known as a
retirement date, if this date is passed, the risk can usually be retired or removed from
the Risk Register. Note also that risk trigger dates can inform contingency profiles
determined by the Awardee. Often, an explanatory description is included with the
date. Example: Trigger Date - April 15. Per the weather service, historically this is the
latest date in the year for significant winter storms to impact the launch area.
•
Risk Rank: A subjective assessment of risk importance according to a ranking matrix.
Risk analysts may choose to start assessment with a completely qualitative analysis early in
the planning by choosing to sort risks into subjective high to low bins for probability or
likelihood of occurrence and impacts, without performing in-depth quantitative assessment
of the bin boundaries or the value of the likelihood and impacts. Ranking is then
accomplished by creating a matrix with likelihood on one axis and impacts to project
parameters on the other. The choice of parameters should match the project characteristics,
such as cost, schedule, and quality/performance impacts. The cells in the resulting risk
ranking matrix or heat map are then subjectively ranked and labelled; assignments of high,
medium, and low, for example, are typically used. Note that a qualitative ranking assessment
carried out early in the project planning when probabilities and impacts are only roughly
known can be useful in identifying which reduction and mitigation efforts will be most
beneficial to the project and should therefore be included in the project baseline as planning
progresses.
Once planning has advanced to a sufficiently mature stage, the bins boundaries can be
determined, and the assessment of the likelihood and impacts narrowed to estimates
backed by data and/or SME judgement. The number and assigned values in the ranges
should have enough granularity to separate risks into meaningful ranking assignments.
Again, the choice of parameters in this quantitative ranking should match the project
characteristics. Some projects may choose to use the probability-weighted risk exposure as
representative of overall risk importance and ranking, while others may choose individual
impacts such as cost, schedule, and quality and performance impacts. The ranking values
assigned to cells in the ranking matrix are based on subjective judgements by the analysists.
The resultant heat map is a qualitative or subjective binning of quantitative inputs. Table
4.6.3-1 provides an example of a ranking heat map. The map inside the dark boundary is
representative of a qualitative ranking analysis, while the entire map, with quantities
assigned to the probability and impacts represents a thorough assessment of risk
importance.
Document Number
268
4.6 Risk Management
Research Infrastructure Guide
Table 4.6.3-1
Example Risk Matrix or Heat Map
Good Practices and Practical Considerations
•
Good practice when performing quantitative analyses is to document assumptions,
supporting data, and the estimate calculation itself as a basis of estimate. Besides
validating the estimate, knowledge of the underlying assumptions and calculations
will be helpful when impacts need to be re-evaluated over time. The probability that
a risk may occur and the impact if the risk were to occur should be evaluated
separately before combining the two parameters in a risk matrix. The idea that the
risk is unlikely so its impact will be low confuses the two parameters of probability and
impact. To mitigate this effect, SME should be asked to estimate the impact as if the
risk had occurred.
•
It is often useful to begin the assessment of a risk impact on separate project
objectives such as time, cost, scope, or quality/performance impact ranges rather
than creating a single, overall risk impact. Ranking levels are defined for each separate
objective to ensure the full extent of the impact is captured. For instance, a particular
risk can be judged to have a high impact on time but a moderate impact on cost and
a low impact on scope. It is also important to note that the impact of a risk may have
secondary or indirect consequences on other aspects of the RI that should be
captured.
Document Number
269
4.6 Risk Management
4.6.4
Research Infrastructure Guide
Step 4 – Determine and Apply Individual Risk Reduction /
Enhancement Responses
The objective of Step 4 of the risk management process is to evaluate each identified risk
documented in the Risk Register and determine whether a response action can or should be
undertaken or whether the risk can be accepted as is. Note that in this context, the term
accept means that no further actions are practical, possible, or should be applied due to
excessive cost relative to the benefit that may be obtained. Actions taken in this step are
called risk reduction/enhancement responses, or simply risk responses, for short.
A risk response is performed by selecting and applying appropriate methods that minimize
the threat’s likelihood and/or impact (or maximize the opportunity’s likelihood and/or
impact). After the determination and application of appropriate risk responses, the
remaining risk is known as the residual risk. This residual risk state wholly replaces the
previous information state of the identified risk in the Risk Register and is then tracked and
managed accordingly, i.e., the Risk Register should always reflect the current status of each
individually identified risk, either before or after a risk response has been applied.
All documented risks in the Risk Register should be responded to using three primary
methods until the residual risk is accepted, meaning further responses are no longer
necessary or beneficial. Risk response methods for reducing threats typically fall into three
primary categories:
•
Avoidance. These are actions taken to reduce the likelihood of the threat occurring.
Example: Adjust the schedule of work activities to perform the launch when storms
are less likely to happen and therefore delay the effort.
•
Transfer. These are actions taken to shift the impact of a threat to a third party if the
risk is realized. Example: Using a fixed-price contract transfers a portion of the risk to
the vendor.
•
Mitigation. These are actions taken to reduce both the likelihood and/or impact of a
threat. Example: Development of efficient de-fueling processes and specialized
storage equipment to speed the process if the launch has to be scrubbed.
Similarly, risk response methods for enhancing opportunities fall into three types:
•
Exploitation. These are actions taken to increase the likelihood of an opportunity
occurring. Example: Invest in early training to take advantage of new technology
expected to come out that, if implemented, could cause an overall shortening of the
project schedule.
•
Sharing. These are actions taken to increase the overall impact of an opportunity by
sharing the benefit with a third party. Example: Partner with Vendor X to increase the
performance of a standard component they sell; the RI benefits from the improved
performance, while the vendor’s development costs are reduced/shared with the
Awardee.
•
Enhancement. These are actions taken to increase the likelihood and/or impact of
Document Number
270
4.6 Risk Management
Research Infrastructure Guide
an opportunity. Example: Change the schedule to stage procurements in batches in
order to take advantage of volume discounts.
Good Practices and Practical Considerations
•
Before applying any risk response, one should consider whether the cost of the
response outweighs the benefit. Only when the benefit is greater than the cost of
responding should it be applied. As such, risk thresholds and response trigger points
need to be determined and factored into the decision to apply risk responses.
•
Early in the RI life cycle, the monetary cost of a risk response can and should be added
to the baseline budget, and the time needed to implement the response is included
in the schedule. Later, once the performance measurement baseline is set, the cost
of responses for newly identified risks will likely necessitate the application of
contingency, i.e., the earlier risks can be identified, analyzed, and responses planned,
the less pressure on contingency will occur.
•
The impact of an individual risk may be modest and still be considered a high or very
high priority for mitigation. This is because the combined or aggregate impact of
many moderate risks may be high. The Project Team may want to mitigate some low
or moderate risks to reduce the combined threat from many risks.
•
Project management literature typically includes four responses to both threats and
opportunities, including acceptance. The guidance given here is based on the actual
sequence of actions, employing the first three risk responses to bring the threat or
opportunity to an acceptable level, followed by the acceptance response. All risks are
accepted before applying the issue responses as necessary.
4.6.5
Step 5 – Establish Issue Response Plans
The objective of Step 5 of the risk management process is to establish plans for responding
to issues, or realized risks, as they are also known. As its name implies, an issue is a risk that
has come to fruition. A risk may or may not occur, while an issue is an event that has
occurred. When a risk becomes an issue, it is addressed via an issue response plan.
Issue responses are commonly confused with risk responses, which address ways to handle
potential risk impacts before the risk is realized. Issue responses are the steps that will be
taken to address an unplanned event if and when it occurs.
Example: If a storm arrives at the site on launch day, we will de-fuel the rocket, move it to a
safe location, and transition its state from launch mode to temporary storage mode. We will
also need to move the team onto other work to keep them engaged while we wait for another
launch opportunity, readjust the schedule, and release contingency monies to pay for these
impacts.
The Risk Register is the central hub for documenting risks, assessments, and even risk
response plans. Issue responses may also be contained within the Risk Register, or at a
minimum, links to detailed issue responses can be included in the Risk Register.
Document Number
271
4.6 Risk Management
Research Infrastructure Guide
Good Practices and Practical Considerations
•
The value of developing issue responses should not be overlooked. Taking the time
to consider potential scenarios and issue responses often will help inform risk
reduction/enhancement responses as well. The details of the plans may change, but
the planning is still indispensable.
•
Developing issue responses also has the benefit of helping estimate the current
impact of a risk, i.e., if the risk is realized, then a number of actions and results will
need to occur, all of which have cost, schedule, and/or performance impacts.
•
Issue and what-if planning also keeps risks forefront in the teams’ mind, training them
to always be in a problem-solving mode.
•
When an issue does occur, a good practice is to document it in an issue log so that it
can be tracked and managed. Transferring the realized risk from the Risk Register to
the issue log may be necessary. The format of an issue log varies with the size and
complexity of the RI, but typically includes such things as issue number,
name/description, associated risk ID, date of occurrence, impact assessment, status,
assignee, and other/related information. Issue logs can also serve to inform any
lessons learned documents at the conclusion of the award.
4.6.6
Step 6 – Assess Total Risk Exposure
The objective of Step 6 of the risk management process is to estimate the total risk exposure,
which is a measure of the entire vulnerability of the work effort to risk and estimate
uncertainties. Estimated risk exposure can then be used as the basis for establishing an
appropriate amount of contingency to be used to offset risk consequences. An allocated
amount of continency that is equal to or larger than the total project risk exposure helps
ensure that the work can be successfully completed within the TPC and TPD (see Section 4.7
Contingency Estimating and Management describes methods of calculating contingency).
There is a large range of methods and techniques to calculate total risk exposure. This
section should focus on demonstrating a selection of quantitative methods of analysis.
The method chosen by the Awardee should be tailored and scaled to the project
characteristics and needs, the available tools, and processes available to the organization,
and the capabilities and experience of the project Risk Managers. Simple projects and those
considered to have low risk may obtain adequate risk exposure estimates using algorithmic
or parametric methods that entail low overhead and effort (e.g., risk factor analyses).
Complex and high-risk projects will likely benefit from more sophisticated probabilistic
methods, such as Monte Carlo analysis. 1 Regardless of chosen method, the Awardee should
ensure that adequate expertise and a thorough understanding of the project’s
characteristics are available and applied. For example, Monte Carlo methodologies generally
necessitate specialized risk management expertise to obtain reasonable results as project
1 Major
Facility construction projects are required by NSF to make use of probabilistic risk exposure methodology to
determine risk exposure used as a basis for estimating contingency amounts.
Document Number
272
4.6 Risk Management
Research Infrastructure Guide
complexity increases.
The following content describes some of the more common estimating methodologies,
starting with algorithmic, progressing through parametric, and ending with probabilistic
methods using scaled applications of Monte Carlo simulations.
4.6.6.1
Algorithmic Method – Risk Register Exposure Sum
If a Risk Register exists, the simplest algorithmic method of estimating total risk exposure is
a summation of the individual calculated risk exposures in the Register from threats
(excluding those from opportunities). 1 Note that estimate uncertainties can also contribute
to total risk exposure. If these uncertainties are not included in the Risk Register (and
therefore summed along with other risks), accommodation needs to be included to factor
their effect into the overall total risk exposure summation. Table 4.6.6.1-1 shows an example
of overall project risk exposure determined by summing the individual risks exposures in a
Risk Register.
The Risk Register exposure summation method can be used by simple projects for both the
initial risk exposure calculation and subsequent updates as work progresses. More complex
projects can use this method as an early planning tool before transitioning to more complex
methods for establishing overall risk exposure as planning matures. The utility of the total
risk exposure calculation with this method depends upon the statistics (>10 risk entries) and
the thoroughness of the risk identification and analyses. Project Teams should be careful to
ensure that correlations between risks are included as much as possible when estimating
the total impact. For example, if the price of steel unexpectedly increases due to global
market conditions for one procurement, then all similar future procurements involving steel
will likely be also affected.
1 This
method is similar to Expected Monetary Value calculations used in business and economic calculations.
Document Number
273
4.6 Risk Management
Research Infrastructure Guide
Table 4.6.6.1-1
Example Risk Register Exposure Summation
Risk
ID
Risk Title
Risk
Description
Estimated
Risk
Probability
Estimated
Cost
Impact
001
Weather
Event
If a severe weather
event weather
disrupts
transportation, then
delivery will be
delayed, resulting in
a schedule delay but
no cost increase.
25%
002
Widget
Failure
If the widget fails
10%
during testing, then a
replacement will need
to be found, resulting
in cost and schedule
increases.
$50,000
003
Gizmo
Cost
Estimate
Uncertainty
Cost uncertainty
estimated at 35% of
baseline cost of
$128,000, due to
design maturity at
conceptual level.
$44,800
15%
Estimated
Schedule
Impact
4 weeks
12 weeks
Total Risk Exposure Sum
4.6.6.2
Cost Risk
Exposure
(Probability
x impact)
Schedule
Risk
Exposure
(Probability
x impact)
1 week
$5,000
1.2 weeks
$6,720
$11,720
2.2 weeks
Parametric Method – Risk Factor Analysis
Risk factor analyses to approximate mathematical calculation of total risk exposure have
been successfully used in both Mid-scale RI and Major Facility efforts. These parametric
analyses use historically derived look-up tables to estimate uncertainty factors for technical
feasibility, cost estimate uncertainties, and schedule impacts on each element of an RI’s WBS
at a common level (e.g., Level 3 of the WBS). These uncertainty factors represent both
discrete risk events and estimate uncertainties in a single risk exposure analysis. The factors
are combined and multiplied by the cost estimate for each element of the WBS and then
summed overall WBS elements. Note that this method results only in cost risk exposure since
schedule exposure is converted to a monetary value, not a time or duration. Additional
analysis with other methods should be used in tandem with risk factor analysis if an estimate
of total schedule risk exposure is needed to support schedule contingency estimation.
See Table 4.6.6.2-1, below, for an example of a risk factor table. Risk managers need to adjust
the table to suit the characteristics of the work at hand. Projects that are particularly sensitive
to schedule delays, for example, may want to use a schedule multiplier of two rather than
one, as assumed in the example table, or change the ranges or uncertainty factors for the
number of days of slippage.
Document Number
274
4.6 Risk Management
Research Infrastructure Guide
For example, imagine that a specific WBS element has the following attributes:
•
Technical: The design of the WBS element is new and necessitates some research
and development but does not advance state-of-the-art. The risk exists in both the
design and the manufacturing areas of this item.
•
Cost: The existing cost estimate was based on strong engineering judgement, i.e., an
in-house estimate for needed staff labor that was based on subject matter
experience. This WBS item is almost entirely comprised of labor costs (i.e., no
significant material costs are part of this item).
•
Schedule: The activities associated with this WBS element are not on the project's
Critical path but would impact it if delayed more than a few days and will then cause
an overall project slip.
•
The overall cost estimate for this item is $10,000.
From Table 4.6.6.2-1 below, we see that:
•
Technical Risk Factor: 8%; and Technical Multiplier: 4
•
Cost Risk Factor: 4%; and Schedule Multiplier: 1
•
Schedule Risk Factor: 8%; and Schedule Multiplier: 1
Therefore, the risk factored exposure percentage for this WBS item is: ((8% x 4) + (4% x 1) +
(8% x 1)) = 44%. As a result, the specific risk exposure of this specific WBS item is: 44% x $10K
= $4,400.
The overall risk exposure of the entire project is obtained by performing similar analysis on
each subcomponent or WBS element and summing the results.
Document Number
275
4.6 Risk Management
Research Infrastructure Guide
Table 4.6.6.2-1
Example of Risk Factor Tables Used to Calculate Total Project Cost Risk Exposure
4.6.6.3
Probabilistic Method – Monte Carlo Simulations
Probabilistic risk analysis (e.g., Monte Carlo simulations) allows the analyst to estimate risk
Document Number
276
4.6 Risk Management
Research Infrastructure Guide
exposure based on many simulations of possible outcomes for selected project objectives. 1
The Monte Carlo simulation method relies on a model of the project objective data (e.g., a
schedule, cost estimate, or a Risk Register) loaded into Monte Carlo software, along with
input values for each objective. The software uses random sampling and statistical modeling
to simulate possible outcomes for the project objectives.
The five steps in a Monte Carlo risk exposure analysis are the following:
•
Determine the model and estimated outcome (e.g., a summary of WBS Level 3
schedule and projected project end date).
•
Collect the inputs (e.g., threat probabilities and cost impact distributions).
•
Load the model and inputs into the Monte Carlo simulation software tool.
•
Run the Monte Carlo for a sufficient number of iterations.
•
Analyze the results.
In its simplest form, inputs are a point estimate (or multiplier) for each element in the model
(e.g. cost, duration, risk impact) and a probability or likelihood of the occurrence of that
estimate. In the simulation, the Monte Carlo tool generates a random probability of
occurrence for each element in turn and compares it to its input probability. If the input
probability is less than or equal to the generated probability, the input point estimate is
assigned as the output value for that element. Otherwise, the value is not included. The
simulation builds an overall outcome for the model by summing the output values for each
element in the model. By running many simulations (typically between 1,000 and 10,000
times depending upon the model complexity), a range of possible outcomes for the
objectives is generated, e.g., a histogram plot of the outcome of each iteration for estimated
total cost, finish date, and/or overall risk exposure. An S-curve of the cumulative frequency
of output values returned by all iterations represents the confidence levels that the project
will finish within the outcome values for the model. It can also provide an estimate of risk
exposure and a basis for the selection of contingency amounts. As an example, Figure
4.6.6.3-1 shows the resultant plot and S-curve for the project end date for a Monte Carlo
simulation on a schedule model. The difference between the baseline value and the highest
output value in the histogram provides an estimate of the total schedule risk exposure to
complete the project with 100% confidence. The 80% level indicated on the S-curve indicates
that 80% of the iterations ended on or before the date at that point on the curve. The amount
of schedule contingency needed to cover the risk exposure for that confidence level is the
difference between the baseline end date and the end date at the 80% confidence level. Said
another way, 80% is the confidence level that the project will successfully complete on or
before that outcome end date if the estimated contingency amount is available.
1 Some risk management guides refer to probabilistic methods as quantitative methods while listing algorithmic and
parametric methods as qualitative. This can be confusing to users since quantitative data is used in all these
methods.
Document Number
277
4.6 Risk Management
Research Infrastructure Guide
Figure 4.6.6.3-1
Graphical Representation of Total Project Duration Using Monte Carlo Simulations Across Various Iteration Counts
Scaled Monte Carlo Risk Exposure Analysis. The Monte Carlo method can be applied in
multiple ways, scaled to match the complexity and/or maturity of project planning. This
section should introduce some of the more basic concepts and methods of applying Monte
Carlo analysis, but it is not an exhaustive exposition on all the nuances and methodologies
that can be utilized. Because the quality of the results relies on the Awardee’s understanding
of the different types of risks, correlations between risk, the quality of the input data, and
the benefits and limitations of various methodologies and tools, most projects will benefit
from the involvement of risk management and risk Monte Carlo experts. For large, complex
projects this may involve hiring dedicated staff for the project duration. For small projects, it
may mean obtaining training in-house staff or hiring temporary experts to direct the
establishment of risk management tools and methods.
The model for probabilistic risk analysis is typically the project cost estimate, project
schedule, or Risk Register. Since most cost estimates and Risk Registers are developed in a
spreadsheet, a risk analysis of the project’s cost estimate or risk exposure alone is often
conducted in a spreadsheet or in a software package that simulates a spreadsheet model.
Schedule risk analyses, on the other hand, simulate a project schedule, so software that is
able to simulate schedules developed in the organization’s preferred scheduling package
should be used. Integrated cost-schedule risk analyses involve a good-quality integrated
schedule loaded with the cost estimates attached to the activities they support. A few
Document Number
278
4.6 Risk Management
Research Infrastructure Guide
examples of Monte Carlo analyses are given below, progressing from simple applications to
sophisticated analysis for complex projects.
Spreadsheet Model Monte Carlo Simulation. A common very simple method to estimate
total risk exposure is to perform a Monte Carlo simulation on spreadsheet data, often on the
Cost Book for budget (see Section 4.3.4.2 Construction Cost Book and Basis of Estimate
Overview) or on the Risk Register for total risk exposure. The example given here is for total
risk exposure estimated by using the Risk Register as the model. Inputs to Monte Carlo are
the individual risk likelihoods/probabilities and their associated most likely impacts. The
Monte Carlo output for each risk includes the impact if the risk occurs, based on likelihood.
The total outcome for each Monte Carlo iteration is the sum of all the outputs, representing
the aggregate or total project risk exposure for that iteration. A graph of how often each
outcome value occurs, called a cumulative frequency or S-curve plot, yields the likelihood
that the total risk exposure will be equal to or less than each value on the curve. See Figure
4.6.6.3-2 for an example of a typical S-curve output of a Monte Carlo analysis performed
using the probabilities and cost impacts for threats listed in a Major Facility project Risk
Register as inputs. In the example, 800 out of 1,000 iterations (80%) resulted in estimated
total exposures equal to or less than $13,935,252. If the Project Team chooses that amount
of contingency, then they have an 80% confidence level that the project can successfully
complete within budget. A similar analysis can be done on the schedule risk elements in the
Register to obtain the total risk exposure for the schedule.
Document Number
279
4.6 Risk Management
Research Infrastructure Guide
Figure 4.6.6.3-2
Example of an S-Curve Output of Monte Carlo Performed on Risk Register
Software Model Monte Carlo Simulation. Monte Carlo analysis using complex models
based in commercial software tools (e.g., scheduling applications) rather than spreadsheets
take more effort and knowledge to set up and run. An added complication can be the use of
distributions instead of point estimates as input values, such as estimate uncertainty ranges
and/or schedule risk probabilities and impact distributions.
Point estimates can be used as inputs when the objective being analyzed is known to be an
exact amount or for simple analyses that haven’t yet been assessed for a range of impact
values. They are commonly used for spreadsheet models, such as Risk Registers, as
illustrated in the example above. Other distribution shapes (e.g., as normal/Gaussian, flat,
triangular, Program Evaluation and Review Technique (PERT), and log-normal) may be used
when a range of values is more representative of project characteristics and the Project Team
understands the pros and cons of using them. Some of the easiest and therefore common
distributions used are the triangular and PERT distributions, which are based on three
estimates to define ranges - the best, most likely, and worst case possible for cost or schedule
values. The most likely value is typically the baseline estimate or the estimated risk impact in
the Risk Register, depending upon the Monte Carlo model being used. The best and worst
values can be expressed in cost or duration units or as a percentage of the most likely value
(e.g., minus 15%, plus 25%). The range for risk impacts often relies on SME judgment, while
EU are often expressed as plus or minus percentages taken from look-up tables based on
Document Number
280
4.6 Risk Management
Research Infrastructure Guide
the maturity and complexity of the activity/deliverable. The nuances of when one or the
other method should be used are beyond the explanations included here.
The distribution ranges for EU often have a low-value tail (opportunity) compared to the most
likely value and a high-value tail (threat), such as -5% and +10%. Asymmetries in the range of
estimate uncertainty occur because it is often easier to overrun than underrun an estimated
value. Also, note that the most likely value may not be the assigned value in the schedule or
estimate. Hence a fairly typical uncertainty estimate range could be .95, 1.05, and 1.15 – the
middle value implies that the estimator judged that the duration or cost is most likely 5%
higher than in the baseline model. Activities that occur far in the future or that are less
understood often can be addressed by allocating a wider range of uncertainty to durations
or costs than to those assigned to better-understood activities occurring in the early years
of the project. Discrete risks can be represented by assigning a risk to a cost element or
schedule activity in the Monte Carlo analysis or by specifying a multiplicative factor to apply
to the estimated cost (Risk Register method) or activity duration (risk driver method). For a
discrete risk, the range of best and worst cases may depend upon the actual circumstances
of the risk realization. If a component does not meet design requirements, the best case may
just be changing out a subcomponent with little impact while the worst case may involve
redesign, fabrication, and testing activities not in the plan. Examples of inputs for threeestimate schedule impact distributions are shown in Table 4.6.6.3-1.
Table 4.6.6.3-1
Probability Distributions of Schedule Risk Impact Durations Based on Best, Most Likely, and Worst-Case Duration
Estimates
Risk Description
Probability of
Occurrence
Best Case
Most Likely Case
Worst Case
Task risk of delay
35%
25 days
50 days
100 days
Estimate uncertainty on task
duration
100%
-10%
60 days
+25%
Monte Carlo analysis of risk for models created in a schedule software application will be
presented in this discussion to illustrate the methodology. An example of a logically driven
schedule is shown in Figure 4.6.6.3-3. For this software-based application, the chosen Monte
Carlo tool should be capable of loading the schedule data from the scheduling tool. Note
that the full project schedule does not have to be used in all cases – many projects use
summary schedules derived from the Integrated Master Schedule (IMS) with Monte Carlo
inputs applied at the summarized levels. This may be because the schedule has not been
fully developed, but the high-level outline has been established, or because an IMS with a
large number of activities is too burdensome to troubleshoot and upload each time the
schedule is updated or changed.
Document Number
281
4.6 Risk Management
Research Infrastructure Guide
Figure 4.6.6.3-3
Example of a High-Level PMB Schedule for a Design and Construction Project
Once the schedule model has been determined and probability-impact distribution ranges
have been assigned to each risk in the Risk Register, the risks are then assigned to the
activities and resources in the Monte Carlo model and the simulation can be run for multiple
iterations. Note that an activity can have more than one risk assigned to it and risks can be
assigned to more than one activity. If a risk occurs for a particular iteration, the output
durations of the activities in the schedule that the risk is assigned to will be randomly
generated from the impact range according to the methodology used by the Monte Carlo
application.
For example, assume a schedule impact distribution ranging from a best case of 10 days,
worst case of 35 days, with a most likely duration of 20 days, is chosen for a risk assigned to
the activity. If the probability of the risk occurring is assumed to be 40%, the Monte Carlo will
generate a random impact value from the distribution range of 10 to 30 days for 40% of the
iterations in the simulation. For the other 60% of the iterations, an output value of zero is
assigned, indicating that the risk does not occur for those iterations.
In order to obtain an output value for the overall project end date for a single iteration, the
Monte Carlo application will sum all the randomly generated output durations for each
activity in the schedule. The output end dates for all iterations can be plotted as a histogram,
which is then analyzed to determine the confidence level for completing the project by a
selected end date. For the analysis, the histogram distribution is converted to a cumulative
frequency curve representing the percentage of times in the simulation that all the work is
completed by each generated end date. The stated confidence level for any end date is equal
Document Number
282
4.6 Risk Management
Research Infrastructure Guide
to the percentage of iterations completed by that date (i.e., 800 out of 1,000 iterations in a
simulation represents an 80% confidence level). A representative Monte Carlo histogram and
S-curve from a typical schedule Monte Carlo analysis for project end date is shown in Figure
4.6.6.3-4, where the 80% confidence level for 10,000 iterations supplies a basis for
establishing schedule contingency to cover overall schedule risk exposure. The amount of
schedule contingency required to ensure that the Project Team can deliver on time at the
80% confidence level is the difference between the baseline end date and the Monte Carlo
generated end date.
Figure 4.6.6.3-4
Histogram from Monte Carlo Simulations Showing Schedule Risk Impacts on Project End Date with an 80% Confidence
Level S-Curve. Baseline End Date: 11/10/2024; Projected End Date at 80% Confidence: 7/14/2025, Suggesting an EightMonth Contingency Requirement
Combined Cost-Schedule Monte Carlo Analysis. The most thorough analysis comes from
Monte Carlo simulations based on an integrated, RLS with costs loaded at the activity level,
coupled with inputs from a comprehensive listing of the probabilities of occurrence and
range of impacts for risks and uncertainties. Awardees must use cost and scheduleintegrated Monte Carlo analysis for Major Facility construction projects, starting with the
Project Definition presented at PDR. Mid-scale RI projects and other life cycle stages may use
scaled Monte Carlo versions described earlier in this section. Due to the complexities
Document Number
283
4.6 Risk Management
Research Infrastructure Guide
involved in running an integrated Monte Carlo combining cost and schedule, as well as the
nuance needed in interpreting results, it is recommended that the Awardee seeks expert
advice to implement such analysis.
As mentioned above, an integrated cost and schedule Monte Carlo risk analysis should
include an accurate, up-to-date, cost-loaded schedule that follows the project WBS, with
established logic links, appropriate constraints, and a clear Critical path. The baseline IMS,
without schedule contingency or float, or a representative summary schedule modeling the
project, may be used. Summary schedules are particularly useful during planning stage
analysis performed before all work packages are fully developed or for a less burdensome
frequent analysis during construction. The scheduling software should be compatible with
the Monte Carlo software, as well as with other project control applications (see Section 4.4
Schedule Development, Estimating, and Analysis).
The PMB cost estimate used to load the schedule should be fully burdened for all WBS scope
(see Section 4.3 Cost Estimating and Analysis). The baseline budget used in the Monte Carlo
analysis does not have to be loaded into the schedule at the lowest detail level. Costs can be
rolled up to higher WBS levels rather than being loaded at the IMS activity level.
A typical result of a Monte Carlo schedule risk analysis is a histogram of possible TPC from a
combined cost and schedule analysis, which is shown in Figure 4.6.6.3-5. A similar plot for
total schedule duration can also be extracted from the analysis. For the histogram below,
the horizontal axis shows the range of possible total cost. The right vertical axis shows the
confidence level for the cumulative S-curve. The solid lines on the plot represent the costs
for which the confidence level for completion within that cost is 50% and 90% respectively.
For this example, the PMB budget is $64.32M. If the Project Team elects to use the 90%
confidence level, then the chosen project total cost is $74.87M, indicating that they need to
mitigate or provide contingency for an additional $10.55M beyond the baseline budget.
Document Number
284
4.6 Risk Management
Research Infrastructure Guide
Figure 4.6.6.3-5
Histogram of Total Project Cost from Integrated Monte Carlo Cost Analysis for Major Facility Construction. Total Cost:
$74.87 M; Contingency: $10.55 M at 90% Confidence Level
The results of the analysis, including all risks and uncertainties, for the Major Research
Equipment and Facilities Construction (MREFC) scope are as follows:
Project base cost (BAC = direct + indirect + escalation)
TPC (BAC + contingency)
Total contingency (TPC at 90% CL – BAC)
= $64.32M
< $74.87M (at 90% Confidence Level)
= $10.55M (at 90% Confidence Level)
An integrated cost-schedule risk analysis can also show the relationship between schedule
and cost in a combined scatter plot. The scatter slope then indicates the positive relationship
between time and cost.
Sensitivity Analysis / Tornado Chart. In addition to producing the likelihood of completion
values, the Monte Carlo method can also identify the Critical path and rank the main sources
of risk in a sensitivity chart, often referred to as a tornado chart. The ranking is determined
Document Number
285
4.6 Risk Management
Research Infrastructure Guide
by removing the risks one at a time and rerunning the simulation to find which one has the
largest impact on the project objectives. Deleting is accomplished by setting the probability
to zero for the risk in question while including all the other risks. Once the highest-ranking
risk is identified, it is excluded from further simulations, and the next impactful risk is
identified by running through the sequence of dropping the remaining risks one at a time to
find the next most important risk. The procedure is repeated until all the risks are ranked in
priority order. This priority ranking is more indicative of a risk’s importance than the Risk
Register ranking because it considers correlations and knock-on effects of realized risks on
other risks. Opportunities can be included in the sensitivity analysis, even if they are not
included in the risk exposure simulations. This identifies which opportunity has the most
beneficial impact on the project objectives if exercised. The sensitivity study thus provides
information for making critical decisions on managing threats and opportunities. A sample
tornado chart is shown in Figure 4.6.6.3-6.
Figure 4.6.6.3-6
Risk Sensitivity Analysis: Tornado Chart Depicting Contributions to Cost Risk Exposure from Individual Risks and
Uncertainties
Document Number
286
4.6 Risk Management
Research Infrastructure Guide
Good Practices and Practical Considerations
•
In general, Awardees should estimate and validate contingency requirements based
on quantitative analyses of total risk exposure. In some cases, however, analogy, SME
judgment, and general rules of thumb may be allowed when warranted and
adequately justified.
•
Scope contingency is an important element of good risk management. De-scope
options can be used to recharge the budget and schedule contingency pools when
needed. In a sense, they represent the additional contingency needed to fill the gap
between the chosen Monte Carlo confidence level and the 100% possibility of success
(see Section 4.7 Contingency Estimating and Management).
•
The preparation work for a Monte Carlo simulation run can take significant time and
effort. Project cost and staffing estimates should include the effort needed for
software licensing and risk management resources, including hired SME, as well as
project management and technical leadership efforts.
•
The detailed project schedule is not always a good candidate for risk analysis input if
it has a large number (thousands) of activities and is difficult to debug. A summary or
analytical schedule may be used instead of a detailed schedule. This analytical
schedule needs to represent all the work of the project and be validated against good
schedule health practices.
•
Projects often use algorithmic or scaled Monte Carlo methods for month-to-month
risk management, saving the more labor-intensive Monte Carlo methods for
establishing a new baseline or calculating an updated risk-adjusted estimate at
completion (RAEAC).
•
Managers should not assume that Monte Carlo analysis always represents the best
analysis and is the final answer for decision-making. Good practice recommends the
use of more than one method of estimating risk exposure. For example, Awardees
may use algorithmic methods during early planning stages, graduating to scaled
Monte Carlo methods with planning maturity. Equally important is the professional
judgment and experience (gut feelings) of the project leadership team.
•
Regardless of method(s) used, the RI team should always review the results and then,
applying judgment, establish a risk exposure value, i.e., it is acceptable to override or
modify the calculated risk exposure, provided an adequate explanation and
justification is provided.
•
Note that total risk exposure typically diminishes over time as risks are realized or
retired. As a general rule, total risk exposure should always be less than or equal to
the remaining contingency.
•
If a risk factor method is used, Awardees are encouraged to review, change, and
adjust the look-up table factors to meet their own project’s unique characteristics.
Further, analyses should occur at one consistent level or tier of the WBS, i.e., it's
common to calculate contingency requirements with this method at Level 3 of the
WBS cost estimates.
Document Number
287
4.6 Risk Management
Research Infrastructure Guide
•
Risk managers may want to explore some common advanced techniques not
discussed in these guidelines, such as the correlation between risks, risk driver
methodology, manipulation of the sensitivity analysis, and the effects of risk
sequencing. These topics are discussed in much of the available risk management
literature.
•
Monte Carlo analysis is a powerful method for understanding and managing risks in
a project, but it does have limitations. First and foremost, the accuracy of the results
depends upon the quality of the input data and the model. Poor assumptions or
inputs can result in unreliable results (garbage in, garbage out). Secondly, the results
can be problematic if the level of staff expertise does not match the complexity and
nuances of the project risks and the tools themselves. Thirdly, the administrative
burden for creating and maintaining Monte Carlo risk analysis increases with the
complexity of the project itself and the chosen risk analysis methods and tools.
4.6.7
Step 7 – Report, Monitor, and Update Risks
The objectives of Step 7 of the risk management process are to ensure regular and consistent
monitoring and updating of the RI risk status, as documented in the Risk Register.
Completing this step facilitates proactive project management to maximize the Awardee’s
chances of success. Equally important, this helps ensure that the primary RI stakeholders
(e.g., NSF) are kept apprised regularly of the current risk status, which helps planning within
the Foundation.
Sound risk management necessitates continuous monitoring of risks, and an iterative
application of the risk process steps to keep the Risk Register current. Existing risks need to
be monitored, controlled, and ultimately retired, while new risks should be identified as they
arise and added to the Risk Register. The frequency, processes, and formats for reporting,
monitoring, and updating risks should be established in the Risk Management Plan. NSF
reporting requirements of risk status and management are specific to each award and are
typically included in the award instrument.
Good Practices and Practical Considerations
•
Managers should not treat risk management as a one-time activity. Ongoing attention
is essential, as new risks emerge, existing risks evolve, and others are retired.
•
A key part of risk reporting is managing stakeholder expectations through open,
transparent communication. NSF and the Awardee should share a clear
understanding of threats and opportunities—risks are not hidden problems but
inherent realities that must be addressed directly.
Document Number
288
4.7 Contingency Estimating and Management
4.7
Research Infrastructure Guide
CONTINGENCY ESTIMATING AND MANAGEMENT
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Contingencies are a necessary component of risk management for NSF-funded projects and
provide the tools to manage known risks. They may be useful tools on proposed projects
and Science Support Programs as well (see Section 4.7.2.5 Contingency Estimating for Major
Facility Operations Stage for Operations and Maintenance [O&M] awards), but their use
should be carefully considered due to the added administrative effort that comes with
contingency estimating, management and oversight.
Contingencies fall into three distinct types: scope, schedule, and budget. At least one of
these—and frequently all three—are used to cover relevant risk exposure sufficiently to
allow the project or program to be completed at or below the authorized TPC or authorized
award amount. The use of contingencies is managed through the formal Change Control
Processes, as documented in Section 3.5.7.3 PEP Subcomponent 7.3 – Change Control Plans,
to ensure robust oversight and administration.
4.7.1
Allowable Contingencies
The definition of contingency varies widely among project management practitioners and
federal agencies. 1 Contingencies for NSF are defined below.
Scope Contingency. Deliverables (work products, outputs, and/or services) that are either:
(1) included in the baseline definition and can be removed (de-scoped) without significantly
affecting the overall objectives but that may still have undesirable effects on performance;
or (2) may be added (up-scoped as a scope opportunity) if adequate funding becomes
available, either through cost underruns or if the full amount of budget contingency is not
needed to cover realized risks and their impacts. Both de-scoping options and scope
opportunities should be included in the Scope Management Plan.
Schedule Contingency. A duration of time to allow for identified delays, conditions, or
events for which the state, occurrence, or effect is uncertain at the time the schedule is
developed and that experience shows will likely result, in the aggregate, in schedule delays.
These known-unknown events are considered manageable by the Awardee.
This duration is held separately from the baseline schedule to help manage risk and
uncertainty in aggregate. Schedule contingency may only be used when a risk, including
uncertainty, from the Risk Register is realized. For projects and Science Support Programs,
this is part of the TPD; also, see the NSF EVM Gold Card.
Budget Contingency. The amount of budget to allow for identified items, conditions, or
events for which the state, likelihood of occurrence, or impacts are uncertain at the time of
1 NSF
terminology aligns with that of the Association for the Advancement of Cost Engineering International (AACEI),
and of the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK Guide). The NSF
definition of contingency is consistent with both the Uniform Guidance (§ 200.433) and the Federal Acquisition
Regulation (FAR).
Document Number
289
4.7 Contingency Estimating and Management
Research Infrastructure Guide
estimate and that experience shows will likely result, in the aggregate, in additional costs.
These events are often referred to as known-unknowns and are considered manageable by
the Awardee.
Budget contingency is held separately from the
baseline budget to help manage risk and Key Takeaway
uncertainty in aggregate. Budget contingency is Contingency may only be used when a
generally obligated to the award for the Awardee risk—identified in the Risk Register,
to manage based on justified need, however NSF including uncertainties and linked to a
can hold up to one hundred percent per NSF specific WBS element—is realized.
policy. Contingency may only be used when a
risk—identified in the Risk Register, including uncertainties and linked to a specific WBS
element—is realized. Budget contingency is part of the TPC; also, see the NSF EVM Gold
Card. 1
In contrast, management reserve is a budget included as part of the authorized TPC to
address unforeseen events or other uncertainties that are beyond the control of the
Awardee or the agency. These events are often called unknown-unknowns; also, see the NSF
EVM Gold Card. Management reserve is not allowable in the Awardee estimates per NSF
policy. 2 The amount of management reserve, if any, is determined and managed solely by
NSF and is based on agency risk tolerance and other factors. Once obligated to the award, it
is allocated as either baseline, budget contingency or fee.
1 https://www.nsf.gov/bfa/lfo/docs/NSF_EVMS_Gold_Card_July%202019-1.pdf
2 Per
2 CFR § 200.433 - Contingency provisions. “Reserves” are funds drawn down and held by the Awardee in
anticipation of future need and are unallowable. As a result, the term “reserve” should never be used in the project
documentation.
Document Number
290
4.7 Contingency Estimating and Management
Research Infrastructure Guide
Figure 4.7.1-1
Methods for Determining Contingency Allocations
4.7.2
Contingency Estimating
4.7.2.1
Budget Contingency
The development of budget contingency starts with estimating the potential monetary risk
exposure, as explained in Section 4.6.6 Step 6 – Assess Total Risk Exposure and depicted in
Figure 4.7.1-1 above. The estimated risk exposure is intended to capture the potential cost
impact of risk and uncertainty, if realized, which can have both direct cost impacts as well as
the resulting costs for schedule delays. Risk exposure can be calculated in a variety of ways.
A contingency budget is then selected to adequately cover this risk exposure while
considering the project maturity, the technical nature of the project, risk tolerance, and the
available de-scoping options, including the potential impacts to science if de-scoping has to
be implemented.
Contingency can have a range of values and
associated confidence levels and still complete
NSF Requirement
the scope within the authorized TPC if the full
suite of risk management tools is used in Major Facility projects must use a
concert. The initial contingency budget should combined cost and schedule risk analysis
using Monte Carlo methods and select a
typically equal or exceed the calculated risk
value within the 70-90% confidence range.
exposure. For Major Facility projects, the
determination of budget contingency must
include the use of a combined cost and schedule risk analysis using Monte Carlo methods
and the selection of a value in the 70-90% confidence range at the time of the PDR. Later, at
the FDR and the award for construction, it is confirmed that the confidence levels remain
within this range when compared against the budget request and anticipated
appropriations. During the Construction Stage, the confidence level is expected to fluctuate,
but if it drops below 50%, de-scoping must be considered along with other risk mitigation
strategies.
Document Number
291
4.7 Contingency Estimating and Management
Research Infrastructure Guide
Higher risk projects with greater complexity and unproven or uncertain technologies often
warrant higher contingency budgets and confidence levels. While it is prudent to be
conservative in selecting a confidence level, professional judgment needs to be used in
consultation with NSF. However, it is always better to deliver the full technical scope and
finish under budget (returning unneeded funds to NSF) than to compromise science
operability through de-scoping or be forced to request additional funding. Projects can never
be 100% certain that the budget contingency alone will be sufficient and selecting a
confidence level higher than 90% diminishes returns and sets unrealistic expectations.
It is not always realistic or even feasible to mitigate all anticipated risks. Risk acceptance is a
normal part of risk management. However, it is also extremely unlikely that a project will
encounter all the risks, or the full extent of possible consequences for each risk, that have
been identified. The contingency estimate should be appropriate to manage only the
aggregate risk, which is much more likely to occur than the sum of the individual risks.
Therefore, a statistical approach like Monte Carlo produces a more likely estimate for the
TPC than the overly conservative approach where CAM increase individual WBS elements to
cover the risk.
Good Practices and Practical Considerations
•
The risk exposure calculation methods identified in Section 4.6 Risk Management are
rigorous bottom-up methods of analysis successfully used throughout government
and industry. However, the overall results should always be scrutinized at the macro
level and subject to a reality check to help ensure they are reasonable and credible.
•
Supporting documentation should clearly articulate which risk elements were
considered, the basis of the impacts and likelihoods, and how they were modified
when making any adjustments to the model outputs when selecting the final
contingency budget.
•
Independent external reviewers and simpler top-down methods, such as percentage
rules-of-thumb or comparison to similar projects, can also be used to help assess
results. However, simple rules-of-thumb are not acceptable to estimate the budget
contingency.
•
Experience and sound professional judgment are essential. Results are subject to
garbage in, garbage out where the quality of the output is dependent on the quality of
the input. Project managers, risk professionals, and SME should always be leveraged
to inform the process and the basis of determining potential cost and schedule
impacts and likelihoods of occurrence.
•
In some circumstances, if the overall contingency appears inadequate, it can be
appropriate to adjust the inputs based on specialized knowledge of a particular
technical area or market condition.
•
Uncertainties in the cost range and schedule durations can be included in budget and
schedule contingency calculations.
•
Scope, schedule, and budget risks are correlated to some extent. A change in scope,
Document Number
292
4.7 Contingency Estimating and Management
Research Infrastructure Guide
for instance, usually means a change in cost and schedule as well. There are often
trade-offs between the different contingencies, which can be balanced to cover risk
exposure adequately. For example, projects with many de-scoping options (e.g.,
decreasing the number of individual detectors that are purchased) may warrant less
budget contingency and vice versa. Risk analysis and budget and schedule
contingency estimation methods should consider the degree of correlation in
estimating an appropriate level of budget contingency.
•
Developing a graphical timeline depicting available contingency-related trade-offs can
help visualize available options when making management decisions. For example,
the cost of available de-scopes and up-scopes can be graphed over the project
duration, as can the estimated cost risk exposure over time, based on the most likely
time of realizing risks or proportional to the baseline funding profile. When
construction is underway, the available budget contingency can be added. See Figure
4.7.2.3-1.
•
The timing of potential risk realization should be considered when determining
budget contingency. For example, escalation of the cost impacts occurring in outyears can be included, and the timeframe in which the project is exposed to different
risks can help determine the appropriate funding profile. See Figure 4.7.2.3-1.
•
Note that total risk exposure typically diminishes over time as risks are realized or
retired. Generally, total risk exposure should always be less than or equal to the
remaining contingency. If the remaining contingency is less than the risk exposure,
recovery plans should be developed, and risk response methods should be revisited
to decrease exposure and/or de-scoping to increase available contingency. See Figure
4.7.2.3-1.
•
Even if all authorized budget contingency is obligated and used, the project may be
completed under budget for other reasons, including final actual costs coming in
below the estimates. Once project objectives are met, scope opportunities may be
implemented, and any residual funds will be de-obligated and returned to NSF, at
which time NSF may request possible re-allocation of those funds to other agency
priorities. Obligated contingency is generally held by the Awardee through award
close-out, where the final accounting is completed. Unused contingency funds may
not be used to support initial operations or other out-of-scope activities. See Figure
4.7.2.3-1.
4.7.2.2
Schedule Contingency
Schedule risk exposure can be estimated using top-down approaches such as simple
percentage rules-of-thumb or comparison to other projects, more rigorous bottom-up
methods such as those described in Section 4.6.6 Step 6 – Assess Total Risk Exposure, or via
a schedule float analysis. A schedule float analysis involves analyzing the available float in
near-critical path activities and using expert judgment to determine or increase schedule
contingency if there are many near-critical path activities with little available float and limited
flexibility. The schedule contingency's total duration should usually equal or exceed the
Document Number
293
4.7 Contingency Estimating and Management
Research Infrastructure Guide
calculated schedule risk exposure.
The project end date is determined by the sum of the baseline duration and the selected
schedule contingency amount. Schedule contingency is held separately from the PMB, and
allocations of schedule contingency to and from the PMB are managed through formal
Change Control (see Section 3.5.7.3 PEP Subcomponent 7.3 – Change Control Plans).
Good Practices and Practical Considerations
•
As noted above for budget contingency, the overall results should always be
scrutinized and subject to a reality check to help ensure they are reasonable and
credible.
•
The cost of schedule contingency should always be considered and factored into the
estimation of budget contingency. For example, if a risk is realized that extends the
overall duration of the project, any LOE personnel (e.g., project management or
engineering) would usually be employed longer and increase costs. For simpler
contingency calculation methods, the average daily cost for LOE personnel could be
multiplied by the days of the schedule contingency.
•
The Project Team should establish controlled milestones for the PMB and riskadjusted end dates.
4.7.2.3
Scope Contingency
Project scope defines the boundaries and deliverables of a project, outlining what needs to
be accomplished and the work that needs to be done to achieve the requirements and
objectives, also known as Key Performance Parameters (KPP). Scope and quality are closely
related, and project scope elements may vary in quality and associated costs. Quality is the
standard (fitness for purpose) of something as measured against the requirements and
specifications. Quality expectations for project scope elements are defined up front in
technical documents and confirmed by defining acceptance criteria, which are checked via
PEP Subcomponent 9.2 – Technical Closeout Plans. One element of scope contingency is
adjusting the quality of a particular scope element, or the extent to which quality or
performance is confirmed during construction or commissioning. This, of course, carries its
own risks.
The term scope contingency will be used herein and may include the quality associated with
certain deliverables. Depending on project risk performance and available budget
contingency, scope contingency can be retained or removed to manage the project within
the authorized TPC. Potential de-scope options are generally lower-priority items or tasks
that can be delayed or dropped without a crippling impact on project objectives. The ability
to de-scope, including targeted reductions in quality, varies widely, and the impact on the
eventual scientific capabilities may also vary. The scope contingency should be well
considered and strive to minimize negative scientific impacts since major reductions in scope
would be considered a rebaseline. De-scoping may be used if the project forecast indicates
that a cost overrun (including those driven by schedule extensions) is likely and/or risks are
being realized with greater impacts than anticipated, and contingency may be significantly
Document Number
294
4.7 Contingency Estimating and Management
Research Infrastructure Guide
depleted.
Scope contingency should be identified in the Scope Management Plan (see Section 3.5.3.2
PEP Subcomponent 3.2 – Scope) and approved by NSF before the start of the Construction
Stage. Since every risk may likely not be realized at its maximum impact, budget contingency
may remain as the end of the project approaches. Depending on final forecasted costs, legal
claims or other encumbrances, remaining contingency may become a significant
consideration as part of the award close-out process.
Identifying scope options may involve comparison to other projects, engaging stakeholders,
and/or having the Awardee do a detailed analysis of the scope, WBS, schedule, and technical,
science, and commissioning objectives and requirements (see Figure 4.7.1-1).
For a Major Facility in the Construction Stage, a Scope Management Plan must be developed
and identify both de-scope options and scope opportunities. For other stages of a Major
Facility, a formal Scope Management Plan is not required, but similar elements may be
utilized in consultation with the PO. The Scope Management Plan describes each of the scope
options, how they plan to be monitored and controlled, and how and when scope
opportunities and de-scoping options might be implemented.
Good Practices and Practical Considerations
•
As a project progresses through the Construction Stage, the risk exposure, available
budget contingency, and de-scoping options continually decrease, as shown in Figure
4.7.2.3-1. Awardees should keep the following considerations in mind:
o
Having de-scope options available as late in the project schedule as possible
is prudent. If many risks are realized and contingency is depleted, they may be
the only option for staying within the authorized TPC.
o
During the Construction Stage, the confidence level is expected to fluctuate,
but if it drops below 50%, de-scoping should be considered along with other
risk mitigation strategies.
o
Maintaining de-scope options at 10% of the baseline ETC is not always possible
over the project duration, particularly as the project nears completion and the
options are past their last possible implementation dates.
o
Viable scope opportunities are more likely to be achievable late in the schedule
as the risk exposure decreases and confidence in an on-budget completion
increases. The likelihood of late decision points should inform the list of scope
opportunities.
•
Identify practical technical or project considerations related to scope contingency
options. For example, on ship construction, adding or removing fixed scope, or major
enhancements to capabilities could lead to potential rework, and impact weight and
stability.
•
The actual savings of executing de-scope options may not be as much as initially
anticipated since the initial list of options may have been based on rough order of
magnitude cost estimates and not considered all implications of the change.
Document Number
295
4.7 Contingency Estimating and Management
Research Infrastructure Guide
Figure 4.7.2.3-1
Comparison of Risk Exposure to Available Contingency Over Time
4.7.2.4
Contingency Estimating for Major Facility Design and Construction Stages
The ability to estimate risks and uncertainties naturally changes over time as the design is
refined, risks are mitigated, and the understanding of the project matures. During the
Conceptual Design Phase, some form of quantitative risk analysis based on discrete risks
and uncertainties should be developed to provide an adequate estimate of risk exposure.
The use of probabilistic risk analysis to help establish a contingency budget at a specific
confidence level is not required in the Conceptual Design Phase.
When the proposed project reaches the Preliminary Design Phase, the drawbacks of simpler
quantitative analyses – the limited subset of risks, ignored correlations, and arithmetic sums
of averages – do not allow an adequate portrayal of total project risk exposure. Awardees
should transition to probabilistic Monte Carlo risk analysis to establish a credible riskadjusted TPC at the time of the PDR.
At the PDR, Awardee must include a funding profile by fiscal year that includes the necessary
funding obligations to meet scheduled objectives, plus that associate annual budget
contingency needs. The profile should come from the current RLS to eventually be used for
EVM reporting, even if resourced at a relatively high level. Since the outcomes of PDR
potentially inform the budget request to Congress, this profile allows NSF to show not only
the Year 1 request, but also future appropriation needs. The annual Congressional
appropriation needs to be sufficient to accomplish the work proposed and provide the
Document Number
296
4.7 Contingency Estimating and Management
Research Infrastructure Guide
financial resources needed to manage the risks foreseen during that period, or the likelihood
of exceeding the authorized TPC increases.
Project Teams should refine the cost estimates following PDR, adding additional known risks,
clarifying definitions, updating likelihoods and impacts, and mitigating risks where possible.
At the FDR, the budget estimate should be based on externally obtained cost estimates
(vendor quotes, bids, historical data, etc.) to an extent practicable. These are expected to
result in an increase in the project’s estimated Budget at Completion (BAC), or baseline cost,
with an associated reduction in the budget and schedule contingencies. FDR confirms that
the sum of the two remains at or below the budget request to Congress.
NSF may partner with other entities to design and construct a Major Facility or design and
implement Mid-scale RI. The guidelines in Section 5.8 Partnerships should be considered
when NSF funds a particular scope of work within a larger project. Risk assessment,
contingency development processes, and contingency status reporting are to be applied to
those WBS elements proposed for funding by NSF. NSF encourages the development of a
unified risk management approach and a clear understanding of expectations between
partners, for the planning and execution of the entire project scope.
An NSF Major Facility in Construction Stages is subject to NSF’s No Cost Overrun Policy (see
Sections 1.4.7 NSF No Cost Overrun Policy and 2.6.1 Construction Award Management and
Oversight for additional requirements and guidance related to contingencies).
4.7.2.5
Contingency Estimating for Major Facility Operations Stage
The processes and procedures for handling risk differ greatly between the Construction and
Operations Stages. As with construction, operations have many inherent risks. However, the
risks are markedly different in nature. Operational estimates are usually based on wellunderstood historical information and experience with routine risk exposures, which can be
included in the BOE as part of the most likely cost for each operational WBS element. The
work itself is based on the day-to-day activities of science support staff and required
consumables rather than production, assembly, and testing of discrete deliverables
associated with a new, one-of-a-kind, facility.
Although budget contingency may be requested and approved, Awardees of Operations
Stage awards generally use, in approximate order, the following strategies:
•
Routine risk impacts are included in the BOE as part of the most likely cost.
•
Re-budgeting authority per the award terms and conditions.
•
Reduce the level of science support effort (with NSF approval if significant).
•
Request supplemental funding, assuming proper justification, availability of funds,
and support from the PO.
In contrast, risk handling on Construction Stage awards uses the strategy per Sections 4.6
Risk Management and 1.4.7 NSF No Cost Overrun Policy.
Per Section 4.3.3.4 Uncertainty, Accuracy, and Allowances, explicitly identified allowances can
Document Number
297
4.7 Contingency Estimating and Management
Research Infrastructure Guide
be used and are generally more appropriate for Science Support Program budgets for
repairs, replacement, and maintenance. Awardees should use a systematic program to
identify the potential costs and operational impacts of both recurring and non-recurring
events to develop these allowances and clearly articulate this information as part of the BOE.
For NSF, if appropriate, allowances could include uncertainties associated with cost
estimating (as part of the BOE) in lieu of a defined risk.
Any request for budget contingency must be justified and fully supported through a formal
risk assessment process, including a Risk Management Plan. A separate contingency budget
may be preferable when risks are better managed in aggregate, or if the award includes
significant upgrades that should be managed as a separate sub-project. Added
administrative effort for both the Awardee and NSF should be carefully weighed against the
benefits, and the ability to effectively handle operational risks though the more common
strategies listed above.
4.7.3
Contingency Management
4.7.3.1
Contingency Management Controls
Management of contingencies is described in
the Contingency Management Plan (see NSF Requirement
Section 3.5.4.3 PEP Subcomponent 4.3 – Contingency use is subject to specific
Contingency Management Plan). In this plan, requirements to ensure accountability and
thresholds are established (based on the transparency. Contingency use must be:
technical nature of the project) for those who
• Tied to identified risks in the Risk
Register that are realized.
have the authority to approve the use of
contingencies. These thresholds are also
• Subject to NSF approved change
controls with defined thresholds for
documented in the terms and conditions of
approval and expectations for
the award. Below certain thresholds, the
documentation.
Awardee has the authority to manage and use
• Related to specific WBS elements.
contingencies accordingly, whether budget,
schedule or scope contingency. Above a
certain threshold, Awardees must obtain NSF approval, with the level of approval typically
corresponding to the magnitude of the proposed change. A CCB may also be used to ensure
certain experts concur (e.g., science advisors, other agencies, independent technical or cost
reviewers).
De-scopes are a risk management tool, and the cost savings is normally handled as a put to
the budget contingency. Underruns, once a WBS element is complete, could be added to the
budget contingency, be allocated to another WBS element in accordance with rebudgeting
authority in the award terms and conditions, or retained in the same WBS element until
needed elsewhere or eventually de-obligated. Regardless of the method, it is important that
the movements of budget are tracked, reported and follow the Change Control Process. See
Table 4.7.3.1-1 for an example of baseline Change Control approval thresholds for a Major
Facility in construction.
Document Number
298
4.7 Contingency Estimating and Management
Research Infrastructure Guide
Table 4.7.3.1-1
Baseline Change Control Authority Levels
Level 1
National Science Foundation
Level 2
Project Manager
Level 3
Control Account Manager
Any change that impacts Key
Performance Parameters or
execution of the Scope
Management Plan.
Any change to scope that does
None
not affect KPPs.
Cost
Any single change requiring
utilization of more than
$100,000 of contingency.
Any single cost change.
Use of contingency below a
Level 1 cost change and above <$10,000; not to exceed
$30.000 in a month.
a Level 3 cost change
Schedule
Any Level 1 or 2 milestone
change.
Any Level 3 milestone change
that does not affect a Level 1 or None
Level 2 milestone.
Scope
The EVM framework for financial status reporting will eventually reflect contingency
movement into the PMB budget (and an increase in BAC).
While budget contingency is developed based
on assessing risk exposure and the impacted Key Takeaway
WBS elements, once estimated and authorized, Like EVM itself, use of budget contingency
it loses its identification with any specific cost is strictly a reporting (paper) exercise to
element. As stated above, it is a budget held show movement of budget, not a financial
separately from the PMB to manage known or accounting exercise in terms of tracking
risks in aggregate. As a result, it is fungible actual costs. Use of budget contingency is
throughout the project to manage the overall an estimate of potential future costs based
project risk. Only when a risk is realized does it on realized risks, where the actual costs
may not be incurred for weeks, months, or
get allocated to the impacted WBS elements
years.
which is strictly a reporting exercise (including
NSF approvals in accordance with the award
terms and conditions) to show movement of budget, not a financial/accounting exercise
related to actual costs. Budget contingency is never shown as an actual cost or expense. To
simplify processes and avoid unnecessary administrative tasks, it is recommended that
Awardees manage to PMB and budget contingency within a single internal account. This
approach ensures efficient oversight and avoids the potential confusion or misperception
that a separate reserve account is being maintained.
Controls in NSF’s financial system prevent the cumulative Awardee cash draws from
exceeding the obligated spending authority. All funds are retained within NSF’s obligated
award amount to be drawn down by the Awardee for allowable expenses once needed. NSF
conducts various post-award monitoring activities, such as periodic external reviews (whose
scope includes financial as well as technical status), site visits, and single and programspecific audits to monitor compliance.
NSF may request a recovery plan if the contingency budget appears inadequate to manage
the remaining risk.
Document Number
299
4.7 Contingency Estimating and Management
4.7.3.2
Research Infrastructure Guide
Contingency Management Documentation
Changes to the PMB budget through use of contingency and rebudgeting should be
traceable through historical records to the initial PMB release. All CCP Change Requests are
to be logged, documented, and archived by the Project Team, with the logs and
documentation available to NSF for review in accordance with the PEP and the award terms
and conditions.
Change Request Form. The CCB Change Request document, whether forwarded to NSF for
approval or not, should have the following minimum content requirements (see the sample
Change Control Request Form in Section 3.5.7.3 PEP Subcomponent 7.3 – Change Control
Plans):
•
Impacted WBS element(s) to allow technical differentiation.
•
Risk identification number from the Risk Register.
•
An analysis demonstrating that the proposed scope, schedule, and cost impacts are
reasonable.
•
Specify all Control Accounts that the budget is being allocated to or recovered from
and tie to budgets itemized by cost element (i.e., labor, materials, supplies, etc.).
Change Request Log. The Change Request log, which summarizes all individual Change
Requests and tracks available budget contingency, should include the following at a
minimum:
•
Change Control action title and document reference number.
•
Change Level as defined in the CCP
•
Awardee approval date.
•
NSF approval date, if required.
•
Risk Register ID number(s) and description for the risk(s) being addressed.
•
WBS elements impacted by the change(s) at an appropriate level for technical
differentiation, including the amounts of change in scope, schedule, and/or budget
for each affected and identified WBS element.
•
All puts and takes and schedule impacts.
•
Remaining contingency balances against the total authorized amount and the
amount obligated/allocated to date.
Budget Reporting. All awards with budget contingency should undergo periodic reporting
to NSF in accordance with the terms and conditions of the award. For Major Facilities in the
Construction Stage, contingency use is generally reported monthly as part of the project
status report.
The Change Requests and Change Log described above are intended to meet this
requirement and also track the use of schedule and scope contingencies.
Projected amounts of future adjustments to contingency in the Liens List (described further
below) should also be periodically reported, generally within the monthly status report as
Document Number
300
4.7 Contingency Estimating and Management
Research Infrastructure Guide
well.
4.7.3.3
Contingency Management Forecasting
As a project progresses, the baseline cost estimate and schedule will evolve, contingencies
will be used, and re-budgeting authority exercised. The project cost estimate should be
revised periodically to reflect all new information, including actual costs and use of budget
contingency, market changes, the learning curves for manufactured items from vendors, and
lessons learned by the Project Team. Key forecasting terms and concepts include (see also
NSF EVM Gold Card):
•
The revised estimate of the cost of the remaining work is called the ETC.
•
The Actual Cost of Work Performed (ACWP) + ETC equals the latest revision of the EAC.
•
The EAC should equal the BAC only at the start of the project and after major changes
to the baseline from replanning or re-baselining.
•
The EAC should be compared to the BAC to identify potential new liens on the
remaining contingency.
For NSF-funded projects, contingency amounts are not included in the ETC, EAC, BAC, or PMB
due to the NSF requirement that contingency be held and managed separately from the
baseline.
Risk exposure changes with risk responses and realization, new knowledge, and new
circumstances as time passes. The remaining budget contingency also fluctuates over time
with risk realization and the return of any savings, either from a risk being retired or work
packages coming in below the estimated budget. There is often a lag between project actions
such as risk realization and formal Change Control execution where the cost impacts are fully
manifested. The Awardee should, therefore, maintain a Liens List of planned future
adjustments to contingency as a forecasting tool that tracks actions that have not yet been
incorporated into the BAC. The Liens List acts as an escrow or staging account for planned
or near-certain contingency use.
The Liens List may document items such as very high probability risks with trigger points for
action, deferred scope held as a form of contingency until the decision is made, realized risks
needing draws on contingency that substantiate more definition for a Change Control action
to be implemented, and anticipated opportunities for returns to contingency. It can also be
used to record the need for a contingency to cover budget and schedule variances that
cannot be mitigated. It does not serve the same purpose as a watch list or major threats list
from the Risk Register. The Liens List should include a description of the identified risk and
the anticipated action, with estimates of budget and schedule impacts and anticipated
decision date for any Change Control action. The affected WBS elements should be identified
at the second level (or the first meaningfully specific level of scope description), where
known.
At least annually, the Awardee should update the remaining risk exposure based on the
quantitative risk analysis with current risks and uncertainties per Section 4.6 Risk
Document Number
301
4.7 Contingency Estimating and Management
Research Infrastructure Guide
Management. For Major Facilities in the Construction Stage, a combined cost and schedule
risk analysis using Monte Carlo methods in the 70-90% confidence range and liens should be
included.
•
RAEAC is the ACWP + ETC + remaining risk exposure (including liens). This RAEAC
should be compared to the BAC plus the remaining available contingency budget.
Note: The NSF EVM Gold Card refers to this as TPCEVM.
•
The total remaining available budget contingency should be compared to the
remaining risk exposure (including liens) to determine whether the project has
adequate funds to cover anticipated risks.
•
The sum of the EAC and liens should include variances (backward-looking actuals) and
updated estimates (forward-looking forecasting) in the current plan.
If the RAEAC is greater than the TPCEVM, de-scoping may be necessary. NSF may request a
recovery plan if the contingency budget appears inadequate to manage the remaining risk,
generally when the confidence level drops to 50%. The Awardee should also determine what
percent confidence the remaining contingency provides and, if necessary, how much more
contingency might be needed to get back to the desired 70-90% confidence range.
Good Practices and Practical Considerations
•
Considerations for setting approval thresholds include:
o
A larger award amount may warrant the establishment of higher thresholds
to lower the administrative effort for both the Awardee and NSF and potential
schedule delays.
o
The complexity and risks associated with the technical nature of the project
may warrant more NSF involvement and, hence, lower thresholds.
o
Past performance may help to indicate whether an Awardee’s Change Control
Process is adequate. Poor conformance to documented Change Control
Processes would support a lower threshold.
o
The Project Team should ensure that safety protocols are not inhibited while
the use of contingencies is under review.
•
Once construction begins, the actual cost for specific WBS elements is likely to exceed
the estimated cost. As stated above, the Project Team can choose to allocate
contingency per the process defined in the PEP for Change Control. In other cases,
the actual cost will be less than the estimates, and the Team may decide to transfer
budget from the affected WBS elements to contingency using re-budgeting authority.
In either case, whether it’s a risk realized or a risk retired, the Change Control
documentation should tie this transfer back to an identified risk in the Risk Register.
•
If needed, and at the appropriate time, cost underruns may either be assigned to
contingency or re-budgeted following the Change Control Process. If approved, this
may involve the AO increasing the contingency balance obligated through an award
modification to ensure proper documentation by NSF in concert with the Change
Control Log.
Document Number
302
4.7 Contingency Estimating and Management
•
Research Infrastructure Guide
For many projects, schedule and budget contingency use occurs during procurement
and the final commissioning/integration phases. A contingency allocation curve for
such a project would be bimodal, with one peak for procurement activities and
another peak for significant contingency amounts held back until the end of the
project, even though the spending curve may be low near the end of the project.
Although risk generally decreases over time, significant reworking of hardware, for
example, may be needed due to knowledge gained during integration and
commissioning activities. Therefore, it is good practice to retain in contingency
approximately 20% of the ETC throughout the project as a rule of thumb.
Document Number
303
5.1 Introduction
5.0
SUPPLEMENTAL GUIDANCE
5.1
INTRODUCTION
Research Infrastructure Guide
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
This chapter provides supplemental guidance on diverse aspects to ensure that the Research
Infrastructure (RI) supported by NSF meets high standards regarding technological,
environmental, human resource, and management considerations. It underscores the
complexities of managing and overseeing research activities in the modern scientific
landscape.
5.2 Cyberinfrastructure. Describes Cyberinfrastructure (CI) encompassing the technical
systems, policies, and staffing required to support a facility’s scientific mission to remain
aligned with evolving research needs and technologies.
5.3 Information Assurance. Specifies how Awardees should protect research data from
cyber threats and unauthorized access by implementing a comprehensive program that
ensures confidentiality, availability, and integrity.
5.4 Environmental Considerations. Outlines key federal environmental laws and
regulations that help protect natural and cultural resources, minimize adverse
environmental impacts, and reduce the risk of litigation associated with noncompliance.
5.5 Property Management. Defines responsibilities for Awardees and NSF for managing
NSF-funded property throughout its life cycle.
5.6 NSF Budget Categories. Provides detailed guidance on budget justification for
financial assistance in alignment with NSF’s Proposal and Award Policies and Procedures
Guide (PAPPG).
5.7 Personnel and Competencies. Emphasizes the importance of skilled professionals
with diverse competencies to effectively manage Major Facilities and Mid-scale RI, as
outlined by NSF.
5.8 Partnerships. Details the essential elements required for Major Facility and Mid-scale
RI projects to build effective partnerships, including careful planning, formal agreements,
and early notification to NSF to ensure compliance with legal and geopolitical
considerations.
5.9 Agile Guidance. Includes guidance on incorporating Agile methodologies in NSFfunded projects, combining traditional and Agile approaches for effective management.
Document Number
304
5.2 Cyberinfrastructure
5.2
Research Infrastructure Guide
CYBERINFRASTRUCTURE
Section Revision: June 2025
Prepared by the Directorate for Computer & Information Science & Engineering (CISE)
Cyberinfrastructure (CI) is the ensemble of computational, data, control, and user-focused
software and middleware, networking, and cybersecurity infrastructure and associated
policies, standards, protocols, and staffing needed to accomplish the scientific mission for
Major Facility or Mid-scale RI. CI elements may be embedded in the Major Facility or Midscale RI and leverage or interface with existing external CI resources.
CI associated with science deliverables is typically distinguished from information
technology, i.e., the administrative- and staff-oriented IT systems and elements needed to
conduct day-to-day operations of the facility itself and serve the staff, e.g., hardware/servers,
personal computers, LAN, and facility security systems. By distinguishing CI from traditional
IT, facilities can ensure that they allocate appropriate resources and support to both areas,
thereby optimizing the overall efficiency and productivity of their operations and research
activities.
Owing to the rapid pace of change of both CI technologies and the changing needs of users,
the approaches to development, deployment, and operation of CI can be dynamic. During
operations, in particular, periodic refreshing and enhancement of CI capabilities is
commonly needed to assure continued robustness, security, and scalability of the underlying
technology infrastructure and that CI continues to be well-aligned with the facility’s vision
and science mission, which necessitates well-defined planning and oversight of CI across the
Major Facility or Mid-scale RI life cycle.
5.2.1
CI Plan Requirements
All proposals for Major Facility and Mid-scale RI must include a CI Plan that outlines the
strategy and approach for CI across the life cycle of the proposed RI. If the Mid-scale RI is an
upgrade to a Major Facility, it can leverage the Major Facility’s CI Plan. The CI Plan should be
tailored and scaled and progressively elaborated as the Major Facility or Mid-scale RI
advances through its life cycle stages, ensuring alignment with the mission and objectives of
the RI. Existing Major Facilities or Mid-scale RI may also develop a CI Plan following this
format based on requirements provided by the cognizant Program Officer. For good
practices on topics to address in the CI Plan, see the NSF Cyberinfrastructure Plan Outline
on the Research Infrastructure Documents and Guidance webpage. 1
5.2.2
CI Plan Purpose and Scope
A CI Plan provides a structured approach for planning, implementing, and managing the CI
aspects of the RI. It also serves as a roadmap for the CI within a Major Facility or Mid-scale RI
and thus helps ensure that NSF's requirements for CI are thoroughly included during
development, design, construction/implementation, and operations. It serves as guidance
1
https://www.nsf.gov/bfa/lfo/lfo_documents.jsp
Document Number
305
5.2 Cyberinfrastructure
Research Infrastructure Guide
for downstream oversight and review of the CI aspects of the infrastructure. Thus, the CI
strategy and elements should be defined and planned for from the inception of the RI, be
adequately resourced, including for periodic technology refresh, and evaluated for adequacy
and performance throughout each life cycle stage. The CI Plan ensures that the complexities
of the CI are well-documented and clearly communicated enabling effective management
throughout the RI’s life cycle.
The CI Plan should not restate or introduce new requirements or technical/operational
design elements; instead, it should reference relevant planning and management
documentation. Given that data are central to many Major Facilities or Mid-scale RI missions
and often drive CI requirements, the CI Plan should appropriately refer to relevant datarelated requirements and design documents. These may include the Data Management Plan,
definitions of data products and life cycles, and requirements related to open science and
open data principles such as FAIR (Findable, Accessible, Interoperable, and Reusable).
Additionally, it should consider emerging principles like data sovereignty, including the CARE
Principles for Indigenous Data Governance (Collective Benefit, Authority to Control,
Responsibility, and Ethics), along with associated requirements for data management,
archiving, curation, and accessibility.
NSF acknowledges that various elements of the CI Plan may already be included in other
Major Facility or Mid-scale RI plans and documentation. However, having a dedicated CI Plan
is crucial as it ensures that all elements of CI are documented in one place that reviewers
and RI team members can specifically reference and clearly understand CI components
within the broader context of the entire Major Facility or Mid-scale RI life cycle.
The CI designs for RI, and thus the CI Plan, should include consideration of both internal
systems within the scope that the proposing organization owns and operates, as well as any
external CI resources that the proposing organization may not own or operate, but need to
be leveraged and integrated into facility operations to accomplish its science mission,
including, but not limited, to NSF-supported resources such as advanced computing, data
and software infrastructure, resources, and networking.
Document Number
306
5.3 Information Assurance
5.3
Research Infrastructure Guide
INFORMATION ASSURANCE
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Definitional Note: Information Assurance (IA) is used
as the umbrella term inclusive of cybersecurity, data Key Takeaway
protections
(including
privacy),
cyber
risk IA encompasses cybersecurity, data
management, and resilience. What was formally
protections, cyber risk
referred to as the security plan is now called the
management, and resilience.
Information Assurance Management Plan (IAMP) to
align the terminology with contemporary use and underscore the distinction between
technical operations and program management (see Section 5.3.4 Information Assurance
Management Plan). That is, the subject of IA is information and not merely information
systems.
5.3.1
Introduction
IA is fundamentally a risk management program and is the responsibility of the management
organizations of Awardees. Management organizations have significant leeway in how they
choose to address IA. However, NSF remains committed to ensuring that the mission of
funding vital national assets is sufficiently protected from disruption, misuse, theft, or
damage. In pursuing this goal, NSF requires sufficient documentation and evidence that
Awardees are performing good stewardship regarding IA. As discussed further in the section,
Major Facilities and Mid-scale RI teams must develop and implement an IA Program
documented in an IAMP as part of the Design Execution Plan, Project Execution Plan, or
Annual Work Plan. If the Mid-scale RI is an upgrade to a Major Facility, it can leverage the
Major Facility’s IAMP. It should be appropriately scaled and tailored to the size, complexity,
and technical nature of the funded activities defined as follows:
•
The IA Program is a set of measures that are taken together to protect and defend
information and information systems.
•
The IAMP is the high-level narrative summary of the IA Program.
The Awardee should recognize that it cannot address cyber risks merely through technical
controls. Cyber-related threats evolve regularly, and prioritizing their mitigation should be
done at the highest levels of a Major Facility or Mid-scale RI management.
Accordingly, an IA Program should be managed in keeping with the principles that:
•
A Major Facility or Mid-scale RI’s IA Program should reflect its specific mission and
goals.
•
Cybersecurity attacks and defense are rapidly evolving areas of activity, and any such
program should be similarly adaptive.
•
IA should be approached programmatically in contrast to a handful of transactional
practices.
•
IA should support the protection of vital national assets from cyber-attacks and data
Document Number
307
5.3 Information Assurance
Research Infrastructure Guide
theft.
•
IA Programs should include engagement with and support of managing organization
leadership.
•
IA Programs should provide NSF with sufficient information about the planned and
executed IA Program to meet its oversight duties.
•
Commonly recognized critical and impactful cyber hygiene controls should be fully
implemented.
Research programs differ from traditional commercial enterprises in many ways. From the
location (traditional Major Facilities or Mid-scale RI to airplanes, ships, and field work) to the
technology (highly customized instrumentation, computational facilities, and data
structures), to the people (students, faculty, remote collaborators), and as such, Awardees
should adapt IA Programs and specific cybersecurity practices to the needs of the research
program. Major Facilities and Mid-scale RI should strive for resilience, consisting of:
•
Minimizing the likelihood of successful attacks in general and unsophisticated,
opportunistic attacks.
•
Minimizing the impact of even sophisticated attacks by constraining the impact or
ability to spread throughout a facility.
•
Minimizing the period of the disruption of scientific operations.
•
Ensuring the integrity of scientific data and artifacts despite a cybersecurity incident.
An effective IA Program that fosters resilience consists of multiple key elements. While it is
easy to focus on specific cybersecurity practices (e.g., strong passwords), the success of any
IA Program is contingent on effective engagement with the NSF Program Office and facility
management.
As with any risk management program, cyber risk is rarely eliminated, rather it should be
minimized where feasible and residual risk should be acknowledged and formally accepted
by facility leadership. NSF evaluates whether cyber risks have been appropriately managed
and addressed through its oversight processes.
Document Number
308
5.3 Information Assurance
5.3.2
Research Infrastructure Guide
Framing Information Assurance Risks in the Contemporary Threat
Landscape
Major Facilities and Mid-scale RI face a wide array Figure 5.3.2-1
of threats and pressures that require attention. Threats to Major Facilities and Mid-scale RI
Facilities should include cyber risks in the Risk
Register which is discussed at length below (see
Figure 5.3.2-1). Four key areas are detailed below
to assist with the establishment of the cyber risk
elements of a Risk Register and to enhance
situational awareness for both PO and facility
management.
5.3.2.1
Geopolitics
The state of the U.S. relationship with several
adversarial countries directly impacts cybersecurity operations. The goal of some state actors
is not always focused on the theft of data or
intellectual property; often, the purpose is simply
the costly disruption of operations. Countries on
the Office of Foreign Assets Control sanctioned list or with International Traffic in Arms
Regulations restrictions warrant special note in this context. 1 Both the Cybersecurity and
Infrastructure Security Agency and the Federal Bureau of Investigation are effective partners
in staying abreast of national security threats. 2,3
5.3.2.2
Specific Research Domains
Facilities that work in specific domains or with nationally critical or emerging technology
should recognize that this work may attract the attention of individuals or groups that are
acting on behalf of a government or nation-state, also referred to as state actors. These
domains include export-controlled data, research involving technology on the Critical and
Emerging Technologies List, vaccine development, or defense related research. 4
5.3.2.3
Regulatory Pressures
Regulations that address cybersecurity practices continue to be advanced by the federal
government and many federal agencies. For example, the National Security Presidential
Memo 33 and subsequent Office of Science and Technology Policy (OSTP) memos identify
cybersecurity as a core component of research security program. 5 Dual use facilities may
1
https://ofac.treasury.gov/sanctions-programs-and-country-information
2 https://www.cisa.gov/resources-tools/services
3 https://www.fbi.gov/investigate/cyber
4 https://www.whitehouse.gov/wp-content/uploads/2022/02/02-2022-Critical-and-Emerging-Technologies-ListUpdate.pdf
5 https://www.whitehouse.gov/wp-content/uploads/2024/07/OSTP-RSP-Guidelines-Memo.pdf
Document Number
309
5.3 Information Assurance
Research Infrastructure Guide
also be facing new Controlled Unclassified Information or other cybersecurity requirements
when engaged with the Department of Defense, or Department of Energy supported
research. Finally, many of the newer privacy focused regulations contain their own data
handling requirements as well as imposing specific cybersecurity controls. Facilities should
monitor the activities of all agencies they interact with and examine these for potential
impact on NSF sponsored programs. NSF’s Office of the Chief of Research Security Strategy
and Policy is a valuable resource for any facility. 1
5.3.2.4
Other Attacks and Concerns
Finally, security professionals are faced with a variety of exigent and emerging attack types,
some of short duration, others of a more enduring nature. Current examples include
ransomware, supply chain management, and MFA fatigue. 2 Items such as these should be
evaluated at least bi-annually, and mitigation plans developed or updated.
5.3.2.5
IA Program Tailoring and Scaling
An IA Program should align with the nature and scope of a facility, whether a Major Facility
or a Mid-scale RI. Accordingly, the materials should be appropriately tailored and scaled. Midscale RIs, which often rely on institutional information security programs, may provide IAMPs
that primarily reference institutional resources and processes, detailing only infrastructurespecific elements. In contrast, Major Facilities, which typically develop standalone security
programs, should provide more comprehensive and rigorous IAMPs.
An IA Program should also align with facility’s life cycle stage. Through the Design Stage, most
proposed projects can only describe how cybersecurity plans to be integrated into the CI
Plan, and what is intended for the future IA Program. However, programs should begin
identifying and anticipating cyber risks as early as possible, allowing time for mitigations to
be planned and resourced. Over time, the IAMP should be progressively elaborated to reflect
the increasing maturity of the IA Program.
5.3.3
Cyber Risks
Awardees should include cyber risk as a category in the Risk Register, if applicable, (see
Section 4.6 Risk Management) and systematically addressed through a Risk Management
Plan. Note that cyber risks included on the Risk Register may be included in the contingency
planning process. Awardees should categorize and codify cyber risks in the Risk Register to
facilitate ease of organizing and extracting them for review, and review them at least
quarterly.
1 https://new.nsf.gov/research-security
2 MFA
fatigue refers to the overwhelming attempts to log into an MFA protected account by a hacker resulting in the
user accepting or approving the access out of fatigue from declining to approve it. See
https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications508c.pdf for a discussion on preventing MFA fatigue.
Document Number
310
5.3 Information Assurance
Research Infrastructure Guide
Cyber risks may be broken down into sub-categories, for example: 1
•
Strategic Risks. For example, relevant geopolitical flareups, reputational damage
from cyber breaches, regulatory compliance, unmet budget, or staffing needs.
•
Exigent or Emerging Risks. e.g., ransomware, supply chain, urgent and impactful
vulnerabilities.
•
Operational Risks. Unmet controls in any adopted standards, i.e., gaps in the
baseline cybersecurity practices.
A reasonably complete set of risks requires input from facility management, scientists and
researchers, and CI and cybersecurity professionals. Each of these groups will have different
perspectives and concerns which should be captured in the Risk Register. Conversations with
allied or similar facilities will also be helpful. Additionally, the Open Science Cyber Risk Profile
was created specifically to assist with risk identification from the perspective of domain
scientists. 2 It can serve as a framing device for tabletop risk identification exercises.
5.3.4
Information Assurance Management Plan
Created by the Major Facility or Mid-scale RI’s IA Lead, the IAMP must provide a high-level
framework for managing an IA Program. 3 It should clearly codify the Program's scope, roles
and responsibilities, governance, and controls, ensuring a structured approach to
cybersecurity and risk management. Unlike a collection of standalone policy or procedural
documents, the IAMP serves as a cohesive guide that integrates these elements into a
comprehensive IA strategy.
The IAMP is intended to be used as part of the Major Facility or Mid-scale RI management
and the following elements should be included:
•
1 This
Statement of Cyber Risk Management Strategy. A cyber risk management strategy
is the process for identifying, assessing, and controlling cybersecurity risks. In
addition to a brief narrative description of the cyber risk management strategy, this
section should include:
o
A Cybersecurity Framework. A cybersecurity framework refers to the
approach taken to organizing an IA Program. This shapes the organization’s IA
Program (see Section 5.3.7 Building an Information Assurance Program).
o
Baseline Cybersecurity Control Set. Specific practices and technologies the
proposer or organization plans to commit to, or has committed to,
implementing to manage cyber risks. A nationally or commonly recognized
taxonomy is provided for the purposes of illustration only.
2 https://trustedci.github.io/OSCRP/
3 The
IA lead, typically entitled an Information Security Officer, is the individual accountable for the entire execution of
the IA Program. While it is ideal to have a dedicated, full time staff member in this role, it is also common to assign
the duties of the information security officer to an existing staff member, typically a member of the infrastructure team.
RI management should expect their IA lead to participate in cross-RI communities and programs. NSF recommends
including the IA Lead on the executive management team.
Document Number
311
5.3 Information Assurance
Research Infrastructure Guide
standard is recommended.
o
Risk Response Plans. Outlines how critical risks, such as ransomware, are
mitigated. They consolidate individual technical, policy, and process controls
into a single summary document, ensuring complex risks are effectively
addressed
•
Scope and Boundaries. A formal enumeration of network and service boundaries is
particularly critical where resources or networks are shared or support dual-use
situations. Include network, cloud, and data resources, as well as organizational
resources.
•
Responsibility Model and Matrix. Roles, responsibilities, and relationships among
the IA and CI teams and critical partners. Include responsibilities for risk identification
and acceptance (therefore include facility and program leadership).
•
Governance. Any governance and advisory committees, working groups, and a
description of their roles and decision-making rights regarding IA.
•
IA Program Operations. This section of the IAMP enumerates and describes core
processes, functions, and responsibilities of the IA Program. It should include the
following components.
•
o
Programmatic Processes. Systematic and structured approaches to
managing various aspects of a program provide a framework for managing
activities within the IA Program. Provide a description and activities to address
processes such as inventory, policy exception handling, or compliance
monitoring.
o
Baseline Security Functions. Establishes baseline security functions crucial
for maintaining an organization's strong and resilient security posture and
serves as fundamental building blocks for a comprehensive security strategy.
Provides a description of and related activities to address functions such as
(but not limited to) incident response, email anti-spam and malware
protections, account management, MFA, vulnerability detection, and patching.
o
Supplemental Responsibilities of the Security Program. Supplemental
responsibilities in a security program go beyond the foundational security
functions and involve additional activities often specific to the Awardee’s
needs, industry regulations, and risk landscape. Provide a description of and
related activities to address supplemental responsibilities, such as regulated
data contract/supply chain review and approval, security awareness, and
training, if these are considered part of the IA Program.
Assessment Plan. Regularly assessing the implementation of baseline security
controls and overall success of the risk management strategy is crucial for ensuring
that security measures remain effective over time. Describe how the controls plan to
be monitored and assessed and consider engaging outside resources for a program
assessment. Weaknesses identified during any assessment should become a
component of the Risk Register (see Section 5.3.10 Program Assessment).
Document Number
312
5.3 Information Assurance
5.3.5
Research Infrastructure Guide
Critical Controls
Awardees must address relevant statutory and legal requirements in their IAMP, ensuring
they are regularly reviewed and updated. For example, Uniform Guidance §200.303 states
that the Awardee’s internal controls, including technology infrastructure and security
management, should be compliant with guidance published by the Comptroller General or
Committee of Sponsoring Organizations of the Treadway Commission. 1, 2
Several cybersecurity controls have been identified as exceptionally impactful in improving
the resilience of Major Facilities and Mid-scale RI, as illustrated in Table 5.3.5-1. These
controls should be embedded within the Awardee’s management practices for each Major
Facility and Mid-scale RI and targeted for prioritized implementation. For new facilities, these
controls should be integrated during design and construction. For operational facilities, they
should be phased in within a reasonable timeframe, as determined by the NSF Integrated
Project Team (IPT).
For example, many modern best practices, such as phishing resistant multi-factor
authentication (MFA) for account protection, are generally applicable to all facilities. Phishing
is considered a technique for attempting to acquire sensitive data through fraudulent
computer-based means. 3
NSF will continue to align cybersecurity guidance for Awardees with federal cybersecurity
standards. Thus, Awardees are encouraged to accelerate implementation of their IA
Programs and regularly engage with their cognizant PO on the question of new or potential
cybersecurity controls.
To accommodate each facility’s unique nature and workflow, alternative controls or
innovative approaches to mitigating targeted risks should be discussed with the cognizant
PO. For guidance on interpreting these controls, refer to National Institute of Standards and
Technology (NIST) guidance for corresponding controls (suggested mappings to NIST
standards are provided); NSF Subject Matter Experts (SME) are available for consultation
through the cognizant PO. 4
1 https://www.ecfr.gov/current/title-2/subtitle-A/chapter-II/part-200/subpart-D/section-200.303
2
3
https://www.coso.org/
https://csrc.nist.gov/glossary/term/phishing
References are to the cited control families of NIST standard 800-53 revision5 (800-53r5) or 800-171. Thus, as an
example, AC-6(4)(5), SC-3 800-53r5 refers to control family AC, controls 6(4)(5) and control family SC, control 3 of
800-53r5.
4
Document Number
313
5.3 Information Assurance
Research Infrastructure Guide
Table 5.3.5-1
NSF Critical Controls Set
Control Key
Control
Description
NSF1
Phishing resistant MFA for all
privileged/ administrator
accounts
Accounts with system management privileges or the ability to
change a system or an application’s configuration are
privileged/administrator accounts and should require phishing
resistant MFA.
REF: IA-2(1), AC-2(7) 800-53r5
NSF2
Phishing resistant MFA for all
remote access
Protocols, for example SSH, RDP (remote desktop), FTP, VNC, or
VPN should require MFA.
REF: IA-2(2), AC-17 800-53r5
NSF3
Limited scope administrative
accounts
Privileged/administrative accounts should be restricted in scope
(e.g., separate accounts for web servers, database servers, system
management, network management).
REF: AC-6(4, 5), SC-3, CM-7 800-53r5; 3.1.5 800-171
NSF4
Deploy and maintain antimalware software
Deploy anti-malware software to systems capable of running such
software. For a variety of reasons some systems (e.g.
instrumentation, HPC, embedded systems, control systems) may not
be able to run anti-malware software and are thus excluded from this
control.
REF: SI-3 800-53r5
NSF5
Modern anti-malware products include or can be supplemented with
Anti-malware includes
Endpoint Detection Response functionality. These greatly improve
Endpoint Detection Response
the ability to validate system integrity.
functionality
REF: SI-3, SI-7(7) 800-53r6
NSF6
Immutable backups of
systems
Backups of CI should be stored in a fashion as to be immutable from
change, corruption, or deletion.
REF: CP-4 800-53r5
NSF7
Immutable backups of
essential research data
Critical research data should be backed up and stored in a fashion
as to be immutable from change, corruption, or deletion.
REF: CP-4 800-53r5
NSF8
Regular tests of back up
integrity and testing of
restoration process
The backup program should include a step to test the integrity of and
ability for large scale restoration of backups at least once a year.
REF: CP-4, CP-10 800-53r5
NSF9
System and application activity logs for the CI should be centrally
Collect and monitor all system
collected for the purposes of security monitoring and auditing.
logs
REF: AU-2, SI-4 800-53r5
Network segmentation and
isolation control
The network environment should be segmented thus reducing the
ability of malware, such as ransomware, to spread. This may include
any method of segmentation (e.g., network design and routing,
internal firewalls, proxies, bastion hosts, etc.) sufficient to protect the
infrastructure.
REF: SC-7(13, 20,21,28,29) 800-53r5; 3.13 (various) 800-171r2
NSF11
Maintain and update an
inventory of critical
infrastructure
Maintain an inventory of critical infrastructure. Critical infrastructure
are systems and devices that maintain and provide access to
services (e.g., VPN, MFA, Identity and Access Management
systems), network devices, and devices enabling core scientific
capabilities.
REF: RA-2, PM-5 800-53r5
NSF12
Defined process for
identifying, tracking, and
remediating vulnerabilities
A vulnerability management program is a framework for managing
vulnerabilities in systems and software throughout the CI.
REF: RA-5 800-53r5
NSF13
Hardening
standards/processes for
critical infrastructure
Create and implement a secure configuration standard applied to all
systems under direct management.
REF: CM-2, CM-6 800-53r5
NSF10
Document Number
314
5.3 Information Assurance
Control Key
NSF14
5.3.6
Research Infrastructure Guide
Control
Incident Response Plan and
annual tabletop exercise
simulating a major incident
Description
Ensure the Incident Response Plan is documented and approved by
Program and facility leadership. Run a regular tabletop exercise of it
at least annually.
REF: IR-2(1), IR-8, IR-3 800-53r5
Building an Information Assurance Program
Figure 5.3.6-1
Pillars of an IA Program
In the context of IA, a framework refers to the
approach taken to organizing an IA Program.
Typically, these are sets of policies, standards,
guidelines, and best practices established to
control information security risk. It is common for
a complex organization to manage multiple
frameworks as different regulatory bodies often
impose particular frameworks. NSF does not
mandate the use of a specific framework; however,
Awardees must select and identify a framework
for their program in the IAMP. To ensure alignment
with recognize good practices, Awardees should
map maintenance of their selected framework to
established federal or international frameworks.
Examples of federal or international frameworks
include NIST’s Cybersecurity Framework and International Organization for Standardization
27001 and 27002. 1,2,3
To help support facilities in establishing their IA Programs, four key elements upon which to
build resilience have been identified below and depicted in Figure 5.3.6-1.
5.3.6.1
Mission Alignment
Mission alignment requires understanding the scientific goals and workflows at a facility and
considering the researchers’ concerns in shaping the selection and implementation of
practices. Identifying mission alignment is critical throughout the life cycle of a facility
because it should guide the architecture of its assurance program. Awardees should closely
analyze mission alignment in a facility's early stages.
5.3.6.2
Resources
IA Programs require adequate resources. The percent of budget that most Major Facilities
devote to IA covers a wide range and is tightly coupled to the type of facility. 4 It is critical,
1 https://www.iso.org/standard/75652.html
2 https://www.iso.org/standard/27001
3 https://www.nist.gov/cyberframework
4 The
security budget as a percentage of total budget for a ship, for example, may be wildly different than a monolithic
computational facility.
Document Number
315
5.3 Information Assurance
Research Infrastructure Guide
however, for an organization to be able to line item the IA budget, thus surfacing the
investment for explicit review by management.
5.3.6.3
Governance
Oversight of IA is part of the overall facility governance process. Organizational roles,
policies, the acceptance or mitigation of risk, and program assessment require engagement
from the most senior administrators of a facility.
5.3.6.4
Cybersecurity Controls
Every IA Program, within its IAMP, should identify a set of cybersecurity controls it plans to
implement. In response to an analysis of historical incidents, NSF has identified a small set
of essential security controls for prioritized implementation, that should also be addressed
as part of the identified baseline control set. These are detailed in Figure 5.3.6-1.
To avoid investing resources in implementing and assessing low-impact controls, Awardees
should select a baseline standard that includes practices that are widely established and
offer the broadest protection. Many organizations are now developing, or have produced,
subsets of the comprehensive body of security controls, identifying those controls with the
highest return on investment. A robust example of such a control would be MFA. Sample
control sets include:
•
Cybersecurity & Infrastructure Security Agency 1
•
Center for Internet Security 2
Facility leadership may reasonably expect periodic updates on the implementation status for
these standard and established practices. While a control assessment rubric can be as
nuanced and sophisticated as desired, a simplified table is often more accessible for facility
leadership.
5.3.7
Data Management and Curation
Historically, data management and the creation of the NSF Data Management Plan (see
Section 3.5.8.4 Project Execution Plan Subcomponent 8.4 – Data Management) have been a
parallel effort to cybersecurity and CI. 3 Awardees should consider these topics holistically by
reviewing access to data and data integrity concerns through the lens of cybersecurity.
When appropriate, Awardees should carefully monitor the work associated with the 2022
OSTP Public Access Memorandum and ensure that their Data Management Sharing Plan and
budget address considerations for data retention in alignment with the needs of domain
science, organizational policies, sponsoring agencies, and federal guidelines applicable to
1 https://www.cisa.gov/cross-sector-cybersecurity-performance-goals
2 https://www.cisecurity.org/controls/cis-controls-list
3 NSF
requires a Data Management Plan for all awards. To underscore the importance of open science, the Data
Management Plan has been renamed the Data Management and Sharing Plan. Information on the Data Management
Sharing Plan requirements can be found at https://new.nsf.gov/funding/data-management-plan.
Document Number
316
5.3 Information Assurance
Research Infrastructure Guide
sponsored programs. 1
The sheer volume of data created at most Major Facilities and Mid-scale RI far exceeds the
capacity to store everything. Awardees should perform a close analysis with the researchers
to identify data that should be retained, establish retention lifetimes, obtain digital object
identifiers (DOI), target repositories, and identify data sets for which data integrity and
provenance concerns are paramount.
Interfaces to data repositories should be examined as a possible entry vector for malicious
activities and malware. Similarly, IA teams can help review the data pipeline between data
collection to storage, identifying possible threats to data integrity or theft.
It is not uncommon for data that is ostensibly public to have elements requiring redaction
or greater access limits. For example, geolocation information within data on endangered
species has been used by poachers. IA staff can partner with domain scientists and data
curation experts to make recommendations on secure data handling and access procedures
and help evaluate the cybersecurity rigor of preferred data repositories.
5.3.8
Information Assurance and Cyberinfrastructure
Awardees should consider how IA and CI relate to one another when writing an IAMP. It is
quite common to see IA referenced as a component of CI, typically because CI is itself secured
through the application of IA practices. However, because IA is fundamentally a risk
management function, it should not be seen as exclusively a subset of a CI Plan.
CI Plans may reference IA by directly addressing the question, how is the CI described here
secured and maintained?, or by reference to the IAMP or the body of policies and practices
enforced on the CI. 2 However, the management of risk—risk identification, assessment,
mitigation, and acceptance—as a programmatic function sits outside pure CI. Strategies for
cyber risk management should be articulated in the integrated risk program for the entire
Major Facility or Mid-scale RI and referenced in the IAMP.
5.3.9
Cyberbreach Insurance
Increasingly organizations of every size, including Major Facilities, have obtained, or are
pursuing, insurance to cover the costs associated with a cybersecurity incident. Typically,
these packages do more than cover some of the expenses associated with a return to
operations and additionally provide access to expertise in the areas of forensics, crisis
communications, breach notification, and legal counsel. NSF neither requires, nor takes a
position on, cyber breach insurance, however, Awardees should discuss this topic with the
cognizant PO. NSF policy aligns with federal guidance and thus dictates that award funds
https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-access-Memo.pdf
Trusted CI framework provides an excellent starting point with templates for major policy documents,
https://www.trustedci.org/framework.
1
2 The
Document Number
317
5.3 Information Assurance
Research Infrastructure Guide
may not be used to pay ransoms, nor cyber insurance’s ransom coverage. 1
5.3.10
Program Assessment
Awardee leadership or the managing organization should conduct an annual assessment of
its IA Program to evaluate its effectiveness and progress in relation to reportable events and
its mission objectives. This assessment is not only essential for ensuring the efficient use of
IA resources but also for maintaining alignment with evolving cybersecurity challenges and
ensuring that the program remains adequately resourced. The assessment may be
conducted internally or by external evaluators to provide an objective review of the
program’s effectiveness. It will assess if sufficient progress is being made in implementing
the baseline controls and identify gaps in compliance with a chosen framework.
The program assessment should be tailored and scaled to align with the nature and
complexity of the program and should be conducted at any life cycle stage that include an IA
Program.
No IA Program is perfect or complete. Over the life cycle of a Major Facility or Mid-scale RI,
the IA Program should show a steady improvement in maturity as measured using one of
the commonly established methodologies. It may be useful to note that most of the
assessment frameworks in common use assume an enterprise or industrial context. 2
However, if an IA Team has expertise in a specific assessment approach, consider leveraging
that capability. .
1 It
is important to note that 2 CFR 200.447 speaks to insurance as an allowable cost for grant Awardees. In
particular, however, the FBI discourages the paying of ransom or extortion demands, and payments may threaten US
national security, foreign policy interests and may violate Office of Foreign Assets Control regulations.
https://www.ic3.gov/CrimeInfo/Ransomware
2 Such as the NIST CSF framework https://www.nist.gov/cyberframework or the DOE’s C2M2
https://www.energy.gov/ceser/cybersecurity-capability-maturity-model-c2m2.
Document Number
318
5.4 Environmental Considerations
5.4
Research Infrastructure Guide
ENVIRONMENTAL CONSIDERATIONS
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
RI supported by NSF must comply with all relevant international (when applicable), federal,
state, and local environmental requirements. Certain environmental compliance
requirements, such as review under the National Environmental Policy Act (NEPA), must be
addressed prior to a funding decision, and is NSF’s responsibility, though the potential
Awardee may provide input to NSF’s review. The Awardee may have other environmental
compliance requirements after the funding decision is made, such as permitting and
implementation of required environmental mitigation measures.
5.4.1
Environmental Considerations prior to NSF Funding Decision
NSF funding for the construction, implementation, operation, modification, or change in
disposition of a Major Facility or Mid-scale RI constitutes a federal action that triggers NSF’s
compliance with federal statutes and regulations that require NSF to consider impacts on
environmental, cultural, and historic resources as part of its decision-making process. These
legal authorities include, but are not limited to, the NEPA, the National Historic Preservation
Act, and the Endangered Species Act. While NEPA focuses on activities proposed to take place
within the United States, activities that are proposed to take place outside of the United
States may be subject to review under Executive Order 12114 and relevant international
agreements and treaties. 1
Environmental review must be completed prior to the issuance of an NSF decision (e.g.,
award and/or approval for use of funds). Failure to take necessary compliance steps can
cause undue delays in the schedule, significant cost escalation, and potential federal
litigation.
Segmenting a proposed funding action into smaller component parts in such a way that
obscures potentially significant impacts is not allowable. However, NSF funding of planning
and conceptual design activities typically does not have the potential to result in
environmental impacts and, therefore, they are not anticipated to trigger environmental
compliance requirements. Subsequent proposed actions that might adversely affect the
quality of the human environment are, however, subject to environmental review and NSF
approval. There is no special source of funding within NSF to pay for the environmental
compliance process; the cost is normally borne by the program using Research and Related
Activities (R&RA) funds.
5.4.1.1
NSF’s Role in Conducting Environmental Review
NSF’s NEPA implementing regulations found at 45 CFR § 640 supplement the Council on
Environmental Quality’s NEPA regulations published at 40 CFR §§ 1500-1508. PO, as required
by NSF’s regulations, are responsible for evaluating potential environmental impacts that
1
https://www.archives.gov/federal-register/codification/executive-order/12114.html
Document Number
319
5.4 Environmental Considerations
Research Infrastructure Guide
may result from the implementation of a proposal and determining the appropriate level of
environmental review required. The PO is encouraged to consult the NSF Office of General
Council Environmental Compliance Team when determining the extent of compliance
requirements. NEPA compliance may require the preparation of environmental
documentation, such as an Environmental Assessment in cases when significant
environmental impacts are not anticipated, or an Environmental Impact Statement when
significant impacts are anticipated.
Compliance with NEPA may require NSF staff to engage with the public on issues such as
potential environmental impacts and ways to avoid, minimize, and/or mitigate adverse
impacts, including effects on communities affected by increased energy costs, pollution, and
historical under-investment in infrastructure. In conjunction with, or independent of, its
NEPA compliance, NSF may be required to initiate consultations with interested parties,
including Tribal Nations and Native Hawaiians, pursuant to the National Historic
Preservation Act, and/or initiate informal or formal consultation with the National Oceanic
and Atmospheric Administration Fisheries, and/or the U.S. Fish and Wildlife Service under the
Endangered Species Act. 1 The PO may need to rely on and maintain close communication
with the potential Awardee when preparing complex environmental documentation and
during various environmental compliance processes and Tribal Nation consultation, as
described below.
5.4.1.2
Potential Awardee Role in Supporting NSF’s Environmental Review
The potential Awardee may be requested to submit supplemental post-proposal submission
information to NSF in order that a reasonable and accurate assessment of environmental
impacts by NSF may be made. The types of information that may be requested are
exemplified in the NSF Environmental Impacts Checklist. 2 Potential Awardee may choose to
consider environmental criteria, as appropriate, when selecting potential sites and
developing conceptual-level design features, to avoid unnecessary environmental impacts
from any future construction and operation of the RI, should it be funded. Further, Major
Facility and Mid-scale RI proposals may benefit from the potential Awardee’s early
consideration of, and/or engagement with (e.g., through culturally appropriate co-design
processes), communities when considering potential site locations and design features. If
the proposed activities are anticipated to impact Tribal Nation resources or interests, and
financial assistance is used, the potential Awardee must follow the requirements set forth
in the PAPPG, related to seeking and obtaining permission from the potentially impacted
Tribal Nation(s) in accordance with the directives of each Tribal Nation.
There may be cases where the Awardee is authorized to prepare an Environmental
Assessment or Environmental Impact Statement, or to conduct activities in compliance with
other environmental statutes, on behalf of NSF, consistent with 40 C.F.R. 1506.5; in such
1
https://www.fws.gov/program/endangered-species
2
https://www.nsf.gov/bfa/dias/policy/papp/pappg17_1/environimpacts_checklist.pdf
Document Number
320
5.4 Environmental Considerations
Research Infrastructure Guide
cases, consistent with 40 C.F.R 1507.3(c), NSF will review and approve the purpose and need
section and the range of alternatives evaluated within the document and independently
evaluate the document.
5.4.2
Environmental Considerations Following NSF Funding Decision
If the Awardee identifies any unexpected or actual environmental impacts while performing
the work required by the award, they must promptly inform NSF, in accordance with the
award terms and conditions. The Awardee must halt any work causing these impacts until
NSF has had time to evaluate the situation, complete necessary compliance activities, and
give further instructions. The Awardee is also responsible for implementing post-award
mitigation measures or fulfilling reporting requirements determined during the
environmental review process. These requirements may be the responsibility of the Awardee
(e.g., to hire a Tribal monitor during ground disturbing activities) and/or NSF (e.g., to provide
training to facilities staff on how to deal with the presence of a listed species).
Permitting is typically the Awardee’s responsibility and may be obtained after a funding
decision is made. Municipality-issued construction permits, and state or federal agencyissued collections permits are examples of environmental permitting.
Good Practices and Practical Considerations
•
It is recommended that the PO contact the NSF Office of General Council
Environmental Compliance Team early in the Conceptual Design Phase to seek
guidance on specific requirements for compliance. The time required to complete
environmental compliance can take one to two years (or more) depending upon the
level of impacts associated with a proposed project.
•
The potential Awardee may be prepared to submit supplemental information to
assist NSF with determining potential environmental impacts, preparing
environmental documentation, and completing various environmental compliance
processes and consultations.
•
It is extremely important that the PO and the Project Team get cost estimates for the
compliance process and factor these into the proposed project’s scope, schedule, and
budget early in the design process.
•
The cost drivers associated with these activities (their impact on the proposed project
construction cost) need to be well understood by Preliminary Design Review (PDR)
since the Preliminary Design Review budget and risk assessment provide the basis
for the construction funding request.
Document Number
321
5.5 Property Management
5.5
Research Infrastructure Guide
PROPERTY MANAGEMENT
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
NSF retains ownership of the property it funds, such as equipment (personal property) or
real property, as specified in the terms and conditions of the award which will vary by award
instrument type. Under financial assistance, title resides with the Awardee unless otherwise
stated in the award terms and conditions since one purpose of such awards is to “transfer a
thing of value to the non-federal entity.” In some limited cases, NSF will retain title to the
property (i.e., keep as federally owned property) based on operational considerations and
other award or program-specific circumstances. These determinations are made at the time
of the award or periodically during the award period of performance when the property is
acquired. At the end of the award, NSF may choose to invoke its conditional interest in NSFfunded property to take title or transfer it to another organization in support of the broader
science program. 1 Under FAR, the government retains title to all property until properly
disposed of, since the primary beneficiary of the activities under the award is the federal
government. These title and disposition determinations are necessary to protect the public’s
substantial investment in these unique research facilities.
Given the extent and value of these investments, it is incumbent on the Awardee to
understand their responsibility under the award and maintain a sufficient property
management system and supporting policies and procedures.
The Awardee’s policies and procedures governing the management of federally funded
property should include:
•
Acquisition and procurement processes.
•
Financial records retention processes (physical and electronic) necessary for property
audits or award close-out.
•
Inventory management processes, including custody, marking and identification,
location, use, and disposition.
•
Routine and preventative maintenance processes, as appropriate.
•
Security and protection processes (during use, storage, or transit), as appropriate.
1 PAPPG,
Part II, Chapter IX.E. and 2 CFR 200.313
Document Number
322
5.6 NSF Budget Categories from the Proposal and Award Policies and Procedures Guide
5.6
Research Infrastructure Guide
NSF BUDGET CATEGORIES FROM THE PROPOSAL AND AWARD
POLICIES AND PROCEDURES GUIDE
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
This section discusses types of detailed additional information typically needed by financial
assistance Awardees to justify the estimates based on the required NSF Budget Categories.
This information is intended to supplement the standard guidance for the NSF Budget
Categories from the PAPPG (see Section 1.3.1.1 Financial Assistance Awards – Grants and
Cooperative Agreements). 1 It is intended to clarify NSF requirements, assist Awardees,
facilitate NSF review with fewer iterative resubmissions, and prevent recurrent issues.
All Personally Identifiable Information should be removed from the documentation.
Awardees may contact their PO, Awarding Official (AO), Research Infrastructure Office (RIO)
Liaison, and/or Cost Analyst for a Master Labor Schedule template spreadsheet that can be
used to compile all labor data to ease estimating and justifying labor costs.
A – Senior Personnel
•
Awardees should verify the actual salaries paid for any named senior personnel.
Salary rates should be based on actual costs per current rate paid by payroll register,
W-2s, or appointment letters. Awardees should note Academic Year (nine to ten
months) versus Calendar Year (12 months) appointments or time available to conduct
independent research if such appointments provide it. The Awardee should also
provide sufficient justification for NSF to determine the cost reasonableness for the
salary rate paid, such as salary rate surveys, salary comparators, Human Resource
Department analysis, or other information.
B.1 – Postdoctoral Scholars; B.3–Graduate Students; B.4–Undergraduate Students; B.5–
Secretarial – Clerical
•
Awardees should provide an average salary rate or rate range for postdoctoral
students in the organization's field of science. Actual payroll data may not be available
as these may be to-be-hired positions.
B.2 – Other Professionals, Technicians, Programmers, Etc.
1
•
Since the NSF budget format poses this as a total number of individuals for a total
number of months, additional explanation is generally required to disaggregate the
total for cost analysis. The Level-of-Effort (LOE) will likely need to be obtained by an
individual or by position for salary calculations. Awardees should also provide a
spreadsheet with the budget justification that includes name or position number,
location, Work Breakdown Structure, title, salary rate and period, level of effort as a
percentage or in person-months, and amount calculation for each award year.
•
Awardees
should
provide
supporting
documentation
for
justification
and
PAPPG, Part I, chapter II.D.2.
Document Number
323
5.6 NSF Budget Categories from the Proposal and Award Policies and Procedures Guide
Research Infrastructure Guide
determination of the salary rates of the proposed technicians, programmers, and
other professionals. For these types of positions, NSF recommends using Bureau of
Labor Statistics (BLS) Standard Occupation Classification Codes by position title and
referencing their positions to BLS salary rates to gather information of proposed
salary rates. BLS data is also available by region or city. Other salary rate survey data
may be used, and larger Awardee organizations may already have established salary
ranges and qualification bases internally through their Human Resources
Departments.
C – Fringe Benefits
•
Fringe benefits proposed shall follow the Awardee’s established written policies, law,
or organization-employee agreements in accordance 2 CFR 200.431.
F – Participant Support
•
Justification should include the number of participants, stipend amount, travel cost
estimate, and subsistence costs per participant. 1 Awardees should also provide the
number of days or weeks of the training activities to provide a basis for determining
the proposed payments.
•
Participant support costs may not be used for personnel at the Awardee institution.
Other Direct Costs
Note: All contracts for procurements or services necessary to carry out the work must be
categorized under the appropriate budget activity: G.1 – Materials and Supplies, G.2 –
Publication, Documentation, Dissemination, G.3 – Consultant Services, G.4 – Computer
Services, or, if none of these apply, G.6 – Other. All contracts must follow 2 CFR § 200.317326, including price and cost analysis, competition, contracting with women-owned, small,
and minority businesses, and contract provisions. The micro-purchase threshold for supplies
or services is $10,000 (based on the micro-purchase threshold as amended by Sec. 207 of
Pub. L. 114–329, codified at 41 U.S.C. § 1902 note). Contracts must not be listed in G.5 Subawards.
To assist Awardees in determining the difference between a subaward and a contract, please
refer to the Subawardee vs. Contractor Checklist developed by the Association of
Government Accountants. 2
G.3 – Consultant Services
•
For each consultant identified, the Awardee should justify the proposed pay rate.
G.4 – Computer Services
•
1
2
Where it is established institutional policy to charge computer services directly, the
Awardee may justify and include such costs in the budget. Generally, such re-charges
See 2 CFR 200.1
https://www.agacgfm.org/Resources/intergov/SubrecipientvsContractor.aspx
Document Number
324
5.6 NSF Budget Categories from the Proposal and Award Policies and Procedures Guide
Research Infrastructure Guide
should be based on established internal institution usage rates. Awardees should
provide a supporting institutional statement or policy document and rates by units of
actual usage.
G.5 – Subawards 1
•
Awardees of cooperative agreements are expected to conduct a pre-award risk
review of the subawards, including cost and price analysis, to identify risk as outlined
in the Uniform Guidance, 2 CFR § 200.331.
•
Awardees should provide NSF with their pre-award analysis of each of the proposed
subawards when submitting for approval of each subaward. Such Awardee preaward analysis should include a determination of subaward risk. This should include
an assessment of financial capability and ensuring the Subawardee is not on any
federal government do not pay listing. The Awardee should also have carried out a
price or cost analysis of the Subawardee’s proposed work to ensure the
reasonableness of costs.
G.6 – Other
•
When applicable, budget contingencies should be presented as part of the total
amount of Other Direct Costs under category G.6 on the standard NSF budget form.
I – Indirect Costs
•
When the Awardee has a Negotiated Indirect Cost Rate Agreement (NICRA)
established with a cognizant federal agency, the rate and base in that agreement
should be used to compute indirect costs. A copy of the NICRA should be included in
the Cost Estimating Plan.
•
When an Awardee does not have a NICRA, the Awardee should provide a calculation
and an indirect cost rate proposal. The Awardee should ensure that indirect costs are
in accordance with the PAPPG, Chapter II.D.2.f.(viii), Indirect Costs. Awardees should
provide a clear description of rates and application bases. Awardees should also
provide a spreadsheet calculation of rates or rates by year clearly showing exclusions
such as subcontracts greater than $50,000, equipment or capital expenditures, and
participant support. If an Awardee has different indirect cost rates across NSF budget
categories, these rates should be clearly identified and justified. Any deviation from
an Awardee’s normal rate should also be justified.
K – Fee
•
Fee can be proposed if it is not disallowed by solicitation but is always subject to
negotiation. The amount of Fees will not exceed the statutory limitations of cost
contracts set forth at 41 U.S.C. 3905, notwithstanding that the Fee is provided through
1A
subaward is for the purpose of carrying out a portion of a federal award and creates a federal assistance
relationship with the subawardee. See 2 CFR § 200.92 Subaward. Characteristics which support the classification of
a subawardee versus contractor can be found at 2 CFR § 200.330. See also PAPPG II C.2.g (vi)(e).
Document Number
325
5.6 NSF Budget Categories from the Proposal and Award Policies and Procedures Guide
Research Infrastructure Guide
a Cooperative Agreement.
•
The payment of fee may be authorized for major facility construction and operations
awards, unless otherwise prohibited in specific circumstances by NSF. Fees will be
evaluated for reasonableness by the AO. Awardees that receive fee must comply with
the award terms and conditions on the use of fee, such as the inappropriate uses of
fee (e.g., including but not limited to not using fee on alcoholic beverages or lobbying
as set forth at 2 CFR § 200.450 and 48 CFR 31.205-22). NSF will reserve the authority
to review the Awardee’s actual use of fee. Accordingly, Awardees will be required to
separately track and account for uses of fee provided under NSF awards. NSF will
consider reductions in future fees if an Awardee’s actual use of fee is in contravention
with the guidelines on inappropriate uses.
Document Number
326
5.7 Personnel and Competencies
5.7
Research Infrastructure Guide
PERSONNEL AND COMPETENCIES
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Successful execution of construction projects and ongoing programs of the scale and
complexity typical of NSF’s Major Facilities requires skilled people who collectively possess a
broad range of professional competencies. The minimum set of competencies that NSF
considers essential for managing a Major Facility is detailed in Section 5.7.3 Competency
Assignment Guidance for Major Facility Management and addresses all the life cycle stages.
It is expected that fulfillment of these competencies will be achieved differently by each
managing organization. Mid-scale RI Awardees should consider this guidance and form their
Project Teams based on the complexity and technical nature of the project or program.
From NSF’s perspective, there are two categories of personnel that are involved with
managing a Major Facility throughout its life cycle. One category is Key Personnel (KP) and
the second is the Project Team as given in Section 5.7.1 Key Personnel and 5.7.2 Project Team
below, respectively. The objective is that some combination of individuals identified as either
KP or Project Team members possess the full breadth of necessary knowledge, skills, and
experience to manage the Major Facility. How this is achieved is up to the Awardee but is
subject to NSF review.
5.7.1
Key Personnel
KP are individuals from the managing organization who are considered essential to
successful project or science support program execution and are named specifically in the
original proposal and, ultimately, in the award terms and conditions. 1 For Major Facility and
Mid-scale RI awards funded through financial assistance, NSF requires identification of a
Principal Investigator (PI) or Project Director (PD). Major Facilities may have both and they
will automatically be considered KP. In addition to the PI and PD roles, KP positions
appropriate for a Major Facility project may include a Project Manager (PM), Deputy PD,
Associate Directors, or similar senior staff members.
Other than the PI and PD, it is the managing organization’s responsibility to propose any
additional KP. For example, in addition to the positions mentioned above, acquisitions and
contract management may be deemed so crucial for success that the organization assigns a
dedicated Procurement Officer and includes this position as KP. The competencies fulfilled
by KP should be identified and maintained over time, as detailed in Section 5.7.3 Competency
Assignment Guidance for Major Facility Management.
Under both the Uniform Guidance and FAR, NSF has approval authority over KP that are
identified and named in the original proposal and any subsequent changes to KP named in
the award terms and conditions. 2 Following award, any proposed substitutions, or
1 Major Facilities use the term Key Personnel as opposed to Senior Personnel on other NSF awards to maintain
consistency with terminology used in Major Facility award documents.
2 The ability to approve other Key Personnel is based on specific requirements detailed in the governing NSF award
documents.
Document Number
327
5.7 Personnel and Competencies
Research Infrastructure Guide
replacements, to KP must be submitted in advance, with all necessary supporting
documentation to assess competencies, to the cognizant PO for review and approval. No
changes may be implemented without prior formal written notification by an NSF AO.
If NSF deems certain personnel who were not listed as KP in the proposal to be nonetheless
essential to the Science Support Program, then NSF may require that these individuals be
listed as KP in the award instrument (e.g., cooperative agreement). Similarly, if restructuring
of the facility’s management chain is recommended (e.g., by NSF or by an external review) or
proposed by the Awardee during the period of performance, then the list of KP should be
updated accordingly in the Award instrument.
The following descriptions include general responsibilities of these roles in executing a Major
Facility or Mid-scale RI implementation project or program:
•
Principal Investigator. Under financial assistance, this position is responsible for the
scientific, technical, and budgetary aspects of the award and is generally the
individual responsible for submitting the proposal to NSF. The PI is ultimately
responsible for all aspects of successfully executing the project and/or Science
Support Program, including ensuring that it meets its scientific and technical
objectives and interfacing with NSF and the broader science community. For the
purposes of this Guide, PI/co-PI is interchangeable with PD/co-PD if not proposed as
separate positions.
•
Project Director (may also be the PI). The PD is typically responsible for the day-today management of the activities funded under the award, generally reports to the
PI (if proposed as a separate position) and may be named as a co-PI. This position
may transition from Design to Construction, or from Construction to the Operations
Stage to help ensure continuity once the prior Stage is complete.
•
Project Manager or Operations Manager. This position is responsible for managing
the proposed projects design activities or project’s construction activities on a day-today basis. For construction projects, this would include major deliverables, the
project’s schedule, budget, and earned value metrics to monitor project progress
against the current plan. The PM is essential in the Construction Stage of a Major
Facility project, but is optional in the Development, Design, Operations, and
Disposition Stages, depending on the planned activities. The PM may also serve in
other capacities, such as deputy PD. For facilities in the Operations Stage, the
Operations Manager could be considered an analogous position to PM. PMs can also
be hired for upgrade projects that take place during the Operations Stage. NSF would
have approval authority if this position were identified as KP or otherwise required in
the award terms and conditions.
5.7.2
Project Team
The Project Team comprises additional managing organization staff who are often spread
across different organizational units. The Project Team may comprise any combination of
individuals or organizational units, such as an Office of Sponsored Research or the
Document Number
328
5.7 Personnel and Competencies
Research Infrastructure Guide
institution’s IT support office. NSF approval of Project Team members is not required, but
the Program should be notified when significant changes occur that might influence the
activities funded under the award.
Project Team members should be identified in the proposal, Design Execution Plan (DEP),
Project Execution Plan (PEP), or Annual Work Plan (AWP) where the Awardee discusses the
organizational structure and fulfillment of the necessary competencies.
This documentation allows NSF, via proposal and annual reviews, to assess whether
competencies are adequately covered by the KP and Project Team.
5.7.3
Competency Guidance for Major Facility Management
The knowledge areas listed in Table 5.7.3-1 are considered necessary for effective project
and program management of a Major Facility and are based on the project and program
management standards developed as part of the Program Management Improvement
Accountability Act (PMIAA), Public Law No. 114-264. While PMIAA is only applicable to federal
staff, the competency requirements nonetheless apply to most Major Facilities. Under NSF
Major Facility awards, the Awardee typically performs many of the management roles
normally done by federal project/program managers at other agencies. As given in Section
2.1 NSF Staff Roles and Responsibilities for Award Management and Oversight, NSF’s role is
to oversee activities performed by the Awardee, including the proper use of federal funds.
Table 5.7.3-1
PMIAA Areas of Program Management Standards and Principles
Knowledge Areas
Change Management
Performance Management
Communications Planning, Stakeholder Engagement,
and Coalition Building
Portfolio Management
Contracting and Acquisition Management
Process Improvement
Customer Service
Project Management
Evaluation
Requirements Development and Management
Financial Management
Risk Management
Human Capital Management
Strategic Planning
Information Management
The competencies listed in Table 5.7.3-2 are derived from these knowledge areas and are
tailored to reflect the characteristics of NSF Major Facility projects.
While there is no one-for-one mapping between these knowledge areas and the
competencies in Table 5.7.3-2, there is a close alignment to align with federal standards
under PMIAA and increase the likelihood of successfully executing the project or Science
Support Program.
It is the responsibility of the managing organization to identify the KP and Project Team that
collectively fulfill the suite of competencies listed in Table 5.7.3-2. All competencies must
Document Number
329
5.7 Personnel and Competencies
Research Infrastructure Guide
have at least one resource assigned; however, the same resource may be assigned to fulfill
more than one competency. Some competencies are required to be assigned to KP as
indicated in the Assigned Resource columns in Table 5.7.3-2. Fulfillment of other
competencies may be provided by Project Team.
It is important to note that not all competencies are necessary for each stage of the Major
Facility life cycle. In some life cycle stages, there is no requirement for one or more
competencies to be fulfilled, and the competency requirement is designated in Table 5.7.3-2
as Optional. The managing organization should make the decision of whether a particular
competency is considered essential based on the nature of the proposed activities under the
award. For example, if an operations award includes a major upgrade, Project Management,
and Earned Value Management (EVM) competencies may be beneficial if the project has a
significant budget or a long duration or would otherwise benefit from the implementation
of project management good practices.
The managing organization should submit documentation (e.g., resume) substantiating the
assigned resource’s expertise and qualifications for each assigned competency based on the
funding announcement, as part of a periodic NSF review, or proposing a change in KP or
Project Team members in accordance with the terms and conditions of the award. As stated
above, NSF approval is only required for KP. While NSF does not approve Project Team
members, substantiating documentation relating to competencies may still be requested
when changes to the Project Team are made. This method allows NSF to confirm that
competencies are adequately covered even though NSF does not have
approval/concurrence authority over the individuals.
If a competency is assigned to an individual KP or Project Team member, then the
substantiating documentation should include a resume, certification, or similar document(s)
describing the individual’s expertise and qualifications relating to the assigned competency.
If a competency is assigned to the Project Team via an organizational unit, the applicable
training or certification requirements for individuals to work within that organization may be
provided rather than those of the individuals themselves. This method allows NSF to confirm
that the competency is addressed by the organizational unit even though NSF does not have
approval/concurrence authority over individuals within the unit. Likewise, if an external
contractor provides a specific competency as an individual, the qualifications should be
specific to that individual, whereas if the contractor is fulfilling the competency as an
organizational unit type, the applicable training or certification requirements required for
the individuals within the organization may be provided.
Document Number
330
5.7 Personnel and Competencies
Research Infrastructure Guide
Table 5.7.3-2
Competency Assignment Guidance for Major Facility Management
Competency Assignment Guidance
Assigned Resource per Life Cycle Stage
Competency
Development
Design
Construction
Operations
Disposition
Project Management
Optional
KP
KP
Optional
Optional
Program Management
Optional
Optional
Optional
KP
Optional
Earned Value
Management
Optional
Optional
KP or Project Team Optional
Optional
Optional
Optional
KP or Project Team KP or Project
Team
Optional
Optional
KP or Project
Team
KP or Project Team KP or Project
Team
Optional
Optional
Optional
Optional
Optional
KP or Project
Team
KP or Project
Team
KP or Project Team KP or Project
Team
KP or Project
Team
Optional
KP or Project
Team
KP or Project Team KP or Project
Team
Optional
Optional
KP or Project
Team
KP or Project Team KP or Project
Team
Optional
Optional
Optional
KP or Project Team KP or Project
Team
Optional
Optional
KP or Project
Team
KP or Project Team KP or Project
Team
Optional
Optional
Optional
KP or Project Team KP or Project
Team
Optional
Optional
KP or Project
Team
KP or Project Team KP or Project
Team
Optional
Risk Management
Cost Estimating
Business Process
Reengineering
Compliance
Contracting and
Acquisition
Financial Management
Data Management
Information Technology
Workforce Management
Stakeholder Management
KP or Project
Team
A general description for each of the listed competencies in Table 5.7.3-2 is provided in Table
5.7.3-3. These descriptions are intended to be general and reasonably in alignment with the
guidance established in PMIAA and are not considered a fully authoritative set of definitions.
Document Number
331
5.7 Personnel and Competencies
Research Infrastructure Guide
Table 5.7.3-3
Competency Descriptions
Competency Descriptions
Competency
Description
Project
Management
Demonstrates general and specialized knowledge of the principles, methods, and tools for
project management, with project defined as a temporary endeavor with a defined
scope, cost, and completion date. A project may be part of a larger program or portfolio.
Demonstrates knowledge of the strategies, techniques, and processes used to plan,
monitor, and control project scope, including collecting requirements, defining scope,
creating a work breakdown structure, validating scope, and controlling scope to ensure
project deliverables meet requirements.
Demonstrates knowledge of the strategies, techniques, and processes used to plan,
develop, and control project schedules and track project milestones, activities, and
deliverables, including timeframes and assigned resources.
Demonstrates knowledge of the principles and methods for identifying, soliciting, analyzing,
specifying, designing, and managing requirements and is able to systematically assess
how well a project is working to achieve its intended outcomes.
Skilled in the use of project management controls to analyze project budget and schedule
information and to generate reports with the primary focus of answering two
fundamental questions:
How much will the project cost at completion, and will the project finish within budget?
How long will the project take, and will it finish as scheduled?
Knowledge of the principles, methods, and tools of Quality Assurance, Quality Control, and
reliability to ensure that a project, system, or product fulfills requirements and standards.
Skilled at recording and controlling changes to the performance baseline (scope, schedule,
and budget).
Able to identify and align project needs to the science mission and goals.
Skilled in satisfying internal and external customers through successful project execution;
able to communicate and report progress to the PO.
Program
Management
Demonstrates knowledge of the principles, methods, and tools for the coordinated
management of a program, including oversight of a set of programs, projects, contracts,
and other work that supports scientific goals.
Able to provide oversight of multiple projects, integrate dependent schedules and
deliverables, and conduct related activities, for example, benefits management, life
cycle management, and program governance.
Able to plan for and manage capital assets and develop budgets, cost/benefit analyses, and
investment decision documentation to evaluate and justify program costs.
Demonstrates knowledge of the strategies, techniques, and processes used to plan,
monitor, and control the level of scientific support; includes collecting requirements,
defining scope, creating a Work Breakdown Structure, validating scope, and controlling
scope to ensure program deliverables meet requirements.
Demonstrates knowledge of the strategies, techniques, and processes used to plan,
develop, and control program schedules and track major sub-project milestones,
activities, and deliverables, including timeframes and assigned resources.
Skilled in implementing Continuous Process Improvement initiatives to leverage
organizational strategy and performance management data to identify and eliminate
waste, reduce variation, and satisfy customer needs.
Skilled in long-term planning, implementing actions needed to realize scientific goals, and
mitigating likely challenges and barriers to achieving the desired outcomes.
Demonstrates knowledge of the principles and methods for identifying, soliciting, analyzing,
specifying, designing, and managing requirements and is able to systematically assess
how well a program is working to achieve intended outcomes.
Knowledge of the principles, methods, and tools of Quality Assurance/Quality Control, and
reliability to ensure that a project, system, or product fulfills requirements and standards.
Able to identify and align program needs to the science mission and goals.
Document Number
332
5.7 Personnel and Competencies
Research Infrastructure Guide
Competency Descriptions
Competency
Description
Demonstrates knowledge of change management principles, strategies, and techniques for
effectively planning, implementing, and evaluating organizational change.
Skilled in satisfying internal and external customers through successful program execution;
able to communicate and report progress to the PO.
Demonstrates knowledge of the principles and methods for evaluating program or
organizational performance using financial and nonfinancial measures, including
identification of evaluation factors such as workload and personnel requirements,
metrics, and outcomes, addressing both the science and operations.
Earned Value
Management
Demonstrates knowledge of the Electronic Industries Alliance-748 on Earned Value
Management Systems and how to use it as an integrated management tool for
successful project planning and execution.
Able to apply the 32 guidelines described in Electronic Industries Alliance-748 when
developing and implementing the project Earned Value Management System.
Skilled at scaling the guidelines based on the size, complexity, and type of work effort
needed to manage the project successfully.
Risk
Management
Demonstrates knowledge of principles, methods, and tools for risk management.
Skilled in identifying, evaluating, mitigating, managing, and overseeing risks and
opportunities within a project or program.
Able to remedy potential issues and implement improvements to reduce risk, including
through the development of Risk Mitigation Plans.
Cost Estimating
Demonstrates knowledge of the principles and methods of cost estimating, including the
best practices (twelve steps) identified in the Government Accountability Office Cost
Estimating and Assessment Guide.
Able to develop a Cost Estimating Plan and Cost Book that reflects NSF and Government
Accountability Office guidance.
Business Process
Reengineering
Demonstrates knowledge of methods, metrics, tools, and techniques for restructuring and
improving business processes.
Compliance
Skilled in ensuring the award is managed in compliance with applicable federal laws,
regulations, and guidance.
Contracting and
Acquisition
Demonstrates knowledge of the process and procedures for soliciting, executing, monitoring,
and closing contracts and other award instruments in compliance with Awardee
organization procurement policies.
Financial
Management
Demonstrates knowledge of procedures for assessing, evaluating, and monitoring programs
or projects for compliance with federal laws, regulations, and guidance, including Office
of Management and Budget Uniform Guidance (2 CFR § 200), relating to financial
management.
Able to prepare, justify, and/or administer the budget for project or program areas.
Able to plan, administer, and monitor expenditures to ensure cost-effective support of
programs and policies, e.g., through financial controls and audits.
Skilled in assessing the financial condition of a project or program.
Data
Management
Demonstrates knowledge of data management principles, procedures, and tools, such as
modeling techniques, data backup/recovery, data mining, and data standardization
processes.
Able to plan/budget for, manipulate, and control access to information/scientific data during
the project or program’s life cycle.
Information
Technology
Able to manage cyberinfrastructure and information technology resources, such as
personnel, equipment, software, etc., that support the project or program.
Demonstrates knowledge of the four pillars of information assurance programs (Mission
Alignment, Governance, Resources, and Controls) and how to develop and manage a
robust information assurance program.
Document Number
333
5.7 Personnel and Competencies
Research Infrastructure Guide
Competency Descriptions
Competency
Description
Workforce
Management
Able to manage workforce requirements to meet organizational and program goals within
budget constraints and to ensure employees are appropriately recruited, selected,
appraised, and rewarded.
Stakeholder
Management
Demonstrates knowledge of the concepts, practices, and techniques used to identify,
engage, influence, and monitor relationships with stakeholders; able to collaborate
across organizational boundaries and engage in partnerships and team building.
Document Number
334
5.8 Partnerships
5.8
Research Infrastructure Guide
PARTNERSHIPS
Revision Date: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
For both Major Facility and Mid-scale RI, partnerships are an essential consideration –
beginning with initial development and extending through disposition decisions.
Partnerships can take many forms, but often include coordinated funding from states, other
federal agencies, non-governmental entities, and foreign funding agencies. 1 International
partnerships are generally the most complex given geopolitical considerations and
differences in lexicons, funding mechanisms, and project management practices.
Regardless of the nature of the partnership, care should be taken to ensure that all parties
have a common understanding of priorities, roles and responsibilities, and schedules. In
most cases, this understanding should be formalized in writing and agreed to by personnel
with authority to commit the partner(s) to the specified arrangement. It is also wise to notify
the cognizant PO of plans to enter into partnership arrangements.
International partnerships present several important challenges to which the Awardee and
PO need to give timely and careful attention. Cultural differences in approaches to the
emergence of science and engineering projects, project management approaches, risk
management, and project oversight should be considered and addressed. Thus, NSF should
be notified of the partnership to facilitate governance and other agreements prior to NSF
making an award. Partnerships being considered post-award also require NSF notification.
Prior to entering formal arrangements with foreign collaborators, Awardees must provide
written notification to the cognizant PO according to the terms and conditions of the award.
Early notification allows the PO to coordinate with the appropriate NSF units, particularly
those associated with research security, to ensure that potential international partnerships
are compliant with U.S. law, NSF policy, and geo-political considerations.
1 See
“Best Practices for Federal Research and Development Facility Partnerships,” IDA Science & Technology Policy
Institute, IDA Paper P-5148 Log: H 14-000676, for guidance or models on forming interagency federal partnerships.
Document Number
335
5.9 Agile Guidance
5.9
Research Infrastructure Guide
AGILE GUIDANCE
Revision Date: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Agile is a project management approach that uses cycles of design, implementation,
evaluation, and process improvement to reduce risk and improve the quality of the produced
scope. It comes in many forms, including Scrum, Kanban, Extreme Programming, and Lean
Development, among others. Agile can apply to many different kinds of scope, and it is
commonly used for developing software.
While there is extensive industry guidance related to Agile management techniques, this
section contains NSF guidance specific to Agile methodologies. This section is designed to be
a starting point on how to integrate Agile into NSF projects and is not intended to provide
instruction on Agile methodologies.
This section explains how Agile systems can satisfy NSF requirements for project
management and identify any unique processes and documentation necessary to support
NSF review. Existing Government Accountability Office (GAO), Project Management Body of
Knowledge (PMBOK), and National Defense Industrial Association (NDIA) Agile guides can
provide general Agile guidance. 1, 2,3
1 The
Project Management Book of Knowledge (PMBOK 7th edition)/Agile Practice Guide (2021) Project
Management Institute (PMI). https://www.pmi.org/pmbok-guide-standards/practice-guides/agile The agile practice
guide is often included with the PMBOK 7th edition. Fees or membership in PMI are required to access these
documents.
2 The GAO Assessment Guide: Best Practices for Agile Adoption and Implementation (GAO-20-590G) may be used
as a general guide to Agile implementation on Major Facility or Mid-scale RI awards but should be modified and
tailored to the needs and requirements of the NSF. https://www.gao.gov/products/gao-20-590g
3 An Industry Practice Guide for Integrating Agile and Earn Value Management on Programs, NDIA December 9,
2022 Version 1.4 https://www.ndia.org/-/media/sites/ndia/divisions/ipmd/division-guides-andresources/2023/ndia_ipmd_agileandevmguide_version_1-4.pdf?download=1
Document Number
336
5.9 Agile Guidance
Research Infrastructure Guide
Figure 5.9-1
Agile Development Methods Versus Traditional Development Methods: Emphasized Elements; Graphic adapted from
GAO Agile Assessment Guide Figure 5 (GAO-20-590G)
Figure 5.9-1, which has been modified from one found in the GAO Agile Guide, identifies the
differences between Traditional and Agile Development. Traditional Development is plandriven where cost and/or schedule are more likely to be adjusted to support scope. Agile
Development tends to be value driven where scope may encounter adjustments to support
a more fixed development team (cost) and schedule. NSF awards, like other government
procurements, have disciplined methods which limit scope (and other driver) flexibility and
often require additional documentation and reporting (see Section 2.1 NSF Staff Roles and
Responsibilities for Award Management and Oversight). NSF does not allow unconstrained
flexibility in scope (i.e., baseline scope changes without executed change order or other
methods documented in the award PEP).
The general project management guidance in this Guide applies to all projects with an Agile
component. Traditional methodologies that are important in an Agile environment may
include but are not limited to the following:
•
The life cycle stage of the project.
•
The need for a well-defined and comprehensive Work Breakdown Structure (WBS).
•
Having all scope assigned to the appropriate accountable individual (Control Account
Manager [CAM]).
•
Appropriate use of a project schedule.
•
Appropriate use of a Change Control Plan for significant scope, schedule, and budget
changes.
•
Appropriate use of risk management scope, schedule, and budget contingency.
Document Number
337
5.9 Agile Guidance
5.9.1
Research Infrastructure Guide
General Agile Guidance
NSF supports projects that use Agile methodologies via a hybrid approach that combines
traditional project management methods with Agile methods. NSF expects the use of a
hybrid WBS when utilizing the Agile methodology. This hybrid method unifies two different
methodologies via the award’s WBS. Traditional project management methods are required
at WBS Levels 1 and 2. An Awardee may elect to extend traditional methods to lower levels
of the WBS, but Levels 1 and 2 are considered essential. Figure 5.9.1-1 shows the WBS that
uses a traditional methodology for WBS Levels 1 and 2 and the Agile methodology below.
Note that some WBS legs utilize only traditional methodology, and Agile is confined only to
the blue leg.
Figure 5.9.1-1
Traditional / Agile Hybrid Project Example WBS
Document Number
338
5.9 Agile Guidance
5.9.2
Research Infrastructure Guide
Agile Documentation
If Agile methodology is utilized, the following needs to be documented in the PEP:
•
A WBS that clearly illustrates the traditional elements and those that are using Agile.
•
An expanded WBS Dictionary with Identifying and mapping linkages between
traditional and Agile terminology. The WBS Dictionary should define all significant
Agile terminologies the Awardee elects to use.
•
Identified type of Agile methodologies used; any are allowable if documented in the
PEP.
•
Identified reporting methods, levels of rigor, and frequency for Agile components.
•
Traditional-Agile Data Flows:
5.9.3
o
Planning. Include a flow chart that shows how the Performance Measurement
Baseline (PMB) refines itself downward from higher traditional WBS levels to
detailed Agile planning (From WBS Level 1 to the most detailed Agile level).
o
Executing. Illustrate how Agile performance data flows upward from the
lowest Agile level to the traditional WBS levels and reports. Agile practitioners
are free to utilize common and acceptable Agile methodologies and
definitions. Methodologies and definitions are not restricted to a single set or
those used in Research Infrastructure Guide examples. However, the above
terminologies and processes used should be documented in the PEP.
Specific Agile Guidance
Traditional waterfall methodology guidance is included throughout this Guide and are not
repeated in this section. The following are specific Agile guidance:
•
The initial budgetary and schedule estimation should include at least a planning
package level for the Agile scope for the entire performance period.
•
Agile utilizes rolling wave planning which involves detailed planning (work package or
equivalent) for near-term efforts and more summary-level planning (planning
packages or equivalent) for subsequent attempts. Planning packages should include
enough detail to provide a credible estimate of schedule and cost.
•
Agile PMB budget/schedule estimates may be calculated via Agile sizing techniques.
The detailed PMB should include performance measurement milestones at the
appropriate detail level for Agile near-term scope. For example, budgeted Stories may
be assessed periodically, giving credit for completion, and summarizing cumulative
performance (percent complete).
•
WBS elements that are identified as Agile may utilize non-Agile methods for support
effort. For example, quality management, program management, and other noncoding (non-development) support activities may be utilized as an LOE within an Agile
WBS element.
•
Agile scope progress should be calculated at the lowest level of the WBS on a
Document Number
339
5.9 Agile Guidance
Research Infrastructure Guide
percentage basis using a chosen metric.
•
Rolled-up expenditures (i.e., actual costs) should be reported and measured against
assigned budgets, which may be executed at the work package level or the Agile
equivalent.
•
A forecast of detailed Agile budgets and actual costs may exceed (or be forecasted to
exceed) the overall work package (may be called Epic) budget. In this case, the
Awardee either realizes an over-run or moves scope, schedule, and budget via the
award’s change management system (same process as with other project
management methods).
•
Agile should utilize the Change Management Plan for scope, schedule, and budget
changes and as well as identify any changes handled within the Agile process Defined
in the PEP what changes use change management and what changes are handled
within detailed agile processes. Appropriate change management thresholds should
be defined in the PEP.
Document Number
340
6.0 References
6.0
Research Infrastructure Guide
REFERENCES
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
6.1
CHAPTER 1 | INTRODUCTION
American Innovation and Competitiveness Act, Pub. L. No. 114-329, 130 Stat. 2969 (2017).
https://www.congress.gov/114/statute/STATUTE-130/STATUTE-130-Pg2969.pdf
Consolidated Appropriations Act, 2024, Pub. L. No. 118-42, 137 Stat. 137 (2024).
https://www.congress.gov/118/plaws/publ42/PLAW-118publ42.pdf
Executive Office of the President. (2023). Buy America implementation guidance update (OMB
Memorandum M-24-02). https://www.whitehouse.gov/wp-content/uploads/2023/10/M24-02-Buy-America-Implementation-Guidance-Update.pdf
Executive Office of the President. (2024). Capital Programming Guide (Supplement to
Circular A-11). https://www.whitehouse.gov/wpcontent/uploads/2021/01/capital_programming_guide.pdf
Federal Acquisition Regulatory Council. (2024). Federal Acquisition Regulation (FAR). U.S.
General Services Administration.
https://www.acquisition.gov/sites/default/files/current/far/pdf/FAR.pdf
Federal Grant and Cooperative Agreement Act, Pub. L. No. 95-224, 92 Stat. 3 (1978).
https://www.govinfo.gov/app/details/STATUTE-92/STATUTE-92-Pg3/context
Further Consolidated Appropriations Act, 2024, Pub. L. No. 118-47, Stat 2882 (2024).
https://www.congress.gov/bill/118th-congress/house-bill/2882/text
National Science Board. (2015). Resolution on recompetition of ongoing facilities (NSB-201546).
https://www.nsf.gov/nsb/publications/2015/NSBResolutionRecompetitionFacilities_201511-19.pdf
National Science Board. (2015). Statement on recompetition of major facilities (NSB-2015-45).
https://www.nsf.gov/nsb/publications/2015/NSBStatementRecompetitionFacilities_201511-19.pdf
National Science Foundation Act, 42 U.S.C. § 1870 (2011). General authority of Foundation.
https://www.govinfo.gov/app/details/USCODE-2011-title42/USCODE-2011-title42chap16-sec1870
National Science Foundation. (1950). National Science Foundation Act of 1950 (Organic Act,
Public Law 81-507). https://www.nsf.gov/about/history/legislation.pdf
National Science Foundation. (2021). Business systems review (BSR) guide (NSF 22-102).
https://www.nsf.gov/pubs/2022/nsf22102/nsf22102.pdf
National Science Foundation. (2024, May 20). NSF proposal & award policies and procedures
Document Number
341
6.0 References
Research Infrastructure Guide
Guide (PAPPG) (NSF 24-1). https://nsf-gov-resources.nsf.gov/files/nsf24_1.pdf
National Defense Authorization Act for Fiscal Year 2021, Pub. L. No. 116-283, § 267 (2021).
https://www.congress.gov/116/plaws/publ283/PLAW-116publ283.pdf
Office of Management and Budget. (2024). Uniform administrative requirements, cost
principles, and audit requirements for federal awards (2 CFR Part 200).
https://www.ecfr.gov/current/title-2/subtitle-A/chapter-II/part-200
Research.gov. (2024). Online grants management for the NSF community.
https://www.research.gov/research-web/
Research Infrastructure Outreach. (2024). Knowledge Gateway.
https://researchinfrastructureoutreach.com/knowledge-gateway/
U.S. Department of Labor. (2023, August 23). Davis-Bacon and related acts.
https://www.dol.gov/agencies/whd/government-contracts/construction
U.S. Government Accountability Office. (2008). Fiscal year (FY) 2009 budget request to
Congress (GAO-08-707T). https://www.gao.gov/products/gao-08-707t
U.S. Government Accountability Office. (2016). Schedule assessment guide (GAO-16-89G).
https://www.gao.gov/products/gao-16-89g
U.S. Government Accountability Office. (2019). National Science Foundation: Cost and
schedule performance of large facilities construction projects and opportunities to
Improve project management (GAO-19-227).
https://www.gao.gov/assets/700/698925.pdf
6.2
CHAPTER 2 | NSF LIFE CYCLE OVERSIGHT
National Science Board. (2005). Setting priorities for large facility projects supported by the
National Science Foundation (NSB-05-77).
https://www.nsf.gov/pubs/2005/nsb0577/index.jsp
U.S. Government Accountability Office. (2020). Cost estimating and assessment guide: Best
practices for developing and managing program costs (GAO-20-195G).
https://www.gao.gov/products/gao-20-195g
6.3
CHAPTER 3 | RESEARCH INFRASTRUCTURE LIFE CYCLE
PLANNING
ASTM International. (2020). Standard classification for building elements and related siteworkUNIFORMAT II (ASTM E1557-09(2020)e1). https://www.astm.org/e1557-09r20e01.html
National Science Foundation. (2019, July). NSF major facilities – Earned value management
gold card. https://www.nsf.gov/bfa/rio/evm-gold-card
National Science Foundation. (2023). Merit review process: FY 2021 merit review digest.
https://www.nsf.gov/nsb/publications/2022/merit_review/FY_2021_Merit_Review_Digest.
pdf
Document Number
342
6.0 References
Research Infrastructure Guide
National Science Foundation. (2024). Cost accounting and financial accountability terms
and conditions: Modifications and supplements for major facilities and FFRDCs (May
2024).
https://www.nsf.gov/bfa/dias/policy/cafatc/cafatc_modsandsup_mfandffrdc0524.pdf
National Science Foundation. (2024). NSF branding portal.
https://mediahub.nsf.gov/portals/dnmqqhzz/NSFBrandingPortal
National Science Foundation. (2024). Preparing your proposal budget.
https://new.nsf.gov/funding/proposal-budget
Occupational Safety and Health Administration. (2016). Recommended practices for safety
and health programs in construction (OSHA 3886). U.S. Department of Labor.
https://www.osha.gov/sites/default/files/publications/OSHA3886.pdf
Office of Management and Budget. (2021). Revocation of OMB memorandum M-21-01,
“Budget and management guidance on updates to the regulations implementing the
procedural provisions of the National Environmental Policy Act” (M-21-23).
https://www.whitehouse.gov/wp-content/uploads/2021/04/M-21-23.pdf
U.S. Government Accountability Office. (2023). Agile assessment guide: Best practices for Agile
adoption and implementation (GAO-20-590G). https://www.gao.gov/assets/gao-20590g.pdf
U.S. Government Publishing Office. (2023). Council on Environmental Quality regulations (40
C.F.R. Part 1500). https://www.govinfo.gov/content/pkg/CFR-2023-title40-vol37/pdf/CFR2023-title40-vol37-part1500.pdf
U.S. Government Publishing Office. (2023). 42 U.S.C. Chapter 55 – National Environmental
Policy. https://www.govinfo.gov/content/pkg/USCODE-2023-title42/pdf/USCODE-2023title42-chap55.pdf
6.4
CHAPTER 4 | FUNDAMENTAL ELEMENTS OF PROJECT
MANAGEMENT
AACE International. (2015). Skills and knowledge of cost engineering (6th ed.). AACE
International.
AACE International. (2019). 36R-08 Development of cost estimating plans – As applied in
engineering, procurement, and construction for the process industries.
AACE International. (2020). 18R-97 Cost estimate classification system – As applied in
engineering, procurement, and construction for the process industries.
AACE International. (2021). 34R-05 Basis of estimate.
Carter, J. (1979). Executive Order 12114—Environmental effects abroad of major Federal
actions. https://www.archives.gov/federal-register/codification/executiveorder/12114.html
National Defense Industrial Association. (2018). Earned Value Management Systems EIA-748-D
Document Number
343
6.0 References
Research Infrastructure Guide
Intent Guide. https://www.ndia.org/-/media/sites/ndia/divisions/ipmd/division-guidesand-resources/ndia_ipmd_intent_guide_ver_d_aug282018.pdf?download=1%20uide
National Defense Industrial Association. (2020). Earned Value Management System Guideline
Scalability Guide – Revision 2. https://www.ndia.org//media/sites/ndia/divisions/ipmd/division-guides-andresources/ndia_ipmd_evms_scalabilityguiderev2_jan292020.pdf?download=1 Template
National Defense Industrial Association. (2023). Earned Value Management System
Acceptance Guide – Revision 4. https://www.ndia.org//media/sites/ndia/divisions/ipmd/2023-files/ndia_ipmd_evms_acceptanceguide_rev_4_jan272023.pdf?download=1.org)
National Science Board. (2005). Priority setting for large facility projects (NSB-05-77).
https://www.nsf.gov/pubs/2005/nsb0577/nsb0577_2.pdf
National Science Board. (2010). Annual timeline for integration of the board MREFC process
with NSF budget process (NSB-10-66).
Program Management Improvement Accountability Act, Pub. L. No. 114-264, 130 Stat. 1372
(2016). https://www.govinfo.gov/app/details/PLAW-114publ264
Project Management Institute. (2021). A guide to the project management body of knowledge
(PMBOK® Guide) (7th ed.). Project Management Institute.
U.S. Department of Energy. (2018). Cost estimating guide (DOE G 413.3-21A).
https://www.directives.doe.gov/directives-documents/400-series/0413.3-EGuide21A/@@images/file
6.5
CHAPTER 5 | SUPPLEMENTAL GUIDANCE
Advisory Council on Historic Preservation. (1966). National Historic Preservation Act, as
amended. https://www.achp.gov/sites/default/files/2018-06/nhpa.pdf
Association of Government Accountants. (2016). Subrecipient vs. contractor checklist.
https://www.agacgfm.org/Resources/intergov/SubrecipientvsContractor.aspx
Center for Internet Security. (2024). The 18 CIS critical security controls.
https://www.cisecurity.org/controls/cis-controls-list
Committee of Sponsoring Organization of the Treadway Commission. (2023). COSO official
website. https://www.coso.org/
Cybersecurity and Infrastructure Security Agency. (n.d.). Cross-sector cybersecurity
performance goals. https://www.cisa.gov/cross-sector-cybersecurity-performance-goals
Cybersecurity and Infrastructure Security Agency. (n.d.). Implement number matching in
multi-factor authentication (MFA) applications fact sheet (508c).
https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-numbermatching-in-mfa-applications-508c.pdf
Document Number
344
6.0 References
Research Infrastructure Guide
Cybersecurity and Infrastructure Security Agency. (n.d.). Resources and tools: Services.
https://www.cisa.gov/resources-tools/services
Federal Bureau of Investigation. (n.d.). Cyber crime. https://www.fbi.gov/investigate/cyber
Global Indigenous Data Alliance. (n.d.). CARE principles for Indigenous data governance.
https://www.gida-global.org/care
International Organization for Standardization. (2022). ISO/IEC 27001:2022 – Information
security, cybersecurity and privacy protection – Information security management
systems - Requirements. https://www.iso.org/standard/27001
International Organization for Standardization. (2022). ISO/IEC 27002:2022 – Information
security, cybersecurity and privacy protection – Information security controls.
https://www.iso.org/standard/75652.html
Internet Crime Complaint Center. (n.d.). Ransomware.
https://www.ic3.gov/CrimeInfo/Ransomware
National Defense Industrial Association. (2022). An industry practice guide for integrating
Agile and earned value management on programs (Rev. 1.4).
National Institute of Standards and Technology. (n.d.). Cybersecurity framework.
https://www.nist.gov/cyberframework
National Science Foundation. (n.d.). Cooperative agreement conditions.
https://www.nsf.gov/awards/managing/co-op_conditions.jsp
National Science Foundation. (n.d.). Data management plan requirements.
https://new.nsf.gov/funding/data-management-plan
National Science Foundation. (n.d.). Research security. https://new.nsf.gov/research-security
Peña, V., Whelan, R.M., & Howieson, S.V. (2014). Best practices for federal research and
development facility partnerships (IDA Paper P-5148). https://www.ida.org//media/feature/publications/b/be/best-practices-for-federal-research-and-developmentfacility-partnerships/ida-p-5148.ashx
Office of Science and Technology Policy. (2022). Ensuring free, immediate, and equitable
access to federally funded research. https://www.whitehouse.gov/wpcontent/uploads/2022/08/08-2022-OSTP-Public-access-Memo.pdf
Trusted CI. (n.d.). Open science cyber risk profile (OSCRP). https://trustedci.github.io/OSCRP/
Trusted CI. (n.d.). Trusted CI framework. https://www.trustedci.org/framework
U.S. Bureau of Reclamation. (2022). FY 2022 federal real property profile addendum.
https://usbr.gov/assetmanagement/docs/FY2022FRPPAddendumFINAL.pdf
U.S. Department of the Treasury. (n.d.). Sanctions programs and country information. Office
of Foreign Assets Control. https://ofac.treasury.gov/sanctions-programs-and-countryinformation
Document Number
345
6.0 References
Research Infrastructure Guide
U.S. Fish and Wildlife Service. (2024). Endangered Species Act of 1973, as amended.
https://www.govinfo.gov/content/pkg/USCODE-2023-title16/pdf/USCODE-2023-title16chap35.pdf
U.S. Department of Energy. (n.d.). Cybersecurity capability maturity model (C2M2). Office of
Cybersecurity, Energy Security, and Emergency Response.
https://www.energy.gov/ceser/cybersecurity-capability-maturity-model-c2m2
The White House. (2022). Critical and emerging technologies list update.
https://whitehouse.gov/wp-content/uploads/2022/02/02-2022-Critical-and-EmergingTechnologies-List-Update.pdf
The White House. (2022). National Security Presidential Memorandum-33 (NSPM-33)
implementation guidance. https://www.whitehouse.gov/wpcontent/uploads/2022/01/010422-NSPM-33-Implementation-Guidance.pdf
Document Number
346
7.0 Acronyms and Abbreviations
7.0
Research Infrastructure Guide
ACRONYMS AND ABBREVIATIONS
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
Acronym or
Abbreviation
Full Spelling
AACEI
Association for the Advancement of Cost Engineering International
ACWP
Actual Cost of Work Performed
AICA
American Innovation and Competitiveness Act
AO
Awarding Official
AWP
Annual Work Plan
BABA
Build America, Buy America
BAC
Budget at Completion
BFA
Office of Budget, Finance, and Award Management
BLS
Bureau of Labor Statistics
BOE
Basis of Estimate
BSR
Business Systems Review
CA
Cooperative Agreement
CA-FATC
Cooperative Agreement Financial and Administrative Terms and
Conditions
CAM
Control Account Manager
CAP
Cost Analysis and Pre-award
CATEX
Categorical Exclusion (NEPA)
CCB
Change Control Board
CCP
Change/Configuration Control Process
CDR
Conceptual Design Review
CEBOK
Cost Estimating Body of Knowledge
CEP
Cost Estimating Plan
CEQ
Council on Environmental Quality
CER
Compliance Evaluation Review
CHIPS
Creating Helpful Incentives to Produce Semiconductors
CI
Cyberinfrastructure
Co-PI
Co-Principal Investigator
Document Number
347
7.0 Acronyms and Abbreviations
Research Infrastructure Guide
Acronym or
Abbreviation
Full Spelling
CO
Contracting Officer
ConOps
Concept of Operations
COR
Contracting Officer’s Representative
CORF
Chief Officer for Research Facilities
COSO
Committee of Sponsoring Organizations of the Treadway Commission
CPM
Critical Path Method
DACS
Division of Acquisition and Cooperative Support
DEP
Design Execution Plan
DOD
Department of Defense
DOE
Department of Energy
DOI
Digital Object Identifiers
EA
Environmental Assessment
EAC
Estimate at Completion
EHS
Environmental Health and Safety
EIS
Environmental Impact Statement
ES&H
Environmental Safety and Health
ESA
Endangered Species Act
ETC
Estimate to Complete
EU
Estimate Uncertainties
EVM
Earned Value Management
EVMS
Earned Value Management System
FAIR
Findable, Accessible, Interoperable, and Reusable
FAR
Federal Acquisition Regulations
FCA
Facility Condition Assessment
FDR
Final Design Review
FFRDC
Federally Funded Research and Development Center
FGCAA
Federal Grant and Cooperative Agreement Act
FY
Fiscal Year
GAO
Government Accountability Office
Document Number
348
7.0 Acronyms and Abbreviations
Research Infrastructure Guide
Acronym or
Abbreviation
Full Spelling
GPRAMA
Government Performance and Results Modernization Act
GR&A
Ground Rules and Assumptions
IA
Information Assurance
IAMP
Information Assurance Management Plan
ICE
Independent Cost Estimate
ICEAA
International Cost Estimating and Analysis Association
IMS
Integrated Master Schedule
IPT
Integrated Project Team
ISO
International Organization for Standardization
IT
Information Technology
ITAR
International Traffic in Arms Regulations
KP
Key Personnel
KPI
Key Performance Indicators
KPP
Key Performance Parameters
LFO
Large Facilities Office
LOE
Level-of-Effort
M&S
Materials and Supplies
MFA
Multi-factor Authentication
MMFWG
Major and Mid-scale Facilities Working Group
MOU
Memorandum of Understanding
MRE
Major Research Equipment
MREFC
Major Research Equipment and Facilities Construction
MRI
Major Research Instrumentation
NCOP
No Cost Overrun Policy
NDAA
National Defense Authorization Act
NDIA
National Defense Industrial Association
NEPA
National Environmental Policy Act
NHPA
National Historic Preservation Act
NICRA
Negotiated Indirect Cost Rate Agreement
Document Number
349
7.0 Acronyms and Abbreviations
Research Infrastructure Guide
Acronym or
Abbreviation
Full Spelling
NIST
National Institute of Standards and Technology
NOAA
National Oceanic and Atmospheric Administration
NSB
National Science Board
NSF
National Science Foundation
NSPM
National Security Presidential Memo
O&M
Operations and Maintenance
OA
Other Arrangements
OA/T
Other Arrangements/Transactions
OBS
Organizational Breakdown Structure
OCRSSP
Office of the Chief of Research Security Strategy and Policy
OM
Operating Manager
OMB
Office of Management and Budget
OSTP
Office of Science and Technology Policy
OT
Other Transactions
P/PM
Project and Program Management
PAPPG
Proposal and Award Policies and Procedures Guide
PD
Project Director
PDR
Preliminary Design Review
PEP
Project Execution Plan
PERT
Program Evaluation and Review Technique
PI
Principal Investigator
PM
Project Manager
PMB
Performance Measurement Baseline
PMBOK
Project Management Body of Knowledge
PMI
Project Management Institute
PMIAA
Program Management Improvement Accountability Act
PMM
Performance Measurement and Management
PO
Program Officer
PPE
Personal Protective Equipment
Document Number
350
7.0 Acronyms and Abbreviations
Research Infrastructure Guide
Acronym or
Abbreviation
Full Spelling
PT
Project Team
PTO
Paid Time Off
QA
Quality Assurance
QC
Quality Control
R&D
Research and Development
R&RA
Research and Related Activities
RACI
Responsible, Accountable, Consulted, and Informed
RAEAC
Risk-Adjusted Estimate at Completion
RAM
Responsibility Assignment Matrix
RI
Research Infrastructure
RIG
Research Infrastructure Guide
RIO
Research Infrastructure Office
RLS
Resource-Loaded Schedule
SMARTTT
Specific, Measurable, Achievable, Relevant, Traceable, Tiered, Total
SME
Subject Matter Expert
STEM
Science, Technology, Engineering, and Mathematics
SVT
Schedule Visibility Task
TIP
Technology, Innovation, and Partnerships
TPC
Total Project Cost
TPCAWD
Award Amount to Recipient (PMB + contingency + profit/fee)
TPCEVM
Total Project Cost Earned Value Management
TPCNSB
National Science Board Authorized Total Project Cost
TPD
Total Project Duration
USD
United States Dollars
VAC
Variance at Completion
VAS
Verification, Acceptance, and Surveillance
WBS
Work Breakdown Structure
Document Number
351
8.0 Lexicon
Research Infrastructure Guide
8.0
LEXICON
8.1
LEXICON PREFACE
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
This lexicon contains definitions of project and program management terms used in this
Guide specifically tailored for use in the context of NSF Major Facilities and Mid-scale
Research Infrastructure (RI). It combines specialized terms NSF defines with widely used
professional project and program management terminology.
A selection of common project management terms, compatible with NSF usage, has been
adopted from the Project Management Institute Inc.'s Lexicon of Project Management Terms
(2017). Entries italicized are directly from PMI’s Lexicon, while those marked with an asterisk
(*) are slightly modified versions for NSF purposes.
This lexicon aims to establish a common set of standard terms and definitions to enhance
communication and understanding among stakeholders in documents and correspondence
related to major facility management. The term project in this lexicon refers to project and
program management elements across all life cycle stages unless specified otherwise.
Please note that the terms and definitions included are in development and may be updated
in future versions.
Document Number
352
8.0 Lexicon
8.2
Research Infrastructure Guide
TERMS AND DEFINITIONS
JUMP TO:
A B C D E F GH I J K L M N O PQ R S TU V WX YZ
A
Acceptance Criteria. A set of conditions that is required to be met before deliverables are
accepted.
Accuracy. The degree of correctness, exactness, and reliability of project-related
information, data, estimates, and measurements. It involves ensuring that project activities,
plans, forecasts, and evaluations reflect the true state of affairs and are free from errors,
bias, or distortion.
Activity. A distinct, scheduled portion of work performed during a project.
Actual Cost. The realized cost incurred for the work performed on an activity during a specific
period.
Allocation. The assignment and distribution of resources to various tasks, activities, or
project phases or stages.
Allowance. 1 An amount of money or time permitted for anticipated but as-of-yet undefined
details or requirements and is included in the basis of estimate for base costs or activity
durations in the schedule. May be used when the level of RI definition may not enable certain
costs or durations to be estimated definitively or times when it is simply not cost effective to
quantify and estimate scope, but reliable correlations are available. If appropriate,
allowances could include uncertainties associated with cost estimating (as part of the Basis
of Estimate) in lieu of a defined risk, where the cost impacts would be held in aggregate as
part of the budget contingency.
Approval. The act of officially accepting an idea, action, or plan.
Assistance. The act of giving support or help; making it easier for someone to do something
or for something to happen.
Assumption. A factor in the planning process that is considered to be true, real, or certain, without
proof or demonstration.
Assurance. To give a strong and/or definite statement that something will happen or that
something is true; to give confidence.
Authorized. The total amount approved by NSF, but not necessarily obligated and allocated
by NSF.
Award instrument. An agreement between NSF and an Awardee with the terms and
1 Definition adapted from: AACEI RP 10S‐90: Cost Engineering Terminology, September 30, 2021; AACE
International Skills and Knowledge of Cost Engineering, 6th Edition, 2015; International Cost Estimating and Analysis
Association (ICEAA), Cost Estimating Body of Knowledge (CEBoK), Glossary of Terms, 2013
Document Number
353
8.0 Lexicon
Research Infrastructure Guide
conditions set forth in (cooperative agreements, contracts, etc.).
Awardee. The organization receiving the NSF award to manage and conduct the day-to-day
operations and maintenance of the Major Facility.
Awardee-titled property. Any federally funded property in the custody of the Awardee
where the government has not retained ownership, but the property is still subject to
established obligations and conditions. Awardee-titled property is held in trust for the
beneficiaries of the project or program (generally the science community) under which the
property was acquired or improved. This arrangement is otherwise known as the “property
trust relationship.” Generally, the Awardee may not encumber (i.e., place a lien on) the
property and must follow the award terms and conditions on use, management, and
disposition of the property. Only following disposition decisions at the end of the award,
would ownership potentially transfer to the Awardee.
B
BACK TO TOP
*Baseline. The approved cost and schedule plan for a scope of work, used during planning. For
NSF, contingency is not included in the baseline but is held and managed separately. A planning
baseline may or may not be under change control. Once a baseline has been approved, is under
change control, and is used as the basis for monitoring progress against the plan, it is referred to
as the Performance Measurement Baseline (PMB).
Basis of Estimate (BOE). Supporting documentation outlining the details used in establishing
project estimates such as assumptions, constraints, level of detail, ranges, and confidence levels.
Bottom-up Estimating. A method of estimating project duration or cost by aggregating the
estimates of the lower-level components of the work breakdown structure (WBS).
*Budget at Completion (BAC). The sum of all budgets established for the work to be performed.
For NSF projects, contingency amounts are not included in the Estimate to Completion (ETC),
Estimate at Completion (EAC), BAC, or PMB due to the NSF requirement that contingency is held
and managed separately from the baseline.
Budget contingency. A budget held to allow for identified items, conditions, or events for
which the state, occurrence, or effect is uncertain and that experience shows will likely result,
in the aggregate, in additional costs. These events are often referred to as “known-unknowns”
and are considered manageable by the Awardee. This amount is held separately from the
baseline budget as part of the Total Project Cost to help manage risk and uncertainty in
aggregate and obligated to the project for the Awardee to manage based on need per NSF
policy. Contingency may only be used when a risk (including uncertainty) from the risk register
is realized. In short, budget contingency is a budget held separate from the baseline to manage
known risks in aggregate.
Document Number
354
8.0 Lexicon
C
Research Infrastructure Guide
BACK TO TOP
Change control. A process whereby modifications to documents, deliverables, or baselines
associated with the project are identified, documented, approved, or rejected.
Change Control Board (CCB). A formally chartered group responsible for reviewing, evaluating,
approving, delaying, or rejecting changes to the project, and for recording and communicating
such decisions.
Change Request. A formal proposal to modify any document, deliverable, or baseline.
Closeout. The process by which the federal awarding agency or pass-through entity
determines that all applicable administrative actions and all required work of the federal
award have been completed.
Conceptual Design Phase. The first phase of the Design Stage, after passing the gate from
the Development Stage, that advances the definition of the scope and requirements,
determines feasibility, and produces updated drafts of most elements of the Project
Execution Plan (PEP), including parametric cost and schedule range estimates and a
preliminary risk analysis.
Conditional interest. The government’s right to invoke a transfer of Awardee-titled
property, including to the government or to another Awardee.
Contingency. See Budget, Schedule, and Scope Contingency.
Constraint. A limiting factor that affects the execution of a project, program, portfolio, or process.
Construction Stage. The period in which funds are obligated for acquisition and/or
construction of a facility that fulfills the terms and conditions set forth in an award instrument
between NSF and the Awardee(s). This Stage ends with the start of the Operations Stage.
Contract. A contract is for the purpose of obtaining goods and services for the non-Federal
entity’s own use and creates a procurement relationship with the contractor. All contracts
over $250,000 require written prior NSF authorization.
Control account. A management control point where scope, budget, actual cost, and schedule are
integrated and compared to earned value for performance measurement.
Corrective action. An intentional activity that realigns the performance of the project work with
the project plan.
Cost Book. A compilation of Cost Book Sheets, typically used to present baseline or Total
Project Cost (TPC) but may be used to present rolled-up costs for smaller elements or subelements.
Cost Book Sheet. A compilation of related information from the Cost Model Data Set, used
to define and present the cost estimate for a particular element or sub-element of a
deliverable- based work breakdown structure for construction or a functional, activity,
and/or deliverable based work breakdown structure for operations.
Cost-loaded. A project schedule or WBS that includes the associated costs for each task or
Document Number
355
8.0 Lexicon
Research Infrastructure Guide
activity and financial resources required for the completion of each task are identified and
assigned, allowing for comprehensive cost management and control throughout the project.
Cost Model Data Set. The cost data used as input to software tools and/or project reports
to organize, correlate, and calculate different project management information.
Cost Performance Index. A measure of the cost efficiency of budgeted resources expressed as the
ratio of earned value to actual cost.
Cost Variance. The amount of budget deficit or surplus at a given point in time, expressed as the
difference between the earned value and the actual cost.
Critical path. The sequence of activities that represents the longest path through a project, which
determines the shortest possible duration.
Critical path activity. Any activity on the critical path in a project schedule.
Critical path method. A method used to estimate the minimum project duration and determine
the amount of scheduling flexibility on the logical network paths within the schedule model.
Current plan. The project cost and schedule plan reflecting the status of progress to date
and updated estimates for completing remaining work that is compared to the approved
Performance Measurement Baseline (PMB), as part of Earned Value Management.
Custody. Protective care or guardianship responsibilities of the Awardee over federally
funded property.
D
BACK TO TOP
Decomposition. A technique used for dividing and subdividing the project scope and project
deliverables into smaller, more manageable parts.
Deliverable. Any unique and verifiable product, result, or capability to perform a service that is
required to be produced to complete a process, phase, or project.
De-scoping options. See Scope Options.
Design Stage. The life cycle stage for detailed planning for projects approved by the NSF
Director at the end of the Development Stage and funded under the formal major facility
planning process. It is divided into the Conceptual, Preliminary, and Final Design Phases; with
a formal and rigorous review gate at the end of each phase to show readiness for
advancement to a higher level of refinement regarding scope, cost, and schedule.
Development Stage. The facility life cycle stage in which initial high-level ideas are
developed and a consensus built for the potential long-term need, priorities, and general
requirements for a large research facility of interest to NSF and the broader research
community.
Disposition Stage. The stage in the facility life cycle encompassing disposition of the facility
starting after the NSF Operations Stage ends and funding for disposition begins. Disposition
options may include partial or complete transfer of a facility to another entity’s operational
Document Number
356
8.0 Lexicon
Research Infrastructure Guide
and financial control (with or without reduction in project scope), “mothballing” the facility
so that operations can be restarted later, or decommissioning. Decommissioning may
include complete removal of the infrastructure and site restoration.
Divestment. The final transfer of property ownership, including relinquishing any
conditional interest, from NSF to another entity. Divestment can occur for the entire Facility,
a component of the Facility, or other capital assets. 1 Divestment can also be accomplished
through the decommissioning and deconstruction of a Major Facility or component in cases
where those actions are necessary to complete the transfer of ownership or meet
environmental obligations. If the assets remain operational under the new entity, NSF may
still fund individual investigators separately to utilize those assets for research. Following
divestment, the asset(s) is no longer considered an NSF-funded Major Facility or part of an
NSF-funded Major Facility.
E
BACK TO TOP
Earned Value. The measure of work performed expressed in terms of the budget authorized for
that work.
Earned Value Management (EVM). A methodology that combines scope, schedule, and resource
measurements to assess project performance and progress.
Effort. The number of labor units required to complete a schedule activity or work breakdown
structure component, often expressed in hours, days, or weeks.
*Estimate at Completion (EAC). The expected total cost of completing all work expressed as the
sum of the actual cost to date and the estimate to complete. For NSF projects, contingency amounts
are not included in the ETC, EAC, BAC, or PMB due to the NSF requirement that contingency is held
and managed separately from the baseline.
*Estimate to Complete (ETC). The expected cost to finish all the remaining project work. For NSF
projects, contingency amounts are not included in the ETC, EAC, BAC, or PMB due to the NSF
requirement that contingency is held and managed separately from the baseline.
F
BACK TO TOP
Facility. Shared-use infrastructure, equipment, or instrument - or an integrated network
and/or collection of the same – that is either acquired or constructed to collect, analyze, and
provide necessary data and information in support of research having a major impact on a
broad segment of a scientific or engineering discipline.
Federally funded property. Any property acquired, fabricated, or improved in whole or in
part with federal funds, whether funded by NSF or any other federal agency.
Federally owned property. Any federally funded property in the custody of the Awardee
Excess or sale of property is a form of divestment. This is more typical for capital assets or components of Major
Facilities that are removed as part of routine upgrades.
1
Document Number
357
8.0 Lexicon
Research Infrastructure Guide
where the agency has retained ownership. The Awardee is subject to use and disposition
requirements in accordance with the award and must submit to NSF annually an inventory
listing of Federally owned property in its custody.
Final Design Phase. The third and last phase of the Design Stage, after a successful
Preliminary Design Phase, that further refines the project definition and the Project
Execution Plan (PEP) and demonstrates that project planning and management meet
requirements for readiness to receive funding. The Final Design Phase ends in a potential
NSF approval to obligate construction funds.
Finish-to-Finish. A logical relationship in which a successor activity cannot finish until a
predecessor activity has finished.
Finish-to-Start. A logical relationship in which a successor activity cannot start until a predecessor
activity has finished.
Float. Also called Free Float. The amount of time that a schedule activity can be delayed without
delaying the early start date of any successor or violating a schedule constraint.
Funding announcement. A formal notification to invite researchers, institutions, and
organizations to submit proposals for financial support of research and educational projects
and provides detailed information about the funding opportunities available, including the
objectives, eligibility criteria, application procedures, evaluation criteria, and deadlines.
G
BACK TO TOP
Gantt chart. A bar chart of schedule information where activities are listed on the vertical axis,
dates are shown on the horizontal axis, and activity durations are shown as horizontal bars placed
according to start and finish dates.
H
BACK TO TOP
I
BACK TO TOP
Independent Cost Estimate (ICE) Review. An objective and unbiased review of a cost
estimate by an independent entity outside of the acquisition chain that may be used by NSF
to help validate the Awardee’s estimate. It may include reconciliation of an ICE with the
Awardee’s estimate and detailed reviews of the schedule, Risk Register, and contingencies.
Information Assurance (IA). The umbrella term inclusive of cybersecurity, data protections
(including privacy), cyber risk management, and resilience.
Integrated Master Schedule (IMS). A detailed schedule that is based on the WBS hierarchy
and includes tasks and activities, project start and end dates, review dates, and other critical
dates and key milestones
Issue. A point or matter in question or in dispute, or a point or matter that is not settled and
is under discussion or in dispute between project stakeholders.
Document Number
358
8.0 Lexicon
Research Infrastructure Guide
J
BACK TO TOP
K
BACK TO TOP
Key Performance Indicator (KPI). A measurable value that indicates how effectively an
organization, project, or individual is achieving key business or science objectives. KPIs
measure performance in specific areas that are important for achieving strategic,
operational, and scientific goals.
Key Performance Parameter (KPP). Critical, measurable characteristic, attribute, or
requirement that a project, system, or process must meet that are used to ensure that
essential performance criteria are met. Failure to meet a KPP typically means the project
cannot achieve its intended purpose and may be considered a failure.
Known-unknowns. Recognized risks and uncertainties with unknown specific outcomes or
details.
L
BACK TO TOP
Lag. The amount of time whereby a successor activity is required to be delayed with respect to a
predecessor activity.
Late finish date. In the critical path method, the latest possible point in time when the
uncompleted portions of a schedule activity can finish based on the schedule network logic, the
project completion date, and any schedule constraints.
Late start date. In the critical path method, the latest possible point in time when the
uncompleted portions of a schedule activity can start based on the schedule network logic, the
project completion date, and any schedule constraints.
Lead. The amount of time whereby a successor activity can be advanced with respect to a
predecessor activity.
Lessons learned. The knowledge gained during a project which shows how project events were
addressed or should be addressed in the future for the purpose of improving future performance.
Level-of-Effort (LOE). An activity that does not produce definitive end products and is measured
by the passage of time. (Note. Level of effort is one of three earned value management [EVM] types
of activities used to measure work performance.)
Liens list. A list of expected adjustments to project scope, budget, and schedule contingency
amounts that are waiting for implementation, including formal change control actions for
planned baseline modifications, scope contingency options held for decision, realized risks,
and coverage of variances.
Life Cycle Stage. The sequence of steps or stages that characterize the lifetime of a facility
from beginning to end. For NSF, the stages include Development, Design, Construction,
Operations, and Disposition.
Document Number
359
8.0 Lexicon
M
Research Infrastructure Guide
BACK TO TOP
Major Facility. A science and engineering facility project that exceeds $100,000,000 in
construction, acquisition, or upgrade costs to the Foundation. 1
Management. The act of controlling and making decisions about an operation, organization,
or project; the act or process of deciding how to use something; the judicious use of means
to accomplish an end.
Management Reserve. An amount of money or time included as part of the Total Project
Cost (TCP) estimate to address unforeseen events or uncertainties that are beyond the
control of the Awardee or the agency. These events are often referred to as “unknown
unknowns.” The amount of management reserve (if any) is determined based on agency risk
tolerance and managed exclusively by the agency. Similar “reserves” are not allowable in
Awardee estimates per the Uniform Guidance.
Mid-scale Research Infrastructure (RI). RI that currently have a TPC between $4 million
and $100 million.
Milestone. A significant point or event in a project, program, or portfolio.
Monte Carlo simulation. A computational technique that utilizes random sampling and
statistical analysis to model the probability of different outcomes in a process that involves
uncertainty, such as cost or schedule. Project managers use this technique to gain insights
into the likelihood of various outcomes, aiding with making more informed decisions about
resource allocation, scheduling, and risk management.
Most likely duration. An estimate of the most probable activity duration that considers all the
known variables that could affect performance.
N
BACK TO TOP
Near-critical path. Activities with minimal total float that can quickly become part of the
critical path if delays occur. These tasks require close monitoring because any delay can
potentially affect the entire project.
No Cost Overrun Policy (NCOP). NSF policy requiring that a Total Project Cost (TPC) estimate
established at the Preliminary Design Phase have adequate contingency to cover all
foreseeable risks. However, NSF conducts its oversight of projects against the Total Project
Cost (TPC) authorized by the National Science Board (NSB) following Final Design Review
(FDR).
Non-renewal. The decision not to recreate a legal relationship between NSF and the current
managing organization by replacing an old award with a new one. It generally applies in
situations where NSF does not have property ownership or any conditional interest in the
capital assets or other property but only funds the managing organization to operate the
1 https://www.congress.gov/116/plaws/publ283/PLAW-116publ283.pdf
Document Number
360
8.0 Lexicon
Research Infrastructure Guide
asset. Following non-renewal, the asset(s) are no longer considered an NSF-funded Major
Facility or part of an NSF-funded Major Facility.
O
BACK TO TOP
Obligation. A definite commitment that creates a legal liability of the government for the
payment of goods and services ordered or received, or a legal duty on the part of the United
States that could mature into a legal liability by virtue of actions on the part of the other party
beyond the control of the United States.
Off-ramps. Decision points where a proposed project can be canceled or no longer
supported to move forward.
Operations Stage. The life cycle stage that succeeds Construction and includes the day-today work to operate and maintain the facility and to perform research. Operations may also
include activities to transition from construction to operations, replacement or upgrade
activities, technology research and development, and activities that support planning and
staging for the Disposition Stage.
Opportunity. A risk that would have a positive effect on one or more project objectives.
Organizational Breakdown Structure (OBS). A hierarchical representation of the project
organization, which illustrates the relationship between project activities and the organizational
units that will perform those activities.
Oversight. Watchful and responsible care of something or some activity; regulatory
supervision.
Ownership [Owned]. The ultimate and exclusive rights and control over property.
P
BACK TO TOP
Parametric estimating. An estimating technique in which an algorithm is used to calculate cost
or duration based on historical data and project parameters.
Path convergence. A relationship in which a schedule activity has more than one predecessor.
Path divergence. A relationship in which a schedule activity has more than one successor.
Percent complete. An estimate expressed as a percent of the amount of work that has been
completed on an activity or a work breakdown structure component.
Performance Measurement Baseline (PMB). The approved cost and schedule baseline for
accomplishing project work scope used as a basis of comparison for Earned Value
Management. The PMB is typically approved and established at the time of the construction
award, in the terms and conditions of the award instrument, and is under formal change
control for the life of the project. (For NSF projects, contingency amounts are not included in
the PMB due to the NSF requirement that contingency is held and managed separately from
the baseline.)
Document Number
361
8.0 Lexicon
Research Infrastructure Guide
Planned Value. The authorized budget assigned to scheduled work.
Planning package. A component of work within the WBS with budget and duration but
without detailed schedule activities (work package). A planning package should be converted
to work package(s) when the lower-level details of the work are defined and prior to start of
the work.
Portfolio. Projects, programs, sub-portfolios, and operations managed as a group to achieve
strategic objectives.
Portfolio management. The centralized management of one or more portfolios to achieve
strategic objectives.
Predecessor activity. An activity that logically comes before a dependent activity in a schedule.
Preliminary Design Phase. The second phase of the Design Stage, after the Conceptual
Design Phase, further advances the project definition and the Project Execution Plan. It
produces a bottom-up scope, cost, schedule, and risk analysis of sufficient maturity to allow
determination of the Project Total Cost and Duration for a stated future start date and to
establish the construction budget request.
Probabilistic Risk Analysis. A quantitative risk analysis that uses probability distributions to
represent the uncertainty usually present in the cost of a deliverable or the duration of a
scheduled activity and discrete risks, to obtain a range of outcomes for overall project cost
and finish dates that support selection of contingency amounts as part of risk management.
Many commercial probabilistic risk analysis applications employ Monte Carlo simulations of
project cost and schedule.
Program. A group of related projects, subprograms, and program activities that are managed in
a coordinated way to obtain benefits not available from managing them individually.
Program management. The application of knowledge, skills, tools, and techniques to a program
to meet the program requirements and to obtain benefits and control not available by managing
projects individually.
Progress schedule. Also called a forecast schedule. A detailed plan that tracks the
advancement of tasks, activities, and milestones within a project and provides a timeline for
the completion of project elements, helping to monitor progress against the planned
schedule.
Progressively elaborating. The iterative process of increasing the level of detail in a project
management plan as greater amounts of information and more accurate estimates become
available.
Project. The activities associated specifically with the Construction Stage for Major Facilities
and Mid-scale RI implementation, even though elements of project and program
management may be associated with other life cycle stages.
Project definition. A clearly defined scope, schedule, and cost that is formulated before the
project begins and is the foundation for project execution. See also Total Project Definition.
Document Number
362
8.0 Lexicon
Research Infrastructure Guide
Project end date. The projected date for the completion of all the project baseline schedule
activities plus use of all schedule contingency. (Note that this date may be earlier than, but
no later than, the end date of the award instrument.)
Project life cycle. The series of stages that a project passes through from its initiation to its closure.
Project management. The application of knowledge, skills, tools, and techniques to project
activities to meet the project requirements.
Project Management Control System. The software tools for development of the project
databases and the processes and procedures needed to organize and manage the project;
schedule and optimize project resources; compute and track Earned Value and document
project risk factors; and manage the change process by evaluating the effects of alterations
to the baseline on the project’s planned budget and schedule.
Project Management Office. A management structure that standardizes the project-related
governance processes and facilitates the sharing of resources, methodologies, tools, and
techniques.
Project Manager (PM). The person assigned by the performing organization to lead the team that
is responsible for achieving the project objectives.
Project schedule. An output of a schedule model that presents linked activities with planned
dates, durations, milestones, and resources.
Project scope. The work performed to deliver a product, service, or result with the specified
features and functions.
Project Team. A group of individuals with specific roles, skills, and expertise, assembled to
collaborate on the planning, execution, and completion of a project. The team is responsible
for managing project resources, schedules, risks, and deliverables, working cohesively to
ensure the project meets its objectives on time, within scope, and on budget. Members
contribute to decision-making, problem-solving, and ensuring the project's overall success
through clear communication and coordinated efforts.
Property. Consists of both real property and personal property. Generally, real property
includes land and things built on land that are not typically moveable, such as buildings.
Personal property is all other property whether it is tangible (having a physical existence) or
intangible (i.e., intellectual property and other financial instruments). Personal property
includes “equipment” which is any tangible property with a useful life greater than one year
and typically a per-unit purchase cost of $10,000 or more unless the Awardee sets a lower
value for financial statement purposes. Equipment can range from the very small to the very
large as long as it is moveable, in principle.
Property trust relationship. The arrangement where the Awardee has custody of federallyfunded property for the beneficiaries of the project or program subject to established
obligations and conditions.
Puts and Takes. Adjustments made during the planning or execution phase to balance
Document Number
363
8.0 Lexicon
Research Infrastructure Guide
resources, timelines, budgets, or scope and are often used when discussing budget
reallocations needed to stay on track with project goals. Puts are a positive adjustment, takes
are negative adjustments.
Q
BACK TO TOP
Quality Acceptance. The process of confirming that a project deliverable, product, or
service meets the specified requirements and fulfills its intended purpose. It involves
assessing whether the output being assessed aligns with the expectations of stakeholders
and complies with the defined quality standards and criteria.
Quality Assurance (QA). The systematic activities and processes used to ensure that project
deliverables meet defined quality standards. QA focuses on the process of producing
deliverables, ensuring that proper methodologies, standards, and procedures are followed
to prevent deficiencies and ensure continuous improvement.
Quality Control (QC). The process of detecting and correcting defects, errors, or variances
to assess performance against the desired quality level in project deliverables or processes.
QC focuses on identifying deficiencies or variances in the final product or service, using tools
like inspections, tests, and reviews.
R
BACK TO TOP
Re-baselining. A modification to the Total Project Definition that results in a change that is
outside the terms set forth in the award instrument for any of the following: 1) Total Project
Cost (TPC); 2) Total Project Duration (TPD); or 3) project scope, except for approved options
in the scope management plan. The initial TPC and award duration are part of the NSB
authorization for the Construction Stage and Mid-scale RI implementation and inform the
terms of the award. Re-baselining actions require special review and approval by NSF beyond
those of the typical change control approval process for re-planning actions.
Re-planning. A normal project management process to modify or re-organize the
Performance Measurement Baseline cost and/or schedule plans for future work without
impacting Total Project Cost (TPC), Total Project Duration (TPD), or overall scope objectives,
or the implementation of approved scope management options. Formal change control
processes are followed for all baseline changes. Retroactive changes to past performance
should not be included in re-planning.
Recipient-titled property. Under financial assistance, any federally funded property in the
custody of the Awardee where the government has not retained ownership, but the property
is still subject to established obligations and conditions. Awardee-titled property is held in
trust for the beneficiaries of the project or program (generally the science community) under
which the property was acquired or improved. This arrangement is otherwise known as the
“property trust relationship.” Generally, the Awardee may not encumber (i.e., place a lien on)
the property and must follow the award terms and conditions on use, management, and
disposition of the property. Only following disposition decisions at the end of the award,
Document Number
364
8.0 Lexicon
Research Infrastructure Guide
would ownership potentially transfer to the Awardee.
Recovery Plan. A formalized plan of corrective actions to address negative cost and/or
schedule trends for return of the project to within the project definition. The plan should be
based on a comprehensive analysis of the variances and establish a timeline for actions and
recovery.
Requirement. A condition or capability that is required to be present in a product, service, or
result to satisfy a contract or other formally imposed specification.
Research.gov. (Replaces the now decommissioned FastLane) Used by potential Awardees
for proposal preparation, submission, proposal file updates, and budgetary revisions.
Research Infrastructure (RI). Any combination of facilities, equipment, instrumentation,
computational hardware and software, and the necessary supporting human capital.
Resource Breakdown Structure. A hierarchical representation of resources by category and type.
Resource leveling. A technique in which the start and finish dates are adjusted based on resource
constraints with the goal of balancing demand for resources with the available supply.
Resource-loaded. A schedule or plan that includes not just tasks and their dependencies,
but also the allocation of resources required to complete those tasks, including personnel,
equipment, materials, and any other necessary inputs.
Responsibility Assignment Matrix (RAM). A grid that shows the project resources assigned to
each work package.
Review and Recommend. The act of carefully looking at or examining the quality or
condition of something AND then suggesting that someone act or do something.
Risk. An uncertain event or condition that, if it occurs, has a positive or negative effect on one or
more project objectives.
Risk acceptance. A risk response strategy whereby the project team decides to acknowledge the
risk and not take any action unless the risk occurs.
Risk-adjusted Estimate at Completion (RAEAC). The expected total cost of completing all
work expressed as the sum of the actual cost to date, the estimate to complete, and the
project’s remaining risk exposure.
Risk avoidance. A risk response strategy whereby the project team acts to eliminate the threat or
protect the project from its impact.
Risk Breakdown Structure. A hierarchical representation of risks that is organized according to
risk categories.
Risk category. A group of potential causes of risk.
Risk exposure. Quantitative impact of risk for a single event, quoted in currency or time,
and typically estimated from probability of occurrence and a likely impact or consequence.
Overall project risk exposure results from an accumulation of individual risk impacts for the
Document Number
365
8.0 Lexicon
Research Infrastructure Guide
work to be completed, typically determined by applying probabilistic analysis to the set of
individual risks.
Risk mitigation. A risk response strategy whereby the project team acts to reduce the probability
of occurrence or impact of a risk.
Risk Register. A document in which the results of risk analysis and risk response planning are
recorded and managed.
Risk transference. A risk response strategy whereby the project team shifts the impact of a threat
to a third party, together with ownership of the response.
Rolling wave planning. An iterative planning technique in which the work to be accomplished in
the near term is planned in detail, while the work in the future is planned at a higher level.
Runbook. A documented compilation of procedures and operations related to the ongoing
management and maintenance of systems that is an essential tool for ensuring consistent
execution of tasks, especially during incident management or routine operations. Key
features may include detailed, step-by-step instructions, guidelines on procedures, incident
management, roles and responsibilities, and standards to ensure uniformity and
consistency.
S
BACK TO TOP
Schedule basis document. A written document to describe the schedule at a high-level
including dependencies, key dates, assumptions, and the project team’s assessment of the
schedule integrity and quality using GAO schedule characteristics.
Schedule contingency. A duration of time to allow for identified delays, conditions, or events
for which the state, occurrence, or effect is uncertain, and that experience shows will likely
result, in aggregate. These events are often referred to as “known-unknowns” and are
considered manageable by the Awardee. This duration is held separately from the baseline
schedule as part of the Total Project Duration to help manage risk and uncertainty, in
aggregate.
Schedule margin. An activity with duration and no resources used to manage risk
associated with specific interim milestones or external deliverable requirements. A schedule
margin activity should not be on the critical path that establishes the performance
measurement baseline (PMB) duration nor used in the schedule risk analysis to establish the
schedule contingency. Schedule contingency amounts are not included in the PMB due to
the NSF requirement that contingency is held and managed separately from the baseline.
Schedule model. A representation of the plan for executing the project’s activities, including
durations, dependencies, and other planning information, used to produce a project schedule
along with other scheduling artifacts.
Schedule Performance Index. A measure of schedule efficiency expressed as the ratio of earned
value to planned value.
Document Number
366
8.0 Lexicon
Research Infrastructure Guide
Schedule Variance. A measure of schedule performance expressed as the difference between the
earned value and the planned value.
Schedule Visibility Task (SVT). Schedule activities with no resources assigned whose
duration is greater than zero. SVTs may be waiting periods such as concrete curing timing or
equipment delivery within the PMB or may be used to represent external effort that is not
part of the PMB. SVTs may also be used to increase management visibility to items otherwise
represented as lag or constrained milestones.
Science Support Program. The suite of activities related to operations and maintenance
(O&M) conducted under the award as negotiated with an NSF Program Office for all Major
Facilities and Mid-scale RI.
Scope contingency. Scope either (1) included in the Scope Baseline that can be removed
(“de-scoped”) without affecting the overall project’s objectives, but that may still have
undesirable effects on facility performance, or (2) may be added to the project baseline (“upscope” or “opportunity”) if budget contingency is not needed to cover realized risks and
remaining risk exposure. De-scoping options and scope opportunities are included in the
Scope Management Plan. Scope opportunities cannot be added after start of the Construction
Stage. For Major Facility construction projects, identified scope contingency should have a
value equal to at least 10% of the baseline budget at the Preliminary Design Review.
Scope creep. The uncontrolled expansion to product or project scope without adjustments to time,
cost, and resources.
Scope options. The various approaches, decisions, and strategies that can be considered
and employed to define, manage, and control the scope of a project.
S-curve. An earned value management technique used to indicate performance trends by using a
graph that displays cumulative costs over a specific period.
Secondary risk. A risk that arises as a direct result of implementing a risk response.
Sponsor. A person or group that provides resources and support for the project, program, or
portfolio, and is accountable for enabling success.
Stakeholder. An individual, group, or organization that may affect, be affected by, or perceive
itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.
Start-to-Finish. A logical relationship in which a successor activity cannot finish until a
predecessor activity has started.
Start-to-Start. A logical relationship in which a successor activity cannot start until a predecessor
activity has started.
Subaward: Award made by the prime Awardee of an NSF for the purpose of carrying out a
portion of a federal award and creates a federal assistance relationship with the Subawardee.
It does not include payments to a contractor or payments to an individual that is a beneficiary
of a Federal program. A subaward may be provided through any form of legal agreement,
including an agreement that the prime Awardee considers a contract. All subawards require
Document Number
367
8.0 Lexicon
Research Infrastructure Guide
written prior NSF authorization.
Successor activity. A dependent activity that logically comes after another activity in a schedule.
T
BACK TO TOP
Task. A specific piece of work or activity that needs to be accomplished to achieve a project's
objectives. Tasks are typically identified during project planning and are listed in a project
schedule or work breakdown structure (WBS).
Termination. The ending of a federal award, in whole or in part at any time prior to the
planned end of period of performance.
Time-Phased Budget. A financial plan that allocates the overall project budget across
specific time periods over the duration of the project and details how much money will be
spent and when, aligning financial resources with the project schedule and milestones.
Title [Titled]. A right to something (for example, property), but the actual rights conferred
may be limited; for example, Awardee-titled property routinely carries limitations on use,
management, and disposition under the “property trust relationship” between the
government and the Awardee.
Then-year. The budget that accounts for the actual costs expected in the year they will occur,
including the impact of inflation and other economic factors over the duration of the project.
It is also known as a current-year budget or nominal budget.
Threat. A risk that would have a negative effect on one or more project objectives.
Total float. The amount of time that a schedule activity can be delayed or extended from its early
start date without delaying the project finish date or violating a schedule constraint.
Total Project Cost (TPC). The sum of the baseline budget (including indirect costs), the
budget contingency, fee/profit (as applicable), and management reserve (if authorized) for
the Construction Stage. For other life-cycle stages, it is referred to as the "authorized award
amount.”
The TPC authorized by the NSB following FDR is a “not-to-exceed” figure against which NSF
manages the No Cost Overrun Policy. The initial award may be at or below this figure.
Throughout the Design and Construction Stages, the TPC is an estimate and only at the end
of the project will the final TPC be known.
Total Project Definition. A project's planned scope, quality, cost, and schedule, including
the performance measurement baseline documents (WBS including any unfunded
contributions, WBS Dictionary, Quality Acceptance Requirements, Integrated Project
Schedule, and Time-phased budget), all associated contingencies and approved fees planned
for the project. See also Project Definition.
Total Project Duration (TPD). The sum of the amount of time (in months) for the
Performance Measurement Baseline schedule duration and the schedule contingency. The
Document Number
368
8.0 Lexicon
Research Infrastructure Guide
NSB authorized award duration is typically the project duration plus approximately 6
months.
Transition. The change from a Major Facility to another class of RI or scale of activity where
NSF retains ownership or conditional interest and oversight responsibility of the assets.
Mothballing (i.e., putting assets into caretaker status) and long-term lease of real property
are considered forms of transition. Transition may involve the assignment of an award or a
competitive process for selecting the Awardee. Following transition, the asset(s) is no longer
considered an NSF-funded Major Facility, or part of an NSF-funded Major Facility, from an
oversight perspective. However, other terms and conditions would apply under the new
award(s), as appropriate.
Trigger. An event or situation that indicates that a risk is about to occur.
U
BACK TO TOP
Uncertainty. 1 Inherent variability in predicting the outcome of future events. Indefiniteness,
lack of certainty. Fundamental inability to perfectly measure or predict something due to
unknown and imperfect information. Uncertainty has a probability of 100% since it is always
present and can include an estimated range for a cost or duration. It is an inherent aspect of
project management and can affect planning, execution, and control.
Unknown-unknows. Significant threats to the project that are either unknowable during
the project planning process or are unreasonably too large to carry as a managed risk in the
project's Risk Register.
V
BACK TO TOP
Validation. The process of confirming that a product, service, or system meets the
requirements and expectations outlined in the project scope. It involves assessing whether
the deliverables align with the predetermined criteria and specifications, ensuring that they
fulfill their intended purpose and provide value to stakeholders. It typically occurs towards
the end of a project or phase, after the completion of the work, but before final acceptance
or approval. It answers the question, "Are we building the right product?" and is typically
performed after the product is completed.
Variance analysis. A technique for determining the cause and degree of difference between the
Performance Measurement Baseline and actual performance.
Variance at Completion (VAC). A projection of the amount of budget deficit or surplus, expressed
as the difference between the budget at completion and the estimate at completion.
Verification. The process of confirming that project deliverables, products, or components
1 Definition adapted from: AACE International (AACEI) Recommended Practice (RP) 10S‐90: Cost Engineering
Terminology, September 30, 2021; DOE Cost Estimating Guide, DOE G 413.3-21A, June 6, 2018; NASA Cost
Estimating Handbook, Version 4.0, February 2015.
Document Number
369
8.0 Lexicon
Research Infrastructure Guide
meet the specified requirements, standards, and criteria established in the project scope. It
ensures that the work results align with the intended objectives and that they adhere to the
defined quality standards and specifications. It answers the question, "Are we building the
product right?" and involves reviews, inspections, and testing during the design and
development stages.
W
BACK TO TOP
Work Breakdown Structure (WBS). A hierarchical decomposition of the total scope of work to be
carried out by the project team to accomplish the project objectives and create the required
deliverables.
Work Breakdown Structure (WBS) Dictionary. A document that provides detailed deliverable,
activity, and scheduling information about each component in the work breakdown structure.
Work Package. The work defined at the lowest level of the WBS for which cost, and duration can
be estimated and managed.
X
BACK TO TOP
Y
BACK TO TOP
Z
BACK TO TOP
Document Number
370
9.0 Appendices
9.0
Research Infrastructure Guide
APPENDICES
Section Revision: June 2025
Prepared by the Research Infrastructure Office and the Office of the Chief Officer for Research Facilities
9.1
APPENDIX A – RANKING CRITERIA FOR PRIORITIZING MAJOR
FACILITY PROJECTS
Excerpted from the National Academies’ Report: Setting Priorities for Large Facility Projects
Supported by the National Science Foundation. 1
9.1.1
First Ranking – Scientific and Technical Criteria Assessed by
Researchers in a Field or Interdisciplinary Area
•
Which projects have the most scientific merit, potential and opportunities within a
field or interdisciplinary area?
•
Which projects are the most technologically ready?
•
Are the scientific credentials of the proposers of the highest rank?
•
Are the project-management capabilities of the proposal team of the highest quality?
9.1.2
Second Ranking – Agency Strategic Criteria Assessed across Related
Fields
•
Which projects will have the greatest impact on scientific advances in this set of
related fields taking into account the importance of balance among fields for NSF's
portfolio management in the nation's interest?
•
Which projects include opportunities to serve the needs of researchers from multiple
disciplines or the ability to facilitate interdisciplinary research?
•
Which projects have major commitments from other agencies or countries that
should be considered?
•
Which projects have the greatest potential for education and workforce development?
•
Which projects have the most readiness for further development and construction?
9.1.3
Third Ranking – National Criteria Assessed across All Fields
•
Which projects are in new and emerging fields that have the most potential to be
transformative? Which projects have the most potential to change how research is
conducted or to expand fundamental science and engineering frontiers?
•
Which projects have the greatest potential for maintaining U.S leadership in key
science and engineering fields?
•
Which projects produce the greatest benefits in numbers of researchers, educators
1 As referenced in Joint National Science Board —National Science Foundation Management Report: Setting
Priorities for Large Facility Projects Supported by the National Science Foundation (NSB-05-77); September 2005.
http://www.nap.edu/books/0309090849/html/R1.html
Document Number
371
9.0 Appendices
Research Infrastructure Guide
and students enabled?
•
Which projects most need to be undertaken in the near term? Which ones have the
most current windows of opportunity, pressing needs and international or
interagency commitments that should be met?
•
Which projects have the greatest degree of community support?
•
Which projects will have the greatest impact on scientific advances across fields taking
into account the importance of balance among fields for NSF's portfolio management
in the nation's interest?
9.2
APPENDIX B – OUTLINE OF PLANS BY LIFE CYCLE STAGE
9.2.1
Design Stage
Design Execution Plan (DEP). First submitted during the Conceptual Design Phase and
revised for the Conceptual Design Review (CDR) and Preliminary Design Review (PDR). The
ten components include Design Execution Overview, Organization, Design Baseline, Risk
Management, Scope Acquisition and Delivery, Safety, Health and Environmental Protection,
Controls, Information Management, Award Close-out, and Post-Award Plans and
Expectations.
9.2.2
Construction Stage and Implementation Planning
Project Execution Plan (PEP). Structured into ten components, the PEP outlines the
planning, management, execution, and closure of a project. It specifies deliverables,
performance metrics, management structure, resources, timeline, milestones, and risks. All
Major Facilities and Mid-scale RI projects must submit a PEP tailored and scaled to the type
of project and its complexity.
PEP Component 3 – Performance Measurement Baseline Plans
Scope Management Plan. Outlines the strategy for managing project scope,
including identification, documentation, and control, along with roles and
responsibilities. It specifies processes for handling scope changes, de-scope, and
up-scope options and their impact on cost, schedule, and decision-making
timelines.
Schedule Basis and Estimating Plan. Details the methodology, tools, and processes
for developing the project schedule, including estimating techniques, guidelines,
and assumptions. It covers schedule logic, external dependencies, critical path
drivers, key dates, and assumptions regarding procurement, operations, funding,
travel, staffing, and resource limitations.
Cost Estimating Plan. This plan outlines the methodology, tools, and processes for
developing, documenting, reviewing, approving, and managing the project budget.
It includes critical assumptions, constraints, cost-estimating techniques, validation
methods, and significant factors, guiding project estimators and informing the NSF.
Document Number
372
9.0 Appendices
Research Infrastructure Guide
PEP Component 4 – Risk and Contingency Management Plans
Risk Management Plan. Describes the tools and techniques for identifying,
analyzing, responding to, and tracking project risks and includes ongoing
processes for managing, mitigating, and controlling risks.
Contingency Management Plan. Details the estimation and management of budget,
schedule, and scope contingency to manage risks and uncertainties.
PEP Component 5 – Acquisition Plans
Scope Acquisition Plan. Outlines plans for acquiring all project scope, including
approaches for remaining development, high-risk acquisitions, and site
considerations. It lists significant procurements with details and timelines,
ensuring each Work Breakdown Structure deliverable has a straightforward
acquisition approach, with child element plans noted at the parent level.
Systems Engineering Plan. Details the systems and subsystems with their technical
requirements and interfaces. It includes planning and design documentation
defining inspection and test regimes for facility commissioning and acceptance.
Quality Management Plan. Outlines a robust strategy for system integration,
testing, and commissioning activities for projects, as well as conditions for
acceptance.
Resource Management Plan. Outlines how human and non-labor resources
required for the project will be identified, acquired, allocated, managed, and
monitored.
PEP Component 6 – Environmental, Safety, and Health Management Plans
Environmental Protection Management Plan. Outlines the strategy to protect the
environment, emphasizing compliance with relevant laws, statues, and
regulations, during and after the project, including impact identification, mitigation
plans, and reporting.
Safety Management Plan. Details the worker safety and equipment protection
strategy, including regulations, hazard identification and mitigation, safety
facilities, documentation, reporting, and training.
Occupational Health Management Plan. Outlines steps to protect workers’ physical
and mental well-being, including stress management, work-life balance initiatives,
and access to mental health resources. Covers health regulations, assessment,
mitigation, monitoring, documentation, and reporting.
PEP Component 7 – Project Controls Plans
Project Management Control Plan. summarizes the main categories of project
control plans: Performance Measurement and Management, Change Control,
Project Documentation and Reporting, and Business and Financial Control. It
details how these plans will be utilized to manage the project and outlines the tools
(such as spreadsheets, databases, and commercial software products) that will be
Document Number
373
9.0 Appendices
Research Infrastructure Guide
employed for various Project Control functions.
Performance Measurement and Management Plan. Covers scope and quality
assessment, schedule progress, budget assessment, variance assessment,
forecasting, and performance management.
Change Control Plan. Outlines how the project manages, controls, and reports
changes to the Total Project Definition.
Segregation of Funding Plan. Establishes guidelines for allocating expenses to the
appropriate award when design, construction, or operations overlap. It outlines
procedures to ensure costs are appropriately expensed and clearly defines the
separation between funding sources.
PEP Component 8 – Cyberinfrastructure and Information Management Plans
Cyberinfrastructure Plan (CI Plan). Outlines the structured approach for planning,
implementing, and managing CI aspects of RI, covering the scientific mission, CI
elements and requirements, internal and external CI, facilities and resources, and
implementation and operational approaches.
Information Assurance Management Plan (IAMP). Details plans for managing
project information during construction, including policies, roles and
responsibilities, data security, response plans, and training.
Data Management Plan. Outlines the management of digital assets, including code,
software deployment, hardware, network architecture, and 3D designs.
Documentation Management Plan. Outlines the document management system
for retaining and retrieving essential project documentation, preventing
miscommunications, and ensuring future facility operators have any necessary
information.
Communications Management Plan. Details the approach to managing project
communications, including meetings, websites, newsletters, and blogs, focusing on
stakeholder interactions.
PEP Component 9 – Project Closeout Plans
Technical Closeout Plan. Describes how the project will complete all scope, verify
compliance, finalize transitions, and document deliverables to meet quality
criteria, and includes plans for scope completion and verification, transition to
operations, lessons learned, and archiving documentation.
Transition to Operations Plan (T2O Plan). Outlines the process for determining
operational readiness and transitioning deliverables from construction to
operations. It includes readiness reviews, demonstrations, verification of
deliverables, operations and maintenance manuals, staff training, and transfer of
title/ownership.
Administrative Closeout Plan. Details how the Awardee will complete
administrative activities, including contract closeouts, financial reconciliation,
Document Number
374
9.0 Appendices
Research Infrastructure Guide
resource transfers, and legal obligations, ensuring proper handling of funds and
release or transfer of resources.
Programmatic/Award Closeout Plan. Outlines processes for obtaining NSF
validation of project completion to close the award.
PEP Component 10 – Post Project Plans
Concept of Operations Plan (ConOps). Details high-level expectations for the postproject Operations Stage and will be finalized by the award time. It's only revised
if new issues or insights on operations and maintenance arise.
Concept of Disposition Plan. Outlines post-NSF funding divestment expectations,
maturing by the Construction Stage award. It is less detailed than the Disposition
Plan and only revised if new issues arise during project execution.
9.2.3
Operations Stage
Strategic Plan. Establishes the Science Support Program's long-term goals, objectives, and
activities. The plan should be revisited at least every five years and include a framework for
resource allocation and program evolution.
Asset Management Plan (AMP). Outlines a strategy to address Facility Condition
Assessment Report issues, specifying the timeline and resources needed. Steps include
prioritizing items based on urgency, aligning with the scientific mission, and developing a
management strategy. The plan identifies funding needs over the facility’s expected life and
lists deferred maintenance items.
Annual Work Plan (AWP). Explains the Science Support Program’s goals for the upcoming
performance period, detailing operations, maintenance, education, outreach, management
tasks, and deliverables. Includes objectives, milestones, targets, assumptions, and risks,
serving as a baseline for assessing planned versus completed activities. Submitted annually
for NSF review and approval, it informs the funding release and focuses on plans and
compliance with award terms.
9.2.4
Disposition Stage
Disposition Plan. A comprehensive plan to ensure transparency, accountability, and
successful RI disposition submitted to the NSF Program Office for review and approval. Key
topics include an overview, scope, roles and responsibilities, risk management, contracts
management, environmental impact analysis, and pension and healthcare responsibilities.
Document Number
375
Mid-scale RI Image Credit:
Ohio State University, Cornell
University, Georgia Tech Research
Corporation, Florida State University,
Woods Hole Oceanographic
Institution, The University of KENTUCKY
RESEARCH FOUNDATION, arizona State
University, NSF I-Corps Northeast
Hub, the University of Arkansas,
Georgia Institute of Technology, the
University of Michigan, University of
California-San Diego, and THE
university OF tENNESSEE, kNOXVILLE
| File Type | application/pdf |
| Subject | Research Infrastructure Guide |
| Author | Rockwell, Alison |
| File Modified | 2025-04-25 |
| File Created | 2025-04-25 |