The (OSI) Budget Language Definitions document provides budgetary terms which are used frequently throughout the Governor’s Budget, the Governor’s Budget Summary, and the annual Budget Bill. Definitions are provided for terminology that is common to all publications.

      (OSI) Budget Language Definitions

This template captures the tiered hierarchy of the project's business. The Business Architecture is broken into Business Areas, Lines of Business, sub-function, and business service areas. The business architecture will become an input into the Business Relationship and Conceptual Solution Architecture template.

      Business Architect Toolkit

The Business Continuity Plan shall describe the Contractor's continuity of business strategies and procedures including system redundancies and backup, disaster recovery, and other business continuity activities. The Plan shall address business continuity for all components that comprises the [Project Name] system.

      Business Continuity Plan

This template captures the suppliers and consumers of information exchange packages. The business relationship will become an input into the Conceptual Solution Architecture template.

   Business Relationship Toolkit

The Communication Plan defines the methodology for managing project communication needs such as information distribution methods, modes, performance reporting, and lessons learned.

      Communication Plan

This template documents the proposed solution’s architecture focusing on how the customer accesses the services provided by the solution and the dependencies on other services/systems as inputs. This is used as a talking point for business process design issues without discussing the technology being used to automate the business process.

      Conceptual Solution Architecture Toolkit

The Contract Management Plan defines the processes used to manage contractors and consultants on the project. It describes how contractor deliverables will be reviewed and approved, how contractor invoices will be reviewed and authorized for payment, how contractor deficiencies are addressed, and how contract amendments and work authorizations will be processed.

      Contract Management Plan

The Cost Management Plan describes the processes for managing costs on the project. The document summarizes the project’s involvement in the state budget process, and describes the project’s cost management activities (from a project management perspective), such as establishing a cost baseline, managing and making changes to the cost baseline, and reconciling the baseline with the allocated spending authority from the state budget process. This plan also describes which tools are used to manage and track costs and expenditures for the project.

      Cost Management Plan

A Deliverable Expectation Document describes the contractor’s proposed approach to preparing a deliverable, including the methodology, format, content and level of detail. This document is prepared by the contractor prior to beginning work on the deliverable and must be approved by the project. The project prepares a template to ensure the contractor adequately describes the deliverable. Compare to Data Item Description (DID).

      Deliverable Expectation Document

The Deliverable Management Process describes the methodology for the administrative tracking of all contractual deliverables generated by a contractor or consultant. Typical activities include: logging receipt of a deliverable, reviewing the deliverable against its administrative requirements, approving/disapproving deliverable submittals, and the handling of deficiencies with the deliverable. The deliverable management process does not include a qualitative evaluation of the deliverable quality (see Quality Management for this). The deliverable management process is included or referenced in the Contract Management Plan.

      Deliverable Management Process

The Detailed Design Specification Outline provides guidance in the uniform development of the detailed design specification document. The purpose of the detailed design specification document is to establish and communicate in sufficient detail how the properties of the system or software requirements will be transitioned into a design. Expectations for the aspects of the system or software features and performance can be compared with the design to identify any design flaws.

      Detailed Design Specification Outline

The Disaster Recovery Plan shall describe the Contractor's approach that will be used to the guide the preparation for and delivery of necessary Contractor [Project Name] disaster services in response to any disaster requiring extraordinary [Project Name] services response. The Plan will identify resources involved in contigency operations, problem management and escalation procedures.

      Disaster Recovery Plan

The Document Management Plan defines the process for managing project documentation during the project life cycle. It also contains a description on how to set up a document management library.

      Document Management Plan

The Evaluation and Selection Plan documents how bidder proposals will be reviewed and evaluated. The selection of the eventual winning bidder will be determined by the guidance and scoring methods defined by this plan.

      Evaluation and Selection Plan

The GC 19130 Justification documents the statutory authority to contract out for personal or consulting services. Once completed, it is attached as a support document to the ITPP.

      GC 19130 Justification

The Governance Plan describes the specific roles and responsibilities of the project and its stakeholders, focusing primarily on authority level and decision-making structure. While some high-level roles and responsibilities are discussed in the Project Charter and/or the Interagency Agreement, the Governance Plan contains the detailed list. For small projects with few stakeholders, this document may be absorbed into the Master Project Plan.

      Governance Plan

The implementation Plan shall describe the Contractor's operational preparation necessary for implementating the [Project Name] system. It should describe the scope, impact analysis, installation of network, hardware, software, security, documentation, training, data conversion, interfaces, and staff transition to the new system.

      Implementation Plan

The ITPP is a DGS mandated document that describes the strategy the project office will use (e.g. firm-fixed price, cost-plus) in procuring goods and services from a vendor. The ITPP is prepared in conjunction with the FSR or initial IAPD. The format of the ITPP is controlled by DGS.

      IT Procurement Plan (ITPP)

The Interface Plan shall describe the unique interfaces involved with the new system. It presents the systems functional, technical, and operational design that accurately reflects the contractor’s creation and support of these interfaces.

      Interface Plan

The Issue and Escalation Process describes how the project identifies, tracks and manages issues and action items that are generated throughout the project life cycle. The process also defines how to escalate an issue to a higher-level of management for resolution and how resolutions are documented.

      Issue and Escalation Process

The Key Budget Schedules document provides information on the various schedules associated with the Budget Summary. The schedules (1-12) described in this document are those that may be the most useful for the public, private sector, or other levels of government.

      Key Schedules

The Contractor shall develop (in cooperation with the [Project Name] Project Office) a Knowledge Transfer and Training Plan to describe the approach for bringing managers, end users and technicl personnel to a familiar level of understanding with how the new system works and how it differs from the system being replaced.

      Knowledge Transfer and Training Plan

The Lessons Learned is a list of observations and suggestions for future improvement based on recent project experiences that may be used by other projects. Lessons may identify both successful and unsuccessful activities.

      Lessons Learned Instruction
      Lessons Learned Report

This template provides a data model of the information system in business friendly language. The logical data model includes a data dictionary, data classification, and relationship information. The model will be used to as an input to the physical data model.

      Logica Data Model Toolkit

This template provides a model of the application and the services provided in business friendly language. Identifies the service components of the solution.

      Logical Service Model Toolkit

This template provides a model of the infrastructure requirements needed to host an application’s solution. The model will be used to help build the Physical Technology Model.

      Logical Technology Model Toolkit

The Master Project plan establishes how the project office will manage the project. It is the highest-level authority for project management under the project charter and is the document that ties all other project management documentation together.

      Master Project Management Plan

The Contractor Transition to M&O Plan will be the document that describes how the Contractor intends to support the System during the contractual period and transitions that support over to the responsible State entities.

      Transition to M&O Plan

The Operational Support Documentation Outline document provides guidance in the uniform creation of the operational support document. The purpose of the operations support document is to provide instructions to the system operators on the procedures for operating, controlling, troubleshooting, and maintaining the system once implemented in production.

      Operational Support Documentation Outline

The OSI Budget Language Definitions document provides budgetary terms which are used frequently throughout the Governor’s Budget, the Governor’s Budget Summary, and the annual Budget Bill. Definitions are provided for terminology that is common to all publications.

      OSI Budget Language Definitions

This template provides a model of the information system in vendor specific terms and language in detail. Includes the specification for all tables and columns and foreign keys to identify relationships between tables. The physical data model may differ from the logical data model based on physical considerations.

      Physical Data Model Toolkit

This template provides a model of the application and the services provided in detail. Identifies the service components of the solution.

      Physical Service Model Toolkit

This template provides a model of the infrastructure requirements needed to host an application’s solution.

      Physical Technology Model Toolkit

A PIER is created at the completion of an IT project and describes the results of the project, including actual completion dates and costs, objectives achieved, lessons learned, and corrective actions for any objectives not achieved. The format of the PIER is dictated by OCIO. The PIER template and instructions may be accessed via the SIMM link found under External Links found on the Navigation Menu to your left.

      PIER Instructions

The Project Charter describes the purpose, expected outcomes, and high-level approach to the project. The charter is used to confirm expectations with the sponsor and stakeholders and to formally authorize the project.

      Project Charter Template
      Project Charter - small project

The Project Concept Statement is a brief statement summarizing the purpose, approach, necessary resources, risks, and impacts of a proposed project/initiative. Executive management uses the concept statement to determine if the proposed project/initiative can be successful based on current resource availability, skill sets and timelines. If approved, the concept statement is used to create the Project Charter.

      Project Concept Statement

The Master Project plan establishes how the project office will manage the project. It is the highest-level authority for project management under the project charter and is the document that ties all other project management documentation together.

      Master Project Management Plan

A chart depicting the organization of the project. Note that there are different ways to depict the organization, such as by function (e.g., administration, implementation, quality assurance), by hierarchy (e.g., sponsor, manager, leads, staff), and by staff classification (e.g., DPM, SSM, consultant, etc.).

      Functional Organization Chart

The Project Status Summary Reports vary in format and purpose, and are targeted to different stakeholder audiences. The importance of standardized reporting on project status is vital to project success and is therefore included as a placeholder for future improvements.

      Project Status Summary Report

The Quality Management Plan defines how the project will tailor and administer the OSI quality program to project-specific conditions. The Quality Management Plan uses IEEE Std 730 as its framework and incorporates considerations for process improvement and test and evaluation.

      Quality Management Plan

The Request for Proposal (RFP) used to solicit proposals from the bidding community based on a set of defined requirements. The requirements may be general in nature allowing the bidders to propose a solution and the specific products to be used. The RFP describes the problem requirements, contractual terms, and required format for the proposal responses. The RFP also includes the specific criteria which will be used to evaluate the received proposals. The project works with DGS to ensure the RFP meets all appropriate state guidelines and regulations.

The Requirements Traceability Matrix Outline provides guidance to the uniform creation of the requirements traceability matrix. The requirements traceability matrix maintains linkage from the source of each requirement through its decomposition to implementation and verification. The traceability matrix should contain columns that will be used to illustrate traceability to the requirements of the project contract, system and software specifications and detailed design specifications. The traceability is required to ensure that all requirements for the project are address and that only what is required is developed.

      Requirements Traceability Matrix Outline

The Contractor shall apply release notes for each release of software to the [Project Name] system.

      Release Notes

The Risk Managment Plan defines the process and how the OSI-defined tool (e.g. Risk Radar) is used to implement the methodology for risk management, including identification, quantification, and response to project risks.

      Risk Management Plan

The Software Requirements Specification Outline provides guidance in the uniform development of the software requirements specification document, which is a structured collection of information that embodies the requirements of the software. The purpose of the software requirements specification is to communicate the stakeholder entities requirements to the technical resources that will specify and build the software to meet the requirements.

      Software Requirements Specification Outline

The Staff Management Plan identifies the process and procedures used to manage staff throughout the project's life cycle. The plan describes the planning and acquisition of both state staff and consulting staff, describes the roles and responsibilities assigned to each staff, and discusses staff transition.

      Staff Management Plan
      Responsibility Assignment Matrix

Staff Orientation Guide	Collapse
The Staff Orientation Guide defines the administrative processes, procedures, and guidelines for things related to the general operations of the project office, but not directly related to the contractual obligations or project-specific processes.       Staff Orientation Guide

System Engineering Management Plan	Collapse
The System Engineering Management Plan shall describe the contractor’s proposed efforts for planning, controlling and conducting a fully integrated engineering effort. The Plan will be used to understand and evaluate the contractors engineering work efforts as part of the contract monitoring process.       System Engineering Management Plan

System Requirements Specification (SyRs)Outline

Collapse

The System Requirements Specification (SyRs)Outline document provides guidance in the uniform development of the system requirements specification document, which is a structured collection of information that embodies the requirements of the system. The purpose of the system requirements specification is to communicate the stakeholder entities requirements to the technical resources that will specify and build the system to meet the requirements.        System Requirements Specification Outline

System Security Plan

Collapse

The System Security Plan describes the Contractor's approach to ensuring that the [Project Name] system (including all network components under the control of the Contractor, either by ownership or through contractual agreements) meets the security standards required by the [Project Name] Project. This DID is based on ISO/IEC 27002 Information Technology, security techniques, code of practice for information security management. In the event the Contractor has an existing security framework or plan based on ISO/IEC 27002, that document may be submitted in lieu of this deliverable pending state approval.       System Security Plan

Technical Reviews are conducted at the end of each SDLC phase of the Project Life Cycle. The technical reviews offer the opportunity to gather all of the information and documentation needed for a specific phase. All decisions will be documented and agreed to prior to moving into the next SDLC phase.

      Technical Reviews

The Test Cases Outline provides guidance in the uniform creation of the project test cases. The purpose for the creation of test cases is to allow for the comparison of the system against the defined specifications. The creation of the test cases should utilize a standard format with definitions of the form and content describe in the outline section of this document.

      Test Cases Outline

The Test Summary Report Outline provides guidance in the uniform creation of the project test summary report. The test summary report derives its information from the results of the testing effort and should summarize all testing activities and results. The test summary report’s ultimate goal is to provide a formal reporting mechanism related to the testing phase. The creation of the test summary report should utilize a standard format with definitions of the form and content describe in the outline section of this document.

      Test Summary Report Outline

The Test/Incident Tracking Log Outline provides guidance in the uniform creation of the project test log. The test log is coupled with the test cases and the purpose for its creation is to provide a chronological record about the actual execution of tests. The results of the tests provide detailed evidence for incident reporting and enable reconstruction of testing as needed. The creation of the test log should utilize a standard format with definitions of the form and content describe in the outline section of this document.

      Test/Incident Tracking Log Outline

The Testing Supplemental Information contains general information regarding the different test stages used throughout the System Development Life Cycle. This document should be used as a reference when developing the Test and Evaluation Master Plan.

      Testing Supplemental Information

The Test and Evaluation Master Plan describes how the project will perform each stage of testing throughout the project. Use the Testing Supplemental Document as a resource when developing the Test and Evaluation Master Plan. The testing templates provide a place to capture all of the testing data.

      Test and Evaluation Master Plan
      Test Plan Template
      Test Case Report Template
      Test Log Template
      Incident Tracking Log Template
      Corrective Action Plan (CAP) Template
      Test Summary Report Template

The Training Plan shall describe how the contractor will provide training to state and customer/user community staff during the transition.

      Training Plan

The Contractor Transition to M&O Plan will be the document that describes how the Contractor intends to support the System during the contractual period and transitions that support over to the responsible State entities.

      Transition to M&O Plan

The User Document Outline provides guidance in the uniform creation of user documentation. It outlines the structure and informational content the user document should contain to create a complete and usable document. Proper identification of the documents intended audience is crucial to determining it usability for its purpose.

      User Documentation Outline

The Vendor Handbook provides contracted vendors with standardized administrative guidance on matters related to their interactions specific to the OSI organization. The vendor handbook is typically referenced in the Contract Management Plan.

      Vendor Handbook