New Yrk Health Benefit Exchange Detailed Design Review Summary fr 9.4.4 Scpe and Change Cntrl Management Plan Octber 9 and 10 Item Number Tpic 9.4.4 Scpe and Change Cntrl Management Plan
New Yrk State Department f Health New Yrk Health Exchange CSC 9.4.4 Scpe Management and Change Cntrl Management Plan Dcument #: 528500-20120831 Cntract Deliverable Number: P-07 and P-05 Cntract Number: FAU # 1106211137 Release Versin 1.1 Date Submitted:
Versin Histry Versin Number Implemented By 1.0 D. Bland, S. Rubenstein Revisin Date Apprved By 08/29/2012 S. Garner, C. Adams Apprval Date Descriptin f Change 08/29/2012 Initial Versin 1.1 S. Rubenstein 09/12/2012 Incrprated QA Feedback Dcument Distributin Any delivered versins f the Scpe and Change Cntrl Management dcument will be stred in the deliverable tracker sectin f the NY-HX SharePint repsitry, and will be available t all via this medium. New Yrk Health Exchange 9.4.4 Scpe Management and Change Cntrl Management Plan Page i
TABLE OF CONTENTS 1 INTRODUCTION... 1 1.1 Purpse... 1 1.2 Scpe... 1 1.3 Intended Audience... 1 1.4 Dcument Maintenance... 2 2 REFERENCED DOCUMENTS... 2 3 ASSUMPTIONS/CONSTRAINTS/RISKS... 2 4 SCOPE AND CHANGE CONTROL MANAGEMENT APPROACH... 3 4.1 Overall Strategy fr Scpe and Change Cntrl Management... 4 4.1.1 Tls, Techniques and Prcesses... 5 4.1.1.1 Scpe Tracking and Change Cntrl Management Tl... 5 4.1.1.2 SharePint Scpe Tracker... 6 4.1.1.3 Ratinal Requirement Cmpser (RRC)... 6 4.1.1.4 Ratinal Team Cncert (RTC)... 6 4.1.2 Scpe and Change Cntrl Management Methdlgy Standards... 7 4.1.3 Technical Perfrmance Metrics... 7 4.1.4 Detailed Integrated Master Schedule... 7 4.2 Rles and Respnsibilities... 8 4.2.1 CSC Scpe Change Review Bard... 8 4.2.2 DOH Scpe Cntrl Bard... 8 4.2.3 CSC Prject Directr... 8 4.2.4 CSC Business Architect... 8 4.2.5 CSC Scpe and Change Manager... 8 4.2.6 Scpe Change Owner... 9 4.2.7 Prduct Owner... 9 4.2.8 Scrum Masters and Requirements Team... 9 4.2.9 Quality Assurance Manager... 9 4.2.10 Cnfiguratin Manager... 9 4.2.11 Enterprise Architect... 9 4.2.12 Prject Stakehlders... 9 4.3 Prject Scheduler... 9 4.4 Respnsible Accuntable Cnsulted Infrmed (RACI) Chart... 10 New Yrk Health Exchange 9.4.4 Scpe Management and Change Cntrl Management Plan Page ii
4.5 Define and Dcument Scpe Baseline... 10 4.6 Prcess fr Scpe Management and Cntrl... 11 4.6.1 Requirement Elicitatin and Priritizatin... 11 4.6.2 Identify and Submit CSR... 12 4.6.3 Analyze CSR... 13 4.6.3.1 Initial Screening... 13 4.6.3.2 Preliminary Analysis... 13 4.7 Review by SCRB... 13 4.7.1.1 SCRB Initial Analysis... 14 4.7.1.2 SCRB Final Analysis... 14 4.8 Prvide Recmmendatin n CSRs t the DOH SCB... 14 4.8.1.1 SCB Initial Analysis... 14 4.8.1.2 SCB Final Analysis... 14 4.9 SCB CSR Dispsitin... 14 4.10 Change Ntificatin and Release... 15 4.11 Mnitr, Track and Reprt... 15 Appendix A GLOSSARY/ACRONYMS... 16 Appendix B Scpe Analysis f DOH Prpsed NY-HX Prject... 17 Appendix C Change Cntrl Checklist... 19 Appendix D Sample CSR Timeline... 21 Table f Figures Figure 4-1 Scpe Management Cnsideratin... 4 Figure 4-2 CSC Scpe and Change Cntrl Prcess... 5 Figure 4-3 Planned Technical Perfrmance Metrics... 7 Figure 4-4 Scpe Management RACI...10 Figure 4-5 Standard Agile Prduct Inventry Repriritizatin...12 Figure 4-6 Snapsht f CSR Entered int Scpe Tracker...13 New Yrk Health Exchange 9.4.4 Scpe Management and Change Cntrl Management Plan Page iii
1 INTRODUCTION 1.1 Purpse The Scpe Management Plan (SMP) and Change Cntrl Management Plan (CCMP) prvides a systematic apprach t identify, rganize, dcument, review and maintain changes t the scpe and requirements f the New Yrk Health Benefit Exchange (NY-HX) Prject, while perating under the principals and guidelines f a firm, fixed price cntract and an Agile-Scrum methdlgy. Agile is an iterative and incremental apprach t sftware develpment, and by nature invites change as a part f its iterative prcess. Typically, and in the specific case f NY-HX, prject duratin and resurces are fixed with scpe a variable. Driven by a Prduct wner and built n cnstructs that place value as the primary bjective Agile has prven pwerful in delivering cmplex systems in a shrt perid f time. The gal f the SMP and CCMP is t allw fr the cre values f the agile methdlgy, while simultaneusly prviding a framewrk fr identifying thse changes that have the ptential t impact the verall prject success, and t prvide a means t assess the value and effectiveness f thse changes thrugh a review and apprval prcess. The nature f a firm, fixed price cntract is t keep the prject within the riginally defined cnstraints f scpe, time, and budget. Althugh effrts will be made t slidify requirements early in the prject lifecycle, bth CSC and New Yrk State Department f Health (NYS DOH) acknwledge that as new infrmatin is discvered, mdificatins t the scpe f the riginal cntractual requirements may be necessary. Simultaneusly it is understd that althugh change is welcme and expected in an Agile methdlgy, CSC and NYS DOH require a prcess whereby scpe changes are cllabratively mnitred and managed t ensure cntractual bligatins and expectatins are met. 1.2 Scpe This plan fcuses n identificatin and handling f all Change System Requests (CSRs) fr the NY-HX prgram. This includes functinal and technical requirements changes. The SMP and CCMP dcument will address prject scpe mdificatins, including additins, trade-ffs and remvals by: Identifying the means t accurately dcument the baseline scpe f wrk Prviding a descriptin f prcesses t manage and cntrl scpe changes during the prject Identifying a prcesses t evaluate and priritize prpsed changes t the prject scpe Identifying a means t cmmunicating requirement changes and any ptential impact Identifying a prcess fr analyzing the change implementatin and determining ptential risks Identifying a prcess fr schedule the CSR, after cmparisn with ther planned activity r events Prviding a mechanism fr DOH review and apprval t implement CSRs Identifying a prcess fr cmmunicating changes dcumenting their successful implementatin Identifying a prcess t mnitr and reprt CSRs Prviding a descriptin f pst-change recrds Ensuring that test and back-ut prcedures are cnsidered, and the handling f cde changes and the assciated management f the Cnfiguratin Items, is nt included as part f this plan. These prcedures are gverned in the Cnfiguratin Management Plan. 1.3 Intended Audience The identificatin f ptential scpe changes and the handling f identified changes is a shared New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 1 f 21
respnsibility acrss the prject team; therefre the intended audience fr this plan is all prject team members, including thse frm CSC, DOH and Cgnsante leadership and management teams. Additinally, these prcesses and prcedures apply t all external rganizatins, grups and cmpanies that may impact the NY-HX prject. 1.4 Dcument Maintenance The NY-HX Prject Management Office (PMO) is respnsible fr the maintenance f this dcument, and ensuring the dcument is reviewed and updated as necessary t reflect changes in the scpe management plicy. The prcesses and prcedures utlined in this plan will be in effect thrughut the prject lifecycle. CSC will ensure the dcument is reviewed every six mnths and any updates r prpsed changes will be discussed with DOH. 2 REFERENCED DOCUMENTS The Prject Management Plan (PMP), and assciated gvernance plans, prvides the verarching discipline and management guide that CSC will use t carefully balance quality, scpe, time, and cst alng with ther best practices and Prject Management Bk f Knwledge (PMBOK) supprted prcesses. By using this cmprehensive management apprach, the NY-HX prject aims t reduce ptential risks invlved with the successful implementatin and peratin f the NY-HX cntract. Our PMP emplys industry best practices, as well as lessns learned frm ur team s cllective experience. Our PMP applies cmprehensive perfrmance measurement and quality assurance cmpnents thrughut the prject life cycle, implements perfrmance (cst, schedule, quality) mnitring and cntrls, incrprates a practive Cmmunicatins Management Plan supprted by a quantitative risk management apprach, and leverages disciplined and practive scpe and change measures thrughut the life f the cntract. 3 ASSUMPTIONS/CONSTRAINTS/RISKS New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 2 f 21 Executing an FFP cntract using an Agile SDLC can increase scpe risk. One f the primary reasns is that in FFP, CSC is bund by scpe and schedule. CSC is educating the team n Agile and incrprating experienced Agile resurces within the cntract. CSC has a dcumented SDLC, dcumented and cnfirmed Acceptance Criteria with DOH, trained the team and DOH in Agile SDLC, deplyed Agile caches in Sprints, is seeking additinal Agile SDLC resurces, and is mnitring prgress tightly with metrics. All stakehlders are integral t the success f the SMP and CCMP and are respnsible fr understanding and assisting with managing prject scpe, identifying variatins in scpe and escalating items fr review by CSC s Scpe Change Review Bard (SCRB). Stakehlder invlvement may als be necessary t cmplete analysis and impact assessments n CSRs befre they are brught t the DOH Scpe Cntrl Bard (SCB) fr dispsitin. Lack f stakehlder awareness and f the baseline scpe and failure t adhere t the SMP and CCMP plans, may present unintended cnsequences t the prject implementatin and schedule. Sme requirements fr the NY-HX Slutin were nt finalized by CMS and NYS DOH at the time f CSC s NY-HX prpsal submissin. Furthermre, Federal rules and regulatins gverning the Design Develpment and Operatin f Exchanges had nt been finalized as f the award date f the NY-HX cntract t CSC. CSC recgnizes that scpe, schedule, and/r budget fr the prject may be impacted as requirements becme better defined, and that depending n the utcme f finalized requirements, this may present additinal risk t the prject. The respnsibility t identify these variatins is shared acrss the stakehlder cmmunity. CSC submitted a firm fixed price prpsal fr the develpment f an peratinal-ready slutin, including the key staff and assciated hardware and sftware defined in the FAS, with the understanding that as additinal requirements becme knwn and additinal funding becmes
available, the Department will amend the cntract fr the additinal wrk. Per FAS Sectin III, Scpe f Wrk, changed requirements may impact the schedule r require additinal funding. The prject schedule has been baselined; therefre verall scpe must stay the same, r even shrink, in rder t maintain the schedule. CSC further understands the Department s intent t leverage the supplemental labr funding fr Change System Requests (CSRs). Any changes that are created will have the requirements prcessed in accrdance with the SMP and the CCMP. 4 SCOPE AND CHANGE CONTROL MANAGEMENT APPROACH The lack f prper scpe management and timely handling f CSRs may intrduce risks t the prject s executin and delivery schedule. CSC s scpe and change cntrl management apprach takes int cnsideratin that in an Agile envirnment, the delineatin between prgressive elabratin and scpe increase, needs t be firmly understd by the Sprint Teams, including the Scrum Masters and Prduct Owners. Once the baseline requirements are apprved, any variatins t prject scpe need t be quickly escalated and addressed via the change cntrl prcess. Table 4-1 utlines the cnsideratins and CSC's assciated SMP appraches pertaining t scpe management. Cnsideratin Requirements are nt always bvius and have many surces. Requirements are nt always easy t express clearly in wrds. There are many different types f requirements at different levels f detail. The number f requirements can becme unmanageable if nt cntrlled. Requirements fr a given prcess, may be related t ne anther, as well as t ther deliverables in a variety f ways. Requirements have unique prperties r prperty values. Fr example, they are neither equally imprtant, nr equally implementable. There are many interested and respnsible parties, which means requirements need t be managed by crss functinal grups f peple. Requirements change. Requirements can be time-sensitive. Scpe Management Plan Apprach Well-rchestrated Enterprise Level and Prcess Area blueprint sessins are designed t flush ut details thrugh an iterative prcess f discvery and capture. Prcess flw mdels help t clarify requirements by representing cmplex cncepts visually. Careful classificatin by type and prper assignment f attributes will assist in defining the varius levels f requirements. Prper use f requirements management tls, and maintaining a disciplined Change Management prcess, will ensure that requirements changes are cntrlled by the NY- HX Prgram management. Must have a cmplete traceability strategy that is cmprehensive fr all cmpnents, and sphisticated enugh t facilitate frward and backward referential integrity (vertical) between requirements, system cmpnents, as well as facilitate same level referential integrity (hrizntal) between bjects. A meaningful, cmprehensive classificatin and attributing scheme can prvide team members with the ability t assign value t a requirement. This will be accmplished by assigning a release number and a pririty t the requirement nce the release strategy has been finalized. The Scpe Management Plan must be inclusive f crssfunctinal stakehlders and must specify checkpints and prcedures fr ensuring prper review. Must have an effective Scpe Management Plan and Change Management Plan that establishes a defined prcess fr assessing and apprving requirement change requests. Prper classificatin and characterizatin shuld recgnize release-sensitivity as an attribute. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 3 f 21
Figure 4-1 Scpe Management Cnsideratin 4.1 Overall Strategy fr Scpe and Change Cntrl Management The SMP and CCMP fr the NY-HX prject, while allwing fr prgressive elabratin f baseline requirements t ccur during the Agile Scrum methdlgy, are designed t prevent scpe creep withut acknwledgement, assessment, and authrizatin. CSC has implemented a cmprehensive scpe and change cntrl management apprach that includes a standardized prcess fr early identificatin, assessment, and tracking f CSRs. The CSC Business Architect and Scpe and Change Manager will prvide versight, guidance and gvernance n the fllwing steps f the SMP and CCMP: Establish Prgram Scpe Management Strategy Define and Dcument Scpe Baseline Identify and Submit CSRs Analyze CSRs Review by Scpe Change Bard ( SCB ) Prvide Recmmendatin n CSRs t Scpe Change Review Bard ( SCRB ) SCRB CSR Dispsitin Change Ntificatin and Release Figure 4-2 illustrates the change management prcess that is the cntrl mechanism fr all variatins t prject scpe; whether additinal requirements, remval f requirements, r a requirements swap ut identified via requirements priritizatin by the Prduct Owner within the Sprint Team. The bjective fr fllwing this strict prcess t manage scpe and change is t prduce a system that cntains nly apprved requirements. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 4 f 21
Stp N CSR PMO CSC SCRB Yes PMO Initial Screeing CSR Valid? N Redirect r Maintenance Activity Frward t SCB? N PMO Originatr fr Clarificatin Yes Yes N N Preliminary Analysis Cmplete? Yes Analysis CSR Cst, Schedule and Staffing Impacts Valid? Yes Analysis Cmplete? N Scpe Change Bard SCB Apprve Change? Yes PMO Cntract Amendment fr Additinal Services? N Yes PMO PMO Yes Resubmit? N Stp Cntract Amendment Cmplete? N N Yes In Scpe? N Executive Review Hurs, Funds, Schedule Available? N Hld Pending Hurs, Funds, Schedule Availability Yes Yes Yes N Implement CSR Yes Hurs, Funds, Schedule Available? 4.1.1 Tls, Techniques and Prcesses New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 5 f 21 Figure 4-2 CSC Scpe and Change Cntrl Prcess CSC is leveraging industry and cmpany best practices fr scpe and change cntrl management, including prven tls, techniques, and prcesses being utilized frm its New Yrk emedny prgram. Examples include infrastructure, prject management tls, as well as lng-term wrking knwledge frm many f ur experienced staff. The tls used fr NY-HX scpe and change management include, but are nt limited t: CSR Tracker in SharePint IBM Ratinal Suite MS Prject Server 2010 emedny and CSC prcesses and prcedures 4.1.1.1 Scpe Tracking and Change Cntrl Management Tl The cre requirements fr the NY-HX prject, as utlined in the cntract between CSC and DOH, are captured and tracked using the Ratinal tls suite (described in the Cnfiguratin Management Plan).
Each high level requirement will be dcumented in the Ratinal Requirement Cmpser (RRC), and further defined by creating a set f "user stries," which are tracked in Ratinal Team Cncert (RTC). Defining requirements via user stries, is an Agile apprach t eliciting necessary system functins and features frm a user perspective. The majrity f user stries will be created by the individual Sprint Teams, via scpe guidance frm the Business Architect and in cnjunctin with their Prduct Owners and SME's (subject matter experts represented by NY DOH) during the initial Sprint 0 planning phase f the individual tracks. The Change Cntrl Management System (CCMS) is cmprised f the SharePint Scpe Tracker, Ratinal Requirements Cmpser and Ratinal Team Cncert. 4.1.1.2 SharePint Scpe Tracker Lcated n the NY-HX SharePint prtal, Scpe Tracker is the initial entry pint f the CCMS. This tl is used by the prject team t dcument identified variatins in the baseline scpe. Scpe Tracker is available t all team members, with the apprpriate security rles as defined by CSC and DOH management, and is the initial pint f entry fr any ptential scpe changes. This culd include functinal requirement (User Stry) changes, infrastructure changes, dcumentatin changes, etc. Scpe Tracker is used by the SCRB t dcument the scpe change triage and t track the dispsitin thrugh the CCMP. All reprting fr CSRs prir t SCB apprval will be generated via Scpe Tracker. 4.1.1.3 Ratinal Requirement Cmpser (RRC) The Sprint Team uses RRC t rganize, priritize, track, and cntrl changing requirements f the NY- HX applicatin. Als part f the CCMS, RRC is the system f recrd fr all requirements details and als a status medium fr the Sprint Team prject resurces thrughut the prject. Specifically, RRC is used fr the fllwing: New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 6 f 21 The baseline requirements are entered int RRC and subsequently traced thrugh the SDLC Tracking requirements attributes as the requirements definitin evlves thrugh the prject life cycle. Prgressive elabratin f high level User Stries int mre granular wrkable User Stries. Aligning requirements with the prject sprint schedule in accrdance with the Agile methdlgy. The NY-HX prject utilizes the IBM Ratinal suite f sftware fr managing the design, develpment and testing, including tracking apprved changes t the prduct inventry. NY-HX SharePint will be used fr tracking prpsed changes, alng with their final dispsitins. Apprved changes will be added t the Requirements Traceability Matrix fr tracking and reprting. 4.1.1.4 Ratinal Team Cncert (RTC) RTC, the final cmpnent f the CCMS, prvides a cllabrative change management slutin that is essential t the SMP and CCMP. RTC has features such as change tracking, prcess autmatin, planning, reprting, and testing and lifecycle traceability. All f which enable better insight, predictability, and cntrl f sftware and systems develpment, alng with their assciated changes. RTC s cllabrative change management capabilities and benefits are used t: Custmize wrk item attributes and capabilities t track and crdinate tasks and wrkflws fr any purpse, gverned by the team s selected prcesses Extend the traditinal ntin f change management frm just wrk items, t include planning and tracking, by linking wrk items t actinable plans t supprt Agile prject planning capabilities Autmate dashbards and reprting fr transparency and mnitring Prvide requirements change management and traceability t the prject team Prvide a cllabratin hub fr a distributed, decentralized enterprise change management view
4.1.2 Scpe and Change Cntrl Management Methdlgy Standards The Scpe Management methdlgy and standards utilized by the NY-HX prject are based n prven Prject Management Institute (PMI) assessed scpe management methdlgy and standards develped and used by CSC, and integrated with Agile develpment practices. The key ingredients f this methdlgy are: Once CSC and NYS DOH establish an agreed upn a set f baseline user stries in Sprint 0 that will cmprise the prduct inventry, changes t the baseline will nly be allwed thrugh a frmal change cntrl prcess. Prpsed changes t prject scpe must fllw the scpe change cntrl prcess, which is mnitred by the (SCRB). Only when CSRs are reviewed and apprved by the SCB, is the scpe f the prject changed. The Scpe and Change Manager is respnsible fr the verall executin f the SMP and CCMP, with a reprting line directly t the Prject Management Office (PMO). All prgram stakehlders are invlved in CSRs. Stakehlders include prgram staff, custmers and users, supprting rganizatins, and representatives f systems that interface with NY-HX. 4.1.3 Technical Perfrmance Metrics CSC s apprach t perfrmance management includes detailed technical prgram metrics that prvide transparency n the perfrmance f the prject teams thrughut the cmplete prject lifecycle. The PMO, as the gverning bdy, cllects metrics n the number f CSRs and their dispsitin n a weekly basis, and uses this data t quantify changes and impacts t the SCB during the Weekly PMO Prject Status Meeting. The PMO will als use the burn metrics and weekly and biweekly variatins in user stry pints as a mechanism t escalate ptential changes in scpe versus the standard prcess f prgressive elabratin assciated with the Agile methdlgy. In the weekly Scpe Management reprting prcess, frequent changes in a specific functinal area will flag the PMO t escalate t the Prject Directr and Requirements Manager fr additinal rt cause analysis. T track prgress, the PMO is planning t reprt as fllws: Number f Baseline Requirements Metric Cllectin Methd Use(s) Number f Decmpsed User Stries Number f requirements fielded Captured in the CSC Requirements Traceability Matrix (RTM) Captured by requirement cycles in Metric reprt Captured in the Metric reprt Measures the vlatility f the verall Requirements as it relates t the initially defined requirements fr the NY-HX Prgram Measure verall NY-HX Prgram risk status as well as status in each key area f impact Measure the actual number f user stries and stry pints that NY-HX has cmpleted thrugh the Sprint cycles Number f CSRs Captured in the Metric reprt Measure the number f requested changes that the SCB has apprved as a request t change the baseline New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 7 f 21 Figure 4-3 Planned Technical Perfrmance Metrics 4.1.4 Detailed Integrated Master Schedule The detailed Integrated Master Schedule (IMS) maintained in Prject Server 2010, including the WBS, is prgressively defined at increasing levels f details, and may therefre incrprate additinal wrk
prducts and dependencies thrughut the prgram. Status updates are incrprated and tracked n a weekly basis. The PMO uses the IMS t assess the impacts f an CSR during the SCRB prcess. This includes additinal activities in the WBS alng with assciated dependencies, level f effrt, resurce assignments and the start and finish dates fr the additinal wrk packages. CSC will use this infrmatin in managing the prject schedule and t determine what, if any, impacts t the implementatin schedule will result during the analysis prcess. This infrmatin will be captured by the SCRB and included with the Change Cntrl Checklist (Appendix C) prvided t the SCB. Once a CSR is apprved, the details fr the CSR will be memrialized and baselined within the IMS t be tracked and measured as part f the prject s implementatin. 4.2 Rles and Respnsibilities Scpe and change cntrl management is a shared respnsibility acrss the entire NY-HX prject team, and includes stakehlders in either management r supprting rles. This sectin utlines the rles and details the respnsibilities f psitins invlved in the SMP. In sme cases, team members may be respnsible fr several rles. 4.2.1 CSC Scpe Change Review Bard The SCRB, facilitated by the CSC Scpe and Change Manager, is cmprised f several key CSC subject matter experts and stakehlders, including the CSC Business Architect, the Scpe Change Owner, Quality Assurance Manager, Cnfiguratin Manager, Enterprise Architect and ther SMEs as apprpriate. This Bard assesses any ptential changes t scpe, cmpletes technical analysis, ppulates the Change Request Checklist and makes recmmendatins n pririty, schedule and budget based n the assessment. 4.2.2 DOH Scpe Cntrl Bard The SCB, a DOH managed bard, is the ultimate arbiter and decisin maker fr prpsed CSRs. The SCB will evaluate, apprve, and priritize changes based n CSC s impact assessment n scpe, cst, schedule, risks, and ther impacts f a prpsed change. The SCB is the nly mechanism fr adding t r remving inventry frm the prject baseline. 4.2.3 CSC Prject Directr The CSC Prject Directr is the facilitatr f the SCRB and represents CSCs psitin and recmmendatin n the handling f CSRs. 4.2.4 CSC Business Architect The CSC Business Architect will participate in the Sprint 0 planning sessin fr each release and will ensure that Sprint Team is educated n the scpe f the functinality assciated with the release. Prir t the end f Sprint 0, the Business Architect will ensure that the Scrum Masters, Requirements Team and Architecture Team have a detailed understanding f the baseline scpe t remve ptential variatins in scpe that ccur during the prgressive elabratin f the User Stries during the executin f the remaining Sprints. The Business Architect leads the decisin making prcess f the SCRB and is key t the success f the SMP and CCMP. The Business Architect, reprting directly t the Prject Directr, is respnsible fr a cmplete understanding f the glbal prgram requirements and is the final CSC decisin-maker as t whether a CSR is deemed t be a scpe change and requires further actin by the SCRB. 4.2.5 CSC Scpe and Change Manager The Scpe and Change Manager, as part f the PMO rganizatin, reprt t the PMO Directr. This ensures the Scpe and Change Manager adheres t the verall prject gvernance and reprting requirements, and will prvide the necessary transparency t the verall prject team. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 8 f 21
The Scpe and Change Manager, is the facilitatr f the SCRB, and is respnsible fr ensuring the CSR details are prperly and cmpletely entered int the tls. The Scpe and Change Manager als wrks with the SCRB and apprpriate Prject Stakehlders t validate the CSR as a scpe change, assess its impacts and ensure utcme is prvided t the Prject Directr fr discussin at the SCB. The Scpe and Change Manager maintains verall respnsibility t ensure identified scpe changes flw thrugh the prcess in a timely manner, and with minimal impact n the prject executin. 4.2.6 Scpe Change Owner The Scpe Change Owner is the stakehlder frm the CSC r DOH team wh represents and entered the CSR in the Scpe Tracker tl in SharePint. The Scpe Change Owner may be available at the SCRB t represent the prpsed scpe change r transfer knwledge and relevant infrmatin t a standing SCRB member. 4.2.7 Prduct Owner The Prduct Owner is a DOH representative wh represents the interests f the custmer by setting the requirements and pririties f the prduct in the Sprint Teams. The Prduct Owner is a member f the SCB. 4.2.8 Scrum Masters and Requirements Team The rle f the Scrum Master is t ensure the team remains fcused and cmmitted t the gals f the sprint as negtiated with the Prduct Owner. The Scrum Master is part f the Requirements Team. 4.2.9 Quality Assurance Manager The Quality Assurance Manager is a member f the SCRB and will audit the scpe and change cntrl management prcess t ensure adherence t prgram prcesses. 4.2.10 Cnfiguratin Manager The Cnfiguratin Manager ensures the prject utput adheres t the rganizatin s cnfiguratin standards. The Cnfiguratin Manager is a member f the SCRB. 4.2.11 Enterprise Architect The Enterprise Architect prvides guidance and expertise fr the technical members f the prject team. If the change spans several technical areas (data, sftware, hardware, netwrk), the Enterprise Architect may request ther technical prject members be present t discuss the CSR. 4.2.12 Prject Stakehlders Fr scpe and change cntrl management t be successful all Prject Stakehlders are respnsible fr ensuring an understanding f the agreed t prject scpe, and fr dcumenting and escalating where ptential variatins exist. As needed, Prject Stakehlders will participate in the SCRB t assess the level f effrt and impacts f a CSR. 4.3 Prject Scheduler The Prject Scheduler will wrk with the SCRB t determine the best apprach fr scheduling the CSR, accunting fr pririty, level f effrt, resurce assignments and dependencies. Once apprved, the Prject Scheduler will ensure that the CSR becmes part f the baseline IMS and will cmmunicate the schedule fr cmpletin t the prject team. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 9 f 21
DOH SCB Prject Directr CSC Business Architect CSC Scpe and Change Manager Scpe Change Owner Prduct Owner Scrum Master and Requirements Team Quality Manager Cnfiguratin Manager Enterprise Architect Prject Stakehlders Prject Scheduler 4.4 Respnsible Accuntable Cnsulted Infrmed (RACI) Chart Figure 4-4 utlines the high-level Respnsible-Accuntable-Cnsulted-Infrmed (RACI) chart shwing the rles invlved in the implementatin f the SMP and their level f participatin in each activity. Key: R = Respnsible; perfrms the task A = Accuntable; ultimately answerable fr cmpletin f task C = Cnsulted; prvides infrmatin r assistance I = Infrmed; kept apprised f the activity Identify additin r remval f prject scpe A I I R Submit Scpe Change Request int Scpe Tracker (Daily) I I A R I I I I I I Perfrm initial scpe assessment R C C C Schedule new SCR fr SCRB review I RAC I C I I C I Cnducts CSC SCRB t determine if SCR prceeds t DOH SCB A R C C C C C C Schedules item fr SCB review I RA I I C I I I I CSR Apprval Dispsitin RA C C C I C I C I I Determine LOE and ptential impact assessment I RAC C I R C C C C C C Apprve LOE and impact assessment RA C C C C I C C C C C Update Scpe Tracker and Add t RTC I C I CI RA I I I I Add t IMS, baseline and track I I I I I I I I I I I R New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 10 f 21 Figure 4-4 Scpe Management RACI 4.5 Define and Dcument Scpe Baseline CSCs prpsal and defined scpe was based n the FAS requirements, which included the CMS Draft Blueprints, and is utlined extensively in Tab 5 f CSC s prpsal. The CSC prpsal was built upn the initial understanding f these requirements, which were used t prvide the basis f effrt, csting and pricing based n the widgets defined and utlined in Appendix B: Scpe Analysis f DOH Prpsed NY- HX Prject. CSC cnducted a requirements Gap Analysis phase at the beginning f the prject t align the current understanding f the prject scpe with what CSC had riginally prpsed. The results f this Gap Analysis, alng with CSC and DOH cncurrence f prject scpe, set the baseline fr the prject s scpe. CSC and DOH are in agreement n the baseline scpe f the prgram and share the respnsibility f scpe management. Any variatins are managed thrugh the SMP and CCMP prcess. The User Stries are assigned t each cre business area, with either a CSC Senir Business Analyst r CSC Senir Plicy Analyst t versee the facilitatin and capture f the detailed User Stries fr that functinal area. The CSC Analyst wrks directly with the Department Plicy SMEs t dcument the detailed User Stries, which are als based n the scpe guidelines identified thrugh wrking with the
Business Architect. The Business Architect has the respnsibility t ensure the team remains aligned with the scpe baseline. This expert invlvement ensures the team fully understands the cmmitted scpe and fcuses User Stry develpment, thrugh the remaining Sprint cycles t be in accrdance with the agreed upn prject baseline defined in Sprint 0. Shuld the CSC Business Analyst r Plicy Analyst identify gray areas f scpe functinality, they will escalate t the Business Architect fr guidance, and t clarify whether the functinality is a result f refining the definitin f an existing requirement r is deemed a CSR. 4.6 Prcess fr Scpe Management and Cntrl 4.6.1 Requirement Elicitatin and Priritizatin Re-priritizatin f the Prduct Inventry is typically driven by discvery f new requirements (user stries) fr functins and features, and/r impsitin f new requirements frm Federal changes. The latter is a likely ccurrence fr the NY-HX requirements, given evlving regulatry understanding f the Affrdable Care Act legislatin, and the features and functins t be included in Health Benefit Exchanges. Thrughut the Sprint cycles, the Prduct Owners are respnsible fr grming the prduct inventry (priritizing, adding r remving requirements, and prviding further details as needed), as well as ensuring the teams are wrking n user stries that are deemed high pririty and high value fr DOH. While repriritizatin f requirements ccurs during the Sprint Cycles within each release, any variatin t the scpe baseline (additin, remval r requirements swap ut) will be escalated thrugh the scpe and change cntrl management prcesses. This exchange r swap f requirements results in deferral f requirements until after the implementatin f the baseline. The deferred r swapped requirement therefre becmes additinal scpe during the Operatins phase f the prject. In a standard Agile envirnment, the requirements described as the Prduct Inventry are regularly assessed and re-priritized by the Prduct Owner. Functins, features, and/r capabilities that are belw the budget line (nt t be dne) may get re-priritized t wrk that will get dne. Any variatins t what is priritized higher and subsequently added abve the line r belw the line is typically at the discretin f the Prduct Owner. On the FFP NY-HX cntract, the team is educated and fcused n the scpe baseline established fr the prject. Any requirements that are added r remved frm the inventry will be dcumented as CSRs and managed thrugh the CCMP, making them visible t bth CSC and DOH management. These trade-ffs are crucial t staying n the prject schedule and meeting the highest pririty requirements. Figure 4-5 illustrates repriritizing requirements (user stries) that are either added r remved frm the prject scpe and handled as CSRs. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 11 f 21
CSR Required Fr These Mves Scpe Baseline Figure 4-5 Standard Agile Prduct Inventry Repriritizatin As nted in the FAS, changes in scpe that invlve new r enhanced requirements (user stries) will drive the need fr schedule impact analysis. The additinal resurces will be prvided wherever pssible thrugh the additin f Supplemental labr funding. Examples f changes which may require the additin f supplemental labr funding include: Additinal scpe identified in the Gap Analysis New r enhanced requirements identified in the curse f the releases Department request f supplemental staff resurces Delays in schedule due t Department requested changes 4.6.2 Identify and Submit CSR The Business Analyst r Plicy Analyst, thrugh educatin by the Business Architect, is respnsible fr having a detailed understanding f the scpe baseline fr their respective subject area. The Business Analyst r Plicy Analyst will dcument and track the users stries in RTC, using the RTM in the tl t trace the detailed user stries back t the baseline scpe. Thrughut the executin f Sprints, they will serve as the driver t ensure the Sprint Teams remain fcused the prject schedule and identify departures frm the agreed t scpe baseline. Since scpe management is a shared respnsibility acrss the CSC and DOH prject teams; all team members will have the ability t enter perceived CSRs int the Scpe Tracker tl (Figure 4-6) in SharePint. Due t the tight schedule and cllabrative agile develpment methdlgy, it is expected that variatins in scpe are raised in a timely manner. The Sprint Teams will execute under the guidance that if questins n scpe arise and there is uncertainty amng the team, they will be escalate fr evaluatin by the Business Architect. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 12 f 21
4.6.3 Analyze CSR Figure 4-6 Snapsht f CSR Entered int Scpe Tracker The prcess fr analyzing a CSR, includes an evaluatin and priritizatin f prpsed changes t the prject scpe by determining if the CSR can first be mapped back t a baseline requirement via the RTM in RTC. An initial screening is cmpleted by a subset f SMEs prir t the inclusin f the SCRB fr additinal analysis. 4.6.3.1 Initial Screening Upn entry f CSRs int Scpe Tracker, the Scpe and Change Manager reviews the CSR fr validity and cmpleteness. If the CSR is deemed invalid either during this screening, r during any pint in the analysis prcess, it is redirected back t the Scpe Change Owner fr additinal infrmatin. If this screening r any pint in the analysis prcess yields pertinent infrmatin is missing, the Scpe and Change Manager will fllw up with the Scpe Change Owner t secure any additinal details needed t ensure a cmplete understanding f the CSR. 4.6.3.2 Preliminary Analysis Each week, the Scpe and Change Manager, Business Architect, and Requirements Manager will jintly cmplete a preliminary analysis f the CSRs entered int Scpe Tracker fr the week s perid. This team will review the CSRs fr cmpleteness and determine based n the RTM in RTC and their expert judgment whether r nt the CSR is deemed ut f scpe and shuld be handled via the SCRB. 4.7 Review by SCRB The SCRB is cmprised f CSC SMEs wh will research the CSR against the baseline scpe via the RTM, and dcument the lineage that supprts that the CSR is ut-f-scpe. The SCRB prcess is twfld cnsisting f an initial and final analysis based n SCB directin. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 13 f 21
4.7.1.1 SCRB Initial Analysis The gal f the initial review is t prvide the SCB with a CSR pririty, any ptential infrastructure impacts, and a high-level rugh f magnitude (ROM) with the SCRB s cnfidence level fr the ROM. This is reflective f the effrt t implement the CSR and the expected level f effrt needed t cmplete the final analysis f the CSR, using the fllwing apprximate parameters classificatins t develp the detailed estimate: Up t 8 hurs Up t 24 hurs Up t and Greater than 40 hurs This infrmatin is used by the SCB t determine whether r nt CSC is t prceed with a mre detailed level f effrt (LOE) determinatin and impact assessment. 4.7.1.2 SCRB Final Analysis CSC will target the assessment t be cmpleted within five business days f SCB apprval t prceed with further analysis. The SCRB will cmplete a deep dive, using the Change Cntrl Checklist (Appendix B) t define the detailed estimate fr the wrk that needs t be cmpleted fr the CSR. In additin t the Supplemental Staff effrt required, this effrt estimate will include any additin infrastructure r supprt items needed t supprt the CSR. The Scpe and Change Manager, using the estimate prvided by the SMEs n the SCRB, wrks with the Prject Scheduler t incrprate the CSR int the Wrk Breakdwn Structure (WBS) in the IMS and determines impacts t resurces, schedule and specifically the critical path. 4.8 Prvide Recmmendatin n CSRs t the DOH SCB Each week the SCRB will prvide details n the recmmended CSRs, t the SCB fr apprval, rejectin r deferment t a later time. Cnsistent with the SCRB prcess, the SCB prcess is tw-fld cnsisting f an initial and final analysis based n SCB directin. 4.8.1.1 SCB Initial Analysis The SCB will review the prpsed pririty, ROM and any ptential infrastructure impacts as part f its initial review. This initial review yields a pririty change, a deferment r rejectin f the CSR r a directin fr CSC t prceed with a mre detailed impact assessment using supplemental staff resurces. 4.8.1.2 SCB Final Analysis At cmpletin f the impact assessment, the SCRB will prvide t the SCB the detailed Change Cntrl Checklist (Appendix B) including the LOE, estimated infrastructure csts and the results f the schedule impact assessment. As additinal requirements becme knwn and additinal funding becmes available the Department will amend the cntract fr the additinal wrk based upn the labr rates supplied in the cntractr s prpsal fr the labr categries identified in Attachment 2, Sectin 12, Staffing. 4.9 SCB CSR Dispsitin The Scpe Tracker will be updated with the status f the SCB dispsitin weekly. Deferred r rejected CSRs will be updated t reflect the reasn fr deferment r rejectin, and if apprpriate, when the SCB wuld like t review r revisit the CSR in the future. Apprved changes will be recrded in Scpe Tracker and will be added t RRC and int the RTM t be implemented. CSC will send a frmal transmittal t DOH summarizing the apprved changes and will expect DOH apprval f the transmittal within five business days f submissin. T execute the apprved New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 14 f 21
CSR, the supplemental labr funding will be exercised as utlined in the FAS Sectin III Scpe f Wrk, and the pending effrt will be slidified and baselined in the IMS. 4.10 Change Ntificatin and Release The apprved CSRs will be incrprated as part f a Sprint fr an apprpriate release and track f wrk t be implemented by the prject team. The Sprint Team respnsible fr implementing the CSR will be ntified f the SCB decisin by the Scpe and Change Manager, and will be respnsible fr implementing the CSR in accrdance with the plan prvided by the SCRB t the SCB. 4.11 Mnitr, Track and Reprt All apprved CSRs will be managed thrughut the implementatin via the RTM, in rder t ensure develpment and testing ccur accrding t the implementatin methdlgy. All apprved CSRs are added t the RTM in RTC and are slidified in the IMS fr mnitring, tracking and reprting. This prcess will prvide traceability f the CSR, as well as a mechanism fr tracking the effrt t cmplete the scpe change. The PMO will track and mnitr all apprved CSRs and will reprt n their respective status until satisfied via the prject schedule. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 15 f 21
Appendix A GLOSSARY/ACRONYMS Please refer t the Master Prject Management Deliverables Glssary and Acrnym List psted n the Deliverables Sectin f the NY-HX SharePint site. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 16 f 21
Appendix B New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 17 f 21 Scpe Analysis f DOH Prpsed NY-HX Prject Per CSC s prpsal respnse t the FAS (page 5-4), CSC s fixed price fr the DDO phase f this prject is predicated n and bund by CSC s understanding f the size f the prject and the number f cmpnents needed t create an peratinally ready NY-HX Slutin, as expressed by the data given belw, and further detailed in the referenced exhibits available in CSC s prpsal. Wrk Area Requirements Design Cding and Architecture Surce(s) f Requirements NY State FAS, CMS Blueprint Exchange Reference Architecture NY State FAS, CMS Blueprint Exchange Reference Architecture, CMS MITA Guidance NY State FAS, CMS Blueprint Exchange Reference Architecture, CMS MITA Guidance, emedny SDLC prir experience Details f wrk area requirements Tab 5 Business Requirements Exhibits 5.2-2, 5.3-2, 5.4-2, 5.5-1 Tab 5 Business Requirements Exhibits 5.2-2, 5.3-2, 5.4-2, 5.5-1 Tab 5 Business Requirements Exhibits 5.2-2, 5.3-2, 5.4-2, 5.5-1 Testing NY State FAS Tab 5 Business Requirements Exhibits 5.2-2, 5.3-2, 5.4-2, 5.5-1; Sectins 6.7.4.2 System Testing, 6.7.5 User Acceptance Testing Training and Dcumentatin NY State FAS Tab 7 Staffing Requirements Management NY State FAS Tab 7 Staffing Requirements Operatins NY State FAS Tab 6 Technical Requirements CSC Quantificatin f Scpe (Basis f Estimate) 47 Business Prcesses, requiring 47 JAD sessins at a pace f apprximate 2 JAD sessins per week; Requirements Definitin Dcument prduced and reviewed 199 Cre business services and 183 supprting business services supprting 47 business prcesses; System Design Dcument prduced and reviewed 710 cmpnents identified t be develped, including SOA Web services, prtlets, business rules, wrkflws and interfaces 710 cmpnents identified t be tested; SIT test cases are the basis fr SIT and UAT tests; maximum f tw cycles per test in SIT and UAT, after which Severity 1 defects are repaired and remainder are priritized Included cntent management fr 1500 pages f cntent; 10 EBT learning mdules prduced; ne train-thetrainer sessin per learning mdule cnducted FAS requirements fr Key Staff, plus CSC s prir experience with emedny SLDC Attachment 2 Technical Requirements Estimating Methd used by Team CSC CSC SOASure mdel; prir experience via emedny SDLC and MA Cmmnwealth Cnnectr CSC SOASure mdel; prir experience via emedny SDLC, MA Cmmnwealth Cnnectr, CMS prjects QSM SLIM Estimate tl, emedny SDLC Prir experience, MA Cmmnwealth Cnnectr Prir experience with emedny SDLC Prir experience with emedny SDLC FAS requirements fr Key Staff, plus CSC s prir experience with emedny SLDC emedny peratins prir experience
Wrk Area Surce(s) f Requirements Details f wrk area requirements CSC Quantificatin f Scpe (Basis f Estimate) Estimating Methd used by Team CSC Supplemental Hurs NY State FAS Attachment 16 N/A Level f Effrt (LOE) as specified in the FAS N/A New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 18 f 21
Appendix C Change Cntrl Checklist Change Cntrl Checklist Implicatins f the Prpsed Change Identify any existing requirements in the baseline that cnflict with the prpsed change. Identify any ther pending requirement changes that cnflict with the prpsed change. Identify any cnflict with knwn NY-HX initiatives. What are the cnsequences f nt making the change? What are pssible adverse side effects r ther risks f making the prpsed change? Will the prpsed change adversely affect perfrmance requirements r ther quality attributes? Will the change affect any system cmpnent that affects critical prperties such as safety and security, r invlve a prduct change that triggers recertificatin f any kind? Is the prpsed change feasible within knwn technical cnstraints and current staff skills? Will the prpsed change place unacceptable demands n any cmputer resurces required fr the develpment, test, r perating envirnments? Must any tls be acquired t implement, test and/r mnitr the change? What is the impact t the NY-HX Testing Team and test plans? Hw will the prpsed change affect the sequence, dependencies, effrt, r duratin f any tasks currently in the Prject plan? Des this change impact schedule, cst r functinality f planned NY-HX Radmap initiatives? Will prttyping r ther user input be required t verify the prpsed change? Hw much effrt that has already been invested in the Prject will be lst if this change is accepted? Will the prpsed change cause an increase in prduct unit cst, such as by increasing third-party prduct licensing fees? Will the change affect any marketing, manufacturing, training, r custmer supprt plans? System Elements Affected by the Prpsed Change Identify any user interface changes, additins, r deletins required. Identify any changes, additins, r deletins required in reprts, databases, r data files. Identify the design cmpnents that must be created, mdified, r deleted. Identify hardware cmpnents that must be added, altered, r deleted. Identify the surce cde files that must be created, mdified, r deleted. Identify any changes required in build files. Identify existing unit, integratin, system, and acceptance test cases that must be mdified r deleted. Estimate the number f new unit, integratin, system, and acceptance test cases that will be required. Identify any help screens, user manuals, training materials, r ther dcumentatin that must be created r mdified. Identify any ther systems, applicatins, libraries, r hardware cmpnents affected by the change. Identify any third party sftware that must be purchased. Identify any impact the prpsed change will have n the Prject's sftware Prject management plan, sftware quality assurance plan, sftware cnfiguratin management plan, r ther plans. Quantify any effects the prpsed change will have n budgets f scarce resurces, such as memry, prcessing pwer, netwrk bandwidth, real-time schedule. Identify any impact the prpsed change will have n fielded systems if the affected cmpnent is nt perfectly backward cmpatible. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 19 f 21
Effrt Estimatin fr the Prpsed Change (Labr Hurs) Task 0.00 Update the requirements database with the new requirement Develp and evaluate prttype Create new design cmpnents Mdify existing design cmpnents Develp new user interface cmpnents Mdify existing user interface cmpnents Develp new user publicatins and help screens Mdify existing user publicatins and help screens Develp new surce cde Mdify existing surce cde Purchase and integrate third party sftware Identify, purchase, and integrate hardware cmpnents; qualify vendr Mdify build files Develp new unit and integratin tests Mdify existing unit and integratin tests Perfrm unit and integratin testing after implementatin Write new system and acceptance test cases Mdify existing system and acceptance test cases Mdify autmated test drivers Perfrm regressin testing at unit, integratin, and system levels Develp new reprts Mdify existing reprts Develp new database elements Mdify existing database elements Develp new data files Mdify existing data files Mdify varius Prject plans Update ther dcumentatin Update requirements traceability matrix Review mdified wrk prducts Perfrm rewrk fllwing reviews and testing Recertify prduct as being safe, secure, and cmpliant with standards Other additinal tasks 0.00 TOTAL ESTIMATED EFFORT Prcedure: 1 Identify the subset f the abve tasks that will have t be dne. 2 Allcate resurces t tasks. 3 Estimate effrt required fr pertinent tasks listed abve, based n assigned resurces. 4 Ttal the effrt estimates. 5 Sequence tasks and identify predecessrs. 6 Determine whether change is n the Prject's critical path. 7 Estimate schedule and cst impact. New Yrk Health Exchange Scpe and Change Cntrl Management Plan Page 20 f 21