MY OCEAN MyOcean Change Management & Baseline Control WP2 MyOcean PRR, Roma, 2011 April 29 th

Marine Core Service Changes arise  Changes arise and are unavoidable: –Discrepancies with the agreed System / Service / Product requirements baselines: anomalies –New identified needs or improvements, involving updates of requirements and baseline control: evolutions –Modifications of the IT infrastructure, not under MyOcean control and without effect on the rest of the System / Service: notifications  Changes originate from: –Within the Project: System Development Teams Oceanographic Product Contributors (Product Managers) IT infrastructure Contributors (Service Managers) –Outside the Project: Users’ feedbacks and requests MyOcean Stakeholders

Marine Core Service Changes arise and they are numerous  Changes may be related to : –The System (automated capabilities) Anomalies with respect of expected behaviour (detected by IV&V activities) Evolutions of desired behaviour (asked by users, stakeholders or project members) –The Products Anomalies / Evolutions in Products descriptions, quality or performances Anomalies / Evolutions in Product Management processes (including Catalogue Management). –The IT Infrastructure Support Services Anomalies / Evolutions / Notifications on the deployed components of the IT Infrastructure (DSL & HDL). Examples : –Notification of a disk capacity change on an operational sub system, –Evolution of the IT CMDB involving the transition (acceptance) of a new released system or sub system in the operational environment. Anomalies / Evolutions in IT Service Management processes (including Service Desk). MyOcean PRR, Roma, 2011 April 29 th

Marine Core Service Changes must be controlled n A process to control, assess and prioritize changes –Request For Change (RFC) Lifecycle Changes are not done savagely They evolve under control and are planned through defined steps : –Open, –Analyzed, –Accepted or Refused, –In progress, –Implemented, –Tested, –Validated, –Closed. –Decisions are made in periodic SCAMG meetings (Service/System Change Approval and Management Group) : In Change Control Review, the SCAMG assesses the analyzed RFCs and schedule them for future and defined releases. In Delivery Readiness Inspection, the SCAMG assesses the RFCs that are already tested and scheduled for the next release. SCAMG Decision in CCR SCAMG Decision in DRI MyOcean PRR, Roma, 2011 April 29 th

Marine Core Service Change Management is organized Change Manager SCAMG chairwoman (WP2.2) Change Manager SCAMG chairwoman (WP2.2) System Change Manager (WP2.1) System Change Manager (WP2.1) Products Change Manager (WP17) Products Change Manager (WP17) IT Infrastructure Change Manager (WP16) IT Infrastructure Change Manager (WP16) + SCAMG members Product Managers & Contributors Product Managers & Contributors System Development Teams System Development Teams Service Managers & Contributors Service Managers & Contributors Users Project Managers, Stakeholders Project Managers, Stakeholders System RFCs (tooled) Products RFCs (tooled) + Service Desk(s) IT Infrastructure RFCs (tooled) RFCs (MSWord Form) RFCs (MSWord Form) Answers +Engineering, PMO + Catalogue Managers Consistency Routing MyOcean PRR, Roma, 2011 April 29 th Members : Permanent members, 3 co chairs: Simon (WP2.2), Joël (WP2.1), Michèle (WP1) Change managers (MyOcean Change Manager, system, products, IT services) On demand : QUARG, experts (PCs, sub-systems)

Marine Core Service Changes are under control and monitored Necessary automation to share and update RFC information : Jira Currently 78 RFCs by type by status by assignee by filtering criteria MyOcean PRR, Roma, 2011 April 29 th

Marine Core Service RFC (sample) MyOcean PRR, Roma, 2011 April 29 th

Marine Core Service RFC (sample, continued) MyOcean PRR, Roma, 2011 April 29 th

Marine Core Service RFC (sample, continued) – edition mode MyOcean PRR, Roma, 2011 April 29 th