Scope Management Plan, Study notes of Business

Download Scope Management Plan and more Study notes Business in PDF only on Docsity!

Department of Health

Care Services

CA-MMIS

Scope Management Plan

Version 5.

Table of Contents

Preface .................................................................................... iv

Revision History ......................................................................................... iv

Preface

Revision History

Version Date Description Author

0.1 June 15, 2009 Request for Proposal (RFP) DRAFT Medi-Cal Business Partnership

0.2 April 28, 2010 Input material from RFP and Proposal Draft PMP into SPARK-ITS Template

Cameron Holm

1.0 June 11, 2010 Restructure plan template and content per discussion with DHCS

Nicole Tressler and Cameron Holm

1.1 February 15, 2011 6 month update Shirley Singh

1.2 March 4, 2011 Resubmission Shirley Singh

2.0 March 28, 2011 DHCS Approval Rick Alfaro

2.1 December 12, 2011 Migrated to SPARK-ITS Template and added comments from collaboration with DHCS

Christine Mock

2.2 January 24, 2012 Updated to add comments from collaboration meetings with DHCS

Christine Mock

2.3 January 30, 2012 Updated to add comments from internal walkthrough with DDI Leadership

Christine Mock

2.4 February 1, 2012 Updated with QMO comments Christine Mock

2.5 February 9, 2012 Updated with comments received during the internal walkthrough with DHCS

Christine Mock

3.0 March 22, 2012 DHCS Approval Paris Moore

4.0 September 12, 2012 6-month update of plan Christine Mock

4.1 October 31, 2012 QM review of 6 month update Sharisse Baltikauskas

4.2 December 10, 2102 Update based on comments from QM review and DHCS walkthrough of Plan

Christine Mock

4.3 December 20, 2012 QM Review of updates Sharisse Baltikauskas

Scope Management Plan iv

Version Date Description Author

5.0 December 31, 2012 DHCS Approval Tanya Sachdeva

5.01 July 1, 2015 Update to align with Agile Software Development Approach adopted for System Replacement (Tracked Changes Version)

Pat Rattan Marty Katreeb

5.02 July 1, 2015 Update to align with Agile Software Development Approach adopted for System Replacement (Initial Updates Accepted)

Pat Rattan Marty Katreeb

5.03 July 30, 2015 Updates based on Peer Review Pat Rattan Marty Katreeb

5.04 July 31, 2015 QM Pre-walkthrough review Sharisse Baltikauskas

5.05 August 7, 2015 Updates based on QM review Marty Katreeb

5.06 August 19, 2015 QM Final Review for Submission Sharisse Baltikauskas

Configuration of This Document

This document is under configuration management and is subject to the conditions and processes described in the Documentation Configuration SOP. See the Configuration Items (CI) List in the CA-MMIS SharePoint site for details.

Scope Management Plan v

• Change Control Management: This process is used control scope and changes to scope.
• Communication Management: This process is used to communicate issues and weekly progress on the scope of specific deliverables, work activities, and elements identified in the WBS
• Deliverable Management: This process defines the naming conventions for deliverable IDs which are also used in the naming conventions for deliverable- related WBS elements. This plan also defines the delivery process used to submit deliverables to DHCS and receive formal acceptance and approval from DHCS which is a means for verifying scope.
• Document Management: This process assists the user in the management of templates stored on SharePoint as well as provides guidance on version control, naming convention, formatting, and the structure of CA-MMIS documentation.
• Governance Management: The governing entities defined in this process meet to discuss project progress and activities
• Quality Management: The verification process includes confirming that each deliverable is reviewed prior to submission to DHCS
• Requirements Management: Requirements are used as a source of input in defining project and product scope
• Time (Schedule) Management: The WBS is used as a structure in which to build, revise and refine, the schedules for each set of work

1.1 Approach

The approach used for scope management is based on the PMBOK Guide® –Fifth Edition, as an aspect of project integration management. This plan provides guidance on how project scope will be defined, monitored, controlled, verified and how the WBS will be created and defined.

Each team member has the responsibility of identifying and understanding the scope of the CA-MMIS contract as stated in the Request for Proposal (RFP) and confirmed and elaborated upon in the Contract. This is accomplished through various avenues including, but not limited to, Project Planning and Release Planning Sessions for SR. Communication of changes to Scope are executed via the Change Process. Project commitments are managed according to the scope management processes defined in Section 2 of this document.

The CA-MMIS FI Contract WBS (Appendix B) demonstrates the high-level branches of the CA-MMIS Contract. The WBS for each high-level branch is developed independently at various phases of the contract using the numbering represented in the CA-MMIS FI Contract WBS (Appendix B). For example, the WBS coding schema created for EPMO begins at 2.0; System Replacement begins at 6.0; etc. Each component of work identified in the CA-MMIS FI Contract WBS is further decomposed in the WBS to define scope.

1.2 Objectives

The objectives of the Scope Management Plan are as follows:

1. Provide a process for defining project and product scope
2. Provide guidelines for developing the WBS using enterprise standard format
3. Provide an understanding of how the WBS feeds other scope-related artifacts (e.g., project schedules, SR project Roadmap, SR Scope Definition Documents (SDDs), and the SR VersionOne tool)
4. Provide processes to monitor unauthorized changes to scope, also known as ‘scope creep^1 ’
5. Provide a process to control modifications to the scope of work
6. Provide a process for verifying scope completion

(^1) Scope creep is a term which refers to the incremental expansion of the scope of a project, which may include

and introduce more requirements that may not have been a part of the initial planning of the project.

a. Project Schedules

b. Project Roadmap (SR only)

c. Scope Definition Document (SR only)

d. Product Backlog (SR only)

2.1.1 Gather and Analyze Data

Relevant information necessary to define the scope of the project is identified and reviewed. Inputs to defining scope include, but are not limited to, the following:

• Project Commitments – includes the requirements from the Conformed Request for Proposal (CRFP), Narrative Technical Proposal (NTP), approved Change Requests (CRs), and Implementations Advanced Planning Documents (IAPD).
• Project Documentation – methodologies such as Agile Software Development Approach (ASDA), PMM, Advance Planning Documents (APD), Project Plans, the Master Product List (MPL), workgroup charters and Project Management Plans (PMPs)
• Project Environment – awareness of the technical, political, and administrative trends within the CA-MMIS environment to include Federal and State requirements, industry best practices, and statutes and regulations.

Project Managers identify and analyze the deliverables and related work elements specified in the requirements and other inputs. These are then organized and documented in a WBS that becomes part of the CA-MMIS Contract WBS (Appendix B).

2.1.2 Create and Update Work Breakdown Structure

The PMBOK® definition of creating the WBS is “the process of subdividing project deliverables and project work into smaller, more manageable components. The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables, with each descending level of the WBS representing an increasingly in-depth definition of the project work. The WBS organizes and defines the total scope of the project, and represents the work specified in the current approved project scope statement.”^3 The WBS is formally documented as the CA-MMIS FI Contract WBS with separate, more detailed WBS structures defined for each high level branch, such as System Replacement. The work components identified in the CA-MMIS FI Contract WBS encompass the entire CA-MMIS contract.

The WBS for each high level branch of the CA-MMIS FI Contract WBS is developed independently during various phases of the contract using the numbering defined in the CA-MMIS FI Contract WBS. For example, the WBS coding schema created for EPMO begins at 2.0; System Replacement begins at 6.0; etc. Each high level branch of the CA- MMIS FI Contract WBS would then be elaborated upon by the Project Manager with lower level WBS components to form a hierarchy of work to be performed. EPMO owns the CA-MMIS FI Contract WBS and makes changes as needed based on approved Change Requests.

(^3) PMBOK Guide – Ch 5 Project Scope Management

A WBS logically takes the form of a tree with the “trunk” at the top and the “branches” below. The primary requirement or objective is shown at the top (trunk), with increasingly specific details shown within the branches. Each descending level of the WBS represents an increasingly thorough description of the work elements, work products, and deliverables. Defining the lowest level items, or “leaves,” is referred to as decomposition.

In general, the lowest level items of the WBS define a work package which is a tangible component of scope. Examples of work packages include deliverables, operational artifacts, work products, and services. There is no need to further decompose a work package into the tasks and activities necessary to deliver the work package; this is a scheduling activity and is too much detail for a WBS.

For the System Replacement Project, the WBS is defined using the structure of the Medi- Cal Business Processes as defined in the State Self-Assessment. The Medi-Cal Business Processes are aligned with the federal Centers for Medicare and Medicaid Services (CMS) Medicaid Information Technology Architecture (MITA) Framework. CMS requires the use of the MITA Framework to guide the development of state Medicaid systems and to qualify for enhanced federal funding. By organizing the System Replacement WBS using the Medi-Cal Business Processes, the project adheres to the use of the MITA Framework, specifically the MITA Business Architecture. The use of the Medi-Cal Business Processes in structuring the WBS provides a business perspective of the work to be performed while supporting the requirements of CMS.

The System Replacement Project WBS is structured using the MITA Business Architecture and Coordinated Support. The focus is on the delivery of the Medi-Cal Business Processes as identified in the contract. This means that the Scope of the project is segmented into two major areas that make up the scope of SR; the Medi-Cal Business Process Implementation and Coordinated Support, which includes service for each area as well as deliverables, work products, attestations and support tasks. Each of the business processes are listed in the WBS and the System Replacement Roadmap (SR Roadmap). The SR Roadmap provides a high-level representation of the SR project scope broken down by Medi-Cal Business Processes impacted by the SR Project. This allows alignment of the project scope between the WBS and the SR Roadmap.

Once the Project Manager has decomposed each work element to the appropriate level, each branch and leaf is documented in the WBS by means of Microsoft (MS) Project using the following minimum requirements of the WBS elements, defined in Table 1, below:

Table 1: WBS Elements and Definitions

Fields within the WBS Definition^ Examples

Notes The Notes column is identified with the symbol. This column is used to provide a brief narrative description of the WBS Element. The Narrative Description is required for a WBS Element Type identified as a WBS Element. The Narrative Description is optional for Deliverables, Operational Artifacts, Services and Work Products.

CAMMIS WBS ID

The WBS is numbered sequentially to identify the hierarchical structure of the work components. The CAMMIS WBS ID column displays this numbering structure that is eventually used in the CAMMIS WBS ID column in the schedule to denote tasks that support the WBS element

1

1.1.

2.1.3 Create/Update Other Scope Artifacts

In addition to the WBS, the following documents and tools are used to track, report, or otherwise illustrate project scope. The structure of each should be modeled after the WBS for consistency. Some of these are produced only for the System Replacement (SR) project.

• Project Schedules
• System Replacement Roadmap
• System Replacement Scope Definition Document
• System Replacement Product Backlog

2.1.3.1 Project Schedules

Once a component section of the WBS is created and approved, one or more project schedules are created to track completion of the work tasks required to produce and deliver the elements outlined in the WBS. Each schedule follows the same structural outline as the WBS, but further decomposes each element into activities and milestones, indicating start and finish dates and, if applicable, resources required to complete the identified activities. See the Time (Schedule) Management Plan and related SOPs for further instructions on creation of project schedules.

2.1.3.2 System Replacement Roadmap

The SR Roadmap is prepared by the CA-MMIS Division in collaboration with DHCS Program Division leadership and the DHCS Director’s office to define the scope of the releases implemented as part of the SR Project. This effort considers the overall project objectives and the business value to be achieved through the implementation of a series of releases over the life of the project.

The SR Roadmap provides a high-level representation of the SR project scope broken down by Medi-Cal Business Processes impacted by the SR Project. These Medi-Cal Business Processes are also used to structure the WBS. This allows alignment of the project scope between the WBS and the SR Roadmap. In addition, the use of the MITA Business Architecture in structuring the WBS and SR Roadmap provides a business perspective of the work to be performed while supporting the requirements of the federal CMS and the use of the MITA Framework.

Collectively the Business Processes define the scope of the functionality to be provided by the SR Project solution when fully implemented. Each Business Process is further divided into “Business Components” which represent the functional pieces of that process that are delivered during a particular project release. The Business Components are allocated to releases based on business need, business value, stakeholder impacts, and technical considerations and dependencies. This allocation is performed during what is known as Release Planning. Release Planning is an ongoing activity that is done at the beginning of each release, when teams understand the high-level CA-MMIS System Replacement Roadmap and Scope Definition Document concepts and visions.

The initial allocation across releases is followed by more specific planning and business process impact analysis for each release prior to starting that release. This specific planning effort results in an SR SDD for the release and an updated CA-MMIS SR Roadmap reflecting any necessary modifications resulting from the planning effort.

The SR Roadmap provides the high level definition of project scope in terms of the Business Processes to be supported by the CA-MMIS HE solution. The SR Roadmap guides the project work to be performed and should remain synchronized with the SR WBS, SR SDD, and SR schedules, such that when scope is added, removed, or re- sequenced within the project, the SR Roadmap gets updated accordingly.

The SR Roadmap is a configured document, and therefore any updates must be approved by the CCM process. The CA-MMIS System Replacement Roadmap and the Scope Definition Document are the responsibility of the Management Teams and the DHCS Business Product Owners, with support from the Xerox Technical Product Owners.

2.1.3.3 System Replacement Scope Definition Document

The SR SDD is a document prepared to define the vision and expectations for a CA- MMIS release in terms of the Medi-Cal Business Processes that are to be supported by system functionality implemented in the release. The SDD is a detailed, iteratively- developed document that provides a description of the work to be completed during each release of the SR project, along with the related outputs (deliverables, work products, etc.). The SDD also includes the expectations for Coordinated Support work to be performed in support of the development and deployment of the release.

The SDD is an elaboration and refinement of the scope of work for a release identified as Business Process Components in the CA-MMIS SR Roadmap. A separate SDD is prepared for each release depicted on the SR Roadmap. Each SDD is directly aligned with the SR Roadmap to provide continuity and clarity to the vision and scope represented in the roadmap. Creation and use of the SDD is described in the Scope Definition Document SOP. The SDD should follow the same outline as the SR WBS, but provide much more detail about the functionality to be provided within each business process component delivered with each release.

The SDD is initially created during the Vision and Strategy phase of the Agile Software Development Methodology (ASDM) Software Development Life Cycle (SDLC) by a cross- functional team established for the purpose of developing the SDD. The SDD team includes business owner representatives, system architects, business analysts, and system analysts. The SDD is used during the Product Planning phase to guide and scope requirements. The SDD is updated to reflect the elaborations and refinements resulting from the analysis performed by the various project teams; such as Concept Teams and Coordinated Support Teams as they perform their solution analysis and create and groom the Product Backlog for the release.

As part of the SDD development, CA-MMIS requirements are reviewed to determine business functionality and other products produced and implemented for the release. This effort includes a review and mapping of HE Transfer System use cases to the Business Process Components identified in the SR Roadmap. A Business Process Component identifies the portion of the Medi-Cal Business Process that is supported by the functionality implemented in the major release.

The initial SDD for each release is baselined when the executive management and the Executive Leadership Council (ELC) have approved the initial SDD and the CR for the SDD has been approved to establish the documents as configured items as outlined in the Scope Definition Document SOP. Any changes to the SDD follow the process outlined in the Documentation Configuration SOP.

The SDD continues to be monitored and maintained throughout the life of the project to communicate and guide the scope of each release. As more details naturally become

representing the SR project scope, VersionOne is only meant to contain the core development and testing work.

2.2 Monitor Project Scope

Once the WBS is baselined, each element has a WBS ID. When Project Managers build their schedules, they map each schedule task to the WBS ID it is supporting. This is performed in MS Project using the CA-MMIS WBS ID column. The CA-MMIS WBS ID is an enterprise field that can only be added once the schedule is uploaded to the CA-MMIS Project Server.

Throughout the course of a project, Project Managers may find the need to add tasks to their schedules, either to add detail to, or elaborate, higher level tasks that have already been defined, or to add work that was previously not included in the schedule. Each new task must have a corresponding CA-MMIS WBS ID assigned in order to assure it is within the current defined scope of the project. The EPMO Scope Analyst reviews the baselined schedules weekly to monitor for potential unauthorized changes to scope by identifying tasks in the schedule where there is no associated baselined WBS ID. The Scope Analyst produces a Scope Variance Report that shows schedule tasks with missing or invalid CA-MMIS WBS IDs. The Scope Analyst works jointly with the schedule owners to resolve the missing CA-MMIS WBS ID. If it is determined there is no valid mapping of the baseline WBS to the schedule task, this may be a candidate for a CR.

The Scope Analyst also monitors the project schedules to ensure each element of scope defined in the WBS has at least one associated schedule task representing its completion. A report can be generated indicating which CA-MMIS WBS elements have no representative tasks in any of the project schedules.

For the System Replacement Project, the approved SR Roadmap and SDDs are used to provide the scope, objectives, and context for the development of the system solution for the release and for coordinated support work to be performed. As the development and support work is performed, possible changes to the SR Roadmap and SDD are identified. As changes are identified, a draft of the updated SDD should be prepared to reflect those changes. The creation and review of the draft SDD also includes participation by business owners or their representatives. Once the updated draft SDD is completed, reviewed, and agreed to by the business owners, a change request is prepared and submitted through the change control management process to secure approval for the updated SDD.

If updates are made to the SR Roadmap or SR SDD, they may or may not result from a change in scope. For example, if a decision is made to move a business process component from one release to another, this is merely a change in timing of execution, not in overall project scope. This change would be reflected in the SR Roadmap, the SR SDDs for the impacted releases, and the SR project schedule. But the SR WBS would likely not need to be updated. During the process of drafting a change request, the group will conduct analysis to determine impacts. This may include, but is not limited to impacts related to technical constraints, architecture, business impacts, and impacts to internal/external stakeholders as outlined in the CCM process. However, each time one of these documents goes through a change via the CCM process, the changes are reviewed by the Scope Analyst to assure affected project documents and artifacts are identified and updated accordingly.

Since work, in the form of Epics and Stories, is continually being added to VersionOne, there needs to be a method to validate that the stories and epics being added can trace back to the SR WBS (to prevent scope creep). This is accomplished by viewing change

reports in VersionOne and identifying the impacted Epics. Stories associated to an epic would be considered part of that WBS element. The EPMO Scope Analyst can use this report from VersionOne similar to the Scope Variance Report to detect VersionOne stories and epics with missing or invalid CA-MMIS WBS IDs assigned in the schedule. It is important that the stories and epics be examined by the EPMO Scope Analyst to assure new epics are part of an existing WBS element or are a new WBS element.

When these are discovered, the Scope Analyst works with the appropriate Scrum Master to correct the data in VersionOne or, if applicable, create a CR to approve the newly identified scope. Since changes to the SR Roadmap and SDD require CRs, most of the scope changes should be identified in a CR that is being or has been submitted. Creating a new CR should be rare due to the EPMO Scope Analyst review.

2.3 Control Project Scope

In general, Project Managers need the latitude to manage their teams effectively and may need to make subtle changes to the schedules in regard to start and end dates, duration, and staffing levels. Additionally, work packages that were not originally accounted for in the WBS may be identified. If during the course of making routine updates it is determined that a schedule update will result in impacts to the baselined WBS , a CR must be initiated. Whenever a CR to update the WBS is created, the responsible Project Manager and Scope Analyst work together to determine what other scope-related documents may also need updating. The Change Control Management Plan describes the steps used to initiate, review, and approve a CR. Scope Change is anything that is considered to change the agreed scope and objectives of the project to accommodate a need not originally defined to be part of the project. It is important to remember that scope changes require an approved CR.

Table 2 describes the two common types of changes that the SR project may accrue, the action required, and the affected artifacts based on the change.

Table 2: Change Types

Type of Change Action Required Affected ScopeArtifacts

Moving Business Components to different Releases

A CR is needed when moving business components from one release to another, as the movement changes the scope of a release. The CR should ask for and justify the change, including identified impacts associated with the change. The CR should indicate that the change in scope is reflected in documents or applications that are affected. Updated copies of each of the affected documents, if available, should be included with the CR.

SR Roadmap

Release SDD

SR Project Schedule

VersionOne Epics

The SDD is designed to facilitate tracing the scope of the release that was implemented back to the scope defined in the last approved SDD. The structure and content of the SDD is designed to provide a definition of the vision and expectations of the release when implemented. During the development of the release the SDD is updated to reflect the agreed upon changes to the original vision and expectations. As such, the last approved SDD provides the baseline against which the actual release content can be compared and evaluated.

The validation of the implemented release involves comparing each Business Process Component and its subcomponents and epics within the scope of the release to the actual functionality implemented in the release for those corresponding components. This validation does not test the accuracy or completeness of the functionality implemented, but it does account for whether or not the scope represented by the components and subcomponents was implemented and is available for use.

For coordinated support work, the products (deliverables and work products) identified in the SDD to be produced are compared to the actual products produced in the release. The validation does not assess the accuracy or completeness of the products, but it does account for whether or not the products were produced as part of the release effort.

Information to validate the implemented release and the coordinated support products includes Operational Readiness Review checklists, release notes, approved DTA forms, the MPL, approved change requests, key decisions, the Release SDD and the RTM. Please refer to the Release Validation SOP for detailed information pertaining to release validation.

2.4.1 Definition of Done

In Agile, the “definition of done” is a key concept used to determine when a piece of work (Story, Epic, and Release) is finished and its resulting functionality or Scope of the project is accepted. The definition of done is applied to all levels of work from Releases to Epics to Stories.

The following sections describe the general criteria for determining when the work performed for a Story, a Business Process or Coordinated Support Epic, or a Release is completed and accepted as done. Please refer to the Scope Definition Document SOP and the Agile Software Development Approach (ASDA ) for detailed acceptance criteria of “definition of done” for each of these types of work.

2.4.1.1 Definition of Done for a Story

At the most granular level, a business feature or functionality to be delivered is defined as a Story. The Story describes the business need to be met and the tasks to be performed to complete the work. A Story is considered done when the Story tasks have been completed and the Story results are accepted by the appropriate Business Product Owner, with support from the Technical Product Owner. The Agile User Stories – Creation and Use SOP explains how to write stories, acceptance criteria, and who is responsible for the story acceptance criteria. The Scope Definition Document SOP and the Agile Software Development Approach (ASDA ) outline the detailed criteria and “definition of done” for a story.

2.4.1.2 Definition of Done for Business Process or Coordinated

Support Epic

After the Stories within an Epic are completed and accepted as done, the Epic is reviewed for acceptance. Each Business Process and Coordinated Support Epic is

considered “done” when the Epic is completed and accepted by the appropriate Business Product Owner, with support from the Technical Product Owner as outlined in the Scope Definition Document SOP and the Agile Software Development Approach (ASDA ).

2.4.1.3 Definition of Done for the Release

A Release is considered “done” when the Business Process Epics and the Coordinated Support Epics identified are completed and accepted by the DHCS Release Lead and the Xerox Release Manager as outlined in the approved SDD for a particular release. The acceptance criteria for the Release to be considered done are outlined in the Scope Definition Document SOP and the Agile Software Development Approach (ASDA ).

Figure 1 below depicts the hierarchy of functional stories and epics into the Epic Tree levels defined for the CA-MMIS SRP and the definition of done for each of those levels.

Business Process Component Level

Business Process Level

Business Process Sub-Component Level

Story Level Story

Business Process Component

Business Process

Business Process Sub-Component

Define and organize the work for a Functional Area into Business Processes

Execute Stories to produce required functionality and products

Decompose work of Business Processes into Components, Sub-Components, and Stories to be completed

Story Definition of Done:

1. All tasks for a Story are completed
2. Story Functionality and Products are validated
3. Story is reviewed and accepted by the DHCS Business Product Owner with support of the Xerox Technical Product Owner

Sub-Component Definition of Done:

1. All Stories within the Sub-Component are done
2. Sub-Component Functionality and Products are validated
3. Sub-Component is reviewed and accepted by the DHCS Business Product Owner with support of the Xerox Technical Product Owner

Component Definition of Done:

1. All Sub-Components within the Component are done
2. Component Functionality and Products are validated, including UAT
3. Component is reviewed and accepted by the DHCS Business Product Owner with support of the Xerox Technical Product Owner

Business Process Definition of Done:

1. All Components within the Business Process are done
2. Business Process Functionality and Products are validated, including UAT
3. Business Process is reviewed and accepted by the DHCS Business Product Owner with support of the Xerox Technical Product Owner

Validate and accept Stories and their functionality and products as they are integrated into parent epics

Figure 1: Epic Tree Levels and Hierarchical Function