Tech Project
Tech Project
Tech Project
MEASUREMENT
SENSITIVE
DOE G 413.3-14
9-12-08
Information Technology
Project Guide
[This Guide describes suggested nonmandatory approaches for meeting requirements. Guides
are not requirements documents and are not construed as requirements in any audit or appraisal
for compliance with the parent Policy, Order, Notice, or Manual.]
TABLE OF CONTENTS
1.2 Scope........................................................................................................................1
APPENDIX B— ACRONYMS.....................................................................................B-1
1.1 Purpose
This Guide provides the Department of Energy (DOE) recommended guidelines to ensure that
the acquisition of information technology (IT) capital assets is performed in compliance with
DOE O 413.3A, Program and Project Management for the Acquisition of Capital Assets, dated
7-28-06. This guide is written for the benefit of the federal project director, the IT project
manager, the integrated project team, the program manager (if applicable), the program office,
and the acquisition executive.
The guide is dissimilar to other DOE 413.3-series guides because rather than focusing on a single
acquisition process topic or phase, the guide covers all process phases where IT-specific
guidance is relevant and necessary.
This Guide is intended to be used in tandem with other DOE 413.3-series guides. Section 1.3
provides exclusive guidance for IT-specific project requirement areas identified in DOE O
413.3A and IT-specific guidance for requirement areas more fully addressed in other DOE
413.3-series guides. In instances where requirement areas are applicable to IT projects but
wholly addressed in other DOE 413.3-series guides, Section 1.3 refers the reader to the
appropriate guide. Requirement areas not applicable to IT projects are omitted from the Guide.
Section 2.0 contains supplemental guidance for the planning, programming, budgeting, and
acquisition of IT capital assets consistent with the Clinger-Cohen Act of 1996, P.L. 104-208, and
the following Office of Management and Budget (OMB) Circulars
• OMB Circular A-11, Preparation, Submission, and Execution of Budget, Part 7, Planning,
Budgeting, Acquisition and Management of Capital Assets;
The source material identified in Section 2.0 should be considered the primary point of reference
and requirements related to the information provided therein.
1.2 Scope
The guidance provided herein applies to any departmental IT project satisfying the applicability
criteria set forth in DOE O 413.3A.
Figure 1 illustrates how these processes are interrelated, spanning from strategic planning to
individual IT projects.
In essence, DOE has a mission to accomplish and, in doing so, has established priorities as stated
in the DOE Strategic Plan and the DOE Information Resource Management (IRM) Strategic
Plan. These priorities and supporting functions and processes and related IT assets are captured
8 DOE G 413.3-14
9-12-08
in the DOE EA and documented as the baseline and target EA. In particular, a transition plan is
documented to ensure that the mission priorities are achieved.
In addition, CPIC processes have been established to ensure that investments and projects are
mapped to mission priorities, that funding is budgeted for these investments and projects, and
that their progress is tracked. The CPIC process also includes a mechanism for coordinating
with budget processes to ensure that IT investments and priorities are included, are consistent
with the DOE EA, and are consistent with acquisition data, especially the Exhibit Form 300
prescribed by OMB Circular A-11. Once the Exhibit Form 300s or projects are approved and
funding is provided, project management and systems engineering processes are established to
ensure successful completion.
The following sections provide more detail into these management processes and how they
integrate or provide their unique contribution to the successful accomplishment of mission
priorities.
Strategic planning is the process by which the Department and the Office of the Chief
Information Officer (OCIO) determine future direction and identify the resources and
transformational agendas needed to meet that direction. The DOE Strategic Plan is the roadmap
to address the energy, environmental and nuclear security challenges for DOE. The IRM
Strategic Plan outlines IT strategic goals, outcomes, priorities, and the means for accomplishing
the goals. The IRM Strategic Plan communicates the linkage of IT strategies to the overall
Departmental Strategic Plan, and thereby, ensures proper guidance and technological support to
accomplish DOE’s critical-mission requirements.
IRM strategic planning precedes the selection of IT investments to ensure that annual
investments and operations fully support organizational goals and missions. The annual selection
of IT investments is completed in coordination with the budget-formulation process under the
direction of the CIO and Chief Financial Officer (CFO) to ensure that IT investment needs and
requests are fully integrated into DOE’s annual budget request.
DOE EA Program
The DOE EA Program helps ensure compliance with OMB Circular A-130 and the
Clinger-Cohen Act by promoting standard architectural practices, providing a framework for
corporate systems modernization, and establishing an enterprise architecture vision aligned with
the Department’s strategic goals. It has defined the foundations, baseline, guidance, standards,
and vision for the development and implementation of an architecture-based process for making
IT investment decisions. A primary tenet of the DOE enterprise architecture methodology is that
business needs drive the need for applications and technology. The architecture is used to ensure
that legacy and development systems are aligned with key business, technical, and operational
criteria.
DOE G 413.3-14 9
9-12-08
EA analysis feeds into the CPIC process. In the selection process, the IT investment is analyzed
to assure it is compliant with the EA. The EA is also aligned with the annual budget cycle and
provides updates that further define the Baseline and Target architectures based on decisions
made in the IT CPIC process.
EA Process
An EA is the explicit description and documentation of the current and desired relationships
among business and management processes and the technology that supports the processes. An
EA describes the current and target architectures, as well as the transition strategy. The EA
strengthens management of the Department’s information and the effective use of it.
For each DOE IT project, a requirement for the project’s architecture to be in alignment and
compliance with the DOE target EA should be included in the project’s Requirements
Specifications. This, like all other project requirements, should be included in the solution and
tracked through to implementation, and should be included in the traceability matrix to ensure an
audit trail and closure.
The program office should work collaboratively within the DOE EA framework and coordinate
efforts to ensure the integration of the Department-wide architecture as well as architectures
specific to individual Departmental elements. During the Control Phase, the investment should
be monitored throughout its development life cycle including focus on how well the technology
(design) aligns with the enterprise technology architecture (infrastructure). These assessments
compare the final design specifications of the investment to the higher level common design
components of DOE’s EA.
More information, including the DOE EA Guidance and Practice document, is available on the
OCIO web site under the “Enterprise Architecture” tab.
The IT projectlife cycle approach is the process by which a project is planned, monitored and
evaluated. It covers all activities conducted within the scope of the entire project, from project
startup to project close-out. An IT project should follow a defined systems development life
cycle (SDLC) methodology that communicates expectations for common activities that are to be
included in an IT project. An SDLC life cycle provides defined phases for an IT project. Further
guidance is provided in Section 2.2.
CPIC, as defined in Section 53 of OMB Circular A-11, is the same as capital programming and
is a decision-making process for ensuring that IT investments integrate strategic planning,
budgeting, procurement, and the management of IT in support of agency mission and business
needs. The CPIC process is a life cycle for capital projects including major IT systems projects.
The DOE CPIC process is iterative with inputs coming from across the Department and outputs
feeding into the budget and control process.
10 DOE G 413.3-14
9-12-08
CPIC is a systematic approach to managing the risks and returns of IT investments for a given
mission. It is an integrated management process which provides for the continuous selection,
control, and life-cycle management and evaluation of IT investments and is focused on achieving
a desired business outcome. CPIC is the program management life cycle for DOE’s IT
investments. The relationship between project management phases and Critical Decisions, CPIC
phases and DOE SDLC phases is depicted in the table below.
Select—The process the Department uses to determine priorities and make decisions about
which initiatives (new and ongoing) will be funded and included in the IT portfolio.
Evaluate—Once initiatives are fully implemented, actual versus expected results are evaluated to
assess the initiative’s impact on strategic performance; identify any changes or modifications to
the initiative that may be needed; and revise the investment management processes based on
lessons learned.
More information, including the DOE CPIC Guide, is available on the OCIO web site under the
“IT Capital Planning” tab.
It is the policy of DOE when acquiring IT solutions to integrate project management, financial
management, acquisition management, and quality oversight processes into a cohesive process to
achieve programmatic goals. Strong acquisition strategy mitigates risk to the Federal
Government, accommodates Section 508 of the Rehabilitation Act as needed, and uses contracts
and statements of work (SOWs) that are performance based. The implementation of the
acquisition strategy should be clearly defined.
DOE G 413.3-14 11
9-12-08
Various drivers identify needs for new or improved IT solutions that are aligned with DOE
mission and business goals and objectives. Through activities such as conceptualization,
functional analysis, feasibility study, business case analysis, and design synthesis, these needs
are translated into high-level requirements that become input to the solution development
process. High-level requirements are strategically mapped against the current system baseline
and functional gaps are identified. A decision may be made to either develop the solution “in-
house” by DOE Federal or contractor personnel or acquire it via a DOE acquisition vehicle from
industry vendors that are expert in a particular solution development.
Once the planning activities for the acquisition strategy have been conducted, the project should
be approved and funded based on OMB Circular A-11, Sections 53 and 300, via the submission
guidelines as outlined in the fiscal year reporting instructions. Note that not all projects initiated
through the Acquisition Strategy result in projects that move beyond this point and into
development of an IT solution.
Computer security requirements should be developed in conjunction with the system owner’s
computer system security officer and other stakeholders who provide competent input in the
information system security area. This involvement affords early determination of classifications
and levels of access protection required for the product.
Applicable security controls and procedures should be implemented to ensure data integrity and
protection from unauthorized disclosure, particularly during development efforts. The
organization that owns the data defines the data classification. The project team should be aware
of all the types of data and of any classified or proprietary algorithms used in the product.
3. Coordinate with the owner of the host platform to identify existing supporting computer
security controls, if applicable.
Security requirements should be documented in the system security plan and incorporated into
the requirements specification.
The cyber security C&A should be completed before the system is placed into operation. The
C&A process ensures that security controls are selected and properly implemented to adequately
protect the system and its information. Certification ensures that the controls are tested and
deficiencies are documented in Plans of Action and Milestones (POA&M) where they are
tracked to closure. The accreditation process ensures a senior official assesses any residual risk
and authorizes the system to go into production. C&A tasks include planning, documenting, and
testing activities that need to be addressed in all stages of the system development life cycle.
More information is available on the OCIO web site under the Cyber Security tab.
For systems processing sensitive personal information, contact the Office of Management's
Freedom of Information Office Act and Privacy Act Division for coordination and assistance in
complying with policy and guidance.
More information is available on the Office of Management web site under the FOIA/Privacy
Act tab.
A life cycle is the process for how a project is planned, monitored and evaluated from startup to
close-out. A project should follow a defined SDLC methodology that communicates expectations
DOE G 413.3-14 13
9-12-08
for common activities that are to be included in an IT project. The DOE Life Cycle standard,
DOE G 200.1-1, Software Engineering Methodology (SEM), provides a generic, adaptable IT
systems development life cycle. The SEM integrates systems engineering, software engineering,
project management, and quality assurance processes into a life cycle that is controllable,
predictable, and repeatable. The life cycle processes are compatible with Departmental policy on
development and maintenance of information technology projects, and compliant with Level 2
and 3 key process areas in the Software Engineering Institute’s Capability Maturity Model.
The life cycle processes are divided into stages, activities, and tasks that can be combined or
modified to tailor as necessary to fit the needs of various types and sizes of projects.The
following table compares the SEM to the DOE O 413.3A critical decision requirements.
The SEM includes a Stage Exit process which is similar in principle to the Critical Decision
Points. The Stage Exit process ensures that an IT project meets the DOE and project standards
and milestones identified in the project plan.
The Stage Exit is conducted by the project manager with the project stakeholders, (e.g., system
owner and the following points of contact: user, quality assurance, security, architecture and
standards, project manager’s manager, and platform.) It is a high-level evaluation of all work
products developed in an SDLC life cycle stage.
It is assumed that each deliverable has undergone several peer reviews, as appropriate, prior to
the Stage Exit process. The Stage Exit focuses on the satisfaction of all requirements for the
stage of the SDLC life cycle, rather than the specific content of each deliverable.
14 DOE G 413.3-14
9-12-08
The amount of project and system documentation required throughout the life cycle is
commensurate with project size and complexity. The life cycle methodology should
communicate the documentation requirements and provide guidelines for life cycle adaptability
based on project attributes and development methodology.
Figure 2 below shows the SEM life cycle phases with deliverables and activities identified by
stage of development. This figure presents the minimum set of documentation contained within
the SEM. The SEM is exclusive in stating where documentation is initiated and when this
documentation should be updated; all documentation is subject to update and revision throughout
the project’s lifecycle.
9-12-08
DOE G 413.3-14
15
Planning
The planning stage is the first stage in the life cycle. It is the time when the scope and feasibility
of the project is determined. The team focuses on identifying what the project will automate, and
whether developing an IT solution makes sense from business, cost, and technical perspectives.
If the project is feasible, then time, cost, and resource estimates are formulated and risk factors
are assessed. The information gathered in this stage is used to plan and manage the project
throughout its life cycle.
Requirements Definition
The primary goal of this stage is to develop a basis of mutual understanding between the system
stakeholders and the project team about the requirements for the project. The result of this
understanding is an approved Requirements Specification that becomes the initial baseline for
product design and a reference for determining whether the completed product performs as the
stakeholder requested and expected. Each requirement identified in the Requirements
Specification should be traceable to one or more design entities. This traceability ensures that
the product will satisfy all of the requirements and will not include inappropriate or extraneous
functionality.
Functional Design
The functional design process maps the “what to do” of the Requirements Specifications into the
“how to do it” of the design specifications. During this stage, the overall structure of the product
is defined from a functional viewpoint. The focus is on the functions and structure of the
components that comprise the products. The goal of this stage is to define and document the
functions of the product to the extent necessary to obtain the stakeholders’ understanding and
approval and to the level necessary to build the system design.
System Design
The goal of this stage is to translate the user-oriented functional design specifications into a set
of technical, computer-oriented system design specifications; and to design the data structure and
processes to the level of detail necessary to plan and execute the next stages of the life cycle.
Construction (Programming)
The goal of this stage is to translate the set of technical, computer-oriented system design
specifications into a language the computer can understand and execute. Construction involves
coding, validation and unit testing by a developer. Any hardware or software procured to
support the construction effort is installed. The activities in this stage result in the transformation
of the system design into the first complete, executable representation of the product.
Integrating and testing activities should focus on the interfaces between and among the
components of the product. In this stage, components are integrated and tested to determine
DOE G 413.3-14 17 (and 18)
9-12-08
whether the product meets predetermined functionality, performance, quality, interface, and
security requirements.
Installation and acceptance of the product are initiated after the system test has been successfully
completed. The objectives of the activities in this stage are to verify that the product meets
design requirements and to obtain stakeholder acceptance and approval of the product and assure
the product is fully operational. At the conclusion of this stage, the responsibility of the IT
Solution is formally transferred from the project team to the system owner and maintenance
staff.
Maintenance
The maintenance stage is the iterative processes for maintaining and improving the IT solution
once it has been placed in production. These processes allow the maintenance team to better
plan, optimize use of resources, take advantage of scale and better control outcome in terms of
both schedule and product quality.
More IT project management information, including the SEM and Stage Exit Process documents,
is available on the OCIO web site under the IT Project Management tab.
DOE G 413.3-14 Appendix A
9-12-08 A-1
APPENDIX A—REFERENCES
1. American National Standards Institute/Electronic Industries Alliance Earned Value
Management System Standard (ANSI/EIA-748-A-1998).
4. DOE M 470.4-1 Chg 1, Safeguards and Security Program Planning and Management,
dated 3-7-06.
9. DOE O 413.3A, Program and Project Management for the Acquisition of Capital Assets,
dated 7-28-06.
11. DOE N 206.5, Response and Notification Procedures for Data Breaches Involving
Personally Identifiable Information, dated 10-9-07.
14. DOE O 471.3, Identifying and Protecting Official Use Only Information, dated 4-9-03.
15. U.S. Department of Energy’s Guide to IT Capital Planning and Investment Control, dated
September 2007.
17. P.L 105-220, section 508, The Rehabilitation Act, as amended by the Workforce
Investment Act of 1998.
22. Office of Management and Budget (OMB) Circular A-11, Preparation, Submission, and
Execution of the Budget, dated 6-26-08.
23. OMB Circular A-123, Management’s Responsibility for Internal Control, dated 12-21-04.
24. OMB Circular A-130, Transmittal Memorandum #4, Management of Federal Information
Resources, dated 11-28-00.
25. OMB Memorandum 05-23, Improving Information Technology (IT) Project Planning and
Execution, dated 8-4-05.
APPENDIX B—ACRONYMS
ANSI/EIA American National Standards Institute/Electronic Industries Alliance
ATO authority to operate
BY budget year
C&A certification and accreditation
CD Critical Decision
CFR Code of Federal Regulations
CFO Chief Financial Officer
CPIC capital planning and investment control
CY current year
D/M/E development/modernization/enhancement
DOE Department of Energy
EA Enterprise Architecture
EVMS Earned Value Management System
FOIA Freedom of Information Act
IPT integrated project team
IRM Information Resources Management
IT information technology
O order
OCIO Office of the Chief Information Officer
OECM Office of Engineering and Construction Management
OMB Office of Management and Budget
PCSP program cyber security plan
PIR post implementation review
POA&M plans of action and milestones
PY prior year
SDD system description document
SDLC systems development life cycle
SEM Systems Engineering Methodology
SOW statement of work
TPC total project cost
DOE G 413.3-14 Appendix C
9-12-08 C-1
APPENDIX C—DEFINITIONS
1. Capital Planning and Investment Control (CPIC). A decision-making process for making
sure IT investments integrate strategic planning, budgeting, procurement, and the
management of IT in support of agency missions and business needs. The term comes
from the Clinger-Cohen Act of 1996 and generally is used in relationship to IT
management issues. (Source: Office of Management and Budget (OMB) Circular A-11,
Preparation, Submission, and Execution of the Budget, dated 6-26-08.)
3. Departmental Element.
b. First-tier in the field is managers of the eight operations offices, managers of the
three field offices, and the Administrators of the Power Marketing
Administrations.
e. Field element is a general term for all DOE sites (excluding individual duty
stations) located outside of the Washington, DC, Metropolitan Area. (Source:
DOE Glossary in the Directives System.)
4. Enterprise Architecture (EA). A business-driven plan that describes the current state,
future vision, and transitional states of an operation presented in terms of: strategy and
performance; business; applications and services; technology; data; and security, all at the
end of a two-to-five year planning horizon.
9. Office of the Chief Information Officer (OCIO). Responsible for ensuring that IT is
acquired and information resources are managed consistent with statutory, regulatory,
and Departmental requirements and priorities.
11. Risk Management. An approach to problem analysis that is used to identify, analyze,
prioritize, and control risks. (Source: DOE Software Engineering Methodology, 5-21-
1997.)
12. Software. All computer programs or procedures or rules and associated documentation
pertaining to the operation of a computer system customized for DOE use, proposed for
use, under development, or being maintained and used, whether developed in-house,
licensed from a commercial vendor for customized use, obtained from another
organization, or otherwise acquired. Types include:
a. administrative/business-oriented programs,
b. scientific/engineering software,
15. Unit Testing. A process for evaluating individual hardware or software units or groups of
related units. The isolated testing of each flow path of code with each unit. The expected
output from the execution of the flowpath should be identified to allow comparisons of
the planned output against the actual output. (Source: DOE Software Engineering
Methodology, 5-21-1997.)
16. Validation. The process of evaluating a system or component during or at the end of the
development process to determine whether it satisfies specified requirements. (Source:
IEEE Standard Glossary of Software Engineering Terminology, Std. 610.12-1990.)