Budget Change Proposal (BCP)
A proposal to change the spending authority for project activities authorized by the DOF. A BCP is also required for any current year changes in spending authority. The DOF annually issues a Budget Letter with specific instructions for preparing BCPs. The term BCP can be used in a generic sense to refer to both the fall and spring process documents, or to specifically refer to the fall process document (the spring process document is a spring finance letter). |
Business Continuity Plan
The Business Continuity Plan describes what actions and decisions are needed to ensure critical business operations will continue in the event of a disaster or facility problem. The plan should discuss who has the authority to initiate the activities described in the plan, which operations should be continued, and how to re-establish the operations. |
Business Process Re-engineering Plan
The BPR plan addresses how business processes will be modified and changed as a result of a technology innovation resulting from the system acquisition. This plan describes how the BPR effort will be defined and managed. A BPR Plan is only required for large-scale process changes. For minor process changes, the approach may be included in the Implementation Plan. |
Capability Maturity Model (CMM)
The Capability Maturity Model describes the principles and practices underlying software process maturity. It is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The focus is on identifying key process areas and the exemplary practices that may comprise a disciplined software process. |
Change Control Process
This process describes how project baselines will be managed and maintained. Typically, projects will utilize a change/configuration control board (CCB) to identify and track configuration items and their disposition. This process is included or referenced in the Configuration Management Plan. |
Change Leadership Plan
The Change Leadership Plan describes how people are affected by technology innovation resulting from the system acquisition. This plan addresses how the people/culture will be affected and what steps will be taken to prepare them for the changes, which may include a change in job duties, new job skills, a new management structure, and/or a new method of doing business. |
|
Concept of Operations (ConOps)
A document used to describe the proposed system and method of doing business from the user’s perspective. The document is often prepared as part of the requirements gathering and definition phase. This document is optional, but suggested for complex systems where there is no legacy system or where the users have primarily relied on manual processes. Refer to IEEE STD 1362. |
Configuration Management Plan
The configuration management plan defines how the project office will maintain control of project baselines and items that must be tracked and managed in a formal and systematic fashion. Configuration items vary from project to project and depend on the level of control the project must maintain on items in support of the system acquisition. The project office Configuration Management Plan generally focuses on documents and project office infrastructure. The prime contractor will also have a Configuration Management Plan that describes how the developed system and software components will be controlled. |
| 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 (4156v1).doc
|
|
| 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 (4306v1).doc
|
|
County/Local Office Fiscal Processes
If the project office will be reimbursing or paying for county/local office implementation costs, a process must be defined for estimating, budgeting, approving, and tracking county/local office expenditures. The processes are written from the point of view of the project and include expectations for the counties/local offices and, if appropriate, the prime contractor. |
County/Local Office Implementation Status Report Template
The purpose of the Implementation Status Report is to give project management staff a snapshot view of the county/local office status, as well as the details for tasks in caution or critical mode. Typically, the report is delivered biweekly and contains a synopsis of workgroup status, issues, risks, changes to workplans, and progress towards key implementation milestone activities. The Implementation Team assists with the development of the report format, but content updates are the responsibility of the prime contractor and county/local office staff. |
County/Local Office Implementation Workplan Template
The work plan template describes the activities to be completed by the county/local office in order to prepare for implementation. The template is provided for the counties/local offices to complete/customize. The project office or contractor implementation team works with the county/local office to customize and provide status on activities within the work plan. |
County/Local Office Readiness Guide
The County Readiness Guide introduces the scope and complexities of the changes required during implementation and provides a basic understanding of the activities and decisions required of the county/local office. The readiness guide is meant to introduce the approach to implementation, the activities and responsibilities. It is presented as an informational tool to assist in understanding the scope of the effort and the impacts and implications of the effort for the county/local office. |
Current Process Analysis Report
This document describes the users current processes and method of doing business. It is used to identify impacts and opportunities for change which may be included in the new system. Usually created as part of a BPR effort. |
Data Conversion Plan
This document describes the approach to converting legacy data to a new format/database. The plan describes the tool(s) to be used, the types of automated and manual processes to be used, how data anomalies and errors are handled, and how converted data will be validated to ensure it is correct prior to its use in the new production system. This plan may be either a project office or contractor responsibility. |
|
| Deficiency Reporting Process |
This process describes how the contract-specific concerns (deficiencies) are identified, analyzed, tracked and ultimately resolved, particularly in the area of system performance, contract services, contract terms, and contract deliverables. This process is included or referenced in the Contract Management Plan. Note: See Problem Tracking/Management for problems specifically related to system performance. There may be some overlap between problems and deficiencies.
Deficiency Management Process Template (3348v3).DOC
Deficiency Management Process Tailoring Guide (3347v3).DOC
|
|
| 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 (3353v3).DOC
|
|
| 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 (2496v6).DOC
Deliverable Management Process Tailoring Guide (3343v3).DOC
|
|
DGS Alternative Procurement Request Form
A letter written by the project to DGS requesting permission to conduct an alternative procurement. The request is submitted to DGS with the project’s ITPP. Most of OSI’s projects are considered alternative procurements because the exact nature of the solution and products to be used are not known when the procurement is conducted. Refer to SAM Section 5215. |
|
| Document Management Plan |
This document explains the process and how the OSI-defined tool (e.g. iManage) is used to implement the methodology for establishing, maintaining, and modifying the documentation baseline, including version control of project documentation, format and style guides, and records retention and archiving. The Document Management Plan is referenced by the Configuration Management Plan.
Document Management Plan Template (2498v4).DOC
Document Management Plan Tailoring Guide (3386v3).doc
|
|
Feasibility Study Report (FSR)
The state approval document required for initial project approval that contains analyses of options, cost estimates and other information. A customized Implementation Advance Planning Document (IAPD) is accepted in lieu of an FSR, for those projects receiving federal funding. The format of the FSR is dictated by DOF. |
Future System Approach
The document describes the "To Be" view of the system, and is produced as part of a BPR study. It is designed to help the users visualize how they will interact with the new/updated system, particularly focusing on business processes and interactions with the system. |
Go Live Support Guide
The Go Live Support Guide provides an overview of the tasks that a county/local office will execute as they prepare to implement and operate the new/modified system. It describes the specific roles and responsibilities, a schedule of activities for the go live period, and instructions for how to log and escalate problems or issues. |
| 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 (3874v1).DOC
|
|
Implementation Advance Planning Document (IAPD)
The IAPD is the approval document used to request initial federal funding for the Development and Implementation, and Maintenance and Operations phases of a project. The IAPD, customized to meet state requirements, is accepted in lieu of the FSR. See also PAPD. |
Implementation Advance Planning Document Update (IAPDU)
The IAPDU is an update to the IAPD submitted to the project’s federal stakeholder annually or as needed to reflect changes in project approach. The IAPD and IAPDU, customized to meet state requirements, are accepted in lieu of the FSR and SPR, respectively. See also PAPD. |
Implementation Guide(s)
This document provides detailed information for the counties/local offices on the upcoming implementation effort. The guide describes the roles and responsibilities for the county/local office, state, and contractor staff. It summarizes the upcoming activities, costs, decisions which must be made and process impacts, and provides the county/local office with appropriate reference and sample materials to use in preparing for implementation. There may be a single guide or separate guides for each of the implementation functional areas. |
Implementation Plan
The implementation plan defines how the system developed by the prime contractor will be implemented in the target environment. In the event of statewide implementations, the plan addresses how the system will be implemented into each site/location. |
Implementation Troubleshooting Guide
This document provides counties/local offices with a tool to assist in troubleshooting problems or issues during the “soft” go live/go live periods and as the system transitions into production. The troubleshooting guide is organized into typical business scenarios based on past business experience or earlier implementation efforts. |
| 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 (2493v5).DOC
|
|
Infrastructure / Facilities Plan
This document addresses the specific strategy to building, furnishing and/or moving into a new location or office space for the project office. The plan must discuss the preparation and installation needs including electrical, telecommunications, security, furniture, and computing equipment. This document is produced as needed. |
Inter Agency Agreement (IA or IAA)
A formal agreement between state organizations. OSI and the sponsor establish an IA that describes the agreement regarding management of the OSI projects in support of the sponsor’s programs. The IA includes the costs for which the sponsor will reimburse OSI and thus must match the numbers in the final State Budget for each fiscal year. Refer to State Contract Manual (on the Navigation Menu to the left, select the Links & Downloads option and go to the State page to find a direct link to the manual). |
Interface Requirements Document (IRD)
Describes the requirements for the existing or known interfaces for the system. This document is developed by the project and included or referenced in the RFP. The prime contractor further refines the interface requirements and documents specific requirements in their Software Requirements Specification, Interface Requirement Specification and resulting design documents. |
| 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 template (4004v1).DOC
|
|
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. |
M&O Transition Plan
The M&O Transition Plan addresses how the project office will manage the project once the system is implemented in the production environment. The plan focuses not only on the transition implications when moving into the M&O life cycle, but also on the transition of M&O responsibilities between the prime contractor and the M&O contractor. |
Maintenance and Operations (M&O) Plan
The M&O Plan summarizes the project’s approach to M&O. The plan is similar to the Master Project Plan, but with an emphasis on sustained operations instead of development and implementation. The M&O Plan places a stronger emphasis on the strategic direction of the project/system, the approach to system releases, upgrades and maintenance, and ongoing operations and customer support. |
|
Memorandum of Understanding (MOU)
A formal agreement with another organization that defines the roles and responsibilities and expectations of each party. Usually used to establish an agreement with counties/local offices, particularly when the project will be reimbursing the county/local office for implementation expenses. Refer to the State Contracting Manual. |
Metrics Process
The Metrics Process describes how measurements will be identified, collected, and analyzed to ensure quality goals (including management and system goals) are being accomplished. The Metrics Process is usually included or referenced in the Quality Management Plan. |
OSI Orientation
OSI Orientations are project team orientations designed to familiarize new project office staff with the OSI organization in general. OSI Orientations are not project-specific. |
OSI Training Plan
The OSI Training Plan defines the division-level training that is mandated on all projects from the OSI organization. Training requirements are general in content and emphasizes topics that have long-term relevance to all projects in OSI (e.g. OSI orientation, Using the BP website, Understanding the OSI life cycle etc). |
Performance Review Presentations
Performance reviews are internal reviews of project office (not contractor) performance and status. These reviews are formal and in-person with the OSI Assistant Director and the project team. These reviews are conducted quarterly and typically do not involve the sponsor or contractor. |
Planning Advance Planning Document (PAPD)
A PAPD is an approval document used to request federal approval and funding for the Initiation, Planning and Procurement phases of a project. There are no approval documents comparable to a PAPD in the state process. Upon selection of a vendor and agreement on project costs, the project submits an Implementation Advanced Planning Document (IAPD). |
Planning Advanced Planning Document Update (PAPDU)
A PAPDU is an updated to the PAPD submitted to the project’s federal stakeholder annually or as needed during the planning phase to report project progress and changes. Upon selection of a vendor and agreement on project costs, the project submits an IAPD. |
Policy Impact Analysis
If performed as part of a BPR effort, this document describes any impacts to the existing policies, particularly if there are changes needed. This document should also highlight areas where the automated system will streamline or assist with implementing policy, and areas where changes in implementing the policy will occur (for instance, changing a team leads manual approval to an automated approval). A Policy Impact Analysis may also be completed as part of the analysis of proposed legislation or policy changes, in which case it describes the anticipated effect of the legislation or policy on the new/existing system. |
Position Descriptions
A document describing the tasks, knowledge, skills and abilities required for a given staff position. PDs are specific to a position on a project and should be consistent with the approved position classification. |
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. |
| Problem-Defect Tracking Process |
This process describes how the system-specific concerns (system deficiencies) are identified, analyzed, tracked and ultimately resolved, particularly in the area of the automated system and/or system documentation. Typically, a help desk would collect system problems and manage the eventual resolution. This process EXCLUSIVELY addresses system-related problems. Some system problems may also be considered deficiencies (refer to the Deficiency Reporting Process).
Problem-Defect Tracking Process Template (3322v3).DOC
Problem-Defect Tracking Process Tailoring Guide (3323v3).DOC
|
|
Process Gap Analysis
This document describes the differences between the current method of doing business and the desired or proposed way of doing business. Generally produced as part of a BPR study, it focuses on identifying what needs to be done to achieve the desired way of doing business. |
Process Implementation Plan
A document used to implement large-scale process changes, such as part of a BPR process. The plan describes the approach to implementing, training, monitoring and correcting the new/modified processes in the actual county/local office location(s). For smaller scale process changes, this information may be included in the Implementation Plan. |
Process Improvement Plan
The Process Improvement Plan describes how the project will tailor and administer the OSI mandates for continuous process improvement to project-specific conditions. The OSI Enterprise Project Management Office coordinates process improvement initiatives at the OSI-level. The Process Improvement Program is typically described as a section within the Quality Management Plan. |
|
| 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 (3269v3).DOC
|
|
Project Master Schedule
The high-level schedule which summarizes all the efforts required to implement the project. It includes (generally by reference) the milestones and key activities of the prime contractor and any consultants. It may also include milestones and key activities from the counties/local offices. The master schedule focuses on dependencies and critical path. |
| 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.).
 Model Project Office - Functional Organization Chart (3337v1).PDF
|
|
Project Toolset Change Control Process
The change control process utilized by the organization to allow for the customization of the project office suite of tools to meet the specific needs of the project. Unlike the "project" change control process, this process is limited to the OSI standard set of project office tools. Some tools and changes must be coordinated at the division level while other changes may be coordinated at the project level, depending on the nature of the change and whether the tool is considered an OSI standard tool. |
Project Training Plan
The Project Training Plan includes training that is unique to the specific needs of the project (e.g. welfare training, unemployment insurance training, etc.) and is determined as the special project need arises. Also refer to the OSI Training Plan for general training requirements for all projects in OSI. |
Project Work Plans
The detailed list of activities required to complete specific tasks on the master schedule. The activities list focuses on specific measurable tasks, task assignments, and due dates. Work plan data is rolled-up to specific tasks of the master schedule. |
Project-Specific Orientation / Training
Project-Specific Orientation/Training is provided to new project office staff for the purpose of familiarizing them with project-specific information. |
|
Proposal Evaluation Report
The report describing the results of the proposal evaluation effort, including the identification of the selected bidder. The report summarizes the criteria used, the bidders who responded, the specific scores for each bidder and any preference criteria applied. The DGS Analyst assigned to the procurement coordinates the development of this report, which is forwarded to DGS management for approval. |
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. |
Request for Interest (RFI)
A letter released to the bidding community seeking to identify interested bidders for a particular procurement. The RFI generally describes the background of the business problem and may describe some of the key requirements. The project works with DGS to develop and release the RFI. |
| 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) Tailoring Guide (3379v3).DOC
|
|
Requirements Management Plan
This document describes the approach to managing the system requirements. The plan describes how requirements are derived and validated, how requirements changes are analyzed and managed, how requirements traceability is maintained and validated, and how the project works with the contractor to ensure traceability of requirements to the system and system documentation. |
Requirements Traceability Matrix
A Requirements Traceability Matrix is a tool that will ensure that all requirements have been fulfilled in the end product by associating each requirement with the object via a matrix. Requirements traceability includes tracing to things other than software that satisfy requirements such as capabilities, design elements, manual operations, tests, etc. A traceability matrix is also used to ensure all requirements are met and to locate affected system components when there is a requirements change. |
Responsibility Assignment Matrix (RAM)
The Responsibility Assignment Matrix (RAM) assigns responsibilities for project work components to project roles. Refer to the Staff Management Plan for instructions on using the RAM. |
RFP Addenda
Addenda are issued after the RFP is released to the bidders to clarify requirements or bidder instructions, or to respond to questions from the bidders. The project must work with DGS to issue any addenda. |
|
Schedule Management Plan
This document describes the process and how the OSI-defined tool (e.g. MS Project) is used to implement the methodology for establishing, managing, and modifying the Master Project Schedule and Schedule Baseline, and coordinating inputs from the contractor and county/local office work plans and schedules. |
Service Level Agreement (SLA)
This document describes the system performance and service level expectations and requirements for the prime contractor during the Implementation and M&O phases. The SLA includes target performance measures, unacceptable measures and penalties for not meeting required service levels. Usually included or referenced in a SOW and contract. |
SLA for the Data Center
If a data center will be hosting or providing services for the system, a Service Level Agreement with the Data Center is needed. The SLA describes the system performance and service level expectations and requirements for the data center during the Development, Implementation and M&O phases. The SLA includes target performance measures, unacceptable measures and penalties for not meeting required service levels. Usually referenced as part of a SOW and contract. |
SOW for the Data Center
If a data center will be hosting or providing services for the system, a Statement of Work (SOW) with the data center is needed. The SOW describes the specific tasks, activities and deliverables that the data center will provide to support the system. The SOW is used with some type of contract vehicle to establish binding responsibility for the work to be performed. An SLA is usually included or referenced by the SOW. |
|
Statement Of Work (SOW)
The SOW describes the specific tasks, activities and deliverables the contractor will provide to the project. The SOW is used with some type of contract vehicle to establish binding responsibility for the work to be performed. An SLA may be included or referenced by the SOW, if appropriate. |
|
System Requirements Specification (SyRS)
Developed by the project to describe the business and system requirements based on the user/sponsor needs. The SyRS is included or referenced in the RFP and forms the basis for the system. The prime contractor further refines the requirements in their Software Requirements Specification and resulting design documents. |
System Test Summary Report
This report describes how test activities were performed and a summary of the results of the test. The report should provide a clear picture of what tests were performed, what types of problems were found, the severity of problems found, how the problems were resolved (or what is currently being done to resolve them), and if the system was sufficiently tested to provide confidence that the system is ready for the next phase. |
Test Strategy
The Test Strategy is used to help the project office clarify expectations with the user and sponsor (and contractor) regarding their obligations in the testing and acceptance of the new system in the user environment. The prime contractor may also prepare a Master Test Plan (as part of the contract) that describes their approach to all testing phases and the activities for which they are responsible. |
Travel Budget
The Travel budget is established to allocate funds for travel on behalf of the project. Typically travel includes site visits to the counties/local offices to prepare for implementation, attendance at federal or national conferences and select training symposiums. The travel budget is submitted annually in accordance with the DOF process. |
User Training Plan
The User Training Plan describes the approach to training the system users. This plan includes the different types of training (staff, lead, manager, administrator), the specific courses and course materials, the training approach, and how training effectiveness will be measured and addressed. This plan may be developed by the prime contractor or the project office. |
| 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 Template (2495v6).DOC
|
|
|
Work Breakdown Structure (WBS)
A product- or deliverable-based grouping of project work that defines the scope of work for the project. The WBS does not identify organization or responsibility, nor does it describe dependencies between products. |
Work Plans, County
These plans (one for each county) outline the component of effort that county stakeholders must employ in support of a statewide implementation. County workplans are integrated into the overall project schedule via guidance and coordination provided by the project office. |
Work Plans, Project Office
Detailed descriptions of work activities performed by the project office in carrying out the duties of the project office. The work plans are derived from and traceable to the WBS elements, include interfaces from the prime contractor schedule, county schedules, and form the basis for network diagramming, critical path analysis, and the creation of the master project schedule. |
