document overview - national energy technology laboratory library/business/site... · web viewto...

ContentsDocument Overview........................................................................................................................................... 4

System Overview................................................................................................................................................ 4

Data Flow................................................................................................................................................................5

Announcements Management............................................................................................................................ 7

Announcement Planning & FRD Development........................................................................................................7Process Overview & Map....................................................................................................................................7Business Requirements.....................................................................................................................................10

Announcement Development...............................................................................................................................12Process Overview & Map..................................................................................................................................12Business Requirements.....................................................................................................................................14

Submissions..........................................................................................................................................................16Process Overview & Map..................................................................................................................................16Business Requirements.....................................................................................................................................19

Merit Review.........................................................................................................................................................22Process Overview & Map..................................................................................................................................22Business Requirements.....................................................................................................................................26

Selections..............................................................................................................................................................27Process Overview & Map..................................................................................................................................27Business Requirements.....................................................................................................................................30

Communications...................................................................................................................................................31Process Overview & Map..................................................................................................................................31Business Requirements.....................................................................................................................................34

DNFA Management...............................................................................................................................................35Process Overview & Map..................................................................................................................................35

Business Requirements.........................................................................................................................................37

Project Management........................................................................................................................................ 38

Lab Project Development......................................................................................................................................40Process Overview & Map..................................................................................................................................40Business Requirements.....................................................................................................................................42

Operational Activities............................................................................................................................................44Process Overview & Map..................................................................................................................................44Business Requirements.....................................................................................................................................46

Award Negotiation (Financial Assistance Projects)...............................................................................................47Process Overview & Map..................................................................................................................................47Business Requirments.......................................................................................................................................50

Project Monitoring................................................................................................................................................52Process Overview & Map..................................................................................................................................52Business Requirements.....................................................................................................................................54

Project Modifications............................................................................................................................................55Process Overview & Map..................................................................................................................................55Business Requirements.....................................................................................................................................57

Project Closeout....................................................................................................................................................58Process Overview & Map..................................................................................................................................58Business Requirements.....................................................................................................................................60

NEPA (National Environmental Policy Act)............................................................................................................62Process Overview & Map..................................................................................................................................62Business Requirements.....................................................................................................................................64

1 | P a g e

Portfolio Management...................................................................................................................................... 65

Reviewer Management.........................................................................................................................................65Process Overview & Map..................................................................................................................................65Business Requirements.....................................................................................................................................67

Peer Review..........................................................................................................................................................69Process Overview & Map..................................................................................................................................69Business Requirements.....................................................................................................................................71

Lab AOP Management & AOP Narratives..............................................................................................................73Process Overview & Map..................................................................................................................................73Business Requirements.....................................................................................................................................75

Portfolio Analysis...................................................................................................................................................76Process Overview.............................................................................................................................................76Business Requirements.....................................................................................................................................76

Budget Management........................................................................................................................................ 78

Budget Planning....................................................................................................................................................80Process Overview & Map..................................................................................................................................80Business Requirements.....................................................................................................................................84

Budget Structure Changes.....................................................................................................................................86Process Overview.............................................................................................................................................86Business Requirements.....................................................................................................................................86

Funding Controls – Budget Execution...................................................................................................................88Process Overview.............................................................................................................................................88Business Requirements.....................................................................................................................................88

Funds Authorization (Project Level Spend Plan)....................................................................................................89Process Overview.............................................................................................................................................89Business Requirements.....................................................................................................................................90

HQ Funding...........................................................................................................................................................92Process Overview.............................................................................................................................................92Business Requirements.....................................................................................................................................94

Funds Transfers & Deobligations...........................................................................................................................94Process Overview.............................................................................................................................................94Business Requirements.....................................................................................................................................96

Program Direction.................................................................................................................................................97Process Overview.............................................................................................................................................97Business Requirements.....................................................................................................................................97

Common Services.............................................................................................................................................. 98

Track Changes and Comment Capability...............................................................................................................98Process Overview.............................................................................................................................................98Business Requirements.....................................................................................................................................98

User Account Management..................................................................................................................................99Process Overview.............................................................................................................................................99Business Requirements...................................................................................................................................101

Alerts, Notifications, and Progress Indicators.....................................................................................................101Process Overview & Map................................................................................................................................101Business Requirements...................................................................................................................................104

Office Administration..........................................................................................................................................104Process Overview...........................................................................................................................................104Business Requirements...................................................................................................................................104

Approval Workflow Management.......................................................................................................................105Process Overview & Map................................................................................................................................105

2 | P a g e

Business Requirements...................................................................................................................................107Helpdesk.............................................................................................................................................................107

Process Overview...........................................................................................................................................107Business Requirements...................................................................................................................................107

Help/FAQ.............................................................................................................................................................108Process Overview...........................................................................................................................................108Business Requirements...................................................................................................................................108

Portal...................................................................................................................................................................108Process Overview...........................................................................................................................................109Business Requirements...................................................................................................................................109

Document Management.....................................................................................................................................109Process Overview...........................................................................................................................................109Business Requirements...................................................................................................................................109

Information Management...................................................................................................................................110Process Overview...........................................................................................................................................110Business Requirements...................................................................................................................................110

Definitions...................................................................................................................................................... 111

3 | P a g e

Document OverviewThe purpose of this document is to provide a general representation of the scope, size and complexity of the EPIC system requirements. This document only includes a limited subset of the full system requirements. For each function, the requirements contain a process overview, process map (if available), and a small set of business requirements. The Government will deliver a full set of requirements and use cases to the contract awardee at the project kick-off meeting. Additional details on requirements can be obtained through the requirements webinar series available within the reading room. The webinars were used to walk EERE stakeholders through a set of conceptual wireframes of each system module to visually explain the system requirements.

System OverviewThe Department of Energy’s Office of Energy Efficiency & Renewable Energy Office has a requirement to build an integrated enterprise management system supporting the following business functions:

Announcements Management Project Management Portfolio Management Budget Planning & Execution

Additionally, the system will provide a series of common services –shared services that will be available across all business modules. The purpose of the EPIC project is to improve EERE's operational effectiveness and efficiency by providing an information system supporting improved execution of EERE’s business processes for managing programs, projects, and data. This will be achieved through the development of a system that automates the day-to-day activities required to develop and maintain EERE’s project portfolio while also streamlining the associated business process and eliminating redundant data entry. The figure below summarizes the various business processes to be automated and the data integration points that will be captured between processes.

Data FlowThe data flow between modules is primarily centered on project activities. Projects are typically originated within the Announcements module where proposals are solicited for new project activities. Selected proposals/applications are then imported into the project management module, where the project is negotiated, monitored and closed out. Project management procedures vary dependent on the type of project. Data from both the announcements module and project management module is integrated with the budget planning and execution module to facilitate budget formulation activities and funds disbursement during budget execution. The portfolio management module is used to provide an aggregate view of project data and to facilitate analysis and evaluation activities.

4 | P a g e

5 | P a g e

High Level Process Flow for Project DataLa

b Pr

ojec

ts/O

pera

tiona

l Acti

vitie

sFA

Pro

ject

sAn

noun

cem

ents

Project Origination Project Management

Ann5

Submission

Ann2

Develop FRD(only for FOA/

NOTA)

Ann3

Announcement Development

Initiate

Maintain Consistency reapprove FRD (if nec)

Ann5

Merit Review

Ann6

Selections

Lab AFPRecipient

PM3

Project Monitoring

Bud(TBD)___

Budget Planning

Bud(TBD)_

Budget Execution/PLSP

FOA/NOTAonly

PM3.2

Change Control

Only in the case of a lab call

PM3.1

Recipient Reporting

PM5

Project Close Out

PM2

Award Negotiation

PM3

Project Monitoring

PM3.2

Change Control

PM3.1

Recipient Reporting

PM5

Project Close Out

PM4

Award Modification

Bud(TBD)___


Bud(TBD)___


Bud(TBD)__


Initiate Project (OA or MR Exempt)

Bud(TBD)___


Non-lab AFPRecipient

PR

NEPAPR

Bud(TBD)__


PM1

Create New Project

Ann1

Announcement Detail

Development

Rev. MgmtNEPA Comms

FOA, RFI,NOI only

Comms

FOA, RFI,NOI only

Announcements ManagementThe announcements module is used to support project origination activities. An announcement is considered a public announcement from the Government in support of a potential funding opportunity. EERE releases announcements to either make known our intent to fund an activity or to collect information or proposals/applications related to the activity. These announcements could be in support of new financial assistance activities (grants and cooperative agreements) or new activities with our national laboratory partners (lab calls).

EERE begins planning for potential announcements as part of the budget formulation process (at least two years in advance), where different topics for research investment are considered as part of various budget scenarios. Once the final budget is appropriated, the announcement content and funding amount will be refined. The Announcements Management Module is intended to support the full scope of Announcement Management activities from planning, announcement development and publishing, submissions, merit review, and selections for Funding Opportunity Announcements (FOAs), Lab Calls, Notices of Intent (NOIs), Requests for Information (RFIs), and Notices of Opportunity for Technical Assistance (NOTAs). Selected proposals/applications from the Announcement Management module will flow into the Project Management Module.

The following section provides the process overview and high level requirements by function.

Announcement Planning & FRD DevelopmentProcess Overview & MapAnnouncement Planning will be tightly integrated with the budget planning process while minimizing duplicative data entry. Additionally the planning process ensures that the planned announcements can be easily tracked and all members of the announcement team is aware of the approved announcements for the fiscal year.

In the planning phase, announcement managers will be able to enter basic detail about the upcoming announcements including title, description, proposed topic areas, and estimated funding. Once the initial plan is created, FOAs & Labs Calls can be associated with multiple budget planning scenarios within the budget module. These scenarios (within the budget module) will allow the Program Budget Lead to plan funding levels for each announcement within the various budget scenarios. Once a budget scenario is approved, the announcement is updated with the approved budget amount and is added to the annual FOA list.

A planning document, called the FOA Requirements Document (FRD) must be drafted and approved prior to publishing a FOA, and can also be required prior to publishing a NOTA. The purpose of the FRD is to enable effective planning for FOAs, the evaluation and selection of applications, the negotiation of awards, and the management of resulting projects. Additionally, the FRD enables early engagement with, and advance approval from, responsible executives and stakeholders within EERE. The announcement manager can begin drafting the FRD in advance of the announcement approval, but will be restricted from initiating the FRD approval until the FOA has been approved as part of the Annual

6 | P a g e

FOA list. The FRD wizard is intended to help walk the user through the various steps of completing the FRD by automating the FRD forms. The system will allow the announcement manager to easily select deviations from the standard EERE or their Office specific processes. Furthermore, the system will automatically identify if the proposed deviations require additional documentation and will allow the announcement manager to complete the required documentation e.g. Cost Share Waivers and DREs within the system --auto populating any information that has been entered in previous steps in the process. Within the system, the Announcement Manager will be able to route the FRD for review, concurrence, and final approval. All changes to the FRD will be tracked throughout the approval process. Once approved, the information captured in the FRD will pre-populate the FOA, eliminating duplicative data entry and redundancy.

7 | P a g e

8 | P a g e

Business Requirements ID Requirement Description

1. The system shall allow the Financial Assistance Team Lead to assign an announcement to a GMS/CS.

2. The system shall allow the Financial Assistance Team Lead to indicate if an announcement has been flagged for business clearance.

3. The system shall, if the announcement type is a Lab Call, generate a unique number for each lab call announcement.

4. The system shall allow the user to create Announcements of the following types: FOA Lab Call RFI NOI NOTA

5. The system shall, if the user attempts to create a FOA or Lab Call after the Annual FOA List is created, require the user to select from the following list of justifications:

EERE Management Direction DOE Management Direction Congressional Direction Presidential Direction Combining Existing Concepts

6. The system shall allow the Announcement Manager to copy information from a single existing Announcement to create a new Announcement

7. The system shall allow the Announcement Manager to cancel an Announcement up until the announcement is published

8. The system shall capture the following data as part of the announcement details Anticipated Year of Publishing Servicing Office Title Description Related Announcements Announcement POC (Announcement Manager, Announcement Manager Backup

POC) Coordination Office, Coordinating Office/Agency POC Funding and Topic Area Mortgage Information Detailed Funding Information TRLs EERE Crosscuts High Priority Activities Project Types

9. The system shall collect the following funding related information for the announcement:

Cost Share Percentage (%)

Anticipated Total Amount of Cost Share ($)

Anticipated funding for evaluation and selection ($)

9 | P a g e

Anticipated Total Amount of Funding (calculated)

10. The system shall calculate the Anticipated Total Amount of Federal Funding to be the sum of the Planned Funding Total (Max) across all topic areas (if planned by topic area)

11. The system shall allow the announcement manager to create topic areas within the announcement.

12. The system shall associate the following data with a Topic Area: Title Lead Description Funding (B&R Code, Appropriation Year, Minimum DOE Amount, Maximum DOE

Amount) Expected number of awards (min/max) Expected Duration

13. The system shall allow the announcement manager to associate each announcement with a crosscut or high priority activity and the following elements:

Title % Allocation

14. The system shall all the announcement manager to route the FRD for approval and concurrence.

10 | P a g e

Announcement DevelopmentProcess Overview & MapIn the Announcement Development phase, the announcement manager is responsible for expanding on the details originally entered in announcement planning and preparing the announcement for publishing. EPIC will be used to publish all of EERE’s Announcements, though the process for creating the announcement will vary by announcement type. For FOAs and NOIs, the system will generate the full FOA (formatted word document) based on EERE’s standard template (Refer to Grants.gov to review EERE FOA formats). Since there is no standard template for Lab Calls or NOTAs, these announcements will be created and approved off-line, and will be uploaded to the system for publication. RFIs will also be created and approved off-line, as these announcements are rarely used.

Creating the FOA in EPIC will be simplified because any information captured in the FRD or in the basic announcement details will be auto-populated in announcement development. The announcement manager is able to make changes to the announcement in this phase, but the system will prompt them if that change warrants an FRD Modification.

During announcement development, announcement managers are in constant communication with the Communications Office to ensure that there are no issues that would cause the announcement to be put on hold, and to finalize any public announcements that may occur upon announcement publication. Two forms, the Comms 130.1 and 130.2 are used to facilitate discussion between the program offices and the Communications Office. These forms are completed at the beginning of announcement development, and are revised and finalized throughout the phase.

Once the announcement manager has made all edits, he/she can route the full announcement for review and approval. The system will allow concurrent reviews and will facilitate the review of edits and comments through EPIC’s online comment and track-changes features. The system will support the creation of a red-lined version and a final version of the FOA document. Once the announcement is reviewed and approved, the Communications Office must initiate a sensitivity check to ensure that all involved DOE offices explicitly approve the announcement to be published. The result of the sensitivity check is a “greenlight” to publish the announcement. EPIC will automatically track release dates and other communications-related activities, including the automation of the green-light process. Information, including submission deadlines, entered during the FRD Development and Announcement Development phases will be made accessible to applicants.

11 | P a g e

12 | P a g e

Business RequirementsID Requirement Description

1. The system shall, if the announcement type is FOA, allow the user to enter the following details of the of the announcement:

Overview Communications Questionnaire FOA Table of Contents Funding Opportunity Description Award Information Eligibility Information Application and Submission Information Applications Review Information Award Administration Information Questions and Agency Contacts Other Information Executive Summary Appendices Access CI Notification Merit Review Prep FRD Modification (only appears if an FRD Modification required) Approvals Publish

2. The system shall pre-populate the following fields from the announcement object: Announcement Title Announcement number

3. The system shall populate the following fields from the FRD and allow the Announcement Manager to edit:

The FOA Issue Date Submission Deadline for Full Applications Expected Date for EERE Selection Notifications

4. The system shall, if the announcement type is a FOA, require the announcement manager to complete the Comms Questionnaire 130.1 and 130.2.

5. The system shall, if the announcement type is a NOTA, allow the announcement manager to complete both the Comms Questionnaire 130.1 and 130.2, but only require the Comms Questionnaire 130.2 to be completed.

6. The system shall, if the announcement type is NOTA, allow the announcement manager to upload the announcement.

7. The system shall, if the announcement is a Lab Call, allow the announcement manager to upload an announcement.

8. The system shall allow the announcement manager to request a greenlight from Communications to publish an Announcement.

9. The system shall, once the Announcement is approved, the greenlight has been received by Communications, and at least 72 hours have passed since the CI Congressional Notification has been sent (if applicable), allow the Contracting Officer to publish the Announcement.

10. The system shall, if publishing an RFI, allow the Announcement Manager to upload the RFI.11. The system shall, once the following has been completed, allow the Contracting Officer to

13 | P a g e

publish the NOI or RFI: The Announcement is approved - if the Announcement is an NOI The Announcement is uploaded - if the Announcement is an RFI At least 24 hours have passed since the Sensitivity Check was started and the

Announcement has not been marked sensitive12. The system shall allow the Announcement Manager to route the Announcement for

approval and concurrence before publishing.

14 | P a g e

SubmissionsProcess Overview & MapOnce an announcement is published, applicants will be able to review open opportunities and submit and track applications in EPIC. Most EERE opportunities including FOAs, NOTAs, RFIs, and NOIs will be available for the public to view without logging into the system. However, to apply to these opportunities, an applicant must first register in the system. Lab Calls will only be viewable by lab organizations, and therefore require the user to be logged into the system to see these opportunities. Additionally, Lab Calls may have restricted eligibility, meaning that only certain labs can apply to the lab call opportunities or to certain topics within the lab call. In this case, only eligible labs will be able to view the Lab Call.

Once the applicant has chosen to apply to a specific announcement, the system will walk them through the application submission requirements. In many cases, the system standardizes the submission process based on the requirements entered during announcement development. To help applicants track their application, the system will also provide statuses for each application that has been started. The system will also provide applicants the ability to submit announcement specific questions to EERE, and allow grants management specialists to post answers to these questions, which are viewable by the public.

Depending on the announcement, there can be various phases of the submission process. The first phase that may be used is the Letter of Intent, which is an optional requirement for a FOA or NOTA that requires the applicant to provide basic information about their organization and application. EERE uses the Letter of Intent submissions to predict the number of reviewers needed for the Concept Paper and Full Application phases. A Concept Paper may also be required for FOAs, NOTAs, and Lab Calls. The Concept Paper is a project summary that describes the proposed project. The applicant’s purpose in developing this submission is to capture the interest of EERE and demonstrate that the idea they are proposing is worthy of further consideration. EERE provides feedback on the Concept Papers, which helps the applicants develop more competitive applications and determine whether to submit a Full Application to the opportunity. The final phase of the submission process is the full application, which requires the applicant to expand upon the Concept Paper and provide a comprehensive Statement of Project Objectives and Budget, which will become part of the award if the applicant is selected for funding.

The information that is provided by the applicants during Submissions is pulled into the Merit Review module, so that reviewers are able to access the submission documents and complete their review. Additionally, the information submitted by applicants is collected in a format that ensures that if the applicant is selected, the system can easily populate a draft project record to begin negotiations eliminating duplicate data entry.

15 | P a g e

16 | P a g e

17 | P a g e


1. The system shall require an unregistered user to request access before he/she can apply to an open opportunity.

2. The system shall allow the Applicant to view open opportunities without a login.3. The system shall restrict access to view lab calls to registered lab users.4. The system shall, if an Applicant is not logged into the system, require the user to login

before they can start an application.5. The system shall allow the applicant to apply and submit an application to open

opportunities.6. The system shall allow the applicant to view all Q&As related to the opportunity.7. The system shall allow the applicant to submit announcement- specific questions to EERE.8. The system shall allow the GMS/CO to draft and publish responses to public Q&As.9. The system shall record the following “Application Status”:

Submission Statuses:

Submitted (once the application has been submitted)

Not Submitted (if the application has been started, but not submitted)

Start Application (If the application has not been started)

Review Statuses (once the submission date has passed):

Concept Papers: Under Review, Ineligible (pulled from Merit Review), Encouraged (pulled from Merit Review), or Discourage (pulled from Merit Review)

Full Applications: Under Review, Ineligible (pulled from Merit Review), Reply to Reviewer Comments Period Open

Replies to Reviewer Comments: If a reply has been submitted: Under Review or Ineligible. If a reply has not been submitted: N/A

10. The system shall, if the submission type is Letter of Intent, require the Applicant to provide the following:

Applicant

Project Title

Percent of Effort Contributed by Lead Organization

Topic Area/Technical Area of Interest (if topic areas are applicable per the Announcement object)

Specify if the application has been previously submitted to EERE

Technical Point of Contact

Team Members

Key Participants

11. The system shall display the following steps as part of the Concept Paper Submission wizard:

18 | P a g e

General Details

Contact Information

Team Members

Funds and Costs

Upload Documents

Review and Submit

12. The system shall display the following steps as part of the Full Application Submission wizard:

General Details

Contact Information

Team Members

SF-424

SOPO

Budget Justification

Field Work Proposal (FWP), if labs are participating in the project

Upload Documents

Review and Submit

13. The system shall require the following information for the Statement of Project Objectives:

Enter text into the Technical Scope Summary and Project Objectives textboxes

Enter the following information for at least one budget period in the “Work Plan” section: Task summary for at least one task and milestone information for at least one task

Enter the details for at least one deliverable in the “Deliverables” section.

14. The system shall require the user to enter the following elements of the budget justification:

Personnel

Fringe Benefits

Travel

Equipment

Supplies

Contractual

Construction

Other Direct Costs

19 | P a g e

Indirect Charges

SF-424A, Budget Information

20 | P a g e

Merit ReviewProcess Overview & MapAfter a Letter of Intent, Concept Paper, or Full Application is submitted, it is first reviewed for eligibility, ensuring that the application was submitted by the deadline stated in the announcement, that all required documents were submitted, and that the entity that submitted the application was eligible to apply to the opportunity. Letters are sent through the system to any applicants whose submission was found to be ineligible, preventing the application from moving forward in the application process.

After the eligibility review is complete, the Concept Paper and Full Application submissions are merit reviewed through the Merit Review module. Concept Papers are reviewed to determine if EERE is interested in the proposed concept. The result of the review is either an “encourage” or “discourage” determination. If an applicant is “encouraged”, EERE is conveying that it is interested in seeing a full application. A “discourage” determination does not mean that the applicant cannot submit a full application; however, by discouraging the submission, EERE is conveying its lack of programmatic interest in the proposed project in an effort to save the applicant the time and expense of preparing an application that is unlikely to be selected for award. Full Applications are reviewed to determine if the proposal has the technical merit to be selected for award negotiations, which results in funding.

Information entered into EPIC during the FRD and announcement development stages will pre-populate the merit review section, so that reviewers understand the review criteria and scoring methodology for the applications. Within the reviewer management module, Announcement Managers will be able to identify reviewers, check reviewer availability, select reviewers, collect nondisclosure agreements (NDAs) and conflict of interest (COI) forms, and assign reviewers to applications through the module. Reviewers will then have access to the application documents for review, and will provide scores and comments for their assigned applications.

After the independent reviewers have completed their review, the Federal Consensus Board, whose primary responsibility is to determine which applications are technically acceptable, convenes. They review the findings of the independent reviewers, reach consensus as to the appropriate score for each application, and ultimately recommend selection to the Selection Official. Once this is complete, a final Merit Review report (called a Merit Review Advisory Report for FOAs and NOTAs), is created in the system to capture the Merit Review process, and the results of the review. This report is used to pre-populate the Selection Statement, which is finalized in Selections.

21 | P a g e

22 | P a g e

23 | P a g e


1. The system shall provide the Announcement Manager and Announcement Contract Support the ability to create a record of eligibility review information for letters of intent, concept papers, full Applications, and replies to reviewer comments.

2. The system shall provide the GMS/CS the ability to send the ‘Non-Eligibility Notification Letter,’ for any letter of intent, concept paper, full application, or reply that was deemed ineligible.

3. The system shall provide Announcement Managers the ability to provide merit review setup information for the concept paper and full application.

4. The system shall allow users to search for Reviewers by expertise, name, or keyword.5. The system shall allow the Announcements Manager to confirm the availability of the

concept paper and full application reviewers.6. The system shall provide the ability for reviewers to respond to availability requests, and

indicate if they are available on specific dates.

7. The system shall provide Announcement Managers the ability to finalize the reviewer roster list.

8. The system shall provide Announcement Managers, Announcement Contract Support, the Selection Official, the GMS/CS, the Contracting Office, Legal Counsel, Internal Reviewers, and Federal Consensus Board the ability to view a Blanket Conflict of Interest and Nondisclosure Acknowledgement (COI/NDA).

9. The system shall provide the internal and external reviewers the ability to assign an overall score for concept papers and full applications, according to the default scoring specified during Announcement Development.

10.The system shall provide internal and external reviewers the ability to input or upload scores and comments for the concept papers and full applications they are assigned to review.

11.The system shall provide the Announcement Manager the ability to send the encourage/discourage notification for concept papers to the technical and administrative points of contact designated by the Applicant.

12.The system shall provide the Announcement Manager, Announcement Contract Support, Federal Consensus Board, and internal and external reviewers the ability to view scores for full applications.

13.The system provide the Federal Consensus Board with the ability to assign a consensus rating by application and criteria.

14.The system shall provide Announcement Managers with the ability to create an MRAR from the MRAR Template.

24 | P a g e

SelectionsProcess Overview & MapThe selections process refers to the process by which the Selection Official identifies projects to receive Federal funding and applicants are notified of selection for award negotiations. Information from Merit Review is pulled over to pre-populate the Selection Statement, which is the document that records the Selection Official’s decisions on which applications are selected for award negotiations, as alternates, or are not selected. Once the Selection Official’s decisions are populated, the announcement manager routes the Selection Statement for review and approval. Just as in Announcement Development, the system accommodates concurrent reviews and facilitates the review of edits and comments.

Once the Selection Statement is signed, the grants management specialist and Contracting Officer draft selection notification letters in the system. These letters notify applicants of the Selection Official’s determinations. The letters are also reviewed and approved in EPIC.

Prior to notifying applicants of the Selection Official determinations, the EERE Comms 130.1 and 130.2 must be updated to include selection information. Throughout the selections process, the announcement manager and the Communications Office work to finalize any applicable public announcements that will be made to announcement the selections. Additionally, the Communications Office must initiate a sensitivity check to ensure that all DOE offices approve the selection announcement, and that there are not any sensitivities that should delay the announcement. The result of the sensitivity check is another “greenlight”, to announce selections. After a greenlight has been received, the grants management specialist releases the Selection Notification Letters to all applicants of the announcement through the system.

Once the selections process has concluded, Application materials and applicant information for selected applicants are used to populate the Project Management module.

25 | P a g e

26 | P a g e

27 | P a g e


1. The system shall pre-populate the Selection Statement information with the information from the MRAR created during the Merit Review phase.

2. The system shall allow the Announcement Manager and Selection Official to edit the Federal Share, Non-Federal Cost Share, Total Cost, Program Policy Factors Applied, Negotiation Strategy, and Selection Official Decision on the Selection Statement.

3. The system shall allow the Announcement Manager to initiate the review/approval workflow for the Selection Statement.

4. The system shall allow the Announcement Manager to edit the EERE 130.2 if the EERE 130.2 was completed during the Announcement Development stage.

5. The system shall initially populate the 130.1 information from the 130.1 completed during Announcement Development, and allow edits.

6. The system shall allow the Announcement Manager to edit the EERE 130.2, completed during Announcement Development.

7. The system shall allow the GMS/CS to edit the template language for the selection notification letters.

8. The system shall allow Selection Letters to be routed for review and approval.

9. The system shall only allow the GMS/CS to send Selection Letters once a greenlight has been received to send the Selection Notification Letters, and at least 72 hours have passed since the 301 Notification was sent.

10. The system shall create the award record in Project Management with all application documents when the Selection Notification Letters are sent.

28 | P a g e

CommunicationsProcess Overview & MapWithin EPIC, the Communications Module will allow Communications staff to review Communications materials, including the Comms Questionnaire 130.1, Comms Questionnaire 130.2, and draft Public Announcements completed by the Announcement Manager during Announcement Development and Selections. Additionally, it allows the Communications staff to review information related to Announcements and begin the sensitivity check for announcement publication, congressional notification, and selection notification, as well as provide necessary greenlights. Communications staff will also be able to provide and review comments regarding communication materials with the Announcement Manager and/or Technology Office Communications Lead through this module.

29 | P a g e

30 | P a g e

31 | P a g e


1. The system shall allow the EERE Comms POC or Comms Lead to view all announcements and only those announcements awaiting a greenlight/sensitivity check.

2. The system shall auto populate the Comms Questionnaire 130.1 and 130.2 with the information that the Announcement Manager completed during the Announcement Development stage or Selections stage, but is editable.

3. The system shall allow the EERE Comms POC or Comms Lead to mark an item as sensitive and place the announcement “On Hold.”

4. The system shall, by default, display the “Sensitivity Check Pending” status for RFIs, NOIs, FOAs, NOTAs, and Selection Notifications.

5. The system shall allow the EERE Comms POC or Comms Lead to view documents associated with an item, add comments, view comments, and archive an item.

6. The system shall allow the EERE Comms POC to provide a greenlight for Congressional Notifications and Announcements.

7. The system shall allow the EERE Comms POC to start sensitivity checks.

8. The system shall, if the announcement is an NOI or RFI, imply the greenlight if the EERE Comms POC or Comms Lead does not place the announcement on hold within 24 hours after the sensitivity check has been initiated.

32 | P a g e

DNFA ManagementProcess Overview & MapThe Determination of Non-Competitive Financial Assistance (DNFA) Module will allow the on-boarding of a project awarded on a non-competitive basis. Applicants submit non-competitive applications for new awards, as well as to existing projects. If the application is submitted for additional scope and funding to an existing award, the process will begin in the Project Management module. The project lead receives the application, and processes a change request (CR) to add the additional scope/funding to the award. Once the CR is concurred upon by the grants management specialist, the DNFA Management module is populated with a record to process the documentation necessary to add the scope/funding, resulting in a DNFA. If the application is submitted for a new award, the process begins in the DNFA Management module. The project lead will create a DNFA record, adding project details from the application.

Although a DNFA does not begin with an announcement, the Merit Review and Selection processes are similar to a project that is selected competitively. The application is merit reviewed to ensure that it is technically sound, and if the project is approved, a Selection Statement is processed and signed by the Selection Official. As with announcements, a greenlight is required by Communications prior to announcing selections. There are two additional documents that result from a DNFA: the DNFA template, which documents all of the general details of the DNFA including the Merit Review results, and the Decision Memo, which is approval from the Assistant Secretary to proceed with the non-competitive award.

33 | P a g e

34 | P a g e


1. The system shall allow the EERE Project Lead to onboard a DNFA project that has been submitted to DOE, but not in response to an open opportunity.

2. The system shall allow the EERE Project Lead to create a DNFA for a new project, or for an existing project.

3. The system shall not associate a DNFA with a FOA, unsolicited proposal, or sole source object.

4. The system shall follow the following steps to create a DNFA:

DNFA Details

DNFA Funds

Justification

Upload5. The system shall allow the user to upload the submissions.

6. The system shall, if a DNFA is created, support a modified merit review of the proposed project.

7. The system shall, if the application is a DNFA, allow the selection official to view the Federal Consensus Board recommendation

8. The system shall, if a DNFA is created, support a modified Selection Statement.

9. The system shall provide ability to produce the following documents for DNFA selections:

Selection Statement

DNFA Template

Decision Memo

35 | P a g e

Project Management The Project Management module and will support the full life-cycle of a project, from planning to closeout, for Lab, Financial Assistance (FA) awards, and operational activities. The bulk of project management capabilities will support the processes that occur after a project is selected for award.

The Project Management module supports the full life cycle of project management activities for lab and financial assistance projects including project negotiations, monitoring, modifications to the project baseline if needed, and close out of projects. This is accomplished through the following steps:

Collaborative negotiation and finalization of the project baseline for scope, schedule, costs, and other aspects specific to monitoring each type of project (Lab and FA projects). This step is completed following the project/award selection process in the Announcements module.

Monitoring project progress on tasks/subtasks/milestones and reviewing reports and deliverables as they are submitted, according to the predetermined reporting checklist and deliverables schedule. This adheres closely to EERE’s Active Project Management (APM) guidelines (Financial Assistance only)

Controlling changes to project baseline through various processes to ensure integrity of project baseline, while also allowing project owners to make edits and get approval through a streamlined process.

Closing out projects and ensuring accountability of all reports, deliverables, physical property, intellectual property (IP), and finances in a timely manner.

36 | P a g e

37 | P a g e

Lab Project Development Process Overview & MapThe Lab Project Development supports the negotiation of lab projects or the modification of scope, schedule, or budget of an existing Lab project. There are two methods of project onboarding: (1) onboarding a project resulting from a Lab Call or FOA; and, in a small number of cases, (2) onboarding a project directly into the Project Management module.

Onboarding Lab Projects from Lab Calls or FOAs: The process starts with creating and posting a Lab Call or a FOA. National Laboratories will submit an application in response to the Lab Call or FOA. The Announcement Manager will then initiate a Merit Review of the Lab’s submission. The Announcement Manager will then select Lab Projects in the Announcements module. The system will carry data from the selections section (within the Announcements module) into the PM module as a new project record. The EERE Project Lead and the Lab Project Lead will enter negotiations and finalize the project. After project finalization, the project will be routed for concurrence and approval.

Onboarding Lab Projects Directly: The process starts when the EERE Project Lead creates an exempt project directly in the system. After entering required project information, the EERE Project Lead and the Lab Project Lead will enter negotiations and finalize the project. After project finalization, the project will be routed for concurrence and approval.

Changing an Existing Lab Project: The process starts when the Lab Project Lead identifies changes that are needed for an existing Lab project. The Lab Project Lead will initiate a change request (CR). The Lab Project lead and the EERE Project lead will enter negotiations and finalize the CR. The CR will then be routed for approval.

In each case, the approval chain will depend on project funding thresholds. Lab projects with funding of $2M or more will require approval from the EERE Office Director and the Associate Lab Director (ALD); whereas, Lab projects with funding less than $2M will require only the EERE Project Lead approval. The Program Manager and ALD will approve the project as part of approving the overall AOP Document. Requirements on the final AOP document are part of the Portfolio Management Module and can be found in Lab AOP Management & AOP Narratives.

38 | P a g e

39 | P a g e

Business Requirements# Requirements Description

1. The system shall, if the selectee is a national lab, automatically create the Lab project in the Project Management module, based on application/selections from the Announcement module.

2. The system shall, if the work category is AOP Direct, allow users to directly onboard new project in the project management module.

3. The system shall allow the Lab and HQ users to send the project back and forth for editing during negotiations/planning. The system shall automatically update the Project Status when the project is sent back and forth, starting with the default status of "Planning at Lab.”

4. The system shall allow Overtarget Projects to retain the planning stage they are in and can be edited and saved. If funding becomes available, an overtarget project can be “submitted for approval” by clicking the button in at the bottom of the General Information tab. A list of Overtarget projects can be accessed from the main project landing page.

5. The system shall display the following overview information about Lab Projects:

Funding Profile Lab Consortium Partners Project Overview (multi-year) Project Objectives (multi-year) Annual Overview EERE Crosscuts High Priority Areas T2M Plan Associations

A fully negotiated project will have all data collected as defined in a full project report .

6. The system shall allow the user to view the following Lab Project financial information for the lead Lab as well each partner Lab:

Project Financials Project Cost Plan Planned Encumbered Balance Project Cost Breakdown Minimum Monthly Funding Needs

7. The system shall allow Lab users that are part of a consortia project to edit their own Financials, Project Plan, and Impacts for the project.

8. The system shall allow Lead Labs to view their financial information as well as the financial information associated with any partner Lab or consortia.

9. The system shall allow the project team to enter the project cost plan by month (by

40 | P a g e

https://eeredocman.ee.doe.gov/offices/EE-64/projects/REI/ITSIRequirements/_layouts/WordViewer.aspx?id=/offices/EE-64/projects/REI/ITSIRequirements/Shared%20Documents/Requirements%20Documentation/Sample%20AOP%20Project%20Report.docx&Source=https%3A%2F%2Feeredocman.ee.doe.gov%2Foffices%2FEE-64%2Fprojects%2FREI%2FITSIRequirements%2FSitePages%2FHome.aspx%3FRootFolder%3D%252Foffices%252FEE%252D64%252Fprojects%252FREI%252FITSIRequirements%252FShared%2520Documents%252FRequirements%2520Documentation%26FolderCTID%3D0x0120003D3AF320833F494C88A67DD5889FE8B5%26View%3D%7BBA815683-4675-461D-BC4A-1C88BF888DFB%7D&DefaultItemOpen=1

https://eeredocman.ee.doe.gov/offices/EE-64/projects/REI/ITSIRequirements/_layouts/WordViewer.aspx?id=/offices/EE-64/projects/REI/ITSIRequirements/Shared%20Documents/Requirements%20Documentation/Sample%20AOP%20Project%20Report.docx&Source=https%3A%2F%2Feeredocman.ee.doe.gov%2Foffices%2FEE-64%2Fprojects%2FREI%2FITSIRequirements%2FSitePages%2FHome.aspx%3FRootFolder%3D%252Foffices%252FEE%252D64%252Fprojects%252FREI%252FITSIRequirements%252FShared%2520Documents%252FRequirements%2520Documentation%26FolderCTID%3D0x0120003D3AF320833F494C88A67DD5889FE8B5%26View%3D%7BBA815683-4675-461D-BC4A-1C88BF888DFB%7D&DefaultItemOpen=1

# Requirements Description

B&R code). Cost plan shall include the following fields:

B&R Code Appropriation Year Expense Type Fiscal Months 1-12 (Oct-September) Annual Cost Total (calculated field; sum of monthly costs)

10. The system shall allow the users to track project encumbered balance to help for planning. Planned Encumbered Balance will have the following fields:

Funding Type Fiscal Year Encumbered Balance Fiscal Months 1-12 (Oct-September) Fiscal Year+1 Planned Beg Encumbrances

11. The system shall allow the user to create, edit, and delete the following Tasks information about the Lab Project:

Item Type Item Number (system generated) Title Description Planned Fiscal Year Costs Planned Start Planned End Team Members

12. The system shall allow the user to create, edit, and delete the following Milestones information about the Lab Project:

Item Type Item Number (system generated) Title Description Criteria Planned End Date Contributing Team Members

13. The system shall, when a project is indicated as “over target,” create a new project proposal record called “over target proposal” based on the original base project record.

14. The system shall allow the EERE users to determine the required reporting elements.

Operational ActivitiesProcess Overview & MapEERE funds and manages other types of projects in addition to the conventional Lab RDD&D Projects and FA Awards. These projects are typically operational in nature and are not a result of

41 | P a g e

a FOA or Lab Call. Because of this, it is necessary to add these projects directly in the Project Management module. Examples of these types of projects include:

Lab Operational Activities: Lab operational activities cover a wide range of projects and are intended to enable, support and complement EERE’s RDD&D efforts. These activities can be performed at the National Laboratories (FFRDCs). Interagency Agreements: Interagency agreements are activities that EERE is funding at other agencies and are also on boarded directly into the project monitoring section of THE SYSTEM. Support Service Contracts: These contracts are used to provide management support to EERE offices. While the scope of the support service contracts can be large and diverse, projects will track the scope of specific tasks that are funded through these contracts.

All of these projects are negotiated between EERE and the recipient during the planning phase and are then monitored, modified, reported on, and closed out in a manner similar to Lab AOP projects. If an organization is not an FFRDC then integration with the System for Award Management (SAM) is critical to allow users to develop a Contract or Task since one would not already exist for this recipient.

42 | P a g e

43 | P a g e

Business Requirements# Description

1. The system shall allow EERE users to create new operational activities within the system

2. The system shall restrict the work category selections to the following if the AFP Recipient is selected to be a national lab (including NETL).

Lab Direct (R,D&D) Operational Activity

3. The system shall recognize the work as non-FFRDC operational activity, if the AFP Recipient is NETL and work category is Operational Activity.

4. The system shall, if the recipient is an FFRDC, will flow the same flow as for Lab Project Development

5. The system shall, if the recipient is an FFRDC, display the associated national laboratory as the prime recipient if a lab AFP recipient was selected.

6. The system shall, if the recipient is an FFRDC, generate a unique project number using the lab numbering method if the AFP recipient is a national laboratory (NL followed by 8 digit number).

7. The system shall, if the recipient is an FFRDC, require the user to complete the following data categories when the work category is operational activities:

Project Overview Project Plan Financials Impacts Assessments

8. The system shall, if the recipient is not an FFRDC, require users to select the recipient using a look up the recipient from a list of recipients in STRIPES if the recipient is not an FFRDC.

9. The system shall, if the recipient is not an FFRDC, allow the users to expand the recipient search to all organizations in SAMS.

10. The system shall, if the recipient is not an FFRDC, require the user to complete the following fields when creating a new project.

Project Title Project Start and End Dates WBS Number Recipient Name(s) (organization) EERE Project Lead Project Overview

44 | P a g e

# Description

11. The system shall, if the recipient is not an FFRDC, generate a unique project number beginning with the letters HQ followed by 8 numbers.

12. The system shall generate a unique project number beginning with the letters HQ followed by 8 numbers If the AFP recipient is a Washington HQ, GO, or NETL and the work category is operational activity.

13. The system shall, if the recipient is not an FFRDC, prepopulate the start and end dates based on the award data from STRIPES.

14. The system shall, if the recipient is not an FFRDC, allow one operational activity to be associated with multiple CIDs. There is a master contract ID and a CID for each task order.

15. The system shall, if the recipient is not an FFRDC, allow users select from a list of task orders associated with the project award numbers based on CID.

16. The system shall, if the recipient is not an FFRDC, display the following financial data fields for each task:

Executed AFP Planned AFP From STRIPES:

o Award Numbero CIDo Vendero Project Titleo Version Numbero Total Award Amount

From STARS:o ITD Obligations (summary and by B&R code and appropriation year)o CY Obligations (summary and by B&R code and appropriation year)o CY Paymentso CY Commitmentso CY Unallocated AFP

Award Negotiation (Financial Assistance Projects)Process Overview & MapAward negotiation will be the first major process step for Financial Assistance projects and will integrate with the Announcements module to reduce manual data entry. The project record will initially be populated in award negotiation based on the project information submitted by the applicant in the Announcements module during the submissions process. The system will allow the EERE Project Lead and Recipient to collaborate on the revisions and submissions of all documentation required to make an award. The system will keep track of all versions of the Statement of Project Objectives (SOPO), budget justification, and other required documents to ensure that all parties have access to the latest version of every document. The system will

45 | P a g e

provide the appropriate templates and checks and balances in the award negotiation process, in alignment with EERE’s SOPs for FOAs. Additionally, the system will help the GMS create the award package (PDF) and gain approval on it before being uploaded to STRIPES for the formal award.

Within the system, the Award Negotiation process will follow the major steps below:

Pre-Negotiation: The process starts when an applicant is selected for award negotiations. The system will create a draft project record. Select EERE team members will hold a post-selection webinar, participate in an initial negotiation call, and send a post-selection letter to the Selectee (the applicant who was selected for the award).

Negotiation: The Selectee will provide all required negotiation documents, such as the pre-award information sheet, indirect rate agreement/proposal, Environmental Questionnaire (EQ-1), revised SOPO, Budget, and SF-424 (if necessary). The Selectee will negotiate with the EERE Project Lead until negotiation documents are finalized. Once the SOPO and EQ-1 are finalized, the EERE Project Lead will complete the Environmental Questionnaire Verification Checklist (EQ-2), which will then be routed to NEPA for their review and final NEPA Determination.

Post-Negotiation: If a Cost/Price review is required, then the Cost/Price Analyst will review the documentation and provide the analysis. At the same time, Legal and IP Counsel will conduct an IP review will make an IP determination. The EERE Project Lead and GMS/CS will jointly complete the Budget Evaluation and Negotiation Memorandum. The GMS/CS will then finalize the Award package and complete the entry into STRIPES.

Award Approval and Issuance: The Award package will be routed to the CO for review and approval. The GMS/CS will then upload the approved award package into STRIPES, which will make the official award and obligate funding.

Negotiation Cancellation: During this entire process, negotiations can be deemed unsuccessful and canceled for a number of reasons, including: (a) Selectee is non-responsive, (b) Selectee has poor past performance, or (c) Selectee has delinquent federal debts.

46 | P a g e

https://eeredocman.ee.doe.gov/offices/EE-64/projects/REI/ITSIRequirements/_layouts/xlviewer.aspx?id=/offices/EE-64/projects/REI/ITSIRequirements/Shared%20Documents/RFP%20Information/EERE%20335%20-%20Budget%20Justification_7.xlsx&Source=https%3A%2F%2Feeredocman.ee.doe.gov%2Foffices%2FEE-64%2Fprojects%2FREI%2FITSIRequirements%2FSitePages%2FHome.aspx%3FRootFolder%3D%252Foffices%252FEE%252D64%252Fprojects%252FREI%252FITSIRequirements%252FShared%2520Documents%252FRFP%2520Information%26FolderCTID%3D0x0120003D3AF320833F494C88A67DD5889FE8B5%26View%3D%7BBA815683-4675-461D-BC4A-1C88BF888DFB%7D&DefaultItemOpen=1

https://eeredocman.ee.doe.gov/offices/EE-64/projects/REI/ITSIRequirements/_layouts/WordViewer.aspx?id=/offices/EE-64/projects/REI/ITSIRequirements/Shared%20Documents/RFP%20Information/EERE%20303%20-%20Statement%20of%20Project%20Objectives%20(SOPO)_2.docx&Source=https%3A%2F%2Feeredocman.ee.doe.gov%2Foffices%2FEE-64%2Fprojects%2FREI%2FITSIRequirements%2FSitePages%2FHome.aspx%3FRootFolder%3D%252Foffices%252FEE%252D64%252Fprojects%252FREI%252FITSIRequirements%252FShared%2520Documents%252FRFP%2520Information%26FolderCTID%3D0x0120003D3AF320833F494C88A67DD5889FE8B5%26View%3D%7BBA815683-4675-461D-BC4A-1C88BF888DFB%7D&DefaultItemOpen=1

https://eeredocman.ee.doe.gov/offices/EE-64/projects/REI/ITSIRequirements/Shared%20Documents/Requirements%20Documentation/EERE%20EQ%20OMB%20APPROVED%209514%20Sample.pdf

47 | P a g e


1. The system shall create FA projects in the project management module directly based on the selected application from the Announcements module.

2. The system shall allow the recipient and EERE project lead to complete following elements of the award

Award Details Pre-Negotiation Steps SOPO Budget NEPA Risk Analysis & Payment Post-Negotiation Documents Award Package Approvals Documents

3. The system shall flag the Cost Share if it is below the required cost share for the project.

4. The system shall flag the SO Allowable Deviation if the deviation in funding is higher (%) than the allowable deviation.

5. The system shall allow users to generate the e-SOPO which is an on-line form version or an uploaded version provided by the applicant during the submission phase. Both versions are populated from the selections phase of the Announcement Module

6. The system shall allow the users to revise the SOPO as needed within the system, which will create a new version of the SOPO separate from the original SOPO.

7. The system shall provide the ability for EERE and Selectee to iteratively edit the SOPO (uploaded document or e-SOPO) and send it to each other for review/feedback. The system

8. The system shall allow track changes to be saved as different document versions each time the document gets sent back and forth between the Applicant and the EERE Project Lead.

9. The system shall allow the Recipient and EERE Project Lead to enter comments and maintain a comment history for an e-SOPO.

10. The system shall automatically pull in the original SF-424A and Budget Justification documents for the Selectee.

11. The system shall require a budget justification for any sub recipient with proposed budget exceeding 25% of the total project value or proposed budget of $250k or higher) into the Budget negotiation step.

12. The system shall automatically generate a revised SF-424A based on the summary sheet of the Budget Justifications for each version of the Budget Justification for both Selectee and

48 | P a g e

# Description

qualifying sub recipients.

13. The system shall provide the ability for EERE and Selectee/sub recipient to iteratively edit their own Budget Justification and send back and forth between EERE and Selectee/sub recipient for review/feedback.

14. The system shall display the funding by B&R codes and appropriation year for the project, showing the following data fields:

Total planned funding DOE Share total (Selectee + FFRDC) DOE Share for Recipient (Selectee) DOE Share for FFRDC Recipient cost share

15. The system shall, if the user requests a mortgage exception, require the user to enter the mortgage profile.

16. The system shall allow the users to create, edit, and view the following documents during the NEPA step of award negotiations:

Environmental Questionnaire-1 (EQ-1) Environmental Questionnaire-2 (EQ-2) NEPA Determination (view only)

17. The system shall allow the GMS/CS, EERE Project Lead, and IP staff (only for IP) to create, view, and edit the following post-negotiation documents as part of the award negotiation wizard:

Budget Evaluation and Negotiation Special Terms and conditions FARC IP Provision Determination

18. The system shall allow the EERE Project Lead and GMS/CS to create and manage the following negotiation memoranda based on the servicing office for the project/award:

Budget Evaluation & Negotiation Memo for the Golden servicing office Financial Assistance Negotiation Memorandum for the NETL servicing office.

19. The system shall allow the user to view and edit the Terms and Conditions document and sections.

20. The system shall allow the GMS/CS to add or delete a term from the Special Terms and Conditions document.

21. The system shall indicate the terms/conditions that require inputs from the GMS/CS.

22. The system shall mark terms/conditions as complete as the inputs are received.

23. The system shall, during award negotiations, allow the EERE Project Lead to create and edit

49 | P a g e

https://eeredocman.ee.doe.gov/offices/EE-64/projects/REI/ITSIRequirements/SitePages/Home.aspx?RootFolder=%2Foffices%2FEE-64%2Fprojects%2FREI%2FITSIRequirements%2FShared%20Documents%2FRFP%20Information&FolderCTID=0x0120003D3AF320833F494C88A67DD5889FE8B5&View=%7BBA815683-4675-461D-BC4A-1C88BF888DFB%7D

# Description

the FARC items.

24. The system shall, during award negotiations, generate the following award documents as pdf files(with bookmarks to help navigate to appropriate sections):

Award Package will contain a combined file of all award package documents except the Special T&Cs.

Supporting Documents will contain a combined file of all relevant supporting documents.

25. The system shall require that the Contracting Officer review all award documentation in the system prior to approving the award package.

26. The system shall allow the negotiations to be cancelled for one of the following reasons:

Delinquent Recipient Misconduct identified on Pre-award information Past Performance

Project Monitoring Process Overview & MapProject monitoring is the longest phase in a Lab or FA project’s lifecycle and is where the EERE Project Lead will spend most of his/her time managing the projects. The Project monitoring phase begins after the award is made in STRIPES (for FA projects) or after the AOP is approved (for Lab projects). Additionally, operational activities and other project categories are also monitored and reported on in a similar manner as Lab AOP projects.

FA Projects: Within project monitoring, for FA awards, the first phase is post-award planning; this time period occurs immediately after an award is made and up to 30 days prior to the first reporting period due date. During this period, the EERE Project Lead and Recipient are able to make minor modifications to the project that do not require an award modification (e.g., adding PMP milestones, developing the cost plan) without submitting a CR in the system. Both the Project Management Plan (PMP) and cost plan are optional for FA projects. After the post-award planning phase, the members of the EERE Project Team are engaged in continuous monitoring to assess the health of the project. Additionally, as part of the monitoring process, FA recipients are required to submit quarterly project status reports within the system, which includes reporting on costing, task/subtask milestones, and other project progress indicators. The EERE Project Lead is required to review and either concur or return the information for additional edits.

Lab Direct Projects: For Lab AOP or FOA prime projects, monitoring starts once a project has gone through the concurrence process during AOP Project Development. Monitoring will allow users to track and monitor project progress and will allow Recipients to submit their deliverables and project-level costing, which will then be available for EERE project lead review on the project record.

Operational Activities and Other Project Categories: Similar to Lab Direct projects, monitoring of these projects starts once the project has gone through negotiations and approval/concurrence. During monitoring, the EERE Project Lead tracks the project progress, while Recipients submit reports and/or deliverables as identified.

50 | P a g e

51 | P a g e


1. The system shall generate a project record based on the negotiated agreement signed by the Contracting Office for a Financial Assistance project and the finalized agreement signed off on by EERE and the Lab Representative for a Lab Project.

2. The system shall allow Recipients to view the funding details stored in the system, the data stored in STRIPES, and data stored in STARS for their project by month and year

3. The system shall track the following Funding Detail elements: Total Approved Budget Federal Share Cost Share FFRDC Funding ITD Obligations ITD Costs Total Invoiced ITD Payments Executed AFP Planned AFP

4. The system shall allow users to view the following information for Financial Assistance Projects annually, quarterly, or monthly over the life of the project. The data elements include DOE share; STARS obligations and payments; planned, actual and cost share from the quarterly reports.

5. The system shall allow users to view the following information for Lab Projects annually, quarterly, or monthly over the life of the project. The data elements Executed AFP; planned costs; and actual Costs from the BARDI system.

6. The system shall update the project level spend plan in the Budget Module of the system when changes are saved in Monitoring for the Incremental AFP Needs.

7. The system shall allow the Prime award holder to develop the financial cost plan for itself and the sub-recipient or FFRDC partner 30 days before the end of the first reporting period.

8. The system shall allow the recipient to submit reporting deliverables within the system based on the deliverables defined in the FARC

9. The system shall provide the option for recipients to enter a cost plan directly in the system or upload a cost plan.

10. The system shall create a reporting schedule, based on the project FARC, for each project.Note: The FARC is finalized during the Award Negotiations phase.

11. The system shall populate the work plan from the SOPO including budget periods, tasks, subtasks, milestones, go/no-go decision criteria, and deliverables.

12. The system shall allow the user with Project Lead or Project Team Member role to enter assessment data for each of their projects in the active phase, per the schedule in the FARC, agreed to upon during award negotiations.

13. The system shall require the EERE Project lead to submit a quarterly assessment as required per EERE’s APM requirements.

14. The system shall allow the EERE Project Lead to schedule a new site visit and export the calendar item to Outlook.

15. The system shall automatically schedule Quarterly Assessments for all FA projects that do not have an exemption.

16. The system shall only display recipient reporting deliverables information on the assessments page for FA projects.

52 | P a g e

# Description

17. The system shall only allow Recipients to initiate a CR if a CR is not already in progress.

18. The system shall require Labs to report FFRDC costs on a monthly basis through the BARDI process and should include the following information:

Project ID FM-FY B&R Code CY Costs CY Obligations

19. The system shall allow the Recipient to submit additional reports indicated in the FARC that are due each quarter, or reports marked in the FARC with an “O” or “A.”

Project ModificationsProcess Overview & MapProject modification is envisioned to be done with the use of three processes: the unlock process, the Change Request (CR) process and the award modification process. The unlock feature is a quick method for project managers to update their record for non-critical changes; any change to a data field that is managed by change control will later be included in the CR process. Most types of projects will go through the CR process to manage changes to the approved project record; however, in cases where a modification has been made to the award record, the FA project will also go through an award modification.

Unlock record: Non-critical or non-significant changes to the project record can be quickly made by unlocking the project record. This does not require approval or concurrence until the next time a CR is initiated; at that time, the changes made with unlock process will automatically be included in the CR for concurrence (if the changes are to data fields that require CR or award modification).

CR Process: Changes to the approved FA project record that do not impact the award record or changes to all other types of approved projects can be accomplished using the CR process. These changes are done locally in the system and do not require an award modification or subsequent change in the STRIPES system.

Changes to an FA project record that impact the award record (SOPO, Budget, etc.) require both a CR in the system and award modification in the system and STRIPES.

53 | P a g e

54 | P a g e


1. The system shall allow changes to the project data to be managed/governed according to the Project Elements document, which displays for each type of project whether the data can be changed

All the time by all users with edit permissions (Always editable)

All the time by EERE project lead only

Under no circumstances (not editable)

Through a CR or award modification

Through Unlock feature

2. The system shall allow users to initiate a Change request (for FA or lab).

3. The system shall create a MOD record for the GMS/CS if the change request modifies a field that is included in the award record.

4. The system shall prevent the user from initiating a CR for a project if another CR for the same project is already in progress. There can only be one CR at a time.

5. The system shall allow the EERE project Lead to unlock the project record to make modifications to fields including the NEPA POC, Project Overview and Project Objectives.

6. The system shall alert the user that any changes made using the unlock function should not affect cost, scope or schedule and that the changes will not result in an official award modification unless a Change Request was submitted and signed by a Contracting Officer.

7. The system shall display the current approved version of the award record until Change Request/Modification is approved for the project record.

8. The system shall maintain the history of all revised copies of the project record version.

9. The system shall update the Project information for any changes that do not need mod in STRIPES, immediately upon CR concurrence.

10. The system shall allow GMS/CS and EERE Project Team to access the award wizard for all awards listed on the award modification page for FA project changes.

11. The system shall display a summary of all submitted changes that have not been processed. Displayed fields include:

CR Number Change Type Date Initiated Initiated By Comments

55 | P a g e

https://eeredocman.ee.doe.gov/offices/EE-64/projects/REI/ITSIRequirements/_layouts/xlviewer.aspx?id=/offices/EE-64/projects/REI/ITSIRequirements/Shared%20Documents/Requirements%20Documentation/Project%20Elements%20-%20CR%20or%20Award%20Mod%20-%20Unlock.xlsx&Source=https%3A%2F%2Feeredocman.ee.doe.gov%2Foffices%2FEE-64%2Fprojects%2FREI%2FITSIRequirements%2FSitePages%2FHome.aspx%3FRootFolder%3D%252Foffices%252FEE%252D64%252Fprojects%252FREI%252FITSIRequirements%252FShared%2520Documents%252FRequirements%2520Documentation%26FolderCTID%3D0x0120003D3AF320833F494C88A67DD5889FE8B5%26View%3D%7BBA815683-4675-461D-BC4A-1C88BF888DFB%7D&DefaultItemOpen=1

# Description

12. The system shall, in the modification phase, auto-select which supporting documents must be updated based on the types of changes are necessary based on the logic provided in Appendix C.

13. The system will update the award modification wizard based on the documents selected to be updated as part of the award modification.

14. The system shall allow users to output a consolidated PDF file of the award modification package and supporting documents to simplify the upload into STRIPES and Fed Connect.

15. The system shall allow the EERE Project Lead and Recipient Technical POC to view any pending CRs.

16. The system shall pause the process if edits to the award package documents are made after approval workflow is initiated.

Project CloseoutProcess Overview & MapThe closeout process includes submitting, reviewing, and approving recipient reports, patent certification, progress reports, and property reports. The closeout process also includes ensuring appropriate closeout documentation is uploaded into STRIPES and information is captured within the system.

The closeout process starts with a notification from the system to the Federal project team informing them that the project end date is within 90 days. If the EERE Project Lead verifies that the project is on track for closeout, the system will prepopulate the Recipient Reporting portal with all the information and documentation needed to complete project closeout immediately after the project end date. The 90 days after the project end date is the project closeout timeframe during which time the recipient will submit final reports, which will be reviewed and accepted by various parties in EERE.

Once the project ends, the system will prompt the Recipient to submit Final Reports. EERE Project Lead will then conduct any necessary reviews, including reviews of final deliverables, cost share (if any), and property and patent clearances. The EERE Project Lead will direct property and patent documents to GMS/CS. The GMS/CS will send property reports to GO Property staff and patent documents to Chicago Patent staff for approval/clearance, who will review and approve accordingly. The EERE Project Lead then prepares the Closeout package and create a requisition in STRIPES to close the award. The GMS/CS will upload the Closeout package to STRIPES, process a modification in STRIPES, and then route the Closeout package to the CO for review and approval. After approval, the GMS/CS will close the files in STRIPES and then notify the Financial Oversight Office to retire the award in STARS; and notify the STRIPES Administrator that the award will be retired.

56 | P a g e

57 | P a g e

Business Requirements

58 | P a g e

59 | P a g e

#Description

1. The system shall display the closeout reports 30 days prior to the project end date for all projects ending on time.

2. The system shall assume that the project is going into closeout on the project end date unless a CR for no-cost time extension has been initiated.

3. The system shall create a project closeout record under the Award Management, Award Closeout section of the system when a project enters closeout.

4. The system shall display all closeout reports required, as indicated with frequency F (Final) in the FARC, to be included in the closeout table.

5. The system will require the recipient to submit a change request if the project is not anticipated to finish on the current project end date.

6. The system shall allow the user to create, store and manage the following closeout reports:

Final Technical Report (will only appear for RD&D projects) Final Progress Report (only for non RD&D projects)Federal Financials Report

(SF-425) Property Report (SF-428) Property Report Supplemental (SF-428S) Patent Certification

7. The system shall require a budget revision via a CR/Mod if the negotiated cost share is not met.

8. The system shall alert the Project Lead and TM to initiate a CR/Mod if there is money to be obligated.

9. The system shall upload the Final Technical Report into OSTI once it has been accepted for RD&D projects.

10. The system shall send the 1st Notification of Non-Responsiveness to the Project Lead and CO 120 after the project end date if reports have not been submitted by the recipient to concur on the notification prior to the notification being sent out to the Recipient.

11. The system shall send the 2nd Notification of Non-Responsiveness to the Project Lead and Specialist 150 days after the project end date if reports have not been submitted by the recipient to concur on the notification prior to the notification being sent out to the Recipient.

12. The system shall send the Final Notification of Non-Responsiveness to the Project Lead and Specialist 180 days after the project end date if reports have not been submitted by the recipient to concur prior to the notification being sent out to the Recipient. Once the Project Lead and Specialist have concurred, the system shall send the CO an alert to sign it. After the CO signs, the system shall alert the Specialist to send the notification.

13. The system shall allow the TM, GMS, or CO to cancel the project Closeout.

14. The system shall allow the TM or GMS to request waiver for reports that have not been received or are not acceptable despite all attempts. The system will require a justification to be entered. The system will send an alert to the GMS and make this one of the waivers requested when the CO reviews the closeout package.

NEPA (National Environmental Policy Act) Process Overview & MapThe NEPA module will allow the NEPA Specialist to review all EERE projects for any potential environmental impacts from the proposed actions.

The NEPA process covers five overarching phases, including (1.1) NEPA Strategy for FOA

Development, (1.2) NEPA Determination Process for Financial Assistance, (1.3) NEPA Determination Process for NREL, (1.4) Environmental Assessment (EA) Process, and (1.5) Environmental Impact Statement (EIS) Process.

These phases include identifying the level of NEPA reviews required, including categorical exclusions (CX), EAs, and EISs. EA and EIS processes will be conducted outside the system.

60 | P a g e

61 | P a g e


1. The system shall a NEPA dashboard that displays status information about Announcements, FA Projects and NREL projects that require NEPA overview and compliance.

2. The system shall track FA projects, as part of project management, for NEPA compliance if EQ-1 and EQ-2 have been filled as part of award negotiations.

3. The system shall track NREL worksheets or the associated EQ-1 and EQ-2 when a control number is requested.

4. The system shall track the FOA –EQ submittal process if a FOA EQ is included in the Announcement’s FRD.

5. The system shall allow the NEPA specialist to create, track and manage Consultation contacts and consultation communication logs.

6. The system shall allow default text to be stored and pre-populated for the NEPA provision depending on the appropriate NEPA Term.

7. The system shall allow the NEPA Specialist to update the default text for the NEPA Provision.

8. The system shall allow the submission of Full NEPA Determinations or Conditional NEPA Determinations.

9. The system shall allow the NEPA Specialist to create and manage the NEPA Determination attribute if the Determination type is Full NEPA Determination.

10. The system shall allow the NEPA Specialist, for NEPA Determination of “with Conditions,” to create, store, and manage tasks by budget period.

11. The system shall make available the following documents to the NEPA specialist as part of the Announcement Review:

FOA EQ FOA Requirements Document

12. The system shall provide multiple approval templates for the NEPA Determination.

13. The system shall allow users to view and control what has been posted to the Public Reading Room (a repository for all determinations that were CXed and is accessible by the public on an EERE website).

14. The system shall provide a Public Reading Room feature based on user’s role and per project.

62 | P a g e

Portfolio ManagementThe portfolio management capabilities covers all activities that are involved with the overall portfolio, including Annual Operating Plan (AOP) Narratives, Lab AOP Management, Portfolio Analysis, Reviewer Management, and Peer Review.

The Portfolio Management functions allow for the management and aggregation of information for the overall portfolio. These functions include:

Organizing EERE’s information in alignment with its organizational structure and collecting information at various levels.

Enabling EERE to aggregate information for each office and allow senior management to approve and view portfolio level data (e.g., AOP document, Technology to Market [T2M] plan, portfolio analytics).

Enabling EERE offices to conduct high-level processes that apply to the entire office at large (e.g., peer reviews).

Enabling EERE to share common resources, leveraging data collected by other offices within EERE (e.g., sharing and managing reviewers for various technical reviews).

Reviewer ManagementProcess Overview & MapThe Reviewer Management module will allow reviewers to manage their profiles, upload CVs, and submit their reviews for all review types. This module in the system will allow EERE users to develop, maintain, and share potential reviewer lists and facilitate reviewer approval.

The reviewer management process starts when a user registers for a Reviewer role within the system.

After registration, Reviewer profile information will be made available within the system for the EERE team to search, view, and add/remove from their own lists.

The Director, Selection Official, or Program Manager will then approve reviewers’ expertise. They will also identify reviewers of interest. Only reviewers who are approved will be considered/invited for participation in merit reviews or peer reviews.

Reviewers will update their availability information and also sign the required COI/NDAs for each review/application/project.

After signing the required COIs/NDAs, the reviewer will begin their merit review or peer review.

63 | P a g e

64 | P a g e


1. The system shall allow announcement managers and all other internal HQ users the ability to search reviewers by keyword, expertise, and name.

2. The system shall allow for the creation, deletion and maintenance of multiple lists of reviewers per HQ user.

3. The system shall allow a request to be sent to a potential new reviewer to register as a reviewer. The system shall record the date that a notification was sent, and number of attempts made to a potential new reviewer. If no response has been provided, the system shall allow users to resend the notification, which increments the number of attempts counter and updates the Notification Date. The system shall remove a reviewer from the proposed reviewers list when they register as a reviewer.

4. The system shall allow for internal and external users to request to be considered as a reviewer.

5. The system shall allow reviewers to update their reviewer profile and respond to availability requests.

6. The system shall display all reviews the reviewer has been or is currently a part of.

7. The system shall only allow reviewers to view information for reviews they are assigned.

8. The system shall allow an internal user to search for reviewers by last name, primary area of expertise, functional area of expertise, publications text, resume text, organization, degree, major, institution, and title.

9. The system shall allow the user to create a list of proposed reviewers.

10. Once identified as a reviewer associated with a Merit review, the system shall require the completion of the conflict of interest/non-disclosure agreement, before listing assigned projects/submissions for their review.

11. The system shall require all reviewers to confirm no COI exists prior to accessing the assigned submission the first time.

12. For all DOE users that are reviewers, the system shall maintain a blanket conflict of interest/non-disclosure agreement, which allows individuals to be associated with announcements. Individual project level COI confirmation is required.

13. The system shall provide the reviewers the ability to indicate a Conflict of Interest with an individual assignment at any time during the review. If a COI is reported, the system shall prevent the reviewer from viewing any further information on the assignment until the COI is

65 | P a g e


mitigated.

14. For each assigned application, the system shall provide the assigned reviewers the ability to enter, edit, save and submit scores and comments for each assignment.

15. The system shall provide assigned reviewers the ability to delete, edit and resubmit scores and comments for each assignment prior to the due date.

16. The system shall calculate the proposed score.

66 | P a g e

Peer ReviewProcess Overview & MapPeer reviews refer to the evaluation of ongoing or existing RDD&D portfolios and can include the review of an overall Technology Office’s performance and organization. Offices will not be required to use the peer review portion of the system; however, they will have the ability to upload the results of the peer review into the tool and link it directly to the project record.

The peer review process will use two of the systems Portfolio Management submodules: (1) The Peer Review module includes setting up of the peer review, establishing review criteria, viewing/finalizing scores that are entered by the reviewer, and exporting the results; (2) The Reviewer Management module includes managing reviewers and viewing their profiles.

The process begins with determining peer review dates and selecting Steering Committee members and the Steering Committee chair.

The system will generate a project list and will prompt all Technology Managers (TM) to review the list and flag projects that should or should not be reviewed.

The Peer Review Coordinator will edit the project list as needed and finalize the project list. Next, the Peer Review Coordinator will develop the evaluation criteria, which will be reviewed and approved by the Steering Committee.

The Peer Review Coordinator will also develop and publish the presentation template associated with the criteria set.

Recipients will prepare and submit their presentation materials and the TM/Team Lead (TL) will review the material.

67 | P a g e

68 | P a g e


1. The system shall allow Peer Reviews to be developed around a specific criteria/topic or by selecting a specific projects.

2. The system shall allow users to select projects for inclusion or exclusion from the review based on the following criteria:1. The projects is active as of the peer review start date, 2. The end date of the project is 6 months or more before the peer review start date3. The project has funding in the appropriation years covered by the review.

3. The system shall allow the Peer Review Lead, Office Administrator, and panel leads to request a new person to register as a reviewer.

4. The system shall require NDAs for reviewers if the review is not open to the public, and is a private review (closed door review).

5. The system shall allow the following deliverables to be added: Presentations, Abstracts, Images, finalized Project List/Agenda Due, publish Materials for Reviewer Access, Reviewer Comments, and PI Comments.

6. The system shall calculate the percentage of the portfolio reviewed (based on the number of projects within the office included in the review).

7. The system shall calculate the percentage of the portfolio funding being reviewed (based on the Federal Funding Share).

8. The system shall calculate the Total Approved Federal Amount for Lab Projects as the sum of the 3-year cost plan.

69 | P a g e

# Description

9. The system shall calculate the Total Approved Federal Amount for non-Lab projects as the total approved federal share of the budget.

10. The system shall calculate the Total Approved Federal Amount for combination projects as the sum of each federal amount for all projects that are combined together for the peer review.

11. The system shall allow the Peer Review Lead to add, update, or remove the Evaluation Criteria used for the review and assigned by project.

12. The system shall provide a way to view all reviewer scores and comments by project, including calculating the average score for a given criteria and the overall average score across all reviewers for a given project.

13. The system shall provide the ability for users to run pre-defined report templates pre-populated with information from the current peer review, and exportable to Word, PDF, or Excel format.

14. The system shall allow the participant to view reviewer scores and comments and provide a response to the reviewers.

15. The system shall calculate an Independence Index for reviewers, based on the reviewer's self-disclosing COI, association with any existing projects, and steering committee member/chair input.

16. The system shall allow the final agenda, final report, and final reviewer to be available for Completed reviews, and the PI Upload due date, or Reviewer comment due date shall no longer be available.

70 | P a g e

Lab AOP Management & AOP NarrativesProcess Overview & MapEach EERE Office develops Annual Operating Plans (AOPs) with each national laboratory with whom it partners. These AOPs describe the new and continuing projects that will be undertaken during the fiscal year, in addition to the planned budget, deliverables, and performance metrics for those projects. The majority of the data collected for the AOP is from the lab project planning functionality in the Project Management module. Within the Portfolio Management module, EERE users will develop the strategic narratives describing the overall scope of work associated to the Office’s work breakdown structure. The following are the highlights of the Lab AOP Management process:

The system will compile a single AOP document for each Lab’s proposed work for each EERE office, combining AOP narratives and all the Lab Direct projects in the current fiscal year for this office. This will include continuing and new projects.

An AOP Document and associated T2M Plan (if it exists) are routed for approval once the T2M plan is final and the AOP document negotiation has been completed. Approval workflow is dependent on the funding thresholds, stated herein. Lab AOPs with total funding of $5M or more, or with a single project funding more than $2M will require approval from the Program Manager and the Associate Lab Director (ALD); whereas, Lab projects with total funding less than $5M and with no project with funding more than $2M will only require approval from the EERE Project Lead.

71 | P a g e

72 | P a g e

Business Requirements# Requirement Descriptions

1. The system shall allow users to initiate a T2M plan if it is not required, if the Lab has at least one active AOP Direct project.

2. The system shall display the T2M landing page at various WBS levels. At the office level, the T2M landing page shall list all Labs with active projects in the selected fiscal year. At the EERE and Sector levels, the T2M landing page shall list all the offices and then the Labs with active projects in the selected fiscal year for that office. Data fields in T2M landing page will include:

Office (only at EERE and Sector levels) Lab T2M Required (Yes/No) AOP Funding Level Status (of T2M plan) Actions permissible for T2M plans (e.g., Initiate, Edit)

3. The system shall display the following information in when trying to create, edit, or review the T2M plan:

Strategy T2M POCs Topics and Activities

4. The system shall allow the user to edit, add, or delete topics within the T2M plan, displaying the following data fields:

Topic Area Title Activities Funding (sum) Description

5. The system shall allow the user to edit, add, or delete activities within each topic of the T2M plan. The system shall allow the user to enter information for the following data fields for each activity. Data fields marked with an asterisk (*) will be required.

Title* Description* Metric Category* Activity Type* Funding* Related Projects (show WBS number of related projects)

73 | P a g e

Portfolio AnalysisProcess OverviewThe system will contain dashboards and data reports to help senior management get a quick, high-level glance at the portfolio. This data will be refreshed as data in different modules of the system are updated by users. Any data reported by recipients will only be represented in dashboards/reports once the EERE team member(s) has approved the submission. Changes proposed in CRs and award modifications will not be used for dashboards/reports until the CR or award modification is approved/concurred. Planning data in the system will not be represented in dashboards/reports until the plan is approved.


1. The system shall allow users to view user specific analysis dashboard, search standard reports, and access ad-hoc reporting in DW2.0.

2. The system shall display a user’s customizable and collapsible list of standard report links.

3. The system shall allow users to add reports to their list of standard report links.

4. The system shall allow users to remove reports from list of standard report links.

5. The system shall allow users to request additional reports and charts through the help desk.

6. The system shall allow EERE users to customize their layout of the Portfolio Analysis Dashboard.

7. The system shall allow EERE users to add subpages to the Portfolio Analysis Dashboard.

8. The system shall allow EERE users to remove subpages from the Portfolio Analysis Dashboard.

9. The system shall allow EERE users to edit the title of the subpages in the Portfolio Analysis Dashboard.

10. The system shall allow EERE users to select from a standard list of graphics which charts to display.

11. The system shall allow EERE users to rearrange, remove, and set standard filter for the displayed charts.

12. The system shall allow all budget charts to be filtered by the following data fields:

Appropriation Year B&R Code Subprogram

13. The system shall allow all portfolio charts to be filtered by the following data fields:

Fiscal Year B&R Code WBS Level Work Category

74 | P a g e


14. The system shall allow EERE users to additionally filter all displayed charts.

15. The system shall allow EERE users to search standard system charts and reports using a smart (proposed auto fill should be the relevant question) is keywords from the following fields:

Title Strategic Value Relevant questions Description

75 | P a g e

Budget ManagementThe Budget Module is intended to automate EERE budget planning and execution activities and integrate with the activities (FOAs, Labs Calls, and Projects) that EERE funds on an annual basis. Budget planning activities include the development of budget scenarios in support of budget formulation process. Budget execution activities includes the ability to plan against an approved scenario, managing the control table, developing a spend plan, creating guidance letters, and managing HQ funding, and deobligations. The Budget Module has planned integration points with several other modules to ensure consistent data across the system. The diagram below provides a high level flow of data across the Budget Management Module. The following section provides the process overview and high level requirements for each major function of the Budget Management Module.

76 | P a g e

Figure 1: Budget Management Process

77 | P a g e

Budget PlanningProcess Overview & MapThe EPIC budget module will support the budget formulation process for scenario planning and will also support budget execution funds distribution and control.

The Budget Planning module will be used to capture details for multiple budget scenarios developed throughout the budget formulation process and execution spend plan development prior to the start of the execution year. For each phase of the budget formulation and spend plan development process, the EERE Budget Office can create corporate scenarios as a means of establishing various budget scenarios to which the EERE Offices will be required to submit budget proposals. For instance, in the internal budget review phase, the EERE budget office may need to collect three funding scenarios from each office (e.g. funding consistent with prior year, 10% reduction, 15% increase). Offices will be asked to submit their budget proposals, outlining the details to build up to each of those funding scenarios. When creating these scenarios, the Budget Office shall be able to create funding limits at different budget structure levels, as well as identify and place funding controls on crosscuts and high priority activities in a Corporate Scenario. Those funding limits will establish thresholds that will constrain the inputs of the EERE Offices. Corporate data scenarios are visible to both the EERE budget office and the program office.

In addition to corporate scenarios, the system will also allow the creation of office scenarios. An office scenario functions similarly to a corporate scenario format and function, but they are used and accessible exclusively by a single office to do internal scenario planning. Data entered into an office scenario should be able to be copied into the submission of a corporate scenario, allowing program offices to run their own scenarios before determining how best to respond to the corporate data call.

The following sections detail the business requirements for creating, responding to, completing funding inputs in, and approving Corporate and Office Scenarios

Creating Corporate Scenarios

The EERE Budget Analyst can create a Corporate Scenario that includes detailed funding guidance and required submission dates to distribute to program offices as data calls for budgetary information. When setting up a corporate scenario, the EERE budget analyst has the ability to set funding controls, establish the level of detail required for submission and determine the various data inputs required within the submission. Once the requirements for the corporate scenario are set, the EERE budget analyst can include relevant instructions and assign this as a data call to the EERE program offices. This data call should be linked to the information management common services module, which defines a common structure for all EERE data calls.

Setting Funding Controls

The EERE budget is broken down into an established budget structure that breaks down into sectors, programs, subprograms and activities. Congressional control levels are typically established at the EERE program level. When creating a budget scenario, the EERE budget analyst should be able to establish funding thresholds at any level within the budget structure. These funding controls should validate

78 | P a g e

against the program office’s submission to either disallow the submission or to require a justification for the deviation. Additionally, the EERE budget analyst should be also be able to establish a funding control on a specific high priority activity or crosscut.

Setting Requirements for Level of Detail

The required data entry for the budget scenario can be set as a simple spread of the funding to program/subprogram/activity budget structure or to include a detailed breakout of lab funding amounts, planned new FOAs, project mortgages, and other corporate requirements that will build up to the scenario funding level.

Lab Planning Amounts – Lab project data is funded on an annual basis. When estimating future budget needs, data collection for lab planning will reference the lab project data from the project management module to identify funding needs on existing projects. New lab funding is associated to a lab call from the announcements module with various funding levels per budget scenario.

FOAs – FOA projects are typically upfront funded at the time of award, meaning that the FOA will be used to award 3-5 year projects which will be fully funded in the year of award. When planning funding needs for the budget planning year, FOAs are associated from the announcements module with funding levels per budget scenario. In the case of large FOAs that cannot be fully funded within a single year, a proposed mortgage plan is entered to identify funding needs for the budget year and out years. Mortgage requests on FOAs will undergo multiple approvals throughout the budget formulation process.

Project Mortgages – While most FOAs are upfront funded, in cases where a FOA has received approval to proceed with a mortgage, that mortgage will later be tracked at the project level, once the FOA is awarded. When estimating funding needs for a budget year, established project mortgage data is collected, and modified as needed per the budget scenario.

Other corporate requirements will be collected using worksheets to capture SBIR/STTR/TCF estimates and estimates for EERE/DOE crosscutting activities.

Setting Requirements for Data Input

In addition to the funding spread, the EERE budget analyst can also collect inputs for other data inputs, including a listing of EERE high priority activities or crosscuts. A high priority activity can be a project or initiative that falls below the budget structure that is relevance to Congress or DOE leadership. A crosscut is a shared initiative across multiple EERE or DOE organizations that is collected holistically.

Issuing the Data Call

Once the parameters for the scenario are set, the EERE budget analyst can include additional instruction and make assignments to the EERE program offices.

Corporate Scenario Submissions

Copying Responses and Assigning for Additional Inputs

A program office Budget Analyst will be able to view any corporate scenarios assigned to the program office to review the requirements of the assignment and determine what information is needed to

79 | P a g e

complete the request. These scenarios can be managed directly by the program Budget Analyst or assigned to program office staff for completion.

The program office Budget Analyst does not have the ability to change the template or structure of the assigned Corporate Scenario, but is able to set up additional funding controls in addition to those set by the EERE Budget Analyst. When completing submissions to a budget scenario, the program budget analyst can pre-fill the submission by copying inputs from another scenario as a starting point. Additionally, the program budget analyst can choose to create a copy of the corporate scenario into one or more office scenarios to collect inputs that are only visible to the program office.

In order to capture the required data for completing the assigned Corporate Scenario, the program office Budget Analyst will be able to assign the scenario to other program office staff for inputs. The initial data call will be forwarded with the inclusion of additional instructions, as needed.

Data Validation

Before the submission can be sent back to the EERE Budget Office, the system will validate entries against the funding controls set by the EERE budget office and/or the program budget analyst. Submissions may either be prevented or require a justification for a deviation.

Data Submission

The system shall support the ability for the EERE budget analyst to review the submission and send back for adjustments as needed. Once the data is concurred upon, each office’s submission can be approved. The full scenario can only be approved once each office’s submission has been approved.

80 | P a g e

81 | P a g e


1. The system shall allow the EERE Budget Analyst to create an external Corporate Scenario.2. The system shall allow the Program Office Budget Analyst to create Office Scenarios3. The system shall allow the EERE Budget Analyst to copy an existing scenario to set the

template structure for a new Corporate Scenario.4. The system shall allow the EERE Budget Analyst to set the template structure with:

Scenario type (Single or Multi-Option Scenario) Input type (either FOA/Data/Lab Data/Mortgage/Other or Budget

Subprogram/Budget Activity Spread) Funding level detail Data entry method SBIR/STTR/TCF allocation Any required crosscuts or high priority activities

5. The system shall allow the EERE Budget Analyst to set funding controls at any level of the budget structure.

6. The system shall allow the EERE Budget Analyst to set funding controls for a high priority activity or crosscut.

7. The system shall allow the EERE Budget Analyst to set the required data entry for the budget scenario to be set as a spread of the funding to program/subprogram/activity budget structure or to include a detailed breakout of lab funding amounts, planned new FOAs, project mortgages, and other corporate requirements

8. The system shall allow the EERE Budget Analyst to send the Corporate Scenario to other members of the Budget Office for review and input by a set deadline.

9. The system will notify the creator of the Corporate Scenario when all requested concurrences have been received.

10. The system shall provide the EERE Budget Analyst the ability to review all elements of the external Corporate Scenario before completing the scenario and assigning it to the program office.

11. The system shall assign an IM number to the completed external Corporate Scenario.12. The system shall allow the EERE Budget Analyst to assign the external Corporate Scenario

to selected program offices for completion.Submitting Response to a Scenario

13. The system shall allow the program office Budget Analyst to view any external Corporate Scenarios including guidance and templates assigned to their respective program office.

14. The system shall allow the program office Budget Analyst to set up additional funding controls in addition to those set by the Budget office.

15. The system shall enforce the Office and Corporate funding controls.16. The system shall allow the program office Budget Analyst to include additional funding

requirements that do not fall into the other pre-defined funding areas. The system shall capture these requirements as “Other Funding Requirements”.

17. The system shall allow the program office Budget Analyst to copy funding inputs from another corporate or office scenario with an equivalent or lower level of detail as a baseline for the selected scenario.

18. The system shall allow the user to copy a B&R funding level as a rollup. 19. The system shall allow the program office Budget Analyst to reassign the scenario to other

users (e.g., Technology Managers) for input.

82 | P a g e

20. The system shall allow the user assigned the Corporate Scenario to complete any funding inputs included in the external Corporate scenario.

21. The system shall provide the user the ability to view lab call or FOA data (from announcements module in the FOA Funding Input section.

22. The system shall allow the user to add the following FOA data into the FOA funding input of the scenario by selecting with FOAs to use from the FOA module:

FOA (Lab Call) Title/Funding Source Minimum Funding Ideal Funding

23. The system shall allow the user to view the existing AOP projects (from project management module) and the projected funding while in the Lab Data tab of the Funding Inputs section of the scenario.

24. The system shall aggregate the AOP project totals and display the funding needs for the applicable fiscal year.

25. The system shall validate entries against the funding controls set by the EERE budget office and/or the program budget analyst as a requirement for submission.

Approving Submissions & Scenarios 26. The system shall notify the EERE Budget Analyst when the program office has completed

and submitted their inputs for the external Corporate Scenario.27. The system shall allow the EERE Budget Analyst the ability to review the submission after it

is submitted by the program office. 28. The system shall allow the EERE Budget Analyst to send the scenario back to the program

office for additional information or revision. 29. The system shall allow the EERE Budget Analyst to approve the office submission. 30. They system shall allow the EERE Budget Analyst to approve the full scenario once each

office’s submission has been approved.

31. Once the scenario is approved, the system shall update the applicable announcement(s) in the Announcement module with the approved budget amount and add it to the annual FOA list.

83 | P a g e

Budget Structure ChangesProcess OverviewEERE maintains an approved budget that is used to capture funding controls to be used in budget formulation and budget execution. During the budget planning process, an office can propose a change to their budget structure. When proposing a change, the office needs to submit a crosswalk of the old structure to the new structure so that the funding can be properly represented to show how historical funding would appear in the new structure and how future funding would appear in the old structure. When the program office identifies a need for a Budget Structure change, the program office Budget Analyst can request a change through the Budget Structure change request function in the Budget Management Module. The EERE Budget Analyst is responsible for reviewing the change request to determine whether it is warranted and taking appropriate action to request Congressional approval as part of the annual budget justification. Once approved through the Congressional budget process, the revised budget structure will appear in the budget execution structure for all future years.


ID Requirement Description1. The system shall allow the program office Budget Analyst to create a Budget Structure

Change Request. 2. The system shall provide the program office Budget Analyst with a copy of the existing

Corporate Scenario budget structure applicable to their office.3. The system shall, within the budget structure change request, to allow the program office

Budget Analyst to indicate whether a specific line item in the budget structure needs to be “Added”, “Deleted”, or “Moved.”

4. The system shall require the program office Budget Analyst to provide an explanation for each requested line item change.

5. The system shall allow the program office Budget Analyst to provide comments for each requested line item change.

6. The system shall allow the program office Budget Analyst to submit the change request to the EERE Budget Analyst.

7. The system shall notify the EERE Budget Analyst of a pending Budget Structure Change Request.

8. The system shall allow the EERE Budget Analyst to review the details of the change request.9. The system shall allow the EERE Budget Analyst to mark the request as approved or not

approved.10. If the change request is not approved, the system shall allow the EERE Budget Analyst to

send a notification back to the program office Budget Analyst with an explanation for the non-approval.

11. If the change request is approved, the system shall notify the program office Budget Analyst of the approval.

12. The system shall allow the EERE Budget Analyst to change the Budget Structure of the Corporate Scenario.

13. The system shall record all approved change requests and associate the previous budget line items to the changed line items for prior and future fiscal years.

14. The system shall maintain the crosswalk of the budget structure changes by fiscal year.

84 | P a g e

Funding Controls – Budget ExecutionProcess OverviewFunding Controls are intended to capture a variety of controls or funding requirements that have been established through the budget planning process including the funding levels for each level of the budget structure, high priority activities, crosscuts, and corporate requirements. In budget execution, the budget structure elements are tracked through the use of budget and reporting (B&R) codes which are used to track all financial transactions in the Department’s accounting and procurement systems. The control table will be linked to an approved budget scenario from budget planning, allowing the offices to leverage much of the detail captured during the annual planning process. To kick off the budget execution process, the EERE Budget Office will approve a spend plan scenario within budget planning. Initially, the approved budget scenario may represent EERE’s nominal planning level (a conservative estimate usually issued in the spring prior to the execution year for office’s planning purposes while waiting for congress to pass an appropriation bill or issue a CR). Later in the year, once a bill or CR is passed, the EERE Budget Office may link the control table to an alternative scenario, thereby modifying the funding levels and requirements. These funding controls will be used to establish funding ceilings to be enforced during funds authorization and distribution.

At the end of each fiscal year, there is a formal process with DOE’s Office of the Chief Financial Officer for requesting apportionment and allotment of any funds that have not been obligated. The system will automate the process for requesting these funds for early re-allotment at the start of the next fiscal year. Additionally, the system will support the development of an annual obligation plan that will be submitted to the CFO’s office at the start of each, and collects the obligation plans for the Office’s FOAs, mortgages, lab projects, and corporate requirements.

Funding Controls will contain the following elements:

Control Table (Apportionment and B&R level Controls) High Priority Activities, Crosscuts, and Corporate Requirements Early Re-allotment Request CFO/OMB Obligation Plan


ID Requirement Description1. The system shall allow the EERE Budget Analyst to approve a budget scenario and link it to

the funding controls table2. The system shall allow the EERE Budget Analysis to link the funding controls to a new

scenario. 3. The system shall track the following elements of the funding controls:

Control Table (Apportionment and B&R level Controls) High Priority Activities, Crosscuts, and Corporate Requirements Early Reallotment Request CFO/OMB Obligation Plan

4. The system shall ensure the that funding controls are associated with a single fiscal year

85 | P a g e

5. The system shall allow the funding controls can be viewed at the following budget levels: EERE Program Office

6. The system shall allow EERE to track the apportionment authority, allotment, and available apportionment by appropriation year at the EERE level

7. The system shall within the B&R funding controls, track the following information by B&R code and Appropriation Year:

Allotment Annual Funding Control Reserve Amounts (rescissions, Prior Year Deobligations, SBIR/STTR, etc.) Actuals (planned, executed amounts per spend plans)

8. The system shall allow EERE budget office to track the base table, allotment, and annual funding control by program office

9. The system shall allow offices to breakout the annual allotment and annual funding control by B&R Code

10. The system shall track changes of all modifications to the control table11. The system shall track current funding levels for high priority activities, crosscuts, and

corporate requirements based on the tags on announcements and projects as a read-only field.

12. The system shall track actual funding amounts for high priority activities, crosscuts, and corporate requirements based on the tags on announcements and projects.

13. The system shall allow offices to either keep actual funding amounts synced with current funding levels (FOA/Project tags) or to manually enter the values

14. The system shall allow the EERE Budget Analyst to issue the request for early re-allotment IM.

15. The system shall allow the offices to enter the amount needed for re-allotment by B&R Code, appropriation year, fund value, and month.

16. The system shall allow offices to complete the OMB/CFO obligation plan.

Funds Authorization (Project Level Spend Plan)Process OverviewWithin the budget execution module, the project level spend plan is used to determine the timing and amount of funding to be included in the monthly AFP. As a precursor to developing the spend plan, the technology offices will have determined how to spread the scenario funding (NPL or enacted budget) across the office’s B&R codes. Since project budgets are already defined, the project spend plan is intended to serve as a tool to manage an office’s cash flow –essentially balancing project needs with the availability of funds given potential budget constraints, e.g. CR, apportionment, etc.

For each project, the spend plan will be pre-populated with a project budget tracked down to the associated B&R code level. The project budget is pulled from either the project management module the announcement module or the information entered in the budget planning scenario. For mortgaged awards, the project budget will be pulled directly from the project’s mortgage profile from the project management module. The announcement budget is based on the funding level entered on the

86 | P a g e

announcement. Lab budgets are based on the planning year funding amount identified in the annual operating plan.

Offices will plan funding at the project level and create funding actions for a given month. The Budget analyst is responsible for aggregating all of the funding actions for a given month and AFP Recipient and generating the required funding documents. Although funds are planned at the project level they are authorized at the congressional control point which is typically equivalent to the program office level.


1. The system shall allow the program office to populate the project level spend plan2. The system shall populate each activity budget in the spend plan based on the following:

Mortgages: based on the project’s mortgage profile for that specific year (PM Module)

Announcement: based on approved scenario Operational Activity: based on funding amount (PM module) Lab: based on funding amount (PM module)

3. The system shall, for each previous AFP months, display the planned, in process, and executed amounts.

4. The system shall display the funding control table for the selected program office by subprogram and B&R code

5. The system shall display the AFP Reconciliation report by identifying any discrepancies between the YTD Executed Amount (EPIC) and YTD AFP (STARS) for each AFP Recipient.

87 | P a g e

6. The system shall allow the program office to calculate the Just In Time (JIT) funding report based on the following logic:

Corporate Requirements: The budget office will pre-load a monthly distribution schedule for all corporate requirements. The monthly funding amounts associated to the corporate requirements will be held in reserve until executed.

Mortgages (Financial Assistance awards): Mortgage profile data will be stored within the project record with B&R/fund type detail identified by budget period. The JIT AFP entry will be auto-populated to include the required mortgage amount for the related budget period two months prior to budget period start date. For example, if the budget period start date was in April, the funding entry would be included in the JIT February AFP.

FOAs: Total award amount (DOE Share) for the identified B&R Code/appropriation year/ fund type combination, unless the FOA has an approved mortgage exception, in which case it will be auto-populated with the annual amount, two months prior to the anticipated award date. For example, if the anticipated award date is set for April, the funding entry would be included in the JIT March AFP.

Labs: The lab funding JIT calculations will be based on a combination of the project-level lab cost plan from the AOP and the project-level YTD Uncosted balance (reported by the lab), taking into account encumbered funds. In order to ensure that labs have sufficient funding to execute their project activities, the JIT calculation will assume that sufficient funding must be included in the AFP for the two months of planned costing following the AFP month. All calculations of available funds will be based on the availability of unencumbered YTD uncosted balances.

7. The system shall generate funding actions for a given month based on the funding amounts and recipients entered in the project level spend plan

8. The system shall allow the user to determine if the funding action should be sent to BA for processing or remain in a planned status.

9. The system shall generate the required funding documents (WAS & Guidance Memo) based on the funding actions for the month.

10. The system shall determine the funding documents required based on the AFP Recipient type.

11. The system shall allow the user to route the funding documents for approval.12. The system shall allow AFP Recipients to view approved funding documents.13. The system shall allow users to view a list of funding documents and funding actions. 14. The system shall allow the budget analyst to denote when funds have been entered into the

AFP.

88 | P a g e

HQ FundingProcess Overview

89 | P a g e

Within the project management module, EPIC will include streamlined projects, called operational activities, to capture the scope of work associated with activities such as support service tasks, interagency agreements and other items funded directly from HQ. Within the Project Management module offices will create operational activities and upload required contract documents including the performance work

statement (PWS) and independent government cost estimate (IGCE) to make them available to procurement staff. Access to those documents will be tightly controlled. Operational activities will be available for funding in the budget module. From the budget module, offices will be able create funding actions and submit them for processing. Unlike funding to the field, HQ transactions can be processed at any point in the month. Once submitted the Financial Oversight Office’s contracting staff will be able to view the request and all associated funding documentation. The remainder of the process of executing the contract action will take place in DOE Corporate Systems STARS & STRIPES.

90 | P a g e


1. The system shall allow users to create multiple funding actions in a given month.2. The system shall send a notification to the assigned contracting officer representative COR

when a funding action is submitted.3. The system shall require the COR to approve the funding action.4. The system shall require the requisition to be uploaded to approve the funding action.

Funds Transfers & DeobligationsProcess OverviewProject Funds Transfers: At times, after funding has been authorized offices may need to move money between projects. The project budget will be managed by the EERE Lead for that activity and may be modified over the course of the year. Any changes made to the project budget are automatically reflected in the project level spend plan—they will always be in sync.Offices have the flexibility to move money between projects with the same AFP Recipient and within the same congressional control point. This functionality is useful in cases where you have sent excess funds for one project, but funds are needed immediately for a different project at the same lab.The system would generate a project funds transfer report that will be reviewed by offices in advance of each monthly AFP. This report will compare the project budget with the YTD executed AFP to identify any projects that may be over funded and thus have funds eligible to be transferred to another project. The PFT report will display the basic project details (name, AFP Recipient, and project budget), Costing & AFP, and finally, the AFP Recommendation. The office can complete the PFT by entering a negative value for the project (s) where they are reducing AFP and identifying the project (s) where the funds are being applied. The balance must total to zero for the transfer to be completed.

Deobligations: Within EPIC, the project management module will be used to initiate contract modifications, including those created to process a de-obligation. The system will capture the original source of the funds (B&R Code, appropriation year). If funds obligated from a prior year, when it is re-allotted, it comes back at the congressional control point and loses its connection to the original B&R code. While Offices do have flexibility in determining how to allocate those PYDs, Congress may still request information on how those funds still follow the original congressional intent.

To help facilitate this process, EPIC will include a report to track the status of all prior year deobligations. Offices can use this report to inform decisions on how to allocate PYD funds down to reporting level B&R codes. This report can be used to track when a deobligation has been processed in STARS and to monitor when those funds will become available in the AFP. Additionally the EERE budget office will also be able to indicate if any PYD funds were used for other purposes (e.g. rescissions or other EE-1 priorities).

91 | P a g e

92 | P a g e


1. The system shall allow the office to transfer funds between projects with the same AFP Recipient and Congressional Control Point.

2. The system shall allow the office to initiate funds transfer at any point in the month (does not need to follow monthly AFP process)

3. The system shall generate a notification to the EERE project lead and field entity once the project transfer is completed.

4. The system shall generate a monthly Project Funds Transfer report with the following data fields:

Project title AFP Recipient Name Project Budget Costing Data AFP Data Recommendation

5. The system shall require the following to complete a PFT: Negative amount for projects where you are pulling money Add a positive $ amount to project within the same AFP Recipient Must balance to zero (= NO change in AFP)

93 | P a g e

Program DirectionProcess OverviewProgram direction is the account that used to fund operations within the agency. Program direction contains funding for salaries & benefits, travel, training, awards, support services and other related expenses. Program Direction planning includes working with HQ and field staff to determine high level allocations for each site based on funding needs. At headquarters allocations are determined by the high level categories of salaries & benefits, training, travel, awards, etc. The execution of that allocation typically happens in other official DOE systems. For example, the largest share of program direction funding is salaries & benefits which is automatically executed within the accounting system based on payroll. Training and travel are also processed in other management systems. In short, the scope of program direction in EPIC will be associated with planning allocations and reporting actual expenditures through the DOE accounting system, STARS.

Business RequirementsID Requirement Description1. The system shall allow the office to manage the program direction allocation spreadsheet2. The system shall allow the office plan allocations by object class (salaries, travel, etc),

location, and operations office.3. The system shall allow the office to share the program direction allocation spreadsheet with

multiple users4. The system shall allow reporting of cost& obligations against planned allocations

94 | P a g e

Common ServicesCommon services are capabilities that will be available across all EPIC functional modules. The scope of common services include user account management, user settings and preferences, organization and contact management, information management, office administration, alerts and notifications, email, progress indicators, document management, system administration, user favorites, help desk, search, approval workflow management, help features, frequently asked questions, reports, application lifecycle management, and portal. The EPIC prototype is a useful resource to better understand the intent for how to implement the track changes features, alerts and notifications, progress indicators, help features and frequently asked questions.

Track Changes and Comment CapabilityProcess OverviewCurrently, many of the documents (the SOPO, FRD, etc.) that will be managed in EPIC are developed are word files and templates that are shared electronically via email. As part of the EPIC requirements, these documents will first exist electronically; they will be created and edited directly within the system. The track changes and comment capability is intended to provide users with the ability to review, edit and collaborate on documents within the system with similar ease and familiarity as MS Word. For some processes, EERE is required to maintain records of a document’s revision history and comments. Additionally, the track changes capability should allow multiple users to edit a single document, view the redline changes within the system, and export them to word. Please see system prototype as an example of proposed functionality.

Business RequirementsID Requirement Description1. The system shall allow a user to provide redline edits to a document.2. The system shall record the name of the user making the change.3. The system shall allow users to provide comments within the document4. The system shall allow users to reply to comments within the document5. The system shall allow the document owner to view comments and redline changes made by

any other user.6. The system shall allow the document owner to accept or reject all edits to the document.7. The system shall allow the user to export a redlined view of the document into word.8. The system shall maintain a copy of the redlined version of any document per the

requirements specific in announcements or project management.

95 | P a g e

User Account Management Process OverviewUser account management covers the full scope user management activities including the user access request wizard, user authentication, manage personal user settings, retrieving lost/forgotten passwords.

Access Request: There are three ways to request/inherit permission within EPIC:

New users: through permissions wizard Manually modify user permissions (limited to federal approvers and system administrators) Inherited permissions based on role on project

EPIC will have the ability for users to self-register and to request permissions to access EPIC. Users will make requests through a ‘Permissions Wizard’, which will prompt users to provide information EPIC needs to determine the permissions levels needed (i.e. type of role needed, and specific announcement records, project records, etc. needed). Once the requesting user submits the permissions request, EPIC will route the permissions request to the appropriate Approver (Office, Lab, and Organization). Once the appropriate Approver approves the request, EPIC will grant the role permissions. If the user needs access to a specific object (record), then EPIC will route the request to the appropriate object (record) approver. Approver will be able to see all actions pending his/her approval and to see previously approved permission requests.

The User Settings function allows users to personalize the system to their preferences including setting proxies, email preferences. The manage user functionality is intended to allow the System Administrator to modify users’ accounts within the system. The Forgot Login and Forgot Password feature allows users to request their login and password information in case it is forgotten.

96 | P a g e

97 | P a g e

Business RequirementsID Requirement Description9. The system shall allow EPIC users to request new or additional access rights through the

Permissions Wizard.10. The system shall require EPIC users to answer a series of questions through the permissions

wizard.11. The system shall use the answers to determine the appropriate roles and appropriate

‘objects’ (or records) including specific announcement objects and project objects.12. For new users, the permissions wizard shall allow users to provide basic user information,

including:

First name, Last Name, Email, and

Phone.13. The permissions wizard shall allow users to provide the location(s) they are associated with,

including:

Lab, Other, HQ, GO,

NETL14. If the user selected ‘Lab’ for location, the permissions wizard shall allow users to select the

name of the lab.15. The system shall allow users to update their personal settings.16. The system shall allow users to access their user settings from any page within the system.17. The system shall allow users to select to use the default user preferences.18. The system shall allow external users to update their email address.19. The system shall provide users the option to reset their passwords by retrieving and

accessing a unique password reset link sent to them via email, or by answering security questions created in the permissions wizard.

20. The system shall allow an impersonation mode for Help Desk Administrators to ‘impersonate’ another user’s view based on their roles and permissions.

21. The system shall retain the Help Desk Administrator’s user credentials when impersonating another user when tracking create/edit/delete actions in the system.

22. The system shall record any actions in the system as the logged in user (not the user being impersonated) when the Help Desk Administrator impersonates another users’ view.

Alerts, Notifications, and Progress IndicatorsProcess Overview & MapThroughout the EPIC system, alerts and notifications are provided to facilitate the management of data. Alerts are automatically closed out by completing a specific action in the system. Notifications have to be manually closed out by the user. The Common Services requirements document provides the

98 | P a g e

information about the overarching functionality of alerts across the system. Specific details about what triggers an alert, the alert message, and who receives the alert will be documented in the requirements document related to the associated module.

99 | P a g e

100 | P a g e

Business RequirementsID Requirement Description1. The system shall send an alert to a user when there is an action requiring his or her

attention.2. The system shall clear alerts from a users’ list when the specified action has taken place.3. The system shall for each alert or notification allow the user to directly navigate to the

location in the system where they need to complete the action.4. The system shall allow users to create calendar invitations (.ics file) for alerts and

notifications.5. The system shall send a notification to a user based on predefined criteria.6. The system shall allow users to dismiss alerts or notifications individually or in bulk.7. The system shall allow users to create personal alerts for themselves at the project/lab level

as reminders for actions they need to complete.8. The system shall track progress/completion of all steps required to complete a specific

process regardless of who is responsible for completing the step. 9. The system shall record the responsible user and status.

Office AdministrationProcess OverviewThe office administration functionality encompasses the management of each level within the EERE work breakdown structure. Additionally, in this section office administrators will be able to manage office specific elements, including high priority activities, lists of program managers/team leads as well as specific defaults & deviations.

Business RequirementsID Requirement Description1. The system shall manage the following levels of the WBS structure:

Office (not editable by an office admin) Program Activity Sub-Activity

2. The system shall associate the work breakdown structure with a fiscal year.3. The system shall allow an office administrator to update the work breakdown structure

(WBS) by fiscal year.4. The system shall manage the following levels of the WBS structure:


5. The system shall associate the work breakdown structure with a fiscal year.6. The system shall allow an office administrator to update the work breakdown structure

101 | P a g e

(WBS) by fiscal year.7. The system shall manage the following levels of the WBS structure:


8. The system shall allow an Office Administrator to manage the approvers & roles within their office across the following areas

Program Manager Team Leads

9. The system shall allow an Office Administrator to manage the defaults and deviations for their office (as described in FRD Development)

10. The system shall, require the office administration to enter justification for each deviation.

11. The system shall, if defaults & deviations are modified, require approval on all items that require approval per the FRD

12. The system shall allow the office administrator to route the standard defaults for review and approval as defined the in the FRD.

13. The system shall allow office administrators to add office specific High Priority Activities & Crosscuts

Approval Workflow ManagementProcess Overview & MapFor certain documents, EERE has a specific processes that establish who are required during reviews and approvals. To support EERE processes, EPIC will allow Headquarters Office Administrators to create an EERE template that will serve as the standard to be used for all offices. The EERE workflow will define the minimum steps and roles required for a particular document. This EERE template will be available to all offices for use. Once an EERE workflow is defined, Office Administrators will be able to create a custom template for their own office, based off of the EERE workflow. This custom office template will contain all the minimum required EERE steps, plus any additional steps the particular office would like to add. This Office template will be available only for the office the template is associated with.

When a document is ready to go through a review and approval process, Initiators will then select an EERE template or an Office specific template to use. Once a template is selected, the Initiator will have some limited customization abilities. The Initiator will be able to add additional steps to the workflow, and be able to remove only the steps from the workflow that the Initiator personally added (Note: Office or EERE template steps cannot be removed). Initiators will also assign users to specific steps. Once initiated, EPIC will then process the workflow according the steps defined the workflow.

102 | P a g e

103 | P a g e

Business RequirementsID Requirement Description1. The system shall have standard approval workflows specific to the document type. 2. The system shall allow Office Administrators to create/update/delete office specific approval

workflows. 3. The system shall, when an Office Administrator creates a custom workflow, allow them to

add or delete any step that is not required by EERE policy. 4. The system shall allow a user to set a proxy for their approval items.5. The system shall allow the initiator of a workflow to choose between the EERE approved

workflow or the custom office workflow (if one has been created).

HelpdeskProcess Overview Helpdesk function in EPIC is intended to provide users with the ability to log requests and have the requests processed internally by the EPIC team. This section describes how an end user would create a request within the helpdesk module. Each specific request type is broken out to describe the processes specific to each type.

Business RequirementsID Requirement Description1. The system shall include the following types of help desk requests:

System Requesto Sub-type: Request User Accounto Sub-type: Request Training and Assistanceo Sub-type: Report System Issueo Sub-type: Policy Change Requesto Sub-type: Analytical Data Change

Information Management Data Call (see section Error: Reference source not found) Data/Report Request

2. All help desk requests shall allow the user to input the following information:

Request Type (selected by user) Request Sub-Type (selected by user) Request Text (full description)

Submitter (if user is creating request on someone else’s behalf)3. The system shall allow requestors to see the following help desk request statuses only:

Public Request Status, and Public Status Notes.4. The system shall allow users to search their own requests. 5. The system shall allow the helpdesk administrator to group one or more requests into a

single tickets.6. The system shall allow requests and tickets to be searchable by Helpdesk Administrators by

ID, requestor, date submitted or keyword in the description.7. The system shall show users all requests they have submitted, and all requests submitted on

104 | P a g e

their behalf.8. The system shall allow Help Desk Administrators to re-classify ticket types by associating the

ticket with a different request type.9. The system shall have an administrative Dashboard shall include options that allow the Help

Desk Administrator to:

1. View/classify all requests2. Create new requests3. Create tickets from one or more requests4. Attach requests to existing tickets5. Transfer requests from one ticket to another

10. Help Desk Administrators shall be allowed to create tasks from tickets to assign to other users. The system shall collect the following task information:

Help/FAQProcess OverviewWithin EPIC, page specific help content and FAQ information will be available. Help content will include access to the SOP for each page, outlining where this fits in the overall process. Users will also be able to download training materials from within the EPIC system. The help pane will provide users with the ability to report system issues, view the training materials, view their helpdesk tickets, or submit general helpdesk requests. FAQs will be available that are relevant to the specific page being accessed within the system.

Business RequirementsID Requirement Description1. The system shall store FAQs in the database with associations to each.2. The system shall allow Help Desk Administrators to add questions and answers using a rich

text control; and to associate each Q&A with a module, function, and sub-function3. The system shall display questions that are associated with the particular page’s module,

function, or sub-function in the FAQ pane.4. The system’s help pane shall provide registered users the option to ‘view my help desk

tickets’. When selected, the system shall display the user’s submitted tickets.5. The system’s help pane shall provide registered users the option to ‘report a system issue’

and ‘submit a question’.6. The system’s help pane shall provide registered users the ability to request additional access. 7. The system’s help pane shall provide registered users the option to ‘access user instructions

for this page’. When selected, the system shall display a help content associated with the particular module, function, sub-function, and specific WBS.

Portal

105 | P a g e

Process OverviewThe Portal is provided for users to customize their entry point into the EPIC system. They will be able to select from a list of different widgets, what they would like to display, and location of the widget on their own customizable home page.

Business RequirementsID Requirement Description1. The system shall allow users to select widgets to display on their landing page2. The system shall allow users to specify position of widgets on the home page3. The system shall provide an inventory of all widgets for users.4. The system shall limit availability of widgets by user role.5. The system shall provide a set of widgets that are required to be on the landing page of the

user6. The system shall retain user’s landing page configurations across their sessions7.

Document ManagementProcess OverviewThe new EPIC System shall automatically add finalized versions of documents created within the system (and revisions needed for reference) to the Document Library. The business rules driving the management of these documents are listed in individual section requirements. Documents uploaded by users shall be uploaded to the Document Library per the requirements in their specific module.


ID Requirement Description1. The system shall store documents generated within the system in a single repository.2. The system shall allow draft and final documents developed in the system to be stored in the

document repository.3. The system shall, by default, associate the following attributes/metadata for each document

managed in the Document Repository:

Document context (Announcement, Submission, Award, Project) Owner(s)

List of authors, reviewers, approvers4. The system shall require all documents to be associated with an object.5. The system shall allow users to, where applicable, upload files directly to the Document

Library.6. The system shall store documents generated within the system in a single repository.7. The system shall allow users to view documents stored in the Document Library, as allowed

by their user permissions.8. The system shall allow taxonomy terms to be associated to documents.9. The system shall provide the ability for system administrators to manage the taxonomy

terms for association with documents.

106 | P a g e

Information ManagementProcess OverviewThe information management (IM) process is EERE’s internal process used to manage any type of data request or request for information that will be sent to multiple offices within EERE. The IM module will be used to generate any date request using a pre-defined template, identify recipients of the request, collect responses and monitor status. Additionally, Offices will have the ability to maintain their own list of recipients by category to allow the system to auto-generate distribution lists for each request. Requests and submissions should be maintained within a searchable repository.

Many IM requests are associated with budget, so this module will be tightly integrated with the budget module for creating requests where inputs will made directly into EPIC. The module will also support requests where inputs are tracked through document collaboration on an internal SharePoint site.


ID Requirement Description1. The system shall allow users create an IM request including identifying the category (budget,

lab, IT, legislative affairs), whether response is mandatory or optional, who is required to respond to the IM, when the IM is due, and description of the IM.

2. The system shall allow users to upload templates as part of the IM request. 3. The system shall require IMs to be reviewed the IM board before distribution4. The system shall allow IM board to approve or return an IM for editing. 5. The system shall send a notification to IM POCs when the IM is sent.6. The system shall allow users to manage the IM POC by office and category7. The system shall allow users to manage the IM POC by office.8. The system shall allow users to submit a response to the IM request. 9. The system shall track the completion status of all IM requests.

107 | P a g e

Definitions

Name or Acronym Definition301 Congressional Notification Depending on the size of the Announcement and

awards resulting from the Announcement, EERE is required to notify Congress prior to selection notification. Prior to announcing selection notification, a 301 Congressional Notification is required unless the award(s) will use FY14 or later dollars where the action is not multi-year and is less than $1M; FY14 or later dollars where the action is multi-year, is fully funded, and is less than $1M; or FY12 or FY13 dollars where the action is multi-year, and is less than $1M.

AFP Recipient Identifies who the intended recipient of the funding is. AFP recipients are either a lab or site office.

Allowable Deviation

Any deviation from standard EERE practice must be approved by the Selection Office (SO) prior to being reviewed by the Contracting Officer. The allowable deviation is defined in the Announcement Documentation.

Announcement Manager The Announcement Manager is a functional role typically carried out by a Technology Manager, Project Manager or, in rare circumstances, a Technical Project Officer. The Announcement Manager is responsible for developing the FOA, leading the evaluation process and negotiation of new awards.

Appropriation A statute that provides budget authority for Federal agencies to incur obligations and to make payments out of the Treasury for specified purposes.

Approved Funding Plan

The Approved Funding Plan (AFP) transfers funds from EERE to the DOE office responsible for administration of a particular national laboratory. Funds transfers are initiated by EERE and occur monthly through DOE’s CFO. Funds are obligated on the M&O contract by the contracting officer.

108 | P a g e

Assistance Agreement

Legally binding document containing signatures of the government agent and the performer’s authorized representative. Contains basic award information such as award number, period of performance, federal funds/cost share, etc.

Award Negotiations (FA)

The process, starting after Selectees are notified of selection, where EERE and the Selectee work together to negotiate and finalize the award package, including the Special Terms and Conditions, SOPO and Milestone Summary Table, and Budget.

Basic and Applied Research and Development Initiative (BARDI)

A process for the DOE National Labs to report financial data into the Corporate Planning System (CPS) at the agreement level rather than at the higher (contract) level reported to DOE’s STARS system. A lab agreement in CPS may contain multiple tasks.

Budget Budget means the cost expenditure plan submitted in the Application, including both the EERE contribution and the Applicant Cost Share.

Budget and Reporting (B&R)Code The B&R code is the coding structure that parallels approved DOE PPAs. The codes are used for executing the budget; reporting actual obligations, costs, and revenues; and controlling and measuring actual versus budgeted performance.

Budget JustificationThe application documents that justify and support the costs in the budget, broken down by cost category.

Budget Period

The interval of time, specified in the award, into which a project is divided for budgeting and funding purposes. Typically, budget periods are established on an annual basis. In some cases, shorter or longer budget periods may be established for compelling programmatic or administrative reasons, such as to allow for project phases not evenly divisible with 12-month increments or to provide program personnel with logical decision points to evaluate whether the project should proceed. Project periods less than 12 months should have co-extensive budget and project periods.

CI Solicitation Notification Depending on the size of the Announcement and awards resulting from the Announcement, EERE is required to notify Congress prior to Announcement publication. FOAs over $50 million (total value) require a 72 hour CI Solicitation Notification prior

109 | P a g e

to publication.

Closeout

A phase after the period of performance has ended. During this phase all outstanding contractual issues are completed and documented to retire the financial assistance award. This phase may include an audit.

Code of Federal Regulations (CFR)

A collection of regulatory rules put out by federal agencies. Each agency's rules are organized into "parts" and "subparts," each of which touches on a discrete topic such as financial assistance, NEPA matters, etc. Rules in the CFR do not supersede statutory laws, though they may clarify a statute if authorized by the statute.

Concept Paper Project summaries submitted by applicants that describe the proposed project. The applicant’s purpose in developing a Concept Paper is to capture the interest of EERE and demonstrate that the idea they are proposing is worthy of further consideration. EERE will provide feedback on the Concept Papers, which helps the applicants develop more competitive applications and determine whether to submit a Full Application.

Conflict of Interest (COI) A personal, professional, organizational, or financial relationship or interest that unduly impacts the impartiality of a party. Conflicts of Interest can be actual (i.e., a relationship actually exists that affects a party's impartiality) or apparent (i.e., a relationship does not actually result in a conflict, but the nature of the relationship is such that a third party with an understanding of the facts would have cause to question the impartiality of a party to the relationship). For the purposes of maintaining the integrity of the procurement process, EERE treats actual and apparent conflicts equally.

Contract Identifier (CID)

The unique identifier assigned to a financial assistance award. Lab awards also have a single CID for the entire M&O contract, e.g., one CID for all NREL activities.

Contract Specialist (CS)

This position performs and develops policies and procedures for professional work involving the procurement of supplies, services, construction, or research and development using formal advertising or negotiation procedures; the evaluation of contract price proposals; and the administration or termination and close out of contracts.

110 | P a g e

Contracting Officer (CO)

A Contracting Officer is the DOE official authorized to execute awards on behalf of DOE and who is responsible for the business management and non-program aspects of the financial assistance process. 10 CFR 600.3.

Cooperative Research and Development Agreement (CRADA)

An agreement between two or more parties to collaborate on a specific research project. No money exchanges hands with this type of agreement. A CRADA may be entered into by the U.S. Government with a company, university, not-for-profit group, or state or local government. Under a CRADA arrangement, a U.S. Government laboratory may contribute personnel, equipment and/or facilities to the effort, but it may not contribute funding to the non-government partner. The collaborating party may contribute the same and may also provide funds to the Laboratory for salaries and other purposes (such as a "funds-in" CRADA). Research results obtained in the performance of a CRADA are protected from release for five years.

Corporate Planning System (CPS)

EERE Corporate System: A web-based budget and program execution system for EERE. CPS manages spend plans, portfolio information, Annual Operating Plans (AOPs), performance milestones, budget execution, project tracking, and automated program guidance letters. CPS tracks funding and performance milestones at the agreement level and aggregates data to higher levels.

Cost Share

The performer's contribution in a financial assistance award; reasonable, allocable, and allowable costs borne by the performer. In a cost‐share agreement, the non-government cost-share amount is the value that the recipient is responsible for. The performer's cost-share type may be in the form of cash, in-kind contributions, or a combination of the two.

Crosscut Activities where the goal and/or objectives cross more than one function or organizational entity.

Data Universal Numbering System (DUNS)

Data Universal Numbering System (DUNS) Number” is a unique nine-character identification number issued by Dun and Bradstreet (D&B). Organizations must have a DUNS number prior to registering in the SAM.

DeliverableA required report or document that is submitted by the Recipient in accordance with the Federal Assistance Requirements Checklist.

111 | P a g e

Determination of Non-Competitive Financial Assistance (DNFA)

A set of guidelines established by DOE for deciding whether a grant or cooperative agreement may be awarded on a non-competitive basis. Grants and cooperative agreements may be awarded on a non-competitive basis only if the application satisfies one or more of the selection criteria in 10 CFR 600.6I 1-8. The responsible program official or Project Officer (PO), in consultation with the CO/CS and Legal Counsel, must prepare a DNFA that sets forth the basis for the proposed non-competitive award and ensure that the proper reviews, concurrences, and approvals are received. (For additional information, see the Financial Assistance Guide, Subchapter 2.8, Non-Competitive Financial Assistance (Oct. 2006, Policy Flash 2007-03.)

DOE Share The dollar value of federal share of the total award.

Early Reallottment Request A request from a program office to have funding that is unobligated by the end of the FY to be reallotted (made available for obligation) in Q1 of the new year rather than the traditional process of reallotting funds in Q2 of the new year.

EERE Environmental Questionnaire (EQ-1)

The EQ-1 form is used by EERE NEPA staff to gather project information that will be needed to perform a NEPA review. The form asks a Federal funding recipient to provide details about their proposed project and the potential environmental impacts associated with the execution of their project.

EERE Project Lead

The project lead carries out projects by defining the work, providing technical direction, ensuring satisfactory project progress and completion, and reporting project information to the program manager and staff. Controls planning, execution and reporting of the project’s activities and resources to ensure that established cost, time, and scope conditions are met. The project lead and technology managers perform equivalent roles in deployment and research programs, respectively.

Environmental Questionnaire Verification Checklist (EQ-2)

The EQ-2 form is used to help ensure the EERE NEPA staff receive a complete NEPA package in order to make a NEPA determination. The preparer of the EQ-2 reviews the information submitted by the Federal funding recipient and determines whether the information is complete & accurate.

Federal Consensus Board (FCB) The primary responsibility is to determine which

112 | P a g e

applications are technically acceptable. In carrying out that responsibility, the Board reviews the findings of the independent reviewers, reaches consensus as to the appropriate rating/score for each application and ultimately recommends selections to the Selection Official. The Federal Consensus Board is typically only the FOA Manager.

FFRDC (also referred to as a National Lab or Lab)

Federally Funded Research and Development Center; A government-sponsored operation that exists for the purpose of carrying out various functions related to both basic and applied research and development on behalf of the Government. Typically, most or all of the facilities utilized in an FFRDC are owned by the Government, but the operations are not always managed by the Government; an FFRDC may be managed by a University or consortium of Universities, other not-for-profit or nonprofit organization, or a for-profit organization, with the Government performing an oversight function. FAR 2.101

Financial Assistance

The transfer of money or property to a recipient or sub recipient to accomplish a public purpose of support or stimulation authorized by Federal statute through Grants or Cooperative Agreements and sub-awards. For EERE, it does not include direct loans, loan guarantees, price guarantees, purchase agreements, Cooperative Research and Development Agreements (CRADAs), or any other type of financial incentive instrument.

Financial Assistance Reporting Checklist (FARC)

A document that provides the specific and required management and scientific/technical reports. Consideration should be given to the scope, complexity, duration of the project, and program legislation, when establishing reporting requirements, and identify any special reporting requirements in the block, entitled “Special Instructions.”

Funding Opportunity Announcement (FOA) A publicly available document by which a Federal agency makes known its intentions to award discretionary grants or cooperative agreements, usually as a result of competition for funds. FOAs may be known as FOAs, notices of funding availability, solicitations, or other names depending on the agency and type of program. See 10 CFR 600.8 for more information.

113 | P a g e

Funding Requirements Document (FRD) The purpose of the FOA Requirements Document (FRD) is to enable effective planning for competitive Funding Opportunity Announcements (FOAs), the evaluation and selection of applications, the negotiation of awards, and the management of resulting projects. The FRD facilitates close collaboration between Technology Offices and the Office of Business Operations, including Golden Service Center (GSC) and National Energy Technology Laboratory (NETL). In addition, the FRD enables early engagement with and advance approval from responsible executives (e.g., Director, Deputy Assistant Secretary, and Assistant Secretary) and stakeholders within EERE (especially the Office of Strategic Programs) and DOE, including the Office of Public Affairs and the Office of Congressional and Intergovernmental Affairs.

Grants Management Specialist/Contract Specialist (GMS/CS)

A DOE official responsible for the day-to-day administration of a financial assistance award instrument on behalf of the Contracting Officer (CO). This official serves as the routine interface between applicants and the U.S. Government. The comparable role for acquisitions is Contract Specialist.

Greenlight Process An internal DOE process related to the FOA development, selection, and award process that ensures information, such as funding amounts, purpose of funding actions, and project details, are shared with the DOE Office of Public Affairs, Office of Congressional and Intergovernmental Affairs, and the Office of the Chief Financial Officer prior to public release of FOAs, selections and awards to avoid unauthorized or inopportune public releases of information on funding actions.

High Priority Activity (HPA) An area that the EE Budget Office defines as high priority.

Interagency Agreement (IA)

A written agreement entered into between a DOE office and the appropriate official of another federal agency that requires specific goods to be furnished or tasks to be accomplished by one agency in support of the other.

Interagency Agreement (IA)

A written agreement entered into between a DOE office and the appropriate official of another federal agency that requires specific goods to be furnished or tasks to be accomplished by one agency in support of the other.

114 | P a g e

ITD Inception to date

Lab Award

Laboratory Projects are documents representing an agreement between a National Lab and its sponsoring EERE offices describing the specific tasks that will be undertaken during the fiscal year, the planned budget for each of those activities, deliverables, and milestones or performance metrics for the activities.

Lab Calls Funding opportunities where eligibility is restricted to FFRDCs.

Lab ConsortiumConsortia entail associations of research partners, advisors, funding agents, and other stakeholders for the purpose on engaging in a joint project.

Letter of Intent (LOI) An optional step in a FOA that requires the applicant to provide basic information about their organization and application. EERE uses the Letter of Intent submissions to predict the number of reviewers needed for the concept paper and full application phases.

Merit Review The process whereby the reviewers evaluate the technical merit of the applications based on pre-established technical review criteria. Merit review is a component of the overall evaluation and selection process.

Merit Review Advisory Report (MRAR) This documents the Merit Review process of each FOA. It contains results of applications, and tracks conflicts of interest.

ModificationAn official alteration to an existing solicitation, award or FOA. Also known as an amendment in financial assistance.

Mortgage The unobligated portion of the DOE Share on a Financial Assistance Award.

Multi-Performer Project A single project with multiple lab partners.

National Environmental Policy Act of 1969 (NEPA)

An Act of Congress signed into law in 1969 by President Richard Nixon that establishes a national policy for the environment, provides for the establishment of a Council on Environmental Quality (CEQ) and requires environmental reviews of major federal actions. The NEPA review process is applied early in the planning stages for DOE solicitations.

115 | P a g e

NEPA Determination (ND)

The ND form is prepared by a NEPA Compliance Officer and is used to document the level of NEPA review (categorical exclusion (CX), environmental assessment (EA), environmental impact statement (EIS) required for a project.

Non-Disclosure Agreement (NDA) An NDA creates a confidential relationship between the parties to protect any type of confidential and proprietary information or trade secrets. As such, an NDA protects nonpublic business information.

Notice of Intent (NOI) A Notice of Intent is an announcement used to communicate the intention to issue a FOA.

Notice of Technical Assistance (NOTA) A Notice of Technical Assistance is an announcement used to solicit applications for technical assistance

Obligations (Obs)

A financial condition that is realized when a legal responsibility is incurred for which the Department must expend funds in future for goods and services that have been contractually ordered or consumed.

Overtarget

Overtarget projects are ones with no funding set aside, but planned in the event of additional appropriations. A project may be marked or unmarked overtarget if planned funding levels change. Overtarget projects are not included in final AOP documents.

Portfolio Management

The centralized management of one or more portfolios, which includes identifying, prioritizing, authorizing, managing, and controlling projects, programs, and other related work, to achieve specific strategic business objectives.

Project

The set of activities described in an Application, State plan, or other document that is approved by EERE for Financial Assistance (whether such Financial Assistance represents all or only a portion of the support necessary to carry out those activities).

Public Announcement Inform the public of DOE's efforts, promote scientific innovation, communication DOE's mission and progress, and reach a wide audience

Request for Information (RFI) A process whereby EERE seeks information on prospective projects and technologies from potential grantees and/ or vendors.

Selection Statement The document that records the Selection Official's

116 | P a g e

selection decisions. The Selection Statement and Analysis must record which projects the Selection Official selected for: award negotiations, alternates and Pre-Selection Interviews (if applicable). The Selection Official must address rationale for the selection decisions including the justification for the application of program policy factors.

Spend Plan (Project)

A plan that delineates how federal funds are to be expended for work to be performed over the entire project period of performance. A project spend plan is normally in tabular or spreadsheet format and would reflect planned expenditures at the project level on a monthly basis, such that comparison can be made to monthly STARS financial data. The project spend plan is typically a subset of the project cost plan, which would include cost share and greater cost details associated with lower level Work Breakdown Structure elements.

Standard Accounting and Reporting System (STARS)

DOE Corporate System: The Standard Accounting and Reporting System (STARS) provides the Department with a comprehensive financial management system that is the foundation for linking Departmental budget formulation, budget execution, and financial accounting with financial reporting, cost accounting, and performance measurement.

Statement of Project Objectives (SOPO) The SOPO and Milestone Summary Table are created from information provided by the Applicant in the Work plan submitted with the Full Application, and is finalized during award negotiations. The SOPO is the baseline document for both the Recipient’s project team and EERE to measure and evaluate the progress of the project. It describes the overall objectives of the project, provides a description of the tasks to be performed, and identifies the milestones and go/no-go decision points of the project. Failure to achieve the outcomes, milestones, and decision points as specified in the SOPO and Milestone Summary Table may result in the discontinuation of a project. The final, agreed-upon SOPO and Milestone Summary Table are incorporated into the award attachments, making the goals and milestones therein a binding part of the award.

Strategic Integrated Enterprise Procurement System (STRIPES)

DOE Corporate System: The Strategic Integrated Procurement Enterprise System (STRIPES) is the

117 | P a g e

procurement and contracts management component of the iManage program and encompasses both acquisition and financial assistance.

Subcontractor(s) Subcontractor(s) are organizations other than the prime contractor performing work on a project.

Sub recipient / Sub awardee / Subcontractor

Sub recipient means the legal entity to which a sub award is made and which is accountable to the recipient for the use of the funds or property provided.

System for Award Management (SAM)

The primary database which collects, validates, stores and disseminates data in support of agency missions. All Selectees must be registered in the System for Award Management (SAM) in order to receive Federal awards.

Terms and Conditions

Administrative requirements (cost share, NEPA restrictions, payments, etc.) incorporated into the award. May include conditions that must be met within a prescribed timeline, or a condition to safeguard taxpayer dollars in the case of high risk recipients. The document is generated by the GMS/CS and includes input from Legal Counsel, Cost Price, and NEPA.

Unobligated Balance The portion of budget authority or CY AFP that has not yet been obligated.

Work Breakdown Structure (WBS) A breakdown of a project into those sub elements that define the required work activity. The WBS provides a consistent organization framework throughout the project, and is a deliverable‐oriented grouping of project elements that organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work.

118 | P a g e