CWDS
Document Management Plan

Objective

This is the Document Management Plan for the Child Welfare Digital Services project. The aim of this plan is to control the storage and distribution of documents, important historical data and information. The plan establishes the methodology for the creation, updating/approval, storage, and distribution of documents. This plan will be evaluated and updated as necessary. As the project transitioned over to the agile methodology, we have introduced new tools and definitions to help with document management.

Scope

The aim of the Document Management Plan is:

Define the types of documents, roles and metrics used in the management of documents.
Describe the infrastructure and tools to be used to ensure proper management of documents.
Classify the standards for the preparation of the document plan.
Document change and version control procedures.
Approach for backup, storage, retention, and distribution.
Document development and life cycle.

References

The review and approval process for digital service vendor deliverables and work products is contained in the CWDS Deliverables Management Plan.

The quality assurance audit and review process for document management is defined in the CWDS Quality Management Plan.

Document Types, Roles and Metrics

This section defines “document” for this plan and outlines the roles for those involved in document management and the metrics that measure the output of the Plan process.

Document Types

Table 2-1 identifies the types of documents created, received, and used by the Project and governed by the document management process.

Table 2-1 Types of Project Documents

Type	Description
Administrative Documentation	Documents pertaining to the administrative operations of the project, including documents for funding, personnel, staffing, equipment licenses and warranties, etc.
Analyses and Recommendations	Documents describing a specific problem or scenario and the anticipated impact and/or recommended course(s) of action (e.g., risks, issues, etc.).
Contract Management Documentation	Documents associated with the solicitation, administration, and management of the contractor’s supporting the project (e.g., contract deliverables, bidder’s library documentation, work authorizations, etc.).
Correspondence and Communications	Documents sent to or received from any organization external to the project, including the project sponsor, control agencies, federal stakeholders, counties, advocates, and the public.
E-mail¹[1]	Only critical e-mail is retained, such as important information received from contractors or other outside sources. As per OSI guidelines, project staff should not use email for formal communication or decision making on the project. Critical e-mail is saved and imported into stored folders on either the shared network drive or SharePoint as .msg files. Non-critical e-mail is purged at the user’s discretion. E-mail and other electronic documents are open to public access under the Public Records Act (PRA), unless privileged or otherwise exempt. Follow these rules for confidential e-mail information: Both incoming and outgoing e-mail can be retained for critical business purposes in designated shared network or SharePoint files. E-mail can be saved into shared folders or SharePoint by saving locally and imported to the appropriate location. E-mail that is no longer needed for business purposes should be purged at the user’s discretion. It is important to note, even though e-mail has been purged it is still discoverable.
Plans, Processes and Procedures	Documents describing the purpose and approach to the project, including the plans, processes and procedures that describe how the project will be executed and managed (e.g., Project Management Plan, Scope Management Plan, Change Requests, etc.).
Presentations and Training Documents	Documents used in training or briefing project staff, county staff, control agencies or stakeholders.
Procurement	Documents used in the development, analysis, review and final distribution of procurements for State services or products.
Reference Materials	Documents generated by an external organization that provide insight, guidance, or examples of pertinent information such as legislation, policy, regulations, handbooks, standards, etc.
Report and Status Documentation	Documents describing the current status of planned and actual activities for the project, including funding, contract, schedule, issue and risk status, and meeting minutes describing decisions, action items and concerns.
Work Products	Ancillary documents used in the daily operations of the project, such as meeting agendas, meeting minutes, presentations, spreadsheets, procedures, etc.

[1] The Email system, which provides transmittal and storage of documents, is currently out of scope for the Document Management Plan, yet is included in this table for completeness.

In general, materials published by another organization in a public location (e.g., Internet) are not retained as project documents. In addition, some personnel and procurement documentation may be turned over to the department’s Human Resources and/or Department of General Services (DGS), respectively, instead of being retained by the Project.

Some project information is retained in project databases that provide tracking, reporting and storage capabilities. Examples of these types of databases include issue tracking, risk tracking, action items, etc. These databases are normally managed by the Project Management Office (PMO) staff directly with a designated project lead or project manager managing the content of the databases.

Roles and Responsibilities

Table 2-2 below provides a list of the roles and responsibilities in the document management process

Table 2-2 Document Management Roles and Responsibilities Matrix

Role	Responsibility
CWDS Contract Manager	Collects and gathers relevant CWDS related information from supporting contractors and digital service vendors for inclusion into the project library (deliverables, status reports, assessments, TAP updates, etc.). Ensures all contract documentation is maintained.
Project Team	Creates and stores documents as per established rules for hard copy and electronic documentation. Completes the document properties information for each document. Identifies critical hardcopy and e-mail documents that should be retained in the hard copy library. Scans, as appropriate, critical hardcopy items, and posts to the electronic document library. Retains working copy of files in individual staff work areas.
Document Author	Utilizes the Document Management Plan to provide the foundational information for developing the draft document for internal project documentation. Develop/Revise the Plan using OSI template and industry standards/best practices. Conduct conceptual walk-through of the Plan and revise the Plan based on comments received from the Document Review Team. Working with the PMO, define an implementation approach for institutionalizing document management processes. Working with the PMO, conduct training, as appropriate, for the end users of the Plan’s processes and procedures. Submits defined tasks for document development and review to Project Scheduler for inclusion in project schedule, and updates tasks as necessary.
Document Review Team	Responsible for the review of various project documents and deliverables according to a specific skill and knowledge set. Review assigned Plans and provide comments to the Document Author using a comments matrix document.
Project Director	Ensure deliverables are archived as defined. Review and Approve process changes to document management.
Project Librarian	Manage and track CWDS project internal documentation for inclusion into the project library. Maintains the document libraries and processes request for document posting to Electronic libraries. Ensure project documents are stored correctly in the project library and in compliance with standard naming conventions and version control policy. Receive and track contractor, vendor and State deliverables. Ensure the repository profiles are complete and consistent. Comply with the OSI’s records retention policies. Archive hardcopy documents, if appropriate. Periodically monitor compliance to the process and work with the Project staff to institutionalize these processes in their daily work activities.
Site Owner/Admin (Slack, SharePoint, GitHub)	Maintain SharePoint application and database. Act as a resource for project staff and stakeholders regarding the tool. Create and manage user accounts. Set up document profile information to be used. Control access and web parts with front-end administration. 1^st level Help desk for all SharePoint issues.
PMO Project Manager	Ensures compliance with the project’s document management plan. Approves the Document Management Plan.
Quality Manager	Provide compliance check to approved standards and guidelines. Provide consistency and completeness check for content. Perform periodic document library audits.
Project Scheduler	Enters tasks submitted by Document Author for all internal document development and review activities.

Metrics

The table below describes the metrics and steps that are necessary to ensure there is compliance with the Document Management Plan.

Table 2-3 Document Management Metrics

Process Area	Metric	Measurement	Reported By	Threshold Tolerance
Internal Project Documents	Internal Document Timeliness (Determines compliance to scheduled milestones for documents)	Number of Documents Submitted on Time / Total Number of Documents (Within reporting period)	Project Manager	No more than 10% pf the total number of deliverables are submitted late for the reporting period
Internal Project Documents	Document Acceptance Rate (This is an indirect measure of project quality by measuring the percentage of documents accepted on time without delays to resolve material deficiencies)	Number of major Deficiencies / Total Number Deficiencies (Within reporting period)	Project Manager	No more than 10% of the total number of documents are accepted later than planned for the reporting period. No more than 25% of the deficiencies identified in the document reviews are categorized as major.
Quality Process Audit	Percent of compliant quality process audits for document management	Total compliant quality process audits on document management / Total quality process audits on document management (Within reporting period)	Project Quality Manager	No Quality Process Audits with an overall RED status.

Document Management Tools and Storage

The CWDS utilizes various tools throughout the life cycle of a document. The table below indicates the tool, life cycle and process.

Tool	Life cycle / Process
Slack	Slack is not a repository for documents or files beyond discovery or alpha. An example of this would be a document that has been created in Microsoft word that does not have formal headers, footers, and other necessary formatting standards. See Slack Usage and Guidelines (Note: This link is temporarily for OSI internal use only) for more details.
G Suite	G Suite is not a repository for documents, files, or artifacts beyond discovery or alpha. G Suite is intended to be used for quick collaboration and sharing both internally, or externally (with Users who may not have access to Sharepoint). See G Suite Usage and Guidelines for more details.
Confluence	Confluence is not a repository for documents, files, or artifacts beyond discovery or alpha. Confluence is intended to be used for quick collaboration and sharing both internally, or externally. See Confluence Usage and Guidelines for more details.
SharePoint	For files that have progressed to Beta, please use your SharePoint team site as the document repository. These documents can then be linked to slack in a direct message or channel.
iManage	iManage is currently used to store and track deliverables for CWS/CMS. iManage and MTS will be phased out within the next couple of years.
Management Tracking System	After a deliverable has been added to iManage, the reference number is then entered into Management Tracking System (MTS) for routing and approvals.
GitHub	Once a document reaches beta, it is appropriate to publish to the CWDS GitHub website.
OneDrive	OneDrive should be used for personal work item storage in place of the network drive.
Network Drive	The current Project document repository is a shared network folder at the following path: G:\CWDS The Project is no longer using the network drive to store documents. *Exceptions to use: 1. Confidentiality (includes Financial, legal, etc...) 2. HR documentation (temporary until a private spot on SharePoint is established) 3. Previous documentation that links to other documents. 4. Contract documentation

Document Standards

This section defines the document standards for the storage, retrieval and development of internal documents and work products.

Internal Documents are defined as project management plans and technical plans that are developed by the project team and govern process and procedure for a particular business area. Work Products are ancillary documents that are used to manage daily operations, such as meeting minutes, meeting agendas, PowerPoint presentations, process and procedure templates, etc.

Document Types

Table 4-1 identifies the types of documents created, received, and used by the Project and governed by the document management process.

Table 4-1 Types of Project Documents

Type	Description
Administrative Documentation	Documents pertaining to the administrative operations of the project, including documents for funding, personnel, staffing, equipment licenses and warranties, etc.
Analyses and Recommendations	Documents describing a specific problem or scenario and the anticipated impact and/or recommended course(s) of action (e.g., risks, issues, etc.).
Contract Management Documentation	Documents associated with the solicitation, administration, and management of the contractor’s supporting the project (e.g., contract deliverables, bidder’s library documentation, work authorizations, etc.).
Correspondence and Communications	Documents sent to or received from any organization external to the project, including the project sponsor, control agencies, federal stakeholders, counties, advocates, and the public.
E-mail	Only critical e-mail is retained, such as important information received from contractors or other outside sources. As per OSI guidelines, project staff should not use email for formal communication or decision making on the project. Critical e-mail is saved and imported into stored folders on either the shared network drive or SharePoint as .msg files. Non-critical e-mail is purged at the user’s discretion. E-mail and other electronic documents are open to public access under the Public Records Act (PRA), unless privileged or otherwise exempt. Follow these rules for confidential e-mail information: Both incoming and outgoing e-mail can be retained for critical business purposes in designated shared network or SharePoint files. E-mail can be saved into shared folders or SharePoint by saving locally and imported to the appropriate location. E-mail that is no longer needed for business purposes should be purged at the user’s discretion. It is important to note, even though e-mail has been purged it is still discoverable.
Plans, Processes and Procedures	Documents describing the purpose and approach to the project, including the plans, processes and procedures that describe how the project will be executed and managed (e.g., Project Management Plan, Scope Management Plan, Change Requests, etc.).
Presentations and Training Documents	Documents used in training or briefing project staff, county staff, control agencies or stakeholders.
Procurement	Documents used in the development, analysis, review and final distribution of procurements for State services or products.
Reference Materials	Documents generated by an external organization that provide insight, guidance, or examples of pertinent information such as legislation, policy, regulations, handbooks, standards, etc.
Report and Status Documentation	Documents describing the current status of planned and actual activities for the project, including funding, contract, schedule, issue and risk status, and meeting minutes describing decisions, action items and concerns.
Work Products	Ancillary documents used in the daily operations of the project, such as meeting agendas, meeting minutes, presentations, spreadsheets, procedures, etc.
Contractor Deliverables	Contractor deliverables provide management a way to monitor and ensure proper contract management. See Deliverables Management Plan<link> and Contract Management Plan<link>.

Document Standards

All documents should follow the OSI Writing Style Guidelines in the following areas:

General Approach to Writing
Sentence Construction
Usage of Words and Terminology (dates, names, abbreviations, internet addresses, etc.)
Outline Format
Common Correspondence Guidelines

In addition to compliance with OSI Writing Style Guidelines, the Document Author should also comply with defined standard templates, if one exists. In the event a template does not exist for your internal document, a document should, at a minimum, contain the following standards:

Header – all documents and work products should have a header if the document is more than one page. The header should contain the following:
Footer – all documents and work products should have a footer if the document is more than one page. The footer should contain the following:
Revision History – all documents that go through a review process should have a revision history section to track various revisions to the document, unless specifically requested to be removed by a control agency.
CWDS Logo and branding – all documents should contain the CWDS Logo.
Minimize color in your document.

Document Tools

The Project uses the following document tools to develop documents, spreadsheets, e-mail, web content, databases, etc.

Table 4-2 Document Tools

Document Type	Development Tool
Document	MS Word 20XX
Spreadsheet	MS Excel 20XX
Presentation	MS PowerPoint 20XX
E-mail	MS Outlook 20XX
Web Content	MS FrontPage 20XX
Databases	MS Access 20XX SQL Server 2000
Diagrams	MS Visio 20XX
Reports	Adobe Acrobat
Schedules	MS Project 20XX
Swim Lanes	MS Visio 20XX

Document Naming Conventions

Documents should have file names that identify their origin, ease search and retrieval, and accurately reflect their content. Adherence to the standards helps maintain consistency in naming documents. The rules for naming may vary depending on what repository the document is located. Please see the Document Management_100_Naming Convention Procedure for more details.

Document Versioning

Document versioning is automatic within SharePoint and GitHub. Documents that are created in Slack are usually the first iteration and should not require additional versioning as they should be moved into a different repository during future revisions. The document should either be uploaded into SharePoint or GitHub depending on its purpose.

When adding or updating a file in SharePoint, there is a “Document Status” field which must be updated with the correct phase. See table below which describes the phases and criteria.

Phase	Key Activity	Exit Criteria
Alpha	Develop and update artifact Submit artifact for peer review Submit for your team’s Service Manager review	Peer review approval Team Service Manager approval
Beta	Update artifact Submit artifact for ELT Approval Submit for all Service Managers’ approval	ELT Approval All Service Managers’ approval Other key stakeholder(s) approval, as required
Live	Present document to project team, as required Make artifact available to general public, as appropriate	None

Document Storage and Control

This section outlines the guidelines for document storage and control of hardcopy and electronic documents.

Public Records Act Policy

According to the California Health and Human Services (CHHS) Agency Public Records Act (PRA) Policy, access to information concerning the conduct or the people’s business by the State of California is a fundamental right of every person. Disclosure of personal information, however, may constitute an invasion of privacy. If a request is received to view project documentation under the Public Records Act, ten days are allowed in which to respond. All OSI PRA requests should be immediately forwarded to publicrecordsrequest@osi.ca.gov .

Document Storage

Hardcopy Library Process

The Project has established the following guidelines for storing hard copy documents in the Document Library, where applicable as per guidelines established by the Project Management Office:

The hard copy storage area is located physically at the project site.
The Project Librarian governs what documents are stored in the hard copy library, and may reject some requests for documents to be stored.
The library is located in an open area that can be locked during non-state business hours, but will be accessible during normal state business hours. Access to the library during non-state business hours must be coordinated with the Project Librarian.
The library has an area large enough to store project documentation for each phase. Appropriate space will be projected for future growth of documentation.
For items that are allowed to leave the library, a checkout process will be in place. All items residing in the library will remain onsite and cannot be removed from the premises.

Note: The Project Librarian maintains a hardcopy storage area for documents that are obtained or available in hardcopy only. If the hardcopy item is considered critical (such as signature pages), the document is scanned and included in SharePoint (to serve as a backup). The hardcopy item is retained in a binder in the project library.

In addition, project staff members may submit items to the library at any time. A Sample Library Submittal Form is located in Appendix A: Hardcopy Library Submittal Form. This form is used to ensure the hard copy document is correctly filed and marked. The Project Librarian retains the completed forms in an index file separate from the actual document.

Hardcopy Library Access

Access control to the hardcopy library is governed by the following:

Library

Access Control

Responsible Party

Control Mechanism

Hardcopy Library

Locked drawer and file cabinets

Project Librarian
PROJECT Site Owner/Administrator

Librarian Audits

Electronic Library Process

Network Shared Drives:

The project no longer uses the network drive for document storage.

GitHub

Until project standards and processes have been finalized, documents will continue to be stored in SharePoint.

SharePoint

SharePoint is an enterprise collaboration tool, accessed through Office 365 and the Microsoft Cloud services. A global library structure with metadata will be established for the project and staff will be assigned read/write access as appropriate.

SharePoint uses document metadata to allow categorization of documents by specific attributes. SharePoint also has features for document check-in/check-out control, version control, document history, and searching. SharePoint is accessible through a website.

OSI Information Technology Office (ITO) controls access to SharePoint at the enterprise level and will be responsible for setting up access permissions for users and acting as 2^nd level help desk for SharePoint. The Project Site Owner/Administrator will be responsible for 1^st level help desk support. Metadata will be defined at the project team level.

The project will use SharePoint document libraries as the means to organize and locate documents within the system. Refer to the CWDS SharePoint User Guides (Note: This link is temporarily for OSI internal use only) for instructions on completing document properties. These include but are not limited to: Document Name, Document Category, Document Author, Version Number, Functional Area, Phase, and Document Status.

Electronic Library Access

Network Shared Drives:

Access control to the network shared drive is governed by the following:

Library

Access Control

Responsible Party

Control Mechanism

Electronic Library – Shared Network Folder

Share Drive View Privileges only

Project Librarian
CWS-NS Site Owner/Administrator

Librarian Audits

Access control to SharePoint is governed by the following:

Library

Access Control

Responsible Party

Control Mechanism

Electronic Library – SharePoint

SharePoint View Privileges only

Project Librarian
CWS-NS Site Owner/Administrator

Librarian Audits

For more information on SharePoint, refer to the SharePoint User Manual.

Library Control

The Project Librarian has the primary responsibility for managing and controlling the project’s hardcopy library, shared network folder and SharePoint library content. The Project Librarian performs periodic reviews of all repositories to monitor compliance to document management processes and procedures.

Hardcopy Library

At least once a year, the Project Librarian performs an audit of the hardcopy library to ensure all contents are correctly filed and present. Any discrepancies or concerns are documented in the project’s issue tracking or risk tracking system and assigned for correction.

The Project Librarian tracks the number of documents in the hardcopy Library and works with the Facility staff to ensure appropriate growth space is projected for future documentation.

Electronic Library

The Project Librarian also performs a partial audit of the SharePoint repository to verify compliance to document management processes and procedures. Any discrepancies or concerns are documented in the project’s issue tracking or risk tracking system and assigned for correction.

The Project Librarian tracks the documents in the electronic Library and works with the IT staff to monitor the size of the SharePoint database to address any database maintenance or changes required.

As the CWDS Project uploads more content into GitHub, the Project Librarian will also audit and monitor the GitHub site.

Document Retention and Purging

Backups

Shared Network Folder

All files are backed up by the CDSS IT Support staff and the backup tapes are kept offsite for two weeks on a rotational basis. Full backups occur once a week with incremental backups performed nightly. The backups include files on the server and network share drives, and e-mail on the MS Exchange server. No backups are performed of individual user hard drives (i.e., C: drives).

SharePoint

All files are backed up by the OSI IT Support staff.

Retention and Archiving

The State Records Management Act (Government Code, Section 14740-14774) requires the Director of the Department of General Services (DGS) to establish and administer the state’s records management program. The program applies “… to the creation, utilization, maintenance, retention, preservation, and disposal of state records.” DGS administers the program though the State Administrative Manual (SAM), Chapter 1600 and the California Acquisition Manual (CAM). SAM and CAM require every state agency to establish Records Retention Schedules which, when approved, becomes the legal authority for the agency to dispose of official public records. Retention schedules are the key element in effective records management programs for both government and private industry.”

Projects should consult with the CDSS Records Retention Policy in establishing retention schedules. For projects with federal funding, consult with the Code of Federal Regulations regarding public welfare retention policies (45 CFR Part 92).

If there are legal proceedings or issues associated with the project, records must be retained for the duration of the legal proceeding. Consult with Legal counsel on the appropriate retention period in these cases.

The following table defines the current document retention guidelines for the shared network folder:

Table 4-9-2 CDSS Document Retention Guidelines

Document Type	Retention Guideline
Administrative Documentation	Retain for the life of the project plus three years (minimum) Follow the appropriate Federal, State and/or OSI retention guidelines, as appropriate; in the absence of specific guidance, retain for three years
Analyses and Recommendations	Retain for the life of the project Only the final version must be retained for the life of the project plus three years
Contract Management Documentation	Retain for a minimum of three years after contract end. Interim and draft versions of deliverable used for review may be purged after the final deliverable is received For deliverables with multiple versions, the current and immediately prior version should be maintained Note: Records related to a contract dispute should be kept for longer periods; refer to the project legal counsel for guidance on retention periods in this case
Correspondence and Communications	Retain for 3 years or until superseded
E-mail	Critical e-mail is saved to the shared network folders for historical purposes. Retention of these items is dependent on the content. Refer to other guidelines in this table Retention of general e-mail is subject to the user’s discretion
Plans, Processes and Procedures	Only the most current version must be retained
Presentations and Training Documents	Retain for the life of the project plus three years Only the final version must be retained for the life of the project plus three years
Procurement	Retain for four (4) years after approved Post Implementation Evaluation Report (PIER).
Reference Materials	Retain for three years or until superseded or withdrawn Use discretion regarding usefulness of items
Report and Status Documentation	Retain weekly status documentation for one year, unless a particular decision was made at the meeting in which case retain for life of the project Retain monthly status documentation for three years Exception: Contractor status deliverables must follow the guidelines for Contract Management Documentation

Purging

Due to excess storage capacity, the project has not had a need to purge any documents and currently does not anticipate purging any documents in the near future.

Document Development Process

The previous sections have defined the approach for managing and storing project documents. This section defines a global approach for development of internal Project Management plans and work products. This approach ensures a consistent method is followed for every document to align formats, styles, content depth and breadth, and a consistent and quality definition of process and procedure.

Table 5-1 Steps to Determine Approach and Strategy

Step #	Phase	Description
1.	Determine Approach	The first step in developing a Document is to define the process, define what is in scope and what is out of scope, and get consensus on the approach and strategy of the process. Determine the document author and subject matter experts (SME) in order to create the document.
2.	Develop Document	After consensus is reached among the SMEs on the approach and strategy for the process, the second step is creating the actual document. The Project will create a variety of documents (deliverables, work products, supporting documentation, progress reports, metrics, etc.) through each stage of the project. Each Document must address its specific area of focus and not overlap or supersede another document/plan or process. A document author should include various focus groups to iteratively and collaboratively develop the content for the document in real-time.
3.	Review & Comment	Once the document has been developed by the focus group, the document needs to be reviewed by project management and oversight teams to determine if it meets the requirements. The review will focus on if the document meets the intended use, is consistent both internally as well as externally, defines process and procedure at the appropriate level and sufficiently, and meets the business needs and purpose of the process.
4.	Resolve & Incorporate	After the document is reviewed, make necessary changes to the document to align it comments brought up from project management and oversight review.
5.	Publish Document to SharePoint	Move the plan into the PMO’s document library “Agile Procedures, Policies, and Plans.” Ensure all embedded links function correctly. (Note: Link is temorarily for OSI internal use only.)
6.	Train on Document	Work with the Training Coordinator to schedule training session to train CWDS team on the revised plan.
7	Post Publicly on GitHub	If appropriate, work with the GitHub administrator or the project librarian to post the PM Plan to GitHub.

Determine Approach and Strategy for the Process

Step #	Description	Role
1.	Assign a Document Author based on skill set and knowledge base of the process.	Project Manager
2.	Get list of assigned SMEs for your process area from the Project Manager. SMEs are knowledgeable in specific process and technical areas and are assigned to help define the approach and process. The SMEs eventually become part of the Focus Group for the document.	Document Author
3.	The Document Author collaborates with assigned SMEs to develop an overview of what the document will include. The document author facilitates a discussion on the document expectations with the team members that will contribute to the development of the document.	Document Author SMEs
4.	Define the standards that will govern your document and associated processes, including but not limited to: PMBOK IEEE ITIL CA-PMM or OSI Best Practices CMMI	Document Author SMEs
5.	Project Management Plans: Align process scope with the matrix in Project Management Scope Matrix Procedure that defines the following for each PM Plan: Standards Purpose Scope Process Procedure This matrix will assist the Document Author in not duplicating process definition in multiple plans and assigns primary processes to specific Plans.	Document Author
6.	Schedule a focus group with SMEs to determine: Roles and responsibilities In Scope Processes Out-of-Scope Processes (reference to other primary process plans) Approach and Strategy for process in alignment with all other project processes Ina collaborative environment, make changes in real-time, use the white board to develop process flows and revise the document within the focus group setting. This process may require multiple focus group sessions.	Document Author Focus Group
7.	Make final changes to the document, iteratively reviewing the revisions as they are made with the focus group.	Document Author
8.	Reach consensus on the approach and strategy.	Document Author SMEs

Develop the Document

See Project Management Scope Matrix Procedure for more information on the specific scope and function of each plan.

Step #

Description

Role

Select the appropriate Document Template to use as the foundation of your plan.

Document Author

Ensure your document has a Cover Page, Table of Contents, and a Revision History.

Document Author

Complete Section 1 – Introduction. Based on meetings with SMEs and other team leads, document the following standard sections:

1.1 Purpose – State what the Document will be used for and what functions it will perform.
1.2 Scope – Provide a detailed list of what is in scope for your Document, and more importantly, what is out of scope for your Document.
1.3 Assumptions and Constraints (optional) – If there were specific assumptions and constraints that were identified or considered as part of the Document development, the Document Author should list them.
1.4 Integration with other CWDS Plans
1.5 Document Maintenance – Describe the process in which this plan will be updated.
1.6 Transition to Agile – Describe how the plan has been updated to reflect the change from SDLC to agile.

Document Author

Complete Section 2 – Roles and Responsibilities. Identify the key stakeholders that will execute the Document or benefit from it. Stakeholder role should refer to the generic role, not the person (e.g. Quality Manager, not Jane Doe).

All Responsibilities should start with a verb in the present tense (i.e. Review and approve process changes). Roles and responsibilities should be listed in table format:

Stakeholder Role	Responsibility

Document Author

Complete Section 3 – Process Approach. Define the processes required to execute the knowledge area in your Document. Processes are related activities that produce a specific service or product. Processes should be repeatable and continuously analyzed for improvement or reengineering. Processes are included as part of the base plan in the body of the Document.

Refer to Document Management_300_Process Definition Procedure for a detailed step-by-step guide on developing processes within the body of your document.

It is important to note that not all processes and procedures may be defined in the first version of the Document. Document Authors should take care to only define what can be managed by available staff. The first version of a document does not have to be perfect – it is acceptable to define processes slowly and continue to refine through progressive elaboration in future revisions.

Document Author

Define, if appropriate, the procedures needed to detail who performs the work, what steps are performed, when the steps are performed, and how the procedure is conducted. Procedures are step-by-step instructions necessary to perform a task or part of a process. Procedures should be referenced outside of the main process and stored in a separate procedural document.

Refer to Document Management_400_Procedure Definition for a procedure template and more supporting information on developing procedures.

Document Author

While documents are under development, the document author will mark the document as beta. The preferred method is to add a “Draft” watermark on each page of the document or simply save the document with the document status as part of the file name.

Document Author

For existing plans, review existing PM plan and make some general changes to the alignment to Agile.

Document Author

Review and Comment

As per the agile method, the review is no longer a lengthy formal process and is done with the focus groups on an iterative basis.

Step #	Description	Role
1.	Identify subject matter experts (SME) to participate in the focus group.	Document Author
2.	Hold focus group with SMEs to review and incorporate changes real time.	Focus Group
2.	Review Document and provide comments to the Document Author. Comments should focus on conformance with CA-PMM and industry standards, its fitness for purpose and fitness for use. Review comments should be for substantive issues and material deviations and should not focus on grammar or syntax.	Focus Group

Resolve and Incorporate Feedback

Step #	Description	Role
1.	After the Document is reviewed by the focus group, resolve and incorporate any changes.	Document Author
2.	Send Plan and comment log via email to PMO team including Quality Assurance (QA) for further review.	PMO + QA
3.	Incorporate changes from PMO team and QA.	Document Author
4,	Send Plan to focus group for final review	Document Author + Focus Group

Publish Document Online

Table 6-6 Approval and Baseline Steps

Step #	Description	Role
1.	Once the focus group has approved document, upload to the SharePoint library, Agile Plans.	Document Author
2.	Send out communications blast to Project that the plan has been posted to SharePoint.	Document Author
4.	Upload document to GitHub. (Current GitHub process is under development)	Document Author

Implement and Train on the Process

Once the Plan has gone through the review process and has been approved and uploaded, the project staff will start executing against the Plan’s processes and procedures. Send out a communication blast to notify the Project of the new plan and provide a link. The document author should prepare a high-level presentation during one of the Training, Learning, and Sharing sessions. This presentation will focus on how the plan has changed to align with Agile.

Appendix A: Hard-Copy Library Submittal Form

Library Submittal Form

Submitted By:

Date:

Document Title:

Document Type: Internal Only

External System Integrator

External Supporting Contracts

Control Agency

Doc Date:

(Use the date shown on the document or the date received at the project office)

Document Description:

Originator/Document Author:

Special Instructions:

Sensitive / Confidential

Replace previous version

Retain previous version(s)

Save to electronic library as back-up

GitHub Repository: ___________________

SharePoint Library: __________________

Other: _________________________________

Originating Office:

Project Office

Federal Stakeholder

Control Agency

Sponsor

User / Stakeholder

System Integrator

Supporting Contract

OSI CDSS CWDA

Other ________________________

Comments/Retention Instructions:

Library Location:

Binder / Folder / File: __________________