Nasdaq CSD SE CHANGE MANAGEMENT AND PROJECT MANAGEMENT PROCESSES OF NASDAQ CSD

Transcription

1 Nasdaq CSD SE CHANGE MANAGEMENT AND PROJECT MANAGEMENT PROCESSES OF NASDAQ CSD Effective Date:

2 1. Overview The Nasdaq CSD (Depsitry) uses standard Nasdaq change management and prject management prcesses t mitigate peratinal risk arising frm mdificatins t peratins, plicies, prcedures and cntrls put in place by the CSD. RTS n CSD Authrizatin. Article 70. Operatinal risk-management system and framewrk 7. A CSD shall peridically review its peratinal bjectives t incrprate new technlgical and business develpments. 8. A CSD's peratinal risk-management framewrk shall include change-management and prjectmanagement prcesses t mitigate peratinal risk arising frm mdificatins t peratins, plicies, prcedures and cntrls put in place by the CSD. Article 73. Audit and testing 4. A CSD shall peridically test and review the peratinal arrangements, plicies and prcedures with users. The testing and review shall als be perfrmed where substantive changes ccur t the securities settlement system perated by the CSD r after peratinal incidents that affect the smth prvisin f services by the CSD. Article 75. IT tls 6.The CSD shall subject its IT systems t stringent testing by simulating stressed cnditins befre thse systems are used fr the first time, after making significant changes t the systems and after a majr peratinal disruptin has ccurred. A CSD shall, as apprpriate, invlve in the design and cnduct f these tests: (a) users; (b) critical utilities and critical service prviders; (c) ther CSDs; (d) ther market infrastructures; (e) any ther institutins with which interdependencies have been identified in the business cntinuity plicy. Article 77. Business impact analysis 3. A CSD shall ensure that its business impact analysis and risk analysis fulfil all f the fllwing requirements: (a) they are kept up t date; (b) they are reviewed fllwing a material incident r significant peratinal changes and, at least, annually; (c) they take int accunt all relevant develpments, including market and IT develpments. In 2012, Nasdaq launched the Operatinal Excellence Prgram (OpX) with the visin f ptimizing current prcesses t imprve the quality and delivery f Nasdaq s prducts and services t its custmers. The OpX prgram is a framewrk that prvides sustainable and repeatable prcesses fr defining, planning and deplying technlgy in prductin, as well as managing Nasdaq prductin systems and infrastructure. The missin f the Prduct Develpment Lifecycle Prcess (PDLC) is t ensure that a sustainable and repeatable plicy and prcess is in place in rder t plan, schedule and successfully deply system changes (changes are defined as any mdificatin t ne r mre cnfiguratin items including hardware, sftware, firmware, and cnfiguratin), prjects, prgrams and releases int prductin. The Change-management missin is t crdinate and cntrl all changes t IT services t minimize adverse impacts f thse changes t business peratins and the users f IT services. Accrding t Nasdaq OpX prgram and PDLC the Prject is any effrt that meets the fllwing cnditins: Is included in the Depsitry prject list by decisin f the Depsitry Management Bard; 2

3 The estimated effrt expressed in hurs spent by all team members r prject lenght in mnth exceeds the limit set by the Depsitry Management Bard; Risk level f at least ne f the cmpnents custmer impact, regulatry impact, legal impact, reputatinal impact, technlgy impact are high; Change intrduces r alters cnnectivity t back-end prductin netwrks and systems; Overall risk level is medium r high. The effrt is defined as Change if it des nt meet abve mentined criteria and the verall risk level f the effrt is lw. Figure 1. Nasdaq OpX prgram verview The Nasdaq OpX prgram and its cmpnents are implemented by respective plicies, prcesses and prcedures, and mnitred by metrics and dashbards. The Depsitry Change-management and Prject-management will fllw: The Nasdaq PDLC Plicy The Nasdaq PDLC Prcess The Nasdaq Change Management Plicy The Nasdaq Change Management Prcess ence_prgram/dc%20lib/opx%20dcuments/opx_pdlc_gverna nce_plicy_v%202.1.pdf ence_prgram/dc%20lib/opx%20dcuments/opx_pdlc_prcess %20%20v2.1.pdf ent/eu_change_management/eu%20reginal%20prcedures/opx _Change_Management_Plicy_v1.4.pdf ent/eu_change_management/eu%20reginal%20prcedures/opx _Change_Management_Prcess_%20v1.4.pdf The Plicy dcuments prvide the rules and guidelines that ensure cnsistency and cmpliance with the cmpany s strategic directin, the Prcess dcuments specify the majr functins t be perfrmed t cmply with the Plicy, and the Prcedure dcuments define the specific instructins necessary t perfrm a task r part f a Prcess, detail wh perfrms the Prcedure, what steps are perfrmed, when the steps are perfrmed, and hw the Prcedure is perfrmed. 2. Prject Management Prcedures The Depsitry Management Bard apprves each prject including: 3

4 Assigning f the Prject manager wh is in charge f achieving the prject bjectives and has the respnsibility f taking the prject thrugh the PDLC prcesses; Apprving Prject Charter and Prject Plan. Prject manager s respnsibilities include: The PM will either d the Risk Assessment, r will ensure that the Risk Assessment is cmpleted by thers n the team. In the event a prject has multiple changes within it, the PM may chse t treat the prject as ne entity r as multiple individual changes. If the PM chses t treat it as ne entity, a single Risk Assessment will be cmpleted which shuld reflect the risk f all changes in aggregate. The PM must ensure that all tllgates and the dcumentatin required by the Rigr Level are cmpleted as needed - at least ne instance f each tllgate and each required dcument must be prduced. The PM shall nt use the ability t include multiple changes in a single prject t circumvent the spirit and intentin f the PDLC prcess t bypass the prductin f required dcumentatin. The fllwing tls are used in the PDCL prcess: Risk Assessment: The purpse f the Risk Assessment is t assess and scre the risk assciated with all prjects and subsequent changes t the prductin envirnment. This Risk Scre is then used t determine the amunt f Rigr (prcess, dcumentatin and gvernance) that is required fr the prject. The Risk Assessment is required t be initially evaluated at the start f the prject and then re-evaluated at each f the PDLC Phases; Within the Risk Assessment, the Risk Criteria is reflected alng with a brief descriptin, and sme questins and guidelines t help the screr determine the Risk Level. The screr enters the rating fr the individual Risk Criteria. The Risk Assessment scre is then used t determine the level f Rigr required A (High), B (Medium) r C (Lw); Security Risk Assessment (SRA): The purpse f the SRA is t determine the level f security risk t the prject. The utcme f the SRA will determine if Infrmatin Security participatin in the prject is mandatry, ptin r nt required. Rigr Level A and B prjects are required t cmplete the SRA. Rigr Definitin: The Rigr Definitin spreadsheet indicates the required input and utput dcuments based n Rigr Level that are required fr each PDLC Phase. 2.1.Required Prject Dcumentin Prject Charter The Prject Charter dcuments the initial requirements that satisfy the stakehlder s needs/expectatins and als frmally establishes the relatinship between the technlgy team and the business r the custmer making the request. The prject is initiated nce the Prject Charter is apprved by its key stakehlders. The Prject Charter als has the fllwing key uses - securing the cmmitments necessary fr success, maintaining thse cmmitments as cnditins change and driving the capture f prject details thrugh t delivery. 4

5 The Prject charter shuld include the fllwing parts: Prblem/Opprtunity Statement: Describes the current situatin (business r technical) as backgrund infrmatin f the prject purpse. With reference t the Depsitry strategy and pririties, it describes the cre prblem t be slved r pen pprtunity that exists. Business Case: A justificatin r makes the case fr the prject. Prject Objective Statement: Prpses a slutin addressing the prblem r pprtunity stated abve and its bundaries. The purpse is t give the reader an understanding f hw this prject will meet the needs f the rganizatin. Objectives shuld be specific and deliverable-based (as ppsed t a high-level gal statement, which need nt describe a deliverable). Prject Scpe/Cnstraint/Assumptins/Dependencies: Prject Scpe: the lgical bundaries f the prject; Assumptins: events that are expected t ccur fr the cmpletin f the prject; Cnstraints: anything that can limit r restrict the extent f the prject and are utside f the prject team s cntrl; Dependencies: an utput frm any anther prject is needed t carry ut the prject s deliverable / milestne executin. Key Stakehlders: Lists majr prject rles, the individuals invlved and hw much time they are cmmitting t this specific prject. (i.e., Prject executive spnsr, Steering cmmittee members, Technlgy Lead, Technlgy Prject Manager, Client/Custmer Prject Manager, Prject advisrs) Prject Financials: An verview f the estimated csts f the prject and the timing f thse csts Prject Plan The Prject Plan (Gantt chart) allws the user t subdivide the prject s large milestnes int manageable cmpnents. It is a type f prject schedule that illustrates hw the prject will flw, the phases invlved in achieving the scpe cmpletin, task duratins, assigned resurces as well as dependencies amng the deliverables. The Prject plan shuld include: Tasks: breakdwn f the prject wrk dwn int tasks; Start Date/Finish Date: including planning phase fr each deliverable; Resurce Name: allcated resurces t specific tasks Prject Risk Analysis The Risk Analysis allws the Prject Manager and prject team members t identify factrs that can jepardize the prject s success and affect the prject quality, budget and/r time: The Risk Assessment determines a Risk Scre assciated with all prjects and subsequent changes t the prductin envirnment; The Risk Scre is used t determine the amunt f Rigr (prcess, dcumentatin and gvernance) that is required fr the prject; The fllwing risks are assessed during the prcess custmer, business, regulatry, legal, technlgy, inf Security, scpe, peratinal, perfrmance, change dependiencies, etc. Once the risks have been identified, plans fr t avid/mitigate the risk shuld be discussed. 5

6 2.1.4.Change Requests The Change Request frm is required fr any prject scpe, schedule, r financial changes (i.e. as a result f system enhancements requests, regulatry requirements, etc.). The Prject Manager shuld have a change cntrl management prcess in place as part f the prcess; the submitted change request will be reviewed with the necessary stakehlders and rejected r apprved fr implementatin. Such prcess: Ensures that scpe changes are intrduced in a cntrlled/crdinated manner (avid scpe creep); Creates transparency amng key prject stakehlders. The fllwing shuld be cnsidered when submitting Change requests: Type f Change: Scpe, schedule, financial, new request; Pririty - High, Medium, Lw; Change Descriptin: What change is being prpsed? What is the driving factr behind the change? Benefit if change is implemented: Revenue/Cst/Resurce/Business benefits; Cst f Change: additinal hardware/resurces/third party vendrs, etc. needs; Schedule: What is the riginal Prject End Date? What is the baselined Prject End Date? By hw many days will the riginal target delivery f the item be impacted as a result f the change? Required Technlgy Changes: Changes t design, functinality, sftware, etc. The Change Requests shuld be apprved by the Depsitry Management Bard and ther prject stakehlders. 2.2.G/N-G Prcedures The Depsitry Management Bard has authrity t make a GO / N-G decisin fr any Prject at any time f the Prject. 3. Change Management Prcedures The primary gal f the Change Management prcedures is t prvide prescriptive details in supprt f the Change Management Prcess. Rles & Respnsibilities Related t Change Management The fllwing rles with further described respnsibilities have t be assigned t each Change Request: Prcess Owner Change Requester Change Crdinatr Change Manager The Change Prcess Owner is respnsible fr the prcess itself, its dcumentatin, perfrmance, alignment with business and supprt tls, and its cntinual imprvement. Fr the Depsitry, the Change Prcess Owner is Chief Technlgy Officer The Change Requester is the persn requesting the Change, speaking fr, and prviding details frm the custmer s r end user s perspective The Change Crdinatr is respnsible fr tracking and pursuing the Change Request during its whle lifecycle and fr making sure it fllws the Change Management Prcess and Prcedures. The Change Crdinatr is usually the Change Requester. The Change Crdinatr is als respnsible fr cnfirming that the Change Impact Level prperly reflects the impact f a ptential failure f the change t the business and IT peratins. The Change Manager is respnsible fr cnvening and chairing a CAB (Change Advisry Bard). The Change Manager is als respnsible fr making sure the prcess is fllwed and adhered t thrughut the rganizatin and taking apprpriate actin if it s nt. 6

7 Change Advisry Bard (CAB) Change Implementer The CAB cnsists f peple representing the custmers, users, supprt teams, develpers and thers applicable t discuss the change impact and necessity. As such, the members may differ frm time t time. The CAB is respnsible fr apprving r rejecting Requests fr Change, based n the infrmatin in the Change recrds submitted. The CAB shuld als hld Change reviews n a recurring basis. This can include, but nt limited t: - Evaluating changes that have caused unfreseen service disruptins - Suggesting prcess imprvements - Cmmunicating Change Management achievements - Re-evaluating any failed Standard Changes The Change Implementer is respnsible fr the detailed planning and actual implementatin f the separate Change Tasks. Respnsibilities may be delegated, but delegatin (r escalatin) des nt remve respnsibility frm the individual accuntable fr a specific actin. A Change Request underges the fllwing stages in its lifecycle initiatin, authrizatin, plan, schedule and review, final review and apprval, implementatin, and clse. 3.1.Types f Change Accrding t Nasdaq Change Management Plicies and Prcedures changes are classified int the fllwing categries: Tier 1 Majr Changes Tier 2 Large Changes Tier 3 Minr Changes Tier 4 Standard/Preapprved Changes Changes where failure (r errr) f the change executin are cnsidered t be a significant risk t the business r IT peratins Changes affecting multiple prductin envirnments Changes where failure (r errr) f the change executin are cnsidered t be a mderate risk t the business r IT peratins Large changes affecting a single prductin envirnment, r a minr change affecting multiple prductin envirnments Changes where failure (r errr) f the change executin are cnsidered t be a lw risk t the business and IT peratins Change t a single prductin envirnment Frequently ccurring, repeatable change with lw cmplexity and lw risk t the business and IT peratins that has been pre-apprved by the Change Advisry Bard Changes that d nt change the functinality f the system Other change types that can ccur: An Urgent Change - a change that has gne thrugh the PDLC prcess and has been successfully tested, but is being submitted fr apprval utside the standard CAB. These changes must be reviewed and apprved by the Head f Operatins Department. A change that needs t be apprved befre the next CAB meeting must be created as an Urgent Change, g thrugh the PDLC prcess and be tested successfully; An Emergency Change - a change that is applied t remedy a prductin majr incident that has nt yet gne thrugh the PDLC prcess. Emergency changes are apprved by the Technical Incident Manager running the incident and the Business Incident Manager. The PDLC Prcess must be initiated and an Emergency Change ticket must be submitted within 48 hurs fllwing its implementatin. The Change Owner & Change Manager rles fr an Emergency Change are delegated t the Technical Incident Manager. CAB has pre-authrized delegatin f change apprval authrity t the Incident Manager fr Emergency changes. 3.2.Tls used in Relatin t Change Management Fr each Change the standard frm Change Request is entered in the remedy ITSM tl. Remedy ITSM is the Nasdaq tl & standard repsitry fr the Change Management Prcess. The fllwing training 7

8 resurces prvide glbal guidance and details n hw t use the Remedy ITSM tl t execute activities required by the Change Management Plicy, Prcess & Prcedures. All Changes Requests must cntain at least the fllwing infrmatin befre an apprval can be cnsidered: What is t be dne by the change? What is/are the reasn (s) fr implementing the Change? What is the risk f implementing the change? What is/are the cnsequence(s) if the change is nt implemented? Test results have been reviewed and are sufficient (YES, NO r N/A)? What is the rll back plan in case the change is nt successfully implemented? Wh is respnsible verall fr the Change? All Changes must als cntain the detailed planning in the separate tasks. The tasks are t be assigned t the different teams invlved in the planning and implementatin f the Change. 3.3.CAB Operating Prcedures The CAB cnsists f peple representing the custmers, users, supprt teams, develpers, and thers applicable t discuss the change impact, necessity, viability, and t apprve r deny requests. The participating members may differ frm time t time. The CAB is authrized by the Depsitry Management Bard as the gverning bdy respnsible fr apprving r rejecting Change Requests, based n the infrmatin submitted with the Change Request Frm. The CAB is als respnsible t hld Change reviews n a recurring basis. This can include, but is nt limited t: Evaluating changes that have caused unfreseen service disruptin; Suggesting prcess imprvements; Cmmunicating Change Management achievements; Re-evaluating any failed Standard Changes. Prir t every CAB meeting an agenda is prvided t the participants. It includes: All Planned Changes (Tier 2 submitted fr apprval); All Scheduled Changes fr Upcming the upcming weekend (Tier 1, Tier 2 and Tier 3 scheduled changes). 3.4.Change Ntificatins Ntificatin f Change t the impacted users, internal r external, might be perfrmed prir t deplyment f the change. Fllwing are basic guidelines fr ntificatins: Distributin f CIT ntices fr changes impacting end users; Distributin f the daily change reprt infrming abut upcming scheduled implementatins; CAB minutes - changes apprved/rejected; Ntificatin t the Depsitry participants n scheduled wrk. 3.5.G/N-G Prcedures Prir t prductin deplyment, a Change Request may g thrugh additinal G/N-G decisins due t additinal infrmatin becming available either directly related t that Change r related t ther changes r business r activities planned arund the Change deplyment schedule. 8

9 The Change Advisry Bard (CAB) r the Depsitry Management Bard has authrity t make a N-G decisin fr any Change Request at any time prir t deplyment f the change. CAB may invke a N-G decisin fr any reasn, including, but nt limited t, change implementatin quality assurance results nt meeting change impact level expectatins, cnsideratin f the brader cntext f changes r ther business r IT peratinal activities planned fr deplyment in a similar deplyment time-windw, etc. 9