Sharing IT Best Practices with youSharing IT Best Practices with you
Randvoorwaarden
Voor de succesvolle afronding van projecten en sprints spelen vele aspecten een rol. Een goede start, met de juiste project/sprint randvoorwaarden, is echter van het grootste belang omdat eenmaal verkeerd begonnen projecten maar moeilijk weer op het goede spoor komen. Als bepaalde zaken onduidelijk zijn en blijven zweven kan een project verzanden in discussies en tot hoge kosten leiden.
Een randvoorwaarde is een voorwaarde waaraan moet zijn voldaan voordat andere dingen kunnen gebeuren of worden gedaan. Bovendien moeten deze acties op een bepaalde manier gebeuren. Project of sprint randvoorwaarden kunnen betrekking hebben op apparatuur, ontwikkeltools, kennis en vaardigheden of budget. Er is een groot scala aan randvoorwaarden voor projecten denkbaar. Uitgangspunt is dat ze vooraf zijn geregeld.
Dit artikel gaat er vanuit dat bovengenoemde zaken al zijn geregeld en de opdrachtgever op het punt staat om een projectleider aan te stellen. We gaan nu dieper in op de randvoorwaarden die de opdrachtgever verder moet regelen voor hij het project of de sprint start.
Randvoorwaarden zijn voorwaarden waaraan we moeten voldoen voordat we een project of een sprint kunnen starten. Vervolgacties daarentegen, zijn gebeurtenissen die worden gegenereerd, zoals werkopdrachten die we maken tijdens de uitvoering.
Per rol in een project of scrumteam kunnen we verschillende randvoorwaarden en vervolgacties stellen. Sterker nog, voor alle rollen moeten we een randvoorwaarde of vervolgactie kunnen opstellen. We kunnen ook bedenken dat een randvoorwaarde of vervolgactie alleen van toepassing is op een specifieke fase of iteratie. Bovendien gelden randvoorwaarden en vervolgacties altijd.
SCRUM-project, we horen deze term vaak, maar het is eigenlijk een vreemd woord want in SCRUM kennen we helemaal het begrip “project” niet. Feitelijk zijn de sprints binnen scrum op zichzelf staande projectjes die we achter elkaar afronden. Maar als een sprint het equivalent van een project is, zijn dan dezelfde randvoorwaarden van toepassing?
Over de vraag of we een pauze moeten nemen tussen de sprints zijn de meningen verdeeld. We moeten echter wel checken of aan de randvoorwaarden is voldaan voor we starten. Als niet aan de randvoorwaarden is voldaan moeten we ons haasten om dit te regelen voor de sprint start.
We kijken nu eerst naar de randvoorwaarden voor traditionele projecten daarna kijken we of de randvoorwaarden voor sprints hiermee overeenkomen.
Randvoorwaarden kunnen we ook zien als kritische succesfactoren die dus bepalend zijn voor het slagen van een project. Probleem hierbij is dat de invulling van de randvoorwaarden niet voor ieder project hetzelfde is maar van project tot project kan verschillen. Voor de aanvang van een project dienen we daarom de invulling van randvoorwaarden in de opdracht te beschrijven zodat deze deel uitmaken van het project. Van belang is dat we een project pas starten nadat deze 8 randvoorwaarden zijn ingevuld.
Een project moet een duidelijke, herkenbare naam hebben zodat iedere betrokkene weet waar het over gaat. Als we meerdere projecten voor één informatiesysteem definiëren dienen projectnaam en informatiesysteemnaam (=applicatienaam) ook duidelijk van elkaar te verschillen. Projectverantwoordelijke: De opdrachtgever.
Duidelijk moet zijn wie de opdrachtgever is en welk mandaat hij of zij heeft. In veel gevallen zal de opdrachtgever ook de toekomstige applicatie-eigenaar zijn. Het moet dus iemand zijn die een direct belang heeft bij het welslagen van het project; zijn commitment is van vitaal belang. Het is niet raadzaam om een team als opdrachtgever aan te stellen. Men kan zich achter elkaar gaan verschuilen terwijl bij spoedeisende vragen eerst het team bijeen moet komen voordat we beslissingen kunnen nemen. De opdrachtgever is naast applicatie-eigenaar budgethouder en kan dus capaciteit vrij (laten) maken voor projecten. Projectverantwoordelijke: De opdrachtgever.
De opdrachtgever wijst de projectleider aan en die trekt het project binnen de randvoorwaarden en planning. Problemen, voortgangsrapportages en mijlpaalproducten koppelt de projectleider terug aan de opdrachtgever waarop deze sturend kan optreden. Als de businessunit waarvoor de automatisering plaatsvindt in staat is om een goede kandidaat te leveren, dan heeft dit de voorkeur. Ook deze persoon heeft een sterk persoonlijk belang bij het welslagen van het project. Zijn commitment bevordert de acceptatie van de producten binnen de business unit. Projectverantwoordelijke: De opdrachtgever.
De medewerking van de juiste personen in de vorm van materiedeskundigen, de leverancier en adviseurs verzekeren het succes van het project. Met name medewerkers die slechts ten dele zijn vrijgesteld om aan een project mee te werken kunnen echter problemen bij hun activiteiten ondervinden. Vooraf zullen we duidelijke afspraken met hun lijnmanagers moeten maken over hun inzet. Hoe de samenstelling van het projectteam tot stand komt kan variëren, het is aan te bevelen dit door de projectleider te laten doen. Deze kiest dan de mensen die naar zijn mening de meeste expertise hebben en het beste met elkaar kunnen samenwerken. Projectverantwoordelijke: De projectleider.
Het stellen van een duidelijk doel van het project is waarschijnlijk het meest essentiële aspect van de te stellen project randvoorwaarden. In een aantal korte zinnen dienen we aan te geven wat aan het einde van het project moet zijn bereikt. Als de doelstelling nog vaag is kunnen we beter een apart project opstarten in de vorm van een vooronderzoek om de doelstelling duidelijk te krijgen. Het mikken op een stilstaand doel is tenslotte eenvoudiger dan mikken op een bewegend doel. Projectverantwoordelijke: De opdrachtgever.
In de opdracht moeten we heel duidelijk stellen welke onderdelen het project bevat en welke activiteiten met welke diepgang moeten worden uitgevoerd. We moeten vaststellen welke onderdelen uitdrukkelijk niet tot het project behoren. Daarbij komt tevens vast te liggen hoe men de randgebieden in het project gaat oppakken zodat er in ieder geval een aansluiting is met de ‘buitenwereld’ van het project. Begrenzingen liggen ook aan de beperking van de toe te passen technieken, platforms en procedures. Projectverantwoordelijke: De opdrachtgever.
Projecten kunnen we voor verschillende situaties opstarten. In het ene geval spreken we van een klein project zonder al te grote risico’s voor een klein aantal gebruikers, in een ander geval zal er sprake zijn van een groot project met grote financiële risico’s. Bij aanvang van het project dient de classificatie duidelijk te zijn zodat we medewerkers van het juiste kaliber kunnen inzetten. Projectverantwoordelijke: De projectmanager.
We moeten voorkomen dat we een vage einddatum voor een project stellen. Bij een vage einddatum bestaat het risico dat links en rechts uitstapjes worden gemaakt, terwijl de interesse voor de hoofdlijn verloren gaat. Het stellen van een duidelijk einddatum heeft meestal direct gevolgen voor de begrenzing van het project. De bekende projectdriehoek moet immers in balans zijn. Bij zeer urgente problemen dan wel grote projecten is het aan te raden om het project in meerdere deelprojecten op te delen, zodat zo vroeg mogelijk van de resultaten geprofiteerd kan worden. Dit vergt wel meer van de kwalificatie van de project(leider)-medewerkers; de aansluiting tussen de verschillende delen moeten we immers waarborgen, bij grote projecten zo nodig door een hoofdprojectleider of projectmanager. Projectverantwoordelijke: De projectmanager.
Een sprint is van aard anders dan een project en kent een andere aanpak. Voor sprints gelden echter vergelijkbare randvoorwaarden. Deze zijn als volgt ingevuld:
Een sprint identificeren we meestal met behulp van een sprintnummer. Bijvoorbeeld 21-11-2. Dan weten we dat het gaat over de tweede sprint in de maand november van 2021. Dat is wel handig want als er bugs in de software blijken te zitten weten we meteen sinds wanneer deze bugs er in zaten. Dan weten ook hoe ver we terug moeten kijken om bijvoorbeeld data te herstellen. Daarnaast is het ook handig om de sprint een naam te geven. Dat spreekt meer tot de verbeelding en weten we vaak meteen welke functionaliteit in die sprint gerealiseerd is. Sprintverantwoordelijke: Het scrum-team.
Daar is in scrum geen twijfel over mogelijk, dat is de Product-owner. Hij of zij heeft het mandaat om knopen door te hakken en vertegenwoordigt de opdrachtgever. De productowner is ook onderdeel van het scrumteam. Het is de bedoeling dat het scrumteam in stand blijft tot dat de product backlog is weggewerkt. Op die manier raakt het gehele team op elkaar ingewerkt en gaat het de sprints steeds gemakkelijker af. Binnen scrum kennen we geen budget maar een hoeveelheid gewenste functionaliteit. We zijn klaar met de applicatie als iedereen het daar overeens is. Budget kan daarbij ook een grote rol spelen. Sprintverantwoordelijke: De productowner.
Binnen scrum is het gehele team verantwoordelijk voor de sprint, een traditionele projecteider kennen we niet. De scrummaster is echter het teamlid dat verantwoordelijk is voor de invulling van de randvoorwaarden en planning. Deze zorgt ervoor dat er zo min mogelijk belemmeringen zijn voor de realisaties. Organisatorische storingen, voortgang en standups zijn de issues waar de scrummaster zich mee bezig houdt. Projectverantwoordelijke: De scrummaster.
De medewerking van de productowner als materiedeskundige verzekert het succes van de sprint. Hoe de samenstelling van het scrumteam is in principe stabiel. Door verandering van werkgever of ziekte kan de samenstelling van een team wel veranderen, maar het is de bedoeling dat het team goed op elkaar is ingewerkt. Scrumteams verhuizen daarom vaak als geheel van de ene klus naar de andere. Sprintverantwoordelijke: De IT-organisatie.
Een sprint bestaat over het algemeen uit een aantal backlog items die op dat moment het meeste rendement opleveren voor de organisatie. Dit hangt natuurlijk af van de behoeften van de gebruikers, maar ook van de voorafgaande sprints. Daar bouwen we op voort. Anders dan bij de selectie van standaard software zoals SaaS kennen we bij sprints dus weinig problemen het het bepalen van de juiste projectscope. Het is echter wel van belang dat we de backlog items goed definiëren. Het succes van een sprint is daarom vooral afhankelijk van goed geformuleerde userstories, requirements en acceptatiecriteria. Projectverantwoordelijke: Het scrumteam.
De sprints in scrum zijn een implementatie wat we in de IT timeboxing noemen. Met andere woorden: we spreken een vaste duur van een sprint af, bijvoorbeeld 4 weken. Binnen die tijd leveren we werkende functionaliteit op. Alle geselecteerde backlog items die we niet binnen die tijd konden realiseren plaatsen we weer terug in de product backlog. Naarmate scrumteam langer met elkaar samen werkt, wordt het steeds beter om een sprint samen te stellen en af te ronden binnen de tijd. Projectverantwoordelijke: Het scrumteam.
Zoals gezegd hebben sprints allemaal een vaste lengte. Het financiële risico lijkt dan ook voor iedere sprint even groot. Alleen de projectrisico’s kunnen wel per sprint verschillen omdat de te realiseren functionaliteit nu eenmaal verschilt. Ook de impact van de nieuwe software kan erg groot zijn. Soms hangt het voortbestaan van de organisatie af van de software of de implementatie van nieuwe wetgeving. Bij de initiatie van het ontwikkeltraject dient de classificatie duidelijk te zijn zodat we een scrumteam van het juiste kaliber kunnen inzetten. Projectverantwoordelijke: De productowner.
Omdat niet alle backlog items bij de start worden uitgewerkt is dit een van de weinige nadelen van scrum. Het ontwikkeltraject is klaar als de organisatie zegt dat de software naar tevredenheid werkt. We kunnen natuurlijk wel een deadline stellen en kijken hoe ver we dan zijn. We lopen dan echter wel het risico dat de software nog niet af is en het traject moeten verlengen. De deadline voor een sprint is echter altijd duidelijk. Projectverantwoordelijke: De productowner.
Zowel bij sprints als projecten kunnen we alle randvoorwaarden goed invullen voor we starten. Omdat scrumteams niet vaak wisselen en scrum als methode vast is omlijnd, is dat eenvoudiger voor sprints. Veel randvoorwaarden zijn bij sprints immers al intrinsiek ingevuld.
Het is mogelijk dat voor de aanvang van een sprint of project nog niet alle acht randvoorwaarden volledig zijn ingevuld. Bij de start moet dan wel duidelijk zijn welke risico’s we ten aanzien van deze onduidelijkheid lopen. Met name een verkeerde inschatting van de classificatie heeft gevolgen voor alle overige randvoorwaarden van het traject waardoor grote onzekerheden ontstaan.
Discussieer mee op LinkedIn.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.