Koppelingen

Wijzigingsverzoek

https://vzvz.atlassian.net/browse/MO-30

Gekoppelde onderwerpen

Inleiding

Huidige situatie:

Twee keer per jaar (in week 18 en week 44) vindt een release voor afsprakenstelsel van MedMij plaats. In de huidige situatie wordt gewerkt met het dakpanmodel. Het dakpanmodel houdt in dat op het releasemoment altijd twee releases van het afsprakenstelsel worden gepubliceerd, namelijk één optionele en één verplichte versie. Bij het volgende release moment wordt:

de verplichte versie ingetrokken,
de optionele release wordt verplicht en
de nieuwe optionele versie wordt gepubliceerd.

Op dit moment zijn dat de versies 1.5.1 en 1.6.0, waarbij versie 1.5.1 voor alle deelnemers verplicht is en 1.6.0. de optionele versie is.

Voorafgaand aan het release moment wordt bepaald welke onderwerpen in de volgende release moeten worden verwerkt.

Probleem

We kunnen binnen het afsprakenstelsel onvoldoende snel inspringen op de veranderende vraag uit de praktijk, doordat:

slechts twee keer per jaar een release plaats vindt,
dat een een halfjaar van tevoren vast ligt wat wordt opgenomen in het afsprakenstelsel en
dat nu het release moment de ontwikkelplanning bepaalt

deze punten er gezamenlijk voor zorgen dat wij anderhalf jaar tot een jaar van tevoren al vastleggen wat er gewijzigd gaat worden.

Ten gevolge hiervan treden verschillende kleinere problemen op namelijk:

Nu worden wijzigingen die alsnog op korte termijn buiten de twee releasemomenten doorgevoerd moeten worden doorgevoerd als correcties, terwijl dit eigenlijk geen correcties zijn.
Op de vaste releasemomenten moeten zoveel mogelijk onderwerpen doorgevoerd worden.
Als er geen onderwerpen zijn om te releasen dan kunnen we alleen óf de optionele versie verplicht maken en geen wijzigingen doorvoeren voor de nieuwe optionele versie óf de release kan worden uitgesteld.
Zijn de geplande onderwerpen niet op tijd uitgewerkt voor het volgende release moment, dan kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en pas een jaar later verplicht gesteld, dit is onwenselijk omdat:
1. het voor bepaalde onderwerpen belangrijk is om deze op korte termijn op te nemen in het afsprakenstelsel. Als deze onderwerpen dus niet tijdens het geplande releasemoment gepubliceerd worden dan betekent dat een vertraging van minimaal een halfjaar.
2. het de betrouwbaarheid van MedMij richting de deelnemers kan ondermijnen. Als wij beloven bepaalde stukken op te nemen in de optionele versie van het afsprakenstelsel en vervolgens leveren wij dit niet op dan kan dat de relatie van MedMij met de deelnemers schaden.
Deelnemers geven aan dat de termijn van een halfjaar tussen het opnemen in de optionele en het opnemen in de verplichte versie te kort is om impactvolle wijzigingen in het afsprakenstelsel door te voeren.

Probleemstelling

Hoe kunnen wij de huidige wijze van release cycle management aanpakken zodat we beter kunnen inspringen op de continue veranderende vraag uit het dynamische Zorg ICT Landschap en MedMij zelf?

Doel:

Door het release cycle management aan te pakken willen we meer flexibiliteit introduceren bij het releasen van minors en patches en meer rekening houden met de implementatietijd van stakeholders voor majors.

Subdoelen

Deelnemers en MedMij medewerkers meer gestructureerd meenemen in de analyses en uitwerkingen van onderwerpen.
Pas de opname in het afsprakenstelsel plannen als het onderwerp al is uitgewerkt en daarmee de betrouwbaarheid richting deelnemers verhogen.

Aannames

De gekozen nieuwe release cycle wordt ondersteunt door de (nieuwe manier van) versioning die nu wordt uitgewerkt.
Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.

Definities

Om verwarring rondom de gebruikte definities te voorkomen wordt in deze paragraaf toegelicht welke termen gebruikt worden en welke definities eraan hangen.

Werkwoord	Moment	Omgeving
Opnemen	Release (moment)	MM Verplicht	Verplichte versie
Opnemen	Release (moment)	MM Optioneel	Release candidate
Publiceren	Publicatie moment	Changemanagement	Uitgewerkt(e wijzigingen)

Voorbeeld:

Tijdens de release wordt een wijziging opgenomen in de MM Verplicht of MM Optioneel
Tijdens het publicatiemoment wordt een wijziging gepubliceerd in de MM Uitgewerkt

Term	Definitie
Wijzigingen	Dit zijn onderwerpen die zijn uitgewerkt door MedMij Ontwikkeling om aan het afsprakenstelsel toe te voegen, om het afsprakenstelsel aan te passen of zelfs stukken uit het afsprakenstelsel verwijderen.
Patches	Kleine wijzigingen die geen invloed hebben op de functionaliteit en wel backwardscompatible zijn.
Minors	Wijzigingen die wel invloed hebben op de functionaliteit en die wel backwardscompatible zijn. Geven interne en/of externe stakeholders aan dat de impact van een minor wel dusdanig groot is dat deze voor hen niet backwardscompatible is dan wordt deze wijziging alsnog als een major geclassificeerd.
Majors	Wijzigingen die wel invloed hebben op de functionaliteit en die niet backwards compatible zijn.
Verplichte versie	Dit is de versie waarop geaccepteerd wordt, oftewel de versie waaraan de deelnemers moeten voldoen. Deze wordt gepubliceerd in de MM Verplicht omgeving.
Release Candidate	Dit is de versie van het afsprakenstelsel die verplicht wordt tijdens het volgende Major Release moment. Een nieuwe release candidate wordt alleen gecreëerd bij major wijzigingen.
MM Optioneel	Dit is de omgeving waar de release candidate zichtbaar is voor deelnemers. Deelnemers kunnen gaan ontwikkelen en mogen nu endpoints aangaan met de R&A.
Changemanagement de pagina Uitgewerkt	Deze pagina bevat een overzicht van alle gepubliceerde wijzigingen voor het afsprakenstelsel die nog niet zijn opgenomen in MM Optioneel en/of MM Verplicht. Als de release data van de wijzigingsstukken bekend zijn dan worden deze hier ook weergegeven.
Uitgewerkt(e wijzigingen)	Dit is de huidige versie met alle gepubliceerde wijzigingen voor het afsprakenstelsel die nog niet zijn opgenomen in MM Optioneel en/of MM Verplicht. Deelnemers kunnen deze wijzigingsstukken inzien en alvast gaan ontwikkelen, maar mogen pas R&A endpoints aangaan na de release van het stuk.
Release (moment)	Tijdens het release moment kunnen wijzigingen worden opgenomen in de MM Verplicht en/of MM optioneel. Er zijn 12 release momenten in een jaar, waarvan er 2 vaste major release momenten zijn.
Major Release moment	Dit zijn de 2 release momenten waar Majors en Minors opgenomen kunnen worden in de MM Verplicht en MM optioneel. Deze momenten vinden plaats op de dinsdag in week 18 en 44, vallen deze data op een feestdag dan wordt de release op een andere dag gepland.

Gewenste situatie

Voor de gewenste situatie willen wij:

Meer publicatie- en releasemomenten per jaar mogelijk maken om zo de flexibiliteit omtrent de releases van minors en patches verhogen.
Meer regie voor stakeholders door ze inspraak te geven in de planning wanneer de uitgewerkte onderwerpen worden opgenomen in het afsprakenstelsel.
Dat de wijzigingen aan in het release cycle management niet de processen van de R&A te veel verstoord.

Usecase

De nieuwe wijze van release cycle management gaat als volgt in zijn werk.

Tijdens het uitwerken van een wijzigingsstuk worden al de (interne) stakeholders betrokken op wie deze wijziging invloed gaat hebben, zodat zij alvast hun input kunnen leveren.
Wanneer een stuk is uitgewerkt wordt deze besproken in de maandelijkse voorbespreking (1e dinsdag vd maand). Hier wordt besproken of de RFC gepubliceerd mag worden, wanneer o.a. acceptatie, ketenregie en R&A verwachten de wijzigingen in hun processen doorgevoerd. Deze duur wordt gebruikt om onze voorkeursreleasemomenten te bepalen.
Wanneer een stuk een oke heeft vanuit de voorbespreking dan wordt deze op de 2e dinsdag van de maand gepubliceerd in MM Uitgewerkt. Vanaf dit moment kunnen deelnemers gaan ontwikkelen, wijzigingen live zetten, endpoints klaarzetten maar mogen deze endpoints nog niet aangaan met de R&A.
Tijdens het Wijziging overleg wordt bepaald wanneer de wijzigingen worden opgenomen in MM Optioneel en eventueel ook releasemoment voor MM Verplicht.
Na opname in de MM Optioneel mogen deelnemers daadwerkelijk endpoints aangaan met de R&A.
Na opname in de MM Verplicht moeten deelnemers aan deze wijzigingen voldoen en worden ze hierop ook geaccepteerd.

Oplossingsrichting

Vraagstuk	Keuze	Toelichting	Voordeel	Nadeel
Publicatie frequentie Patches & Minors & Majors	Maandelijks	Elke tweede dinsdag van de maand is er een publicatie moment waarop we alle uitgewerkte wijzigingsstukken in MM Uitgewerkt publiceren. Zijn er geen uitgewerkte stukken dan wordt er niets gepubliceerd.	Doordat uitgewerkte wijzigingen sneller gepubliceerd worden kunnen wijzigingen op kortere termijn worden opgenomen in de MM optioneel en daardoor ook de MM Verplicht . Deelnemers krijgen meer ontwikkeltijd. Door maandelijks een publicatiemoment beschikbaar te hebben kan een afgerond onderwerp direct gepubliceerd worden en kunnen deelnemers eerder zien welke onderwerpen eraan komen. Waardoor deelnemers al kunnen beginnen met ontwikkelen, testen en deze alvast klaarzetten om endpoint aan te gaan met de R&A. Deelnemers hebben tijd om te bepalen hoeveel ontwikkeltijd zijzelf nodig hebben en kunnen invloed uitoefenen op keuze voor het release moment. Door te publiceren wanneer de stukken zijn uitgewerkt kunnen deelnemers zien welke stukken er nog meer aankomen en aan de hand daarvan hun planningen bijsturen.	Voor stakeholders kan het verwarrend zijn dat er meerdere wijzigingen in MM Uitgewerkt staan met iedere een eigen releasedatum.
Publiceren Wijzigingsstukken voor opname in MM Optioneel?	Ja, in MM Uitgewerkt	In het openbare deel van de 'MedMij Afsprakenstelsel Changement' omgeving komt de confluence pagina 'MM Uitgewerkt' te staan. Hier staat dan een tabel met een overzicht van alle uitgewerkte wijzigingsstukken met de volgende informatie: MO-nummer en titel Korte samenvatting Link naar de volledige uitwerking Indien bepaald, het geplande release moment Onder MM Uitgewerkt staan de uitgewerkte wijzigingen. Deze uitwerkingen zijn inzichtelijk voor alle deelnemers.
Behoud optionele versie	Ja	De processen voor R&A beheer en release cycle management zijn nauw verweven. De inrichting van de R&A is namelijk gebaseerd op het dakpanmodel. Je kan het dakpanmodel dus niet loslaten zonder de R&A opnieuw te moeten in te richten. In eerste instantie wordt het release cyclemanagement wel gewijzigd, maar blijft het dakpanmodel wel behouden. Op een later moment wordt geëvalueerd of herinrichting van de R&A en verder herstructureren van het release cycle management wenselijk is en zo ja hoe dit wordt vormgegeven.	Het kan onduidelijk zijn voor deelnemers welke minors en majors wanneer verplicht worden.	Door geen optionele versie te hanteren is het mogelijk op korte termijn aanpassingen door te voeren voor de verplichte versie.
Voorbespreking	Maandelijks	De voorbespreking is intern. Uitgenodigd zijn ten minste: Product manager MM ontwikkeling MM Ketenregie MM Acceptatie Stichting MM NICTIZ R&A Agenda: Door te voeren wijzigingen Toelichting het wijziging Classificatie v.d. wijziging bepalen o.b.v.: - of het de uitwisseling beïnvloedt - of het de functionaliteit beïnvloedt - de impact op MedMij intern, bijv. op ketenregie, acceptatie en het loket - de impact van de aanpassing voor deelnemers - de impact van de aanpassing op de keten In hoeverre het onderwerp samenhangt met andere (nog uit te werken) wijzigingen. Hoeveel implementatietijd stakeholders nodig hebben. Hoe vast we willen houden aan deze tijdslijn in het wijziging overleg. Uit te faseren functionaliteiten Impact stakeholders en keten Gewenste duur voor uitfasering (incl. hoe strikt wij hierin zijn Evaluatie releaseplanning Is er overeenstemming bereikt over de stukken dan worden deze gepubliceerd op pagina "Uitgewerkt".	Tijdens de voorbespreking bepalen wij hoelang interne stakeholders nodig hebben om de wijzigingen te implementeren in hun processen. Door deelnemers pas na de Vanaf Datum voor Acceptatie endpoints met de R&A aan te laten gaan hebben VZVZ, Stichting MM en Nictiz tijd om hun processen aan te passen, kunnen deelnemers alvast gaan ontwikkelen en hoeven niet alle deelnemers op hetzelfde moment endpoints met de R&A aan te gaan. De voorbespreking wordt ook gebruikt om te bepalen wanneer wijzelf de wijziging in het afsprakenstelsel willen opnemen en hoe strikt wij vasthouden aan deze deadline. Doen wij dit niet dan is er het risico dat we onderwerpen te laat opnemen in het afsprakenstelsel terwijl dat niet wenselijk is of dat we te stevig vasthouden aan deadlines voor kleine aanpassingen.	Het vergt tijd van de deelnemers van VZVZ en er zijn al veel standaard overleggen.
Wijziging Overleg	Bij voorkeur 4x per jaar, maar voorlopig in lijn met de geplande expertsessies	Bij het wijziging overleg wordt samen met alle stakeholders voor de minors en majors bepaald tijdens welk release moment de wijziging wordt opgenomen in het afsprakenstelsel. Deze overleggen vinden sowieso plaats één maand voor het major release moment. Bij voorkeur vinden de wijziging overleggen eens in de 3 maanden plaats doordat deze overleggen worden gecombineerd met de expert sessies deze vindt het wijziging overleg niet plaats in de zomer. Uitgenodigd zijn: ZN VWS NICTIZ MM beheer (productmanager, MM ontwikkeling) Stichting MM DVA's DVP's Tijdens het stakeholder overleg worden de volgende punten besproken: Update backlog items Toelichting uitgewerkte wijzigingen en gezamenlijk per onderwerp het releasemoment bepalen. Evaluatie huidige release planning & vaststellen release candidate Bepalen v.d. uitfaseringtermijn voor de te verwijderen functionaliteiten Evaluatie releaseplanning en vaststellen release candidate
Creëren nieuwe release candidate	Alleen bij majors	Is er een major wijziging uitgewerkt en willen we deze opnemen in de verplichte versie dan moet deze eerst 6 maanden in de release candidate staan. Alleen majors leiden tot nieuwe release candidates. Bij nieuwe minors en patches gaat de nummering van de huidige release candidate wel gewoon door.
Wanneer release candidate vaststellen voor release	Minimaal 1 maand voor het Major Releasemoment	Eén maand voor het Major release moment wordt de release candidate voor de volgende release vastgesteld om een maand later te worden opgenomen als de release candidate in de MM Optioneel omgeving.	Het kan zijn dat de implementatietijd wordt onderschat, waardoor de wijzigingen te vroeg worden opgenomen in het Afsprakenstelsel wat problemen kan veroorzaken. Om dit risico te mitigeren zijn in de voorbespreking en stakeholder overleggen ook evaluaties ingepland.	Door voor wijzigingen geen minimumduur te hanteren tussen het stakeholderoverleg en het opnemen in het afsprakenstelsel is er meer vrijheid om te bepalen welke wijzigingen wanneer accepteerbaar zijn. Hierdoor kunnen minors en majors die weinig impact hebben op deelnemers maar die wel essentieel zijn voor een betere uitwisseling eerder doorgevoerd kunnen worden.
Releasemoment a. Patches b. Minors c. Major	a. Patches 1x p.m. b. Minors 2x p.j in overleg met stakeholders kan opname ook buiten de twee releasemomenten. c. Majors 2x p.j., tenzij het wegens een wetswijziging of security risico het vereist is om buiten de releasemomenten de Major in het Afsprakenstelsel op te nemen.	Patches kunnen 12x per jaar opgenomen worden in de release candidate en de verplichte versie. Minors worden in principe alleen opgenomen op de twee major release momenten per jaar. In overleg met de stakeholders kan hiervan worden afgeweken en kan er tussentijds een minor release op de verplichte versie plaatsvinden. Majors worden ook twee keer per jaar doorgevoerd, tenzij er noodzaak is om de wijziging tussentijds door te voeren bijvoorbeeld een wetswijziging of een security risico.	a. De verwachting is dat patches weinig invloed hebben op de stakeholders en dat planning van het releasemoment voor de patch onnodig is. Door de releasemomenten voor patches maandelijks te laten plaatsvinden is het mogelijk om kleine veranderingen op korte termijn door te voeren. b. In principe worden minors doorgevoerd tijdens de tweejaarlijkse releasemomenten. In overleg met stakeholders kunnen de wijzigingen ook tijdens de patch releasemomenten worden opgenomen in het Afsprakenstelsel. Zo is er duidelijkheid voor alle stakeholders maar is de optie er om indien nodig op korte termijn wijzigingen door te voeren. c. In principe hebben majors twee keer per jaar releasemomenten. Indien noodzakelijk kunnen majors eerder verplicht worden gesteld. Het voordeel hiervan is dat het wel duidelijkheid creëert voor stakeholders, maar dat we nog wel op korte termijn noodzakelijke wijzigingen door kunnen voeren.	1. Als we teveel tijd en middelen vragen van deelnemers dan kan dit leiden tot een afname in draagvlak onder deelnemers. 2. In deze oplossingsrichting kan de mogelijkheid in flexibiliteit in het verplichtstellingsmoment tot verwarring leiden over welke onderwerpen wanneer verplicht worden.

Als over de bovenstaande punten duidelijkheid bestaat en willen we het onderwerp pre-releasen op het eerst volgende pre- release moment dan wordt één week later het onderwerp gepubliceerd.
In het driemaandelijks stakeholderoverleg wordt gezamenlijk bepaald wanneer we de minors en majors uit de pre-release verplicht willen laten worden.

Vervolgens wordt de uitwerking van het onderwerp gepubliceerd als een pre-release stuk, waarbij:

Patches bij publicatie direct worden opgenomen in het afsprakenstelsel.
voor Minors tijdens de voorbespreking en het stakeholderoverleg wordt besproken op welke termijn deze verplicht moet wordt. Stel we kiezen het eerst volgende verplichtingsmoment, dan zou het onderwerp een maand later tegelijkertijd met de pre-release verplicht gesteld worden. De minor dient in principe binnen twee verplichtstellingsmomenten verplicht gesteld worden, wel kan in samenspraak met stakeholders hiervan worden afgeweken.
voor Major in de voorbespreking en het stakeholderoverleg wordt besproken tijdens welk verplichtstellingsmoment de major worden opgenomen in het afsprakenstelsel. Stakeholders mogen niet oneindig majors uitstellen. In principe worden majors verplicht gesteld tijdens de verplichtstellingsmomenten, hiervan kan worden afgeweken mits er een gedegen reden hiervoor is (bijv. i.v.m. security redenen of een wijziging in wetgeving) of als minimaal 70% van alle aanwezige stakeholders en deelnemers hiermee instemt.

Stakeholders kunnen deze stukken lezen en bepalen of ze willen aansluiten bij het stakeholder overleg.

Punten ter verduidelijking:

De stakeholders krijgen dus inspraak in wanneer onderwerpen worden opgenomen in het afsprakenstelsel, hier zit wel een grens aan. De inspraak van de stakeholders is wel dusdanig beperkt dat ze de opname van het stuk in het afsprakenstelsel niet oneindig uit kunnen stellen.
Deelname aan het stakeholder overleg is facultatief. Stakeholders hebben vooraf inzicht in de agenda en de pre-release stukken, waardoor ze zelf kunnen bepalen of ze wel of niet aanwezig willen zijn bij het overleg. Om te worden meegenomen in het stakeholder overleg moeten de stukken minimaal 1 week van tevoren gepubliceerd zijn.
Het feit dat pre-release momenten en verplichtstellingsmomenten beschikbaar zijn betekent niet vanzelfsprekend dat deze ook gebruikt moeten worden.
Als er niets te publiceren is of er binnen het stakeholderoverleg wordt bepaald dat we bij het volgende verplichtstellingsmoment geen onderwerpen verplicht willen stellen dan hoeft dit ook niet.

Uitwerkingen n.a.v. feedback 1-11-22

Loslaten dakpan model

Argumenten voor het afschaffen van dakpanmodel

Bij deze oplossingsrichting is het dakpan model losgelaten, hiervoor is gekozen omdat:

het behouden van het dakpanmodel ervoor zorgt dat de gewonnen flexibiliteit om wijzigingen door te voeren op de korte termijn weer ongedaan maakt,
deelnemers in de huidige situatie geen gebruik maken van de optionele versie, omdat twee versies van hun systeem in de lucht houden teveel geld kost en
ook binnen de rest van VZVZ beperkt gebruik wordt gemaakt van het dakpanmodel

Argumenten voor het behouden van het dakpanmodel

Een voordeel van het dakpanmodel is dat de optionele versie het team acceptatie de kans biedt om hun acceptatieproces aan te passen voor de volgende verplichte versie van het afsprakenstelsel. In deze oplossingsrichting wordt de optionele versie alsnog verwijderd. Om het team acceptatie de tijd te gunnen om de benodigde wijzigingen door te voeren hebben ze tijdens de voorbespreking een belangrijke stem in de planning van het moment van verplichtstelling voor minors en majors.
Het dakpanmodel biedt MedMij en deelnemers de kans om pilots te laten plaatsvinden. Door een optionele versie in de lucht te houden is experimenteren mogelijk zonder dat deelnemers meteen aan deze nieuwe afspraken moeten voldoen en zonder dat ze hierop geaccepteerd worden. Dit zou een valide reden om te overwegen het dakpanmodel te behouden. Echter kunnen wij de mogelijkheid tot het doen van een pilot ook behouden door het schrijven van een addendum aan het hoofdstuk Beleid van het afsprakenstelsel.
een vorm van een bigbang voor minimaal een van de betrokken partijen is niet te voorkomen. Zelfs in de huidige situatie hebben we een bigbang effect. Zouden we de Bigbang in zijn totaliteit willen voorkomen dan moeten dusdanig veel controlemechanismes ingebouwd worden dat we er zelfs op achteruit zouden gaan qua flexibiliteit. Wat ook tegen het streven van afdeling ontwikkeling in zou gaan om juist de flexibiliteit en het beter inspringen op het veranderende zorg IT landschap te vergroten tegen zou gaan.

Ontwikkeltijd nodig voor Acceptatie

De optionele versie bood het team acceptatie de mogelijkheid om de wijzigingen aan het afsprakenstelsel door te voeren in de acceptatieprocessen voordat deze wijzigingen werden opgenomen in de verplichte versie van het afsprakenstelsel. Als de optionele versie weggaat moet het team acceptatie op één of andere manier toch voldoende tijd krijgen om wijzigingen van het afsprakenstelsel te implementeren in het acceptatieproces voor (kandidaat-)deelnemers. Hiermee is omgegaan door de wijzigingen pas te publiceren in de aankomende versie als acceptatie ze heeft doorgevoerd in zijn/haar processen.

Deelnemer ontwikkeltijd

De vraag werd gesteld of deelnemers nog wel genoeg tijd zouden hebben om de wijzigingen door te voeren voordat ze in het afsprakenstelsel worden opgenomen en in hoeverre er rekening wordt gehouden met hun ontwikkeltijd

Volgens ons is met het nieuwe systeem juist beter inzicht hoe het gaat met het ontwikkelproces van deelnemers, doordat de deelnemers meebepalen wanneer de aanpassingen worden opgenomen in het afsprakenstelsel, we regelmatig evalueren met deelnemers hoe het met het implementatieproces gaten dat we bij vertraging de planning aanpassen. Hierdoor krijgen deelnemers een ontwikkelduur die voor hen passend is.

Implementeren nieuwe versies afsprakenstelsel in o.a. R&A

Hoe kan voorkomen worden dat tijdens het opname moment alle deelnemers tegelijkertijd hun wijzigingen willen/moeten doorvoeren waardoor er problemen optreden bij bijvoorbeeld de R&A?
In de tijd tussen de publicatie in de aankomende versie en publicatie in de actuele versie kan R&A alvast de wijzigingen klaar zetten en dat deze wijzigingen pas live worden gezet tijdens de publicatie.

Uitfaseren oude versies afsprakenstelsel

Tijdens het stakeholder overleg wordt voor de uit te faseren optionele functionaliteiten bepaald hoeveel tijd de stakeholders nodig hebben voor uitfasering. De uit te faseren functionaliteit wordt verplaatst naar de extensie en de minimumduur uit het stakeholder overleg wordt gebruikt als einddatum van de de functionaliteit. De periode tussen verplaatsing en beëindiging is de periode van uitfasering.

Openstaande vragen en overdenkingen

Nog nadenken over

Hoe bepalen we of iets een major of minor is?
Wat gaat het effect van de gekozen oplossingsrichting op de R&A zijn

Risico's

Dat niet genoeg stakeholders (m.n. deelnemers) deelnemen aan de overleggen, waardoor we wijzigingen door gaan voeren op korte termijn maar vervolgens blijkt dat het niet mogelijk is en dit voorkomen had kunnen worden als de juiste stakeholders aan tafel hadden gezeten.
In hoeverre zijn wij en de stakeholders goed in staat om te bepalen wat de impact van bepaalde wijzigingen en/of onderwerpen voor deelnemers gaat zijn.
Dat we onvoldoende in kunnen schatten wat de effecten voor acceptatie en ketenregie zijn
Big bangs

MedMij Change Management

20221213 -MO-30, Release Cycle Management