Transcript Flexibeler omgaan met de project cycle in een

VNSG Magazine | december 2016
Flexibeler omgaan met de project cycle in een implementation
project
Een tip om een issue waar ChaRM gebruikers in de praktijk tegenaan kunnen lopen, te omzeilen.
Zoals we allemaal weten kan je een maintenance cycle in een maintenance project op completed
zetten en opnieuw genereren. Dit gebeurt op de georkestreerde momenten maar ook tussentijds als je
bijvoorbeeld Logical Components wil aanpassen. Je maakt dan een nieuwe takenlijst.
Echter het kan ook gebeuren dat je voor de project cycle in een implementation project ook
tussentijds de takenlijst wil aanpassen. Dus nog voordat het project live is. Als je de standaard hebt
gevolgd stuit je dan op een muur. Er zitten errors ingebouwd die het afsluiten van je cycle
tegenhouden. De actie om de cycle een fase verder te zetten is standaard niet beschikbaar. In deze
tip lees je hoe je dit kunt oplossen.
Waarom?
De onderliggende change documenten hebben nog niet de vereiste status bereikt. Ze zijn bijvoorbeeld
nog In Development, het project is immers nog niet live.
Dit komt door de volgende instelling:
VNSG Magazine | december 2016
en die kan je hier vinden:
Lessons learned:
 Als je de errors omzet naar warnings kan je de project cycle wel tussentijds afsluiten en
opnieuw genereren. De errors in de project cycle zijn eigenlijk te star. De wens om de project
cycle te wijzigen kan ook opkomen in the heat of the kitchen en dan kan het opeens een hot
issue zijn en slecht voor de beeldvorming van ChaRM.
 In de maintenance cycle heb je vergelijkbare checks en daar zijn het ook warnings.
 Nadeel: de wijze waarop de warnings worden gepresenteerd bij het verzetten van de fase van
de cycle is niet erg gebruiksvriendelijk. Je ziet ze in de smalle strook boven het status
overview. De kans is groot de gebruikers die de fase verzetten deze warnings niet zien of
negeren. Daar moet men dus alert op zijn.
 Het ligt er natuurlijk aan wat de gebruiker wil met de cycle. Voor sommigen zijn de errors in de
project cycle wenselijk. De wijze waarop het systeem moet reageren moet je eerst goed
afstemmen.
 Als je de errors in de project cycle omzet naar warnings zijn er bijna geen verschillen meer
tussen de cycle in een implementation project en een maintenance project. Behalve dan de
naam.
Voor meer informatie kunt u contact opnemen met Hans van der Horst,
[email protected]