1.1 Purpose

The Project Management (PM) Plan (hereafter called the PM Plan) describes how the project will be executed, monitored, and controlled, as well as will focus on activities that establish the day-to-day operational execution of the CWDS NS project. The initial activity will be the development, communication, and management of the project plans and procedures that provide the project management framework for both the Child Welfare System – New System (CWS-NS) Project and the Child Welfare Services Case Management System (CWS/CMS).

The PM Plan focuses on agile delivery, Project Team, and Project Stakeholders with a working guide on how the Child Welfare Digital Services (CWDS) manages activities throughout the project lifecycle.

The PM Plan identifies the various elements of the project and their coordination. It also establishes the framework for integrating and managing some of the various project focus areas.

1.2 Scope

The Project establishes activities / events using six simple steps; initiating, planning, sprinting, reviewing, retrospective, and closing; as well as the management of unanticipated tasks, the project schedule, and lessons learned throughout the project activities. To assist with the comprehension of the scope, it is necessary to understand how the CWDS executes project management processes.

While agile defines the framework for project execution, ancillary project management plans are required to complete the definition to the approach, responsibilities, and sub-processes of the project management process.

1.3 Assumptions and Constraints

1.4 Integration with other CWDS Plans

Project References
The project is using OSI's CWDS SharePoint for its document repository. For the purposes of information sharing and transparency, the project is using the following tools:
Pivotal Tracker for its Sprint planning and execution.
Slack is used for enhanced open communication.

1.5 References including Subsidiary Plans and Procedures

All Plans and Procedures associated with this project are maintained on the OSI CWDS SharePoint Project Management subsite, as well as the draft CWDS Github site. While the review of these plans and procedures occur on a periodic basis, procedures are subject to change more frequently without the need to re-baseline the entire document. As of the latest version of this plan, the following plans are hereby incorporated:

Project Charter
The Project Charter is the document the formally authorizes the existence of a project and provides the Project Director with the authority to apply organizational resources to project activities.

Change Management Plan
Change Management Plan is the process of managing changes to project artifacts, application code, deliverables, or baselines at a strategic, tactical, and operational level. The purpose of this Change Management Plan is to establish a standard approach for the approval and tracking of proposed changes for the project.

Configuration Management Plan
Documents the standards and processes to manage the repository of CWS-NS baselined artifacts (documents, product deliverables, and historical information).

Contract Management Plan
The purpose of the Contract Management Plan is to provide the processes and procedures to ensure the project meets all contractual obligations and maintains the contract during its lifetime.

Communication Management Plan
This Communication Management Plan describes the specific framework for sharing information in a timely manner with all stakeholders and developed to ensure that internal and external stakeholders are informed of the project’s goals, objectives, status, schedule, and outputs.

Cost Management Plan
The Cost Management Plan documents the processes and guidelines for ensuring the project is completed within budget and adheres to all applicable State and federal regulations pertaining to cost management.

Deliverables Management Plan
The purpose of the Deliverables Management Plan is to facilitate the timely review and approval of contractor deliverables; to ensure deliverables are tracked and all events are recorded; and to ensure a copy of each deliverable and all supporting materials are archived in the Project Library. Deliverable management is necessary to ensure the Project only accepts deliverables that meet contract requirements.

Document Management Plan
The purpose of the Documents Management Plan is to capture how document management is defined for the project, as well as how internal Project documentation is developed and reviewed. Document Management is the process of organizing, storing, protecting, and sharing documents. This plan describes how to manage the hard copy and electronic repositories of documents, historical information, and provides a consistent approach to the creation, update, and format of documents.

External Systems Management Plan
The External Systems Management Plan provides a framework to identify the business processes that are missing from CWS/CMS, having been implemented in external systems. The relevant data resident in the external systems will be identified, analyzed, and eventually migrated, archived or decommissioned. By identifying the missing business processes, the operational capabilities of the project can be validated to ensure it will support the decommissioning of these external systems and can integrate any existing data in the new repository.

Governance Plan
The Governance Plan describes the Governance Plan for the Project. The purpose of the Governance Plan is to describe the specific roles and responsibilities of the project participants involved in executing 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 (IAA), the Governance Plan contains the details.

Human Resource / Staff Management Plan
The purpose of the HR Staff Management Plan is to capture ‘how’ the Project will manage staff resources throughout the life of the Project. This plan defines the staff management activities necessary to ensure that the Project has sufficient staff possessing the correct skill sets and experience to perform Project activities and tasks.

Interface Management Plan
There are information exchange interfaces that do not exist in CWS/CMS that can aid users and significantly enhance investigation, case management, and service delivery efficiency. The Project plans to evaluate these interfaces as part of the new solution to take advantage of these efficiencies. Interface Management Plan

Procurement Management Plan
The purpose of the Procurement Management Plan is to identify the tasks and activities to be performed to procure goods and services for the Project. This Plan documents the scope, content, methodology, sequence, and responsibilities for systematically and efficiently procuring goods and services to maximize best value to the state at the lowest risk while complying with state contracting laws and regulations.

Quality Management Plan
The primary purpose of the Quality Management Plan is to define how quality will be managed throughout the project lifecycle in the following areas; Quality Planning, Quality Assurance, Quality Control, and Quality Improvement.

Requirements Management Plan
The Requirements Management Plan identifies the process used to plan, develop, monitor, and control requirements in all stages of a project’s lifecycle. This document is the foundation for all project requirement management policies for the Project.

Risk and Issue Management Plan
Documents the R&I Management Plan used to identify and mitigate CWS-NS Project risks that may affect the project or stakeholders and issues that are influencing the project or stakeholders.

Schedule Management Plan
The Schedule Management Plan covers the approach to how data in the two platforms comes together to provide overall high-level project status. The Plan addresses the steps to develop, manage, track, analyze, and control the project master schedule, and how effort recorded in Pivotal Tracker is represented in the Master Schedule.

Stakeholder Management Plan
The Stakeholder Management Plan documents the formal stakeholder management processes of the project. This plan describes the specific framework for identifying the people, groups, and organizations that could impact or be impacted by the project, analyzing their expectations and impact on the project, and developing strategies for effectively engaging stakeholders in project decisions and execution.

1.6 Document Maintenance

With the practice of the PM Plan; revisions, improvements, and updates will occur through each phase of the project lifecycle and the Lessons Learned efforts. A minor version change does not change the intent of the document and consists of spelling, grammatical and minor corrections. A major version is when a document’s content is changed and represents a change in intent, change in process, or procedures. Please refer to the CWDS Configuration Management for further detail on version control.

During development of this PM Plan, the guidelines and standards provided through the Project Quality Management Plan will apply; specifically all peer review requirements must be met.

It takes a cooperative team of employees, consultants, and comtractors to complete a project. While the Governance Plan describes the specific roles and responsibilities of the project participants and some high-level roles and responsibilities are discussed in the Project Charter, the below chart outlines some Agile project teams roles:

In addition, the project team formed into functional areas to allow for focused effort. The below chart outlines some of the areas:

3.1 Approach

The Project Director has the overall authority and responsibility for managing and executing this project according to this Project Plan and its Subsidiary Management Plans. The project team will consist of personnel from the service groups, quality control/assurance analyst, schedule specialist, agile coach, and development vendors. The project director will work with all resources to perform project planning. All project and subsidiary management plans will be reviewed and approved by the project sponsors, IPOC, and IV&V. All funding decisions will also be made by the project Director and managed according to the Change Management Plan. Any delegation of approval authority to or by the project director should be done in writing and signed by both the project sponsor and project manager.

The project team will be a matrix in that team members continue to report to their organizational management throughout the duration of the project. The appropriate Service Manager is responsible for communicating with organizational managers on the progress and performance of each project resource.

3.1.1 The 12 Agile Principles
These are a set of guiding concepts that support the project team with implementing this agile project.

• 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• 4. Business people and developers must work together daily throughout the project.
• 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• 7. Working software is the primary measure of progress.
• 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• 9. Continuous attention to technical excellence and good design enhances agility.
• 10. Simplicity — the art of maximizing the amount of work not done — is essential.
• 11. The best architectures, requirements, and designs emerge from self-organizing teams.
• 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

3.2 Scope

The scope of the project includes the planning, design, development, testing, and transition of the CWS/CMS application from the legacy architecture into a digital services platform. The below is based on point-in-time prioritization and is subject to change based on lessons learned from Intake and API procurements. The CWDS NS project plans to cover the following:

• API Module
• Intake Module
• Care Licensing Approval Services (CALS) Module
• Platform Module
• Case Management Module
• Resource Management Module
• Court Processing Module
• Eligibility Module
• Finance Management

With these modules, the project will also need to manage a separate vendor to conduct the implementation aspects of the modules. Each module will use Alpha and Beta Phases in lieu of UAT/Pilot, follow a phased rollout (i.e. incremental) or big bang on at least a quarterly basis, and counties can elect to participate in a particular wave depending on the level of released functionality and availability of implementation resources. These modules will meet or exceed organizational software standards and additional requirements established in the project charter.

The scope of this project also includes completion of all documentation, manuals, and training aids used in conjunction with each of the modules. Project completion will occur with successful execution of the software in production and documentation successfully transitioned to the state.

All project work performed as pertinent to each SOW and all artifacts will be stored within GitHub for access to all.

3.3 Methodology

The project has adopted a specific type of Agile Scrum Methodology. With this approach, the project will go through many repetitions of the following seven steps through completion of the project.

Step 1: The initial planning for your project
Project planning includes creating a product vision statement and a product or service roadmap. The product vision is a definition of what your product or service is, how it will support the project strategy, and who will use the product or service; which can take place in as little time as one day.

Step 2: The service manager creates a product roadmap.
The product roadmap is a high-level view of the product or service requirements, with a loose period for when you will produce those requirements. Identifying requirements, then prioritizing, and roughly estimating the effort for those requirements are a large part of creating your product roadmap.

Step 3: The service manager creates a release plan.
Planning the next set of features to release and identifying an imminent launch date around which the team can mobilize. The release plan identifies a high-level timetable for the release of an artifact into production. An agile project will have many releases, with the highest-priority features usually launching first. The project has pre-set 90-day release, which include 6 sprints based on the fact sprints being 2 week iterations.

Step 4: The Service Manager, the scrum master, and the development team plan sprints.
A meeting at the start of each sprint, where the scrum team determines what requirements will be in the upcoming iteration, a sprint goal. They also identify the requirements that support this goal and will be part of the sprint, and the individual tasks it will take to complete each requirement. This is a short cycle, in which the team creates potentially shippable or minimum viable product functionality. The project sprints, sometimes-called iterations, typically last for two weeks. Sprints can last as little as one day, but should not be longer than four weeks. Sprints should remain the same length throughout the entire projects.

Step 5: during each sprint, the development team has daily meetings.
A 15-minute meeting held each day in a sprint, where team members state what they completed the day before, what they will complete on the current day, and whether they have any impediments.

Step 6: the team holds a sprint review.
A meeting at the end of each sprint, attended by the service manager, where the team demonstrates the working functionality it completed during the sprint to the product stakeholders.

Step 7: the team holds a sprint retrospective.
A meeting at the end of each sprint where the team discusses what went well, what could change, and how to make any changes for improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every sprint.

3.4 Iterative vs. Waterfall

CWDS made the change from a monolithic waterfall approach to an iterative agile approach to revise the CWS/CWS application. One of the differences between agile and waterfall is the approach to quality and testing. In the waterfall model, there is always a separate testing phase after a build phase. However, with agile, development testing works concurrently with, or at least in the same iteration as, programming.

Because testing is done in every iteration, which develops a small piece of the software, users can frequently use those new pieces of software and validate the value.

After the users know the real value of the updated piece of software, they can make better decisions about the software's future. Having a value retrospective and software re-planning session in each iteration, scrum sprints are typically just two weeks in duration, which helps the team continuously adapt its plans to maximize the value it delivers.

This iterative practice also introduces a product mindset rather than the waterfall model's project mindset. The product approach implies greater flexibility at any stage of the development process, while project requirements tend to be perfectly defined from the very beginning and difficult to change later in the process. Iterative product development is ongoing as the software evolves due to any changes in business environment or market requirements.

3.5 Objective and Goals

The project plans to keep the existing CWS/CMS IBM application running in production, while incrementally introducing new digital services (DS). CWDS will release each new DS as a beta service for a few pre-approved CA Counties to utilize, while the remaining counties continue to utilize the existing legacy CWS/CMS IBM system. The beta county results will dictate when the DS will change to general availability (GA). Upon GA approval, the remaining counties will migrate to use the DS and the existing CWS/CMS IBM application will disable the specific legacy function. As the project continues to introduce new DS, the legacy CWS/CMS IBM application will continue to disable functionality appropriate with the DS, until all the functionality is contained with DS.

3.5.1 Project Schedule
The project schedule milestones; Planning, Solicitation, Design & Development, Implementation, and Closure can be found within the Schedule Management Plan, section 6.

3.5.2 Project Cost
The project Cost Management Plan identifies the processes and guidelines for ensuring the project is completed within budget and adheres to all applicable State and federal regulations pertaining to cost management

4.1 Conducting Formal Lessons Learned

The lessons learned documentation represents knowledge and experience gained during the project. It documents how to address project events, and how they should be addressed in the future, with the purpose of improving future performance. The Quality Management Plan.

4.2 Project Status Reports (Oversight)

The final Project Status Report communicates an appraisal of project closing activities to the Project Sponsor(s) and key Stakeholders identified in the Communication Management Plan. This also concludes the reporting of project status and tasks and makes note of issues or items handled upon project closure.

4.3 Project Closeout Report

The project closeout report documents the final and remaining activities of the project.

4.4 Post Implementation Evaluation Report (PIER)

The PIER must be submitted to the Department of Technology (CDT) within the Department’s required time frame. It contains six sections:

• 1. Background and Summary of Results
• 2. Attainment of Objectives
• 3. Lessons Learned
• 4. Corrective Actions
• 5. Project Management Schedule
• 6. Economic Summary