XLC Artifacts & Templates
Your project’s complexity will determine which artifacts are needed for a project—as documented in the Project Process Agreement (PPA). It is unlikely that any single project will need all of the artifacts, reviews, and tests.
- Artifact overview
- Figure mapping artifacts to phases and reviews
- Artifact descriptions & templates A – H | I – P | Q – Z
The life cycle of possible artifacts is mapped to the XLC phases and associated stage gate reviews in the figure below. For artifacts spanning phases, it is expected that updates to the artifact (usually increased detail reflecting work accomplished in the phase) will be available for review. Artifacts evolve in maturity through the XLC:
- Preliminary – the first instance of an artifact that contributes to a stage gate review. Detailed expectations are provided in the various reviews’ templates.
- Interim – a “point in time” snapshot of an artifact that contributes to a stage gate review. This updated snapshot should represent progress from the last time the artifact was reviewed. Detailed expectations are provided in the various review’s templates.
- Baseline – a version of the artifact that is under initial configuration management control. It is possible but usually difficult to change a baselined artifact. Such a change requires a change request which ensures implications to cost, schedule, and technical baselines are addressed. The expectation is that all sections of the artifact have been completed, reviewed and approved in order to declare a baseline for the artifact.
- Final - a baseline version of the artifact that is deemed complete and cannot be changed in later XLC phases. It is deemed unchangeable for a particular release of a system. The expectation is that all sections of the artifact have been completed, reviewed and approved. A Final version of an artifact is used for hand off to Operations and Maintenance.
- Updated Yearly – Several security artifacts are updated on a yearly basis in the Operations and Maintenance (O & M) phase.
SELECT THIS LINK TO VIEW/DOWNLOAD THE ARTIFACTS TABLE
(mapping artifacts to XLC phases and reviews)
Select the template's name to download the template for that artifact.
Artifacts A – H back to top
Acquisition Strategy: The overall objective of an Acquisition Strategy is to document and inform stakeholders about how acquisitions will be planned, executed, and managed throughout the life of a project or investment. For questions about this template, please contact the Division of IT Governance.
Action Items: Records and manages assignments that generally result from meeting discussions.
Annual Operational Analysis Report: Documents elements from the Capital Planning and Investment Control (CPIC) evaluation and results from monitoring the performance of the system/application during normal operations against original user requirements and any newly implemented requirements or changes. The document assists in the analysis of alternatives for deciding on new functional enhancements and/or modifications to the system/application, or the need to dispose of or replace the system/application altogether.
Authorization Package: Demonstrates and validates that appropriate security controls exist to safeguard the system. Please note that there is no template for this artifact.
Business Case: Describes the basic aspects of the proposed IT project: why, what, when, and how.
Business Product / Code: Documents the implemented system (hardware, software, and trained personnel) that addresses a business need. Please note that there is no template for this artifact.
CMS CIO-Issued Authorization to Operate (ATO): Provides CIO approval of System Certification and System Accreditation authorizing the system to become operational. Please note that there is no template for this artifact.
Computer Matching Agreement (CMA) / Interagency Agreement (IA): Documents agreements permitting computerized comparison of systems of records which contain personally identifiable information.
Contingency Plan: Describes the strategy for ensuring system recovery in accordance with stated recovery time and recovery point objectives.
Contingency Plan Tabletop Test: Documents planned tests of strategies, personnel, procedures, and resources that respond to a supported applications/system interruption.
Database Design Document: Describes the design of a database and the software units used to access or manipulate the data.
Data Conversion Plan: Describes the strategies involved in converting data from an existing system/application to another hardware and/or software environment.
Data Use Agreement: Informs recipients of any CMS data containing personally identifiable information (PII) of their responsibilities to protect the confidentiality of the data and obtains their agreement to abide by these requirements.Click here for more information about Data Use Agreements.
Decision Log: Documents the decisions made over the course of the project.
Enterprise Architecture Analysis Artifacts: Consists of models, diagrams, tables, and narrative, which show the proposed solution’s integration into CMS operations from both a logical and technical perspective. Please note that there is no template for this artifact.
Enterprise Systems Development (ESD) Section J: Section J is a service delivery guideline tailored for information technology (IT) contracts for the Enterprise Systems Development (ESD) Program. The document specifies contractual IT-tailored guidelines and requirements to contractors who have received awards from a predefined list.
Enterprise Systems Development (ESD) SOW Template: The ESD SOW template is a guideline tailored for information technology (IT) contracts for the Enterprise Systems Development (ESD) Program. The document recommends guidelines and requirements to contractors who have received awards from a predefined list.
High Level Technical Design: Documents conceptual functions and stakeholder interactions.
Artifacts I – P back to top
Implementation Plan: Describes how the automated system/application or IT situation will be installed, deployed and transitioned into an operational system or situation.
Information Security Risk Assessment (ISRA): Contains a list of threats and vulnerabilities, an evaluation of current security controls, their resulting risk levels, and any recommended safeguards to reduce risk exposure.
Interface Control Document: Describes the relationship between a source system and a target system. Required for review, normally not updated after originally baselined in Design Phase.
IT Intake Request Form: Collects basic new project information from a Business Owner.
Issues List: Keeps a record of all issues that occur during the life of a project.
Logical Data Model: Represents CMS data within the scope of a system development project and shows the specific entities, attributes, and relationships involved in a business function’s view of information. Please note that there is no template for this artifact.
Operations & Maintenance Manual: Guides those who maintain, support and/or use the system in a day-to-day operations environment.
Performance Test Plan and Results Template: Provides a template to integrate performance test planning and reporting in CMS’ Enterprise Testing Center (ETC).
Physical Database / Model: Represents CMS data within the scope of a system development project and shows the specific tables, columns, and constraints involved in a physical implementation’s view of information. Please note that there is no template for this artifact.
Plan of Action Milestones (POA&M): Reports the status of known security weaknesses with associated Plan of Action and Milestones.
Post Implementation Report: Documents results from monitoring the performance of a system/application during normal operations against the original user requirements and any newly implemented requirements or changes.
Privacy Impact Assessment: Ensures no collection, storage, access, use or dissemination of identifiable respondent information that is not both needed and permitted.
Project Charter: Authorizes the existence of a project and provides the authority to proceed and apply organizational resources.
Project Closeout Report: Assesses the project, ensures completion, and derives lessons learned and best practices to be applied to future projects.
The Project Management Plan (PMP) is developed in the Planning Phase by the Project Manager and provides detailed plans, processes, and procedures for managing and controlling the life cycle activities of a specific IT project. The PMP describes the processes for managing, tracking, and controlling the development of an automated system/application or other IT solution. It provides necessary information to improve the level of communication and understanding between all project team members and stakeholders, and may be comprised of other subsidiary management plans.
Possible subsidiary management plans include the following items. If it is determined that a separate subsidiary plan is not required, this information should be conveyed in the Project Management Plan.
Change Management Plan: The Change Management Plan is completed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The Change Management Plan defines the approach, administrative procedures, roles and responsibilities for submitting, evaluating, coordinating, approving or disapproving business and technical changes to baselined configuration items (CIs) for the project.
The Communications Management Plan is completed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The Communication Management Plan documents the protocol for conducting effective communications for the project to help manage project team and stakeholder expectations and prevent un-channeled communication. The Communication Management Plan documents the methods and activities needed to ensure timely and appropriate collection, generation, dissemination, storage, and ultimate disposition of project information among the project team and stakeholders. The Communication Management Plan also defines which groups do not have access to certain information and what type of information will not be widely distributed
Configuration Management Plan: The Configuration Management Plan is completed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The Configuration Management (CM) Plan establishes the technical and administrative direction and surveillance for the management of configuration items (i.e., software, hardware, and documentation) associated with the project that are to be placed under configuration control.
The document defines the project's structure and methods for:
- Identifying, defining, and baseline configuration items (CIs);
- Controlling modifications and releases of CIs;
- Reporting and recording status of CIs and any requested modifications;
- Ensuring completeness, consistency, and correctness of CIs; and
- Controlling storage, handling, and delivery of CIs.
Development Approach Plan: The Development Approach Plan describes the approach to developing technologies or information system(s). The approach to development incorporates methodology, processes, transition points, people and tools to be used. The level of detail in the Development Approach Plan is dependent upon the characteristics of the project (e.g., new development or maintenance), Statement of Work (SOW) requirements, stakeholder needs, etc.
The Development Approach belongs to a tree of plans subordinate to the Project Management Plan (PMP.) If a corporate System Development Management Plan (SDMP) exists, the Development Approach Plan may reference the corresponding section(s) of the SDMP rather than reiterating the content of the SDMP in the Development Approach Plan. Where applicable, references to the SDMP should also be augmented to address any additional information or deviations from the SDMP that are specific to the given project.
Financial Management Plan: The Financial Management Plan (FMP) is developed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The purpose of the Financial Management Plan is to document the Financial Measurement Baseline (FMB) and define how it will be tracked, define the reviews that will be established for reporting on the financial health of the project, and define the invoicing requirements and timelines.
Performance Management Plan: The Performance Measurement Plan is developed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The Performance Measurement Plan is used to more effectively manage performance and incorporates performance objectives, measures and expectations allocated to the performance of specific aspects of the project.
Quality Management Plan: The Quality Management Plan (QMP) is developed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The Quality Management Plan documents the necessary information required to effectively manage quality during the life cycle of the project. It defines the project's quality policies, procedures, areas of application and associated criteria, and roles and responsibilities.
Risk Management Plan: The Risk Management Plan (RMP) is developed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The purpose of the Risk Management Plan is to define the process details for managing risks during the life of the project. See also XLC Risk Management Guidelines.
Schedule Management Plan: The Schedule Management Plan is developed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The Schedule Management Plan describes how the Project Schedule will be established and managed.
Software Process Improvement Plan: The Software Process Improvement Plan (SPIP) is developed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The SPIP Plan describes any process reviews that have been conducted including the methodology used for the appraisal and any findings and recommendations. The SPIP also identifies the approach taken to achieve software process improvement along with goals and methods, processes, and tools that will be used.
Staff Management Plan: The Staff Management Plan is developed during the Planning Phase in conjunction with the Project Management Plan by the Project Manager. The Staff Management Plan describes the approach for identifying, obtaining, allocating, developing, tracking, and controlling human resources associated with the project during the life of the project.
The Subcontractor Management Plan is one of the subordinates to the Project Management Plan (PMP.) The Subcontractor Management Plan is a managerial approach to selecting subcontractors, identifying the services that the subcontractors will provide, establishing and maintaining agreements with the subcontractors, executing agreement, and monitoring subcontractor performance. How the subcontractor's processes will be integrated should also be addressed. The tools and methods selected to address these areas are to be documented. The artifact should also outline the risks, constraints and assumptions of performing the selected approach.
If a corporate System Development Management Plan (SDMP) exists, the Subcontractor Management Plan may reference the corresponding section(s) of the SDMP rather than reiterating the content of the SDMP in the Subcontractor Management Plan. Where applicable, references to the SDMP should also be augmented to address any additional information or deviations from the SDMP that are specific to the given project.
Project Process Agreement (PPA): Authorizes and documents the justifications for using, not using, or combining specific reviews and the selection of specific work products.
Project Schedule: Shows the Integrated Master Schedule which includes all activities required to complete a project and their interdependencies.
Artifacts Q – Z back to top
Release Plan: Describes what portions of the system functionality will be implemented in which release and why.
Risk Register: Captures the results of a qualitative and quantitative risk analysis and the results of planning for response.See also XLC Risk Management Guidance and Risk Register Instructions.
Section 508 Assessment: Provides information regarding compliance with required accessibility standards.
The Assessment may also be referred to as the Voluntary Product Accessibility Template (VPAT). CMS has adopted the VPAT for use in assessing Section 508 compliance of Electronic Information Technology products being acquired by or developed for the Agency. Once the template is completed, please submit to your Section 508 Clearance Officer. The list of officers can be found https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/Section508/Section_508_clearance_officers.html
Security Assessment: Describes the completed assessment phases following established assessment procedure and reporting procedures.
Security Monitoring Reports: Describes the completed security assessments and documents results following established assessment procedure and reporting procedures.
System Design Document: Documents both high-level system design and low-level detailed design specifications.
System Disposition Plan: Documents how the various components of an automated system (software, data, hardware, communications, and documentation) are to be handled at the completion of operations to ensure proper disposition of all the system components and to avoid disruption of the individuals and/or other systems impacted by the disposition.
System of Records Notice (SORN): Organizations issue SORNs to provide the public notice regarding PII collected in a system of records, which the Privacy Act defines as “a group of any records under the control of any agency from which information is retrieved by the name of an individual or by some identifying number, symbol, or other identifier.” SORNs explain how the information is used, retained, and may be corrected, and whether certain portions of the system are subject to Privacy Act exemptions for law enforcement or national security reasons. Privacy
Act Statements provide notice of: (i) the authority of organizations to collect PII; (ii) whether providing PII is mandatory or optional; (iii) the principal purpose(s) for which the PII is to be used; (iv) the intended disclosures (routine uses) of the information; and (v) the consequences of not providing all or some portion of the information requested. When information is collected verbally, organizations read a Privacy Act Statement prior to initiating the collection of PII (for example, when conducting telephone interviews or surveys).
System Security Plan (SSP): Documents the system’s security level and describes managerial, technical and operational security controls. CFACTS produces an initial SSP, including an initial Risk Assessment (RA) that contains mission/business process risks and the monitoring strategy, for review and approval by the Technical Review Board (TRB).
Test Case Specification: Describes the purpose of a specific test, identifies the required inputs and expected results, provides step-by-step procedures for executing the test, and outlines the pass/fail criteria for determining acceptance.
Test Plan: Describes the overall scope, technical and management approach, resources, and schedule for all intended test activities associated with validation testing. Also see the CMS Testing Framework document.
Test Summary Report: Summarizes test activities and results including any variances from expected behavior.
Training Artifacts: Satisfies the training plan with required products which may include web-based instruction, instructor guides, student guides, exercise materials, and training records. Please note that there is no template for this artifact.
Training Plan: Describes the overall goals, learning objectives, and activities that are to be performed to develop, conduct, control, and evaluate instruction.
User Manual: Explains how a novice business user is to use the automated system or application from a business function perspective.
Version Description Document: Identifies, tracks and controls versions of automated systems and/or applications to be released to the operational environment.
- Page last Modified: 11/01/2017 9:43 AM
- Help with File Formats and Plug-Ins