PAISC_Attachment B.pdf

PDF 8 MB Posted

Attached to
Paying Agent-related Information Security Consultant (PAISC) Federal contract opportunity
Solicitation number
PBGC01-RP-12-0060
Issued by
Pension Benefit Guaranty Corporation

About this file

Attachment B

View the file

Other files for this federal contract opportunity

Other files attached to Paying Agent-related Information Security Consultant (PAISC), newest first.
File Type Posted
PAISC_Attachment A2.pdf PDF
PAISC_Q A.pdf PDF
FormSF30.pdf PDF
PAISC_Attachment A1.pdf PDF
PAISC_Attachment C.pdf PDF
Request for Proposal.pdf PDF

On GovTribe

Work with this file on GovTribe

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Paying Agent-related Information Security Consultant (PAISC) Contract

PBGC Solicitation Number PBGC01-RP-12-0025

Attachment B

This attachment includes the following documents (in this order) as listed in section C – 1.3.2.2 PBGC

Information Technology System Life Cycle Methodology:

PBGC Directive IM-05-07, PBGC’s Information Technology Solutions Life Cycle Methodology

(ITSLCM)

PM-PRO-01-01: IT Solutions Life Cycle Management (ITSLCM)i Framework Narrative

PM-STD-01-01ii: PBGC OIT - System Documentation Standard

PM-STD-01-02: PBGC OIT - Design and COTS Configuration Document Standard

PM-STD-01-03: PBGC OIT - Requirements Document Standard

PM-STD-01-04: Implementation and Training Plan Standard

PM-STD-01-05: Lessons Learned Document Standard

This attachment also includes the following two documents (in this order) which are not listed in the original Request for Proposal, since they are newly published documents from PBGC’s Program

Management Office:

PM-GDE-01-01: IT Solutions Life Cycle Management (ITSLCM) v1.1 Framework Narrative

PM-REF-01-01: ITSLCM v1.1 Views i Original Request for Proposal listed as “Methodology”, it is correctly listed here as “Management (ITSLCM)”.

ii Original Request for Proposal listed as a “10”, it is correctly listed here as a “01”.

Subject: PBGC’s Information Technology Solutions Life Cycle

Methodology (ITSLCM)

Directive Number: IM-05-7

Effective Date: 2/2/10 Originator: OIT

Stephen E. Barber Chief Management Officer

1. PURPOSE: The Pension Benefit Guaranty Corporation (PBGC) requires that all federal and contract employees adhere to the Information Technology Solutions Life Cycle Methodology (ITSLCM) for delivering and managing the delivery of new and existing Information Technology (IT) solutions.

2. CANCELLATION: This updates IM 05-7 dated April 4, 2007 in order to add a PAL link for the electronic version and change the Process Management Committee to the OIT ITSLCM Program Lead.

3. SCOPE: The ITSLCM applies to all PBGC federal and contract employees (across all

PBGC departments and offices), leading or participating in delivering and managing the delivery of IT solutions – from new solutions, to modernizing, enhancing, maintaining and operating existing solutions, through disposition of the solutions.

4. AUTHORITIES:

Below are the Federal authorities that directly influence the establishment of this Order:

a. Clinger-Cohen Act (Information Technology Management Reform Act - ITMRA) – July 16, 1996

b. OMB Circular A-11 – Parts 2, 3, and 7:

(1) Preparation and Submission of Strategic Plans, Annual Performance Plans, and Annual Program Performance Reports

(2) Planning, Budgeting, Acquisition and Management of Capital Assets

(3) Exhibit 300 and Exhibit 52 submissions

c. OMB - Office of E-Government and Information Technology – Improving Information Technology (IT) Project Planning and Execution – August 2005

Pension Benefit Guaranty Corporation

Order

d. Federal Acquisition Regulation (FAR) – Part 34-Major System Acquisition, subpart 4.2-Earned Value Management System – July 2006

e. OMB Circular A-130, Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources, November 28, 2000.

f. OMB Guidance on Section 208 of the E-Government Act of 2002 (Public Law 107-347, 44 U.S.C. Ch 36) on implementing the privacy provisions of the E-Government Act

5. BACKGROUND:

Based on the Clinger-Cohen Act of 1996, the Office of Inspector General identified an audit recommendation for PBGC to establish a Systems Development Life Cycle (SDLC) methodology as one of its FY2000 corporate objectives. On March 30, 2001, PBGC’s SDLC methodology was first issued.

In March 2002, the SDLC was renamed to the Systems Life Cycle Methodology (SLCM) to reflect an overall systems life cycle approach, rather than just focusing on development efforts. In late FY2002, a Business Planning Framework was established that defined the relationship between Strategic Planning and Corporate Initiatives to meet PBGC’s goals and objectives. The SLCM was redefined against the business process model, and was approved on July 2, 2003. On October 7, 2005 the SLCM Corporate policy was approved.

In August 2005, OIT commenced an effort to modify the SLCM to incorporate industry best practices from Software Engineering Institute’s (SEI) Capability Maturity Model ® Integration (CMMI®), and the Project Management Institute’s Project Management Body of Knowledge (PMBOK®). In March 2006, SLCM v2006.1 was released to include the first set of CMMI® industry best practices: Requirements Development (RD) and Requirements Management (REQM) processes.

In January 2007, the SLCM v2006.1 was renamed to ITSLCM. It incorporates several process improvement suggestions, a complete IT investment framework, Project Management Life Cycle (PMLC) and Solutions Delivery Life Cycle (SDLC) processes, procedures, and templates using best practices from CMMI® and PMBOK®. The SDLC is based on a waterfall model and can accommodate COTS and/or custom projects. This model can be used to concurrently perform activities across multiple phases, while phase completion is sequential. The ITSLCM framework does not preclude adding other models (e.g. iterative) in future releases.

6. DEFINITIONS:

a. Business Case: A documented solution proposed to fill a business need, links to the corporate strategic plan and outcomes or statutory and regulatory mandates, provides evidence of feasibility and viability with acceptable level of risk, defines return on investment/benefits, and provides alternatives to solving the business problem.

b. Change Control Board (CCB): A formal entity established, owned, led, and managed by the business unit (department users of the solution) with participating stakeholders to review, approve, or reject proposed change requests for incorporation into specified releases throughout the life cycle of an IT solution.

c. IT Solution: An Information Technology (IT) investment (custom developed, COTS or infrastructure component) that is deployed into production to meet a business need.

d. Project: A time-bound (temporary) endeavor undertaken to create a unique product, service, or result, and has a definite beginning and a definite end and is distinctive from other products or services.

e. Program: A group of related projects managed in a coordinated way to obtain benefits and control not available from managing the projects individually.

f. Stakeholder: A PBGC contractor or federal employee who has a business need and has a vested interest for a specific IT Solution, who may be positively or negatively impacted by the IT solution.

7. POLICY: It is the policy of the PBGC that all federal and contract employees, leading, participating delivering, or managing the delivery of IT solutions adhere to the ITSLCM.

Proposed exemptions to the applicability of the ITSLCM will be reviewed and approved by the Chief Information Officer (CIO).

8. ROLES AND RESPONSIBILITIES:

All PBGC federal and contract employees, who lead or participate in delivering and managing the delivery of IT solutions, have a related role associated with the ITSLCM.

Roles and responsibilities are defined in the context of supporting adherence to this order.

Description of the columns in the below table are:

Role: Function performed by a group, team, committee or an individual.

Purpose: Primary reason for performing the assigned role.

Responsibility: Duties or activities performed to successfully achieve the role’s purpose.

Authority: Mechanism by which the role is established or empowered.

Accountability: Higher entity or position to which a role is liable for the outcome.

Role Purpose Responsibility Authority Accountability Executive

Management Committee

(EMC)

Provide corporate level scope, cost and schedule governance and approval

• Establish, maintain, and publish Corporate Strategic Plan and ensure IT programs and projects align with Corporate Outcomes

• Review, evaluate, prioritize, and approve business cases and funding, aligned with the

Corporate Strategic Plan and Mission

Agency Director

Corporate Strategic Plan

• Conduct periodic reviews of project status to address risks, issues, and funding needs

Chief Information

Officer (CIO)

Provide IT program-level scope, cost and schedule governance and approval

• Establish, maintain, and publish IT Strategic Plan aligned with the Corporate Strategic Plan and ensure IT programs and projects align with IT Strategic Outcomes

IT Strategic Plan

Agency Director

Internal Controls

(ICC)

Ensure that key internal controls are appropriate for the project and are not changed without ICC approval.

• Maintain and publish a list of internal controls that impact the business

• Provide input to the CFO and ICC as to the adequacy of the controls including deletions, additions, and modifications

ICC Charter Chief Financial Officer

Project Sponsor

OR

Sponsoring

Chief or Department

Director

Provide primary sponsorship, guidance and governance of project scope, cost and schedule

• Define the overall business need, vision, outcome, key success indicators, scope, cost and schedule for the project

• Authorize the project by approving the project charter

• Coordinate funding and business issues with impacted Chiefs and Department Directors

• Provides final approval of scope, cost and schedule changes or decisions

• Lead and designate project Steering Committee (SC) members, frequency of meetings, and decision making process

Project Charter

EMC

• Designate Business User

Representative(s) (BUR)

• Establish a Change

Control Board (CCB) for their business area and designate a CCB lead and participants

Impacted Chiefs

OR

Department Directors

Manage inter-departmental business impacts and risks

• Designate a project SC member

• Coordinate with Project Sponsor to define inter-departmental scope, cost and schedule impacts

• Designate BUR(s)

Project Charter

EMC

Steering

(SC)

Provide sustaining sponsorship, guidance and governance to the project

Meet weekly until weekly meetings are no longer required, then bi-weekly or monthly (as appropriate) to review project progress

• Review and monitor project progress to address project issues and risks and commit resources necessary for successful project completion

• Participate in decision making process for approving scope, cost and schedule changes, including change requests from the Change Control Board

(CCB)

• Authorize projects to proceed to the next ITSLCM phase or terminate project

• Address inter-departmental coordination issues, including designation of special teams to solve specific issues

Project Sponsor

Change Control Board

(CCB)

Manage or control (approve or reject) changes

• Establish processes and procedures for managing change requests

• Work with project teams

CCB Charter Project Sponsor

Steering

Meet regularly (as defined by the business unit) to review change requests to conduct analysis and impact of change requests

• Approve or reject change requests that do not impact scope, cost or schedule

• Maintain a list of change requests for future releases

• Report change requests status to SC, specifically those that impact scope, cost or schedule

Business User Representative

(BUR)

Manage business and user needs and impacts

• Prepare and present the business case for a proposed project or corporate initiative along with designated Federal Project Manager

• Provide subject matter expertise on business functions and user needs with user group members and other BURs

• Primary change agent for users by coordinating and managing impacts to project stakeholders

• Provide subject matter expertise and participants for defining Business Process Modeling/Engineering (as-is/to-be) and requirements gathering

• Coordinate participation in user acceptance testing and provide final sign-off

• Lead the planning and delivery of user training and roll-out of the IT solution to users

Project

Stakeholders

Provide subject matter expertise and support to BUR and Federal Project Manager

• User Group members identify and manage impacts to business unit (User Group)

• Non-User Group members identify and manage impacts to IT solutions (including infrastructure such as networks, storage, telecom, servers, other IT solutions/systems, security, operations, etc.)

• Submit change requests and participate in CCB

• Participate in requirements, user acceptance testing and sign-off

BUR

Federal Program Manager

Manage program scope, cost and schedule across multiple projects to achieve the program’s strategic business objectives

• Manage a collection of projects within a defined program

• Coordinate scope, cost and schedule of activities between inter-related projects, including program risks, issues, and dependencies

• Define and establish a 12 to 18-month program release schedule in alignment with Enterprise Architecture (EA) and Corporate Strategic Plan

• Develop and establish program-level ITSLCM Tailoring and Compliance Plan

• Deliver program level SC and other management reporting

• Ensure all program ITSLCM artifacts are

Project

Deputy Chief Information Officer(s) completed and approved in accordance with the approved program schedule and with quality

Federal Project Manager

Project management, monitoring, controlling and reporting

• Manage project integration, scope, cost, time, quality, procurement, human resources (business and IT), communications, risks & issues

• Support BUR in the preparation/presentation of business cases, providing level of effort estimates and evaluating viable alternatives for IT solutions

• Support the BUR by providing resources for developing and documenting Business Process Modeling/ Engineering and requirements gathering

• Perform all project management life cycle (PMLC) processes and procedures from project initiation, to planning, to execution, monitoring and control, to close-out

• Establish an approved Project Charter

• Develop and establish a project ITSLCM Tailoring and Compliance Plan and lead project team in using the ITSLCM

• Lead all project planning activities, including forming and maintaining

Project Charter

Federal Program an Integrated Project Team (IPT) to perform all tasks and activities on the project

• Ensure all project ITSLCM artifacts are completed and approved in accordance with the approved project schedule and with quality

• Ensure IT solution is in compliance with EA

• Prepare for and deliver project progress reports and metrics (Earned Value), such as SC briefings and other management briefings

• Lead weekly/bi-weekly (as appropriate) project team meetings to ensure coordination and completion of tasks and activities

Integrated Project Team

(IPT)

Core Team – Primary Federal and/or Contractor staff dedicated to the execution of project activities

Normally meets weekly

Core Team

• Participate in planning, monitoring, and execution of project activities

• Perform all activities in support of successful execution and completion of project

• Create, maintain, and publish quality ITSLCM project deliverables and meet project milestones

• Identify risks and issues to Project Manager

• Report actual activities worked and completed

• Coordinate and communicate

Management Plan

Extended Team - Support Federal and/or Contractor staff indirectly support the Core Team

Meets as needed dependencies within IPT members

• Comply with ITSLCM, Change and Configuration Management (CCM) policies and procedures, compliance with EA, and adherence to IT Security policies, processes and procedures

Extended Team

• User group members or business function subject matter experts who support the BUR(s)

• Support for tailoring and compliance with ITSLCM, CCM policies and procedures, compliance with EA, and adherence to IT security policies, processes and procedures

• Support to ensure quality of all project deliverables

• Support release management and engineered infrastructure between the Common Development Environment (CDE), Integrated Test Center (ITC), Production & Continuity of Operations

(COOP)

• Support testing of impacted solutions

• Transition IT solution to IT Operations and Maintenance (O&M) for IT service delivery and support

9. PROCEDURES

a. Publication of ITSLCM Processes and Related Artifacts

The ITSLCM and all related artifacts, such as supporting processes, procedures and templates are published in the OIT’s Process Assets Library (PAL) portal community.

The PAL is version-controlled and contains the most recent and approved release of the ITSLCM-related artifacts. PBGC federal and contract employees shall access this repository to obtain the current ITSLCM process information and templates.

b. ITSLCM Tailoring

In order to accommodate varying IT solution project sizes and types, the OIT has established guidance for tailoring the ITSLCM, such as what artifacts are required for project completion. Procedures for tailoring the ITSLCM are established in the ITSLCM Tailoring and Compliance Plan Guidance document.

c. ITSLCM Modification Suggestions and Releases

OIT encourages ITSLCM users to provide valuable feedback in order to continuously improve and streamline the ITSLCM. All suggestions for future modifications or Process Improvements (PIs) shall be submitted via the PAL portal community, which is open to all PBGC Federal and Contractor staff. The OIT ITSLCM Program Lead then reviews, prioritizes, and approves changes for subsequent ITSLCM scheduled releases.

Future releases will be coordinated with PBGC departments and users prior to release.

The OIT is responsible for modifying the ITSLCM, scheduling releases, and delivering training as necessary.

Reference: Information Technology Solutions Life Cycle Methodology (ITSLCM) http://pbgcportal/portal/server.pt?open=512&objID=500&PageID=0&parentname=Login&parentid=1&cached=true&mode=2&userID=7457�

IT SOLUTIONS LIFE CYCLE MANAGEMENT (ITSLCM) FRAMEWORK

v1.1 Dated: February 22, 2012

Need/Concept Planning Solution Implementation

(Requirements, Design, Build, Test, Deploy) Operations & Maintenance Disposition

Reviews ( ) / Gates ( )

Stream Tasks

Requirements (Technology

Solution Review)

Design (Technology Solution Review)

ITIRB

(IT Synopsis Review and

Recommendation)

TRB

(BNA

Review)

Production Readiness Validation

ITIRB

(Post Implementation Review)

Phases

Execute annual maintenance/steady state tasks

Document System

Execute Deployment and Disposition Plan

Conduct solution disposition reviews

Requirements Document

Design and COTS Configuration Document

Deployment and Disposition Plan (U)

User Manual

Implementation & Training Plan

Program Charter (PgC)

Deliverables

Program Management Plan (PgMP)

Business Need Analysis Document (e.g. Segment

Architecture, Architectural Analysis or White Paper)

IT Synopsis

Operational Analysis

System Documentation

Program/Investment Performance Reports

Lessons Learned Document

System Security Plan (F)

Security Risk Assessment (F)

MOUs, SLAs, and/or Intra-agency Agreements

Disposition ReviewCAB

(Production/COOP Deployment Review)

Architect Invest Implement

ITIRB

(Annual Operational Analysis)

Program/Investment Management

Project Management

Technology Solution Management

Develop and submit Advanced

Procurement Plans

Obtain products/services

Conduct ongoing acquisition management administration

Develop MOUs, SLAs, and Intra-agency Agreements, as needed

Perform program and investment monitoring and reporting o For Major: Monthly steering committee reporting

(cost and schedule performance), ITIRB reporting, OMB IT Dashboard reporting o For Non-Major: Monthly steering committee reporting of cost and schedule, ITIRB reporting

Conduct Operational Analysis o Perform Post Implementation Review to validate that the solution aligns with business needs and closes performance gaps o Perform Annual Operational Analysis Review to determine whether solution should be continued, modified, or terminated

Update PgMP with annual maintenance/steady state tasks including results of Operational Analysis

Receive authorization to dispose of solution

Update Deployment and Disposition Plan

Close out program/investment

Conduct ongoing acquisition management administration

Execute according to the PgMP

Perform program and investment monitoring and reporting o For Major: Monthly steering committee reporting (cost and schedule performance using EV), recurring ITIRB Program/Investment Implementation Progress Reviews, OMB IT Dashboard reporting o For Non-Major: Monthly steering committee reporting of cost and schedule, recurring ITIRB

Program/Investment Implementation Progress Reviews

Build Program Management Plan (PgMP) with IPgT:

o Identify IPgT and define Roles and Responsibilities o Perform Business Needs Analysis (BNA), Business Process

Assessment, and identify business and IT gaps, including system replacements o Determine strategic alignment (e.g. Legislative, Audit, Strategic Plan, etc.)

o Conduct Alternatives Analysis and Cost Benefit Analysis

(including Information Security considerations) o Develop IGCE, including impacts to other programs o Develop Acquisition Strategy o Develop Risk, Issue, Quality, Configuration, Communication Plans and Matrices o Define program reporting/oversight o Prioritize program requirements and program schedule with IPgT stakeholders (Business, EA, IT Security, and

Infrastructure, etc. )

Finalize PgMP with IPgT

Submit IT Synopsis for the Program/Investment

Reflect IGCE in departmental budget formulation/request

Select development approach

Develop Project Management Plan

(PMP), if necessary, to address exceptions in the PgMP

Conduct Product and Technology Selection

Develop high level design from high level requirements, including integration with other systems, and submit for CAB review

Refine IGCE

IT Program Release Plan

Project Management Plan (PMP)

OMB Exhibit 300

Deployment and Disposition Plan (P)

Security Registration Document

Security Risk Assessment (P)

System Security Plan (P)

PMP/

Schedule/

Cost Review

IT Standards (S) & Guidance (G)

Program Charter (PgC) (S)

IT Program/Investment

Management (G)

IT Program/Investment Management (G)

Business Need Analysis (S)

Total Cost of Ownership (G)

Review & Update

Annually

Requirements Document (S)

Design and COTS Configuration

Document (S)

System Development (S)

Data (S)

TRB

(Requirements & Design Review)

Analyze business need within the program solutions

Analyze business need across enterprise solutions o EXISTING: Obtain access to existing solution (STOP) o ENHANCE EXISTING: Develop

Independent Government Cost

Estimate (IGCE) to modify and use existing solution, inform

ITIRB, and submit to Program

CCB

o NEW: Form Integrated Program

Team (IPgT), Develop IGCE for performing Planning Phase tasks, finalize sponsorship and

Program Charter (PgC), and submit for ITIRB Review

Develop and submit Advanced

Procurement Plan for planning tasks

TRB

(Product

Selection Review)

IT Product and Technology (S)

Project Management Plan (S)

IT Program Release Plan (S)

Project Management (G)

Solution Development Approach (G)

Deployment and Disposition Plan (S)

Operational Analysis (S)

Execute selected development approach

Establish Program CCB

Develop IT Program Release Plan

Update PgMP with results of product selection and refined IGCE

Develop OMB Exhibit 300 for Major investment

IT Software Services (S)

Implementation & Training Plan (S)

Lessons Learned Document (S)

System Documentation (S)

Develop high level business requirements mapped to BNA Results

CAB

(Infrastructure

Resources

Review)

Update & Maintain

Iteratively

Enterprise Information Security

Acquisition (follow procurement guidelines)

Roles

Stabilize the solution

Grant access to users

Set up service desk support

Transition to O&M

Deployment and Disposition Plan (F)

External Processes

Change ManagementConfiguration Management

Configuration Management

Configuration Management

Configuration Management

Business Needs Analysis IT Service/Incident/Problem Management IT Service/Incident/Problem

Management

Budget Formulation & Execution

IT Risk Management

Review & Update

Annually

ITIRB

(IT Portfolio

Registration Review)

Perform Security Registration Process

Begin Security Assessment & Authorization

(SA&A)

Conduct Security Impact Analysis

Complete Security Assessment & Authorization (SA&A) Continuous Monitoring

AO/CIO/SAISO

(ATO/Go Live)

Security Authorization Package

Program Charter Review

(F) – Final

(P) – Preliminary

(U) –Update

Reviews ( ) / Gates ( ) Reviews ( ) / Gates ( )

Execute according to the IT Program Release Plan, PMP and corrective actions (manage scope, cost, schedule, and risk using EVM)

Develop Implementation Strategy and Training Plan in coordination with HR Department

Obtain approvals from Reviews and Gates

Execute Implementation Strategy and Training Plan in coordination with HR Department

Document Lessons Learned and

Project Closeout

Analyze and document detailed requirements (functional, technical, etc.)

Develop design specifications

Initiate System Documentation

Develop/configure solution

Conduct testing tasks (functional, system, performance)

Document operations and maintenance needs

Deploy solution to production/COOP

IT Risk Management

IT Risk Management

IT Risk Management IT Risk Management

Obtain Authority to Operate

Business Program Manager

IT Program Manager

IT Account Manager

Chief Architect

Business Owner/Sponsor

Business Program Manager

IT Program Manager

Integrated Program Team (IPgT)

Authorizing Official

Information System Owner/ Information Owner

Information System Security Officer

Privacy OfficerBusiness Project Manager

IT Project Manager

Integrated Project Team (IPT)

Business Owner/Sponsor

IT Investment Owner

COTR

Contracting Officer Business Project Manager

IT Project Manager

Integrated Project Team (IPT)

Business Program Manager

IT Program Manager

Integrated Program Team (IPgT) Authorizing Official

Information System Owner/ Information Owner

Information System Security Officer

Steering/Oversight Committee Release Manager

COTR

Contracting Officer

Business Project Manager

IT Project Manager

Integrated Project Team (IPT)

Business Program Manager

IT Program Manager

Integrated Program Team (IPgT) Authorizing Official

Information System Owner/ Information Owner

Information System Security Officer

Steering/Oversight Committee Release Manager

COTR

Contracting Officer

Business Program Manager

IT Program Manager

Integrated Program Team (IPgT)

Authorizing Official

Information System Owner/ Information Owner

Deployment and Disposition Plan (S)Deployment and Disposition Plan (S)

• Enterprise Information Security (S) *

*Please click the link for the complete list of Enterprise Information Security Standards required for this phase.

• Enterprise Information Security (S) *

• Enterprise Information Security (S) *

• Enterprise Information Security (S) *

Change Management Change Management

ITIRB

Review(s)

Release Management

ITIRB

(Deselect IT Program from Portfolio)

PM-STD-01-01

PBGC OIT: System Documentation Standard

2011-12-01 Page 1 of 2

Purpose To define a consistent set of information that must be contained in the System Documentation deliverable in the ITSLCM.

Scope To document a point-in-time snapshot of any given system (hardware, software, COTS, custom, combination of COTS-custom, infrastructure) that is operational in the production/COOP environments. A system is expected to transform during the solutions implementation phase in the areas of such as requirements, design, build, and test.

Authority/ References

NIST 800-53 – SA-5 – Information System Documentation ITSLCM – Operations & Maintenance Phase

Approving Body Governance Control Board (GCB)

Owner IT & Business Modernization Department / Project Management Division

Collaborator ITIOD’s SDD Manager, IT&BMD’s PSD, CSD & and FMSD Managers (Account Managers), Chief Architect, SAISO

Implementer Not Applicable

Standard Type Operational – The standard pertains to actions that are primarily implemented in the enterprise and executed by people (as opposed to systems) in the operations phase of an information system, IT project, program, or initiative.

Control Number xxx

2011-12-01 Page 2 of 2

Standard The System Documentation must contain or reference at a minimum the information/items listed below:

• Revision History – Document the revision number, content changes, date changes, and author.

• Executive Summary – an overview of the system and its components, including interfaces and integration with other systems, and how it fulfills the business operation.

• Release History and a brief description of what was addressed in each release (could be a table or even an Appendix).

• Functionality List - List of end-to-end functionality or use case(s) provided for the system with a brief description of the functionality, including any administrative modules, security modules, role-based functionality, and any significant algorithms worth documenting (could use information from the requirements documents).

• List of user and administrative roles.

• List of Development Tools used to build and maintain the solution, including versions of the tools.

• List of development source files with a brief description of each.

• System Architecture Diagram - Physical topology diagram of production/COOP environments, identifying components that reside on the front-end, middle-tier and back-end, the list of servers (without IP addresses), with list of components that reside on each server (could use information from the Design Document or SSP).

• Database References – List of production database objects, such as table names, views, snapshots, etc. and a brief description of them (could use information from the Design Document or SSP).

• Required Security Documents – All security related documents should be developed at the appropriate time in the development lifecycle and must be included or referenced in the System Documentation package. The required security documents are: (Note – the location of the information in other documents is acceptable.)

o System Categorization Statement o System Description with System Boundaries Noted o Network Diagram and Data Flows o Software and Hardware Inventory o Business Risk Assessment o System Risk Assessment o Contingency Plan o Self-Assessment o System Security Plan (SSP) o Memoranda Of Understanding (MOU) o Service Level Agreements (SLA) o Intra – Agency Agreements o Authority to Operate – (ATO)

• Appendix A – Entity Relationship Diagram representing the Physical Data Model

• Appendix B – Any other significant information that is deemed necessary or is of value to the project.

• Appendix C – References to any documents that are deemed related to the contents

2011-12-01 Page 3 of 2 of this document.

Metrics For future use

PM-STD-01-02

PBGC OIT: Design and COTS Configuration Document Standard

2011-12-01 Page 1 of 4

Purpose

To define a consistent set of information that must be contained in the Design and COTS Configuration Document deliverable in the ITSLCM.

Scope The Design and COTS Configuration Document Standard refers to the designing of an IT solution (Design Document) or the configuring of COTS products (Configuration Document – [not configuration management]). It documents the information required to communicate architectural and system designs to the integrated project team (IPT), integrated program team (IPgT) and appropriate governance boards.

Authority/ References

PBGC Development Standard, Data Standard, and Services Standard ITSLCM – Solution Implementation Phase

Approving Body

Governance Coordination Board (GCB)

Owner IT & Business Modernization Department/Project Management Division

Collaborator ITIOD’s SDD Team, IT&BMD’s PSD, CSD & and FMSD Managers (Account Managers) Chief Architect, SAISO

Implementer Not Applicable

Standard Type Operational – The standard pertains to actions that are primarily implemented in the enterprise and executed by people (as opposed to systems) in the operations phase of an information system, IT project, program, or initiative.

Control Number xxx

Standard The Design and COTS Configuration Document must contain at a minimum the information/items below:

Revision History – Include revision number, content changes, date of change, and author.

• Assumptions - List of assumptions (e.g. availability of a hardware/software platform, pending legislation, court decisions that have not been rendered, or developments in technology) shall be documented.

System Overview - Provide a general description of the complete system design architecture for COTS (or externally hosted solution) or custom developed solution. Include a discussion of the basic design approach and organization. This section documents technical and relatively static components.

Document Standard

2011-12-01 Page 2 of 4

• Constraints – List of conditions or constraints, outside the control of the project that limits the design alternative.

• Dependencies - Describe where the solution would interface with other systems.

• Standards – Identify the PBGC standards used in the solution design (e.g. list EA

Standards) and all exceptions with justification (if any).

COTS Configuration DOCUMENT

• Design Components – Focus on the specific functional behavior of the solution’s components.

• Integration Design – Describes how the solution interfaces with other solutions.

• Reporting – Describes the design and functionality of the solution’s reports.

• Security Architecture – A description and logical view of the system security, processes, disciplines, and the rules and relations among those elements necessary to effectively secure the system being developed.

• Communication Architecture - Logical view of the system’s communication, processes, disciplines; and the rules and relationships among those elements necessary to effectively communicate among elements of the system being developed.

• Performance - Any related processes including a detailed description of specific performance requirements and how they are associated with specific project functionality/deliverables.

DESIGN DOCUMENT

Functional Design - The functional design addresses what the solution will do. Flowcharts and diagrams may be used to describe how the design will support the implementation of the requirements (Flowchart; Architectural Diagram.

Functional Design - The functional design addresses what modules are being used in the solution and how.

Service/Interface Design — This section highlights the interfaces with databases and other dependent applications and software. Please follow PBGC’s Services Standard for this section.

Data Design – This section highlights any conversion/migration that may be required for the solution.

Configuration — This section highlights the configuration of COTS software and externally hosted solution to meet PBGC’s needs. (Note: Use vendor provided documents as appropriate.)

If the IT Solution is a COTS or Externally Hosted Solution, follow the instructions listed in the standard for the COTS Configuration Document.

If the IT Solution is a Custom Developed IT solution, follow the instruction listed in the standard for the Design Document.

2011-12-01 Page 3 of 4

• Design Components – Focuses on the specific functional behavior of the solution’s components.

• Integration Design – Describes how the solution interfaces with other solutions.

• Reporting- Describes the design and functionality of the solution’s reports.

•User Interface Design - Interface design focuses on the user's experience and interaction with the system, if applicable.

• System Performance - Include a description of specific performance requirements and how they are associated with specific project functionality/deliverables (i.e. cycle time, size of transaction, speed per transaction, test requirements, minimum bug counts, speed, end-user requirements, etc).

• Security Architecture – A description and logical view of the system security, processes, disciplines, and the rules and relationships among those elements necessary to effectively secure the system being developed.

• Communication Architecture - A logical view of the system’s communication, processes, disciplines, and the rules and relationships among the components necessary to effectively support the communications of the system being developed.

• Performance - Any related processes including a detailed description of specific performance requirements and how they are associated with specific system functionality/deliverables.

• System Performance - Include a description of specific performance requirements and how they are associated with specific project functionality/deliverables (i.e. cycle time, speed per transaction, test requirements, minimum bug counts, speed, reliability, utilization, end-user requirements).

Database Design — This section highlights the logical and physical database model, data migration, conversion, etc. Please follow PBGC’s Data standard for this section.

Technical Design— This section will follow the PBGC’s Development Standard and has the following details:

• Include a description and logical view of the hardware, processes, disciplines; and the rules and relationships among those elements necessary to effectively implement the solution being developed.

• Provide a descriptive and logical view of the software, processes, disciplines, and the rules and relationships among those elements necessary to effectively build the system being developed

Approvals: Signature(s) and Date(s) of appropriate Business, OIT and IPT approval authorities.

2011-12-01 Page 4 of 4

PM-STD-01-03

PBGC OIT: Requirements Document Standard

Purpose To define a consistent set of information that must be contained in the ITSLCM’s Requirements Document deliverable.

Scope To document the IT Solution’s defined functional, operational and services requirements needed to meet the business need.

Authority/ References

PBGC Technical Standards ITSLCM –Solution Implementation Phase

Approving Body Governance Coordination Board (GCB)

Owner IT & Business Modernization Department/Project Management Division

Collaborator ITIOD’s SDD Team, IT&BMD’s PSD, CSD & and FMSD Managers (Account Managers), Chief Architect, SAISO

Implementer Not Applicable

Standard Type Operational – The standard pertains to actions that are primarily implemented in the enterprise and executed by people (as opposed to systems) in the operations phase of an information system, IT project, program, or initiative

Control Number xxx

Standard The Requirements Document must contain at a minimum, information/items listed in this standard below:

Revision History – Document the revision number, content changes, date changes, and author.

Executive Summary – A brief overview of the project that addresses business areas, people and process that are impacted by the implementation of the solution, and documents the scope of the requirement document.

Assumptions – List of assumptions (e.g. availability of a hardware/software platform, pending legislation, court decisions that have not been rendered, or developments in technology) shall be documented.

Constraints – List of conditions or constraints, outside the control of the project, that limit the design alternatives to include:

o Enterprise constraints (e.g. domain technologies, enterprise general specifications, standards, or guidelines imposed on the solution and strategic decisions) o External constraints (e.g. public and international laws and regulations, technology base, human availability, recruitment, and selection] shall be documented.

Project dependencies and impacts - Identify projects, applications, solutions, systems, processes, departments and infrastructure that impact or are impacted by the solution. Address impacts to Internal, Management, and Audit Controls. Outline project dependencies and relationships. This section describes solution impacts and is a required input for the Design & COTS Configuration Document.

System Diagram - A high level diagram depicting the “To-Be” internal and external application/system interactions.

System Interfaces - A list of incoming and outgoing interfaces to/from the IT solution.

Standards – Identify the PBGC standards used in the solution design (e.g. list EA

Standards) and exceptions with justification (if any).

Key Requirement Characteristics:

Traceable – Each requirement must have a unique identifier to link from the source through requirements, design and test.

Atomic – Each requirement should not contain conjunctions and must reference one and only one thing.

Unambiguous – Each requirement should be written in clear, plain language to avoid misinterpretation and promote a single, common interpretation.

Testable – Each requirement must be verified against quantitative criteria.

Complete – Each requirement must be fully stated in one place and include all information.

Consistent – Each requirement should not contradict other requirements in the document or other related documents.

Correct – Each requirement must be accurate.

Feasible – Each requirement must be implementable within the constraints of the project.

Business Process and Detailed Requirements - Detailed requirements (functional requirements) to the business processes in which the requirements are related to what the system should be able to do. [If there are no related business processes, state the reasons why (e.g. bug fixes, Infrastructure projects, etc.) If using a requirements management tool to document requirements, be sure to include the following types of requirements within the tool.

Business Process – List of defined replaced name(s) and number(s) of the business process from the “To-Be” Business Process Model.

Process Function / Sub-Function – List of defined major activities and sub-activities within the business process. (A further decomposition of a function and/or sub-functions is completed in the high level and detailed requirements section.)

High Level Requirement – Provide a detailed description of the requirement. (High level requirements are decomposed into detailed requirements, until the lowest level of meaningful activity is reached.) Include Service Level Agreement requirements. Out of Scope – List anything deemed out of scope to further clarify the requirement.

Detailed Requirements – Decompose the high level requirement(s). Define the requirements in a manner that enables the reader to see broad concepts decomposed into layers of increasing detail and are unambiguous, atomic, and testable.

Global Requirements – Documents the general/common function requirements not specific to any one business process.

Data Requirements – List the requirements specific to the structure and behavior of the solution’s data.

The data requirements would utilize the PBGC Data Standard and capture logical data elements, relationships, changes to enterprise data model (if any), data conversion requirements, data quality requirements and data capture/storage requirements.

Please refer to Enterprise Information Security Office Standards for guidance on (media encryption and audit controls, system controls, etc.)

List any additional categories based upon project need.

Operational Requirements - Document the detailed requirements (non-functional). Specify the attributes and characteristics of the system unrelated to the functional use to assess the operation of the solution.

Infrastructure Requirements - Please refer to the Infrastructure Standards regarding performance and security: (e.g. scalability, interoperability, reporting, data capacity, reliability, availability, reliability, recoverability, etc.)

Performance / Capacity Requirements – Define performance requirements in quantitative terms that the software must meet, including response times for queries, Reports – List of operational reports, process reports, management reports, etc.

IT Security Requirements – Please refer to the Enterprise Information Security Office Standards for guidance on information security requirements.

PM-STD-01-04

Implementation and Training Plan Standard

2011-12-01 Page 1 of 2

Purpose To define the information that must be contained in the Implementation and Training Plan deliverable in the ITSLCM.

Scope To document the organizational change tasks (e.g. training, marketing, and communications) required to transition the IT solution from the IT program/project team to the business/customer.

Authority/ References

Government and Industry Best Practices ITSLCM – Solution Implementation Phase

Approving Body Governance Coordination Board (GCB)

Owner IT & Business Modernization Department/Project Management Division (PMD)

Collaborator PMD, ITIOD’s SDD & SSD Program & Project Managers, IT&BMD’s IT Program & Project Managers, Business Program & Project Managers

Implementer Not Applicable

Standard Type Management – The standard pertains to the management of an information system, IT project, program, or initiative through the life-cycle phases.

Control Number xxx

Standard The Implementation and Training Plan must contain at a minimum the information /items below: (Note: Keep the level of detail appropriate for the project)

• Revision History – Document the revision number, content changes, date changes, and author.

• Implementation Goals/Outcomes – Describe the desired outcomes and critical success factors and indicators for the implementation of the IT solution.

• Implementation Team Roles and Responsibility – Define the roles and responsibilities of the team.

• Stakeholders – Define the stakeholders involved in or impacted by the implementation plan.

• Audience – Define the target group(s) the implementation and training plan will reach, inform, influence, etc.

• Risks – Identify any risks that may affect implementation and training, such as training room availability, time constraints, resource availability, etc.

• Issues – Identify known challenges that must be managed in order to achieve the implementation goals.

• Assumptions – Identify and document implementation and training assumptions. Refer to the Program Management Plan and/or the Project Management Plan.

PM-STD-01-04

Implementation and Training Plan Standard

2011-12-01 Page 2 of 2

• Constraints – Identify and document any implementation and training limiter. Refer to the Program Management Plan and/or the Project Management Plan.

• Impacts, Relationships and Dependencies – Describe any changes to organizational components (e.g. policies, existing systems, processes, operational activities, organizational groups, projects or activities) required because of the relationships, dependencies and impacts of the IT solution (e.g. will the deployment of the solution require process change to the users on the system and other impact solutions? Will this process change require training?)

• Implementation Approach – Describe the high-level approach of how the solution will transition from the technical/development/configuration phase to the business/production phase (e.g. how will the users be prepared to receive the IT solution?)

The following items are as appropriate for the project:

• Implementation – (Marketing and Communication) – Describe the organizational change, marketing, and/or communications strategy(ies). Describe for each impacted audience the goals, approach, begin/end dates, equipment needed, the material needed, roles and responsibilities, and the evaluation criteria/method.

• Training – Describe the training strategy. The details should include at a minimum who is assigned to the training tasks and the date the tasks are due to begin and end.

Describe for each audience impacted the training scope, approach, course/curriculum, goals, dates, equipment, roles and responsibilities, evaluation method, etc.

PM-STD-01-05

Lessons Learned Document Standard

2011-12-01 Page 1 of 2

Purpose To define a consistent set of information that must be contained in the Lessons Learned deliverable in the ITSLCM.

Scope To document processes, lessons learned, and recommendations to improve the quality and efficiency of the program/project.

Authority/ References

Government and Industry Best Practices ITSLCM – Solution Implementation Phase

Approving Body Governance Coordination Board (GCB)

Owner IT & Business Modernization Department/Project Management Division (PMD)

Collaborator PMD, ITIOD’s SDD & SSD Program & Project Managers, IT & BMD’s Program & Project Managers, and Business Program & Project Managers.

Implementer Not Applicable

Standard Type Management - The standard pertains to the management of an information system, IT project, program, or initiative through the life-cycle phases

Control Number xxx

Standard The Lessons Learned Document must contain at a minimum the following:

• Project Identification – Name, project description to include the type of project

(Development, Modernization or Enhancement (DM&E), Steady State (SS), whether it was a COTS, Hosted, custom developed, maintenance, etc.), and names of the department director and the federal PgM/PM, and project participants.

• Category – Identify key words (tag words) to describe the content of the lessons learn document (e.g. project management, team building, communications, etc.). This section may contain any descriptors that the author deems best describes the success, lessons learned, and recommendations of the project and would help a potential user during a document search.

• Lessons Learned Participants – Participants in the lessons learned session(s).

• Project Successes –List the strategies and techniques used during the project that worked well and contributed to the success of the project. (e.g. processes, activities, artifacts, meeting formats, or any other process or activity) that was implemented that brought value to the project.

• Project Lessons Learned - List strategies and techniques used during the project that did not go well or that could have been done differently (e.g. processes, activities, artifacts, meeting formats, or any other process or activity). This may assist others in understanding what occurred during the course of the project and what could be done differently in the future for better outcomes on similar projects. There should

PM-STD-01-05

Lessons Learned Document Standard

2011-12-01 Page 2 of 2 be a recommendation to address each lessons learned.

• Recommendations – Include suggestions on ITSLCM process improvements, best practices that worked during the project. Recommendations should provide guidance to future project teams for managing, documenting and reporting on projects of similar size and scope.

Once the Lessons Learned session and document is complete, send a copy of the Lessons Learned document to the ITSLCM mailbox…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .