| Business Architecture |
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
|
|
| Business Relationship |
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
|
|
| Communication Plan |
This document defines the methodology for managing project communication needs such as information distribution methods, modes, performance reporting, and lessons learned.
 Communication Plan Template
|
|
| Conceptual Solution Architecture |
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
|
|
| Contract Management Plan |
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
|
|
| Cost Management Plan |
This document 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 Template
|
|
| Data Item Description (DID) |
A Data Item Description describes the specific format, content and level of detail for a contractor deliverable. This document is generally included or referenced in the RFP and is not negotiable. Compare to Deliverable Expectation Document (DED).
Data Item Description Template
|
|
| Deliverable Expectation Document (DED) |
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 Template
|
|
| Deliverable Management Process |
This 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 Template
|
|
| Detailed Design Specification Outline |
This document 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
|
|
| Evaluation and Selection 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 Template
|
|
| GC 19130 Justification Form |
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 Template
|
|
| Governance Plan |
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 Template
|
|
| Information Technology Procurement Plan (ITPP) |
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) Template
|
|
| Issue and Escalation Process |
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
|
|
| Key Budget Schedules |
This 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
|
|
| Lessons Learned |
A list of observations and suggestions for future improvement based on recent project experiences. Lessons may identify activities that were successful as well as things which were not successful. Lessons learned should be forwarded to the division-level repository for use by all projects.
Lessons Learned Template
|
|
| Logical Data Model |
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.
Logical Data Model Toolkit
|
|
| Logical Service Model |
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
|
|
| Logical Technology Model |
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
|
|
| Master Project Management Plan (MPP) |
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
|
|
| OSI Budget Language Definitions |
This 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
|
|
| Physical Data Model |
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
|
|
| Physical Service Model |
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
|
|
| Physical Technology Model |
This template provides a model of the infrastructure requirements needed to host an application’s solution.
Physical Technology Model Toolkit
|
|
| Post Implementation Evaluation Report (PIER) |
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 DOF. The PIER template and instructions may be accessed via the SIMM link found in the State link category of Links & Downloads selectable on the Navigation Menu to your left.
PIER Instructions
|
|
| Project Charter |
A formal document that 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 Concept |
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 Template
|
|
| Project Organizational Chart |
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 Organizational Chart
|
|
| Project Status Summary Reports |
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
|
|
| Quality Management Plan |
This document 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
|
|
| Request for Proposal (RFP) |
A document 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.
Request for Proposal (RFP) Template
|
|
| Requirements Traceability Matrix Outline |
This document 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
|
|
| Risk Management Plan |
This document 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
|
|
| Software Requirements Specification Outline |
This document 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
|
|
| Staff Management Plan |
This 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.
 Appendix - Responsibility Assignment Matrix
Staff Management Plan Template
|
|
| Staff Orientation Guide |
This manual 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 Requirements Specification Outline |
This 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
|
|
| Test Case Outline |
This document 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
|
|
| Test Log Outline |
This document 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 Log Outline
|
|
| Test Summary Report Outline |
This document 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
|
|
| User Documentation Outline |
This document 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
|
|
| Vendor Handbook |
This document 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
|
|
