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
| File | Type | Posted |
|---|---|---|
| PAISC_Attachment A2.pdf | ||
| PAISC_Q A.pdf | ||
| FormSF30.pdf | ||
| PAISC_Attachment A1.pdf | ||
| PAISC_Attachment C.pdf | ||
| Request for Proposal.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 .