Alle nieuwe ontwikkelingen en methodieken ten spijt. Digitale en IT projecten blijven keer op keer dezelfde fouten maken.
Hieronder de belangrijkste 7 denkfouten:
- Requirement overslaan want dat is waterval
- Opstellen van oplossingsgerichte requirements
- Oplossing baseren op 1 systeem
- Niet plannen want dat is niet agile
- geen externe resources huren om kosten te besparen
- Niet documenteren
- Beheer komt later wel.
Requirements overslaan want dat is waterval.
Het overslaan van de requirements is een van de meest gemaakte fouten in Digitale en IT projecten op dit moment. Hierdoor kunnen veel projecten niet goed inschatten wat er allemaal op hun pad gaat komen en zijn ze veel tijd kwijt aan het agile oplossen van te voorziene problemen.
De 5 belangrijkste denkfouten waarom requirements overgeslagen worden:
1. Requirements worden geassocieerd met de de verfoeide waterval methodiek.
Conclusie vanuit de waterval methodiek is dat requirements alweer achterhaald zijn op het moment dat het project waterval opgelegd zijn. Hierdoor hebben requirements een nare nasmaak gekregen. Terwijl de requirements eigenlijk niet de schuldigen zijn, maar de lange realisatie duur (ontwerp bouw test).
Met Agile werken is de lange realisatie duur opgelost en zouden requirements dus snel gerealiseerd kunnen worden.
Toch kiest men liever voor nog minder detail en neemt men genoegen met “Als x wil ik zus en zo zodat” . zie bijvoorbeeld ook het artikel requirements vs user stories.
2. In het Agile Manifesto wordt gesteld dat de beste manier om informatie te delen F2F is.
Wat natuurlijk helemaal waar is maar niet perse betekent dat je niks meer opschrijft. Immers in complexe projecten blijkt het toch handig te zijn om bepaalde zaken op te schrijven. Want zeg nou zelf hoe efficiënt is het om steeds de zelfde Babylonische discussie te hebben over een non functional requirement, een architectuur principe of een design pattern.
3. Requirements Analyse is duur, Business Analisten zijn schaars, laten we maar snel beginnen.
Wellicht is het goed om je eens af te vragen wat er nu precies duurder is één Business Analist die de juiste vragen stelt waar door duidelijk wordt wat er gemaakt moet worden in welke omstandigheden. Of een heel SCRUM Team dat er na een sprint bouwen achter komt dat wat er gemaakt was niet helemaal de bedoeling is.
Is wel lekker agile natuurlijk.
Mocht je op kort termijn op zoek zijn naar een Business Analist kijk dan eens naar onze Business Analyse as a Service
Opstellen van oplossingsgerichte Requirements
Een ander veel gemaakte denkfout is om requirements/user stories op te stellen op basis van hoe je nu met je systemen werkt. De reden waarom dat onhandig is omdat je dan zeer waarschijnlijk een kopie krijgt van wat je nu hebt in een ander jasje. Met dezelfde issues waarom je je Digitaliserings- of IT project was gestart.
Daarnaast gebeurt het vaak dat gebruikers gaan nadenken over wat mogelijk technisch complex is, meestal gebaseerd op basis van eerdere ervaring met het huidige systeem. Hierdoor nemen ze bij voorbaat genoegen met een minder passende oplossing. Terwijl de gepercipieerde complexiteit mogelijk geen issue was geweest voor het nieuwe systeem.
Tip: Stel je requirements / user stories zo op dat duidelijk is wat je wil bereiken laat voldoende ruimte over voor de leverancier om de beste oplossing te vinden.
Oplossing baseren op 1 systeem.
Presentaties van software leveranciers zijn altijd fantastisch, blits en geniaal, echter een nieuwe software leverancier zal in zijn demo nooit rekening houden met de onmogelijkheden van jouw bestaande applicatie landschap en werkprocessen. Daardoor lijken nieuwe software pakketten altijd alles in een keer op te lossen en is de daadwerkelijke integratie een crime.
Tip: doe voordat je begint een analyse op de werkprocessen en mogelijke systeem integraties zodat je van te voren weet waar je op moet letten en of doe een proof of concept met die systemen.
Niet plannen want dat is niet agile.
Agile wordt vaak gebruikt als excuus om niet te hoeven plannen, immers er is geen projectmanager en de Product Owner bepaalt samen met het team wat er in een 2/3 wekelijkse sprints gerealiseerd kan worden.
Toch kan een planning wel zinvol zijn op het moment dat het Scrum Team afhankelijk is van externe factoren. Externe factoren die niet door het Scrum Team zelf beïnvloed kunnen worden zoals bijvoorbeeld externe events, beschikbaarheid externe systemen en leveranciers. In zo’n geval wordt het praktisch om een overall planning te maken om er voor te zorgen dat het Scrum Team op de juiste momenten de juiste resources tot zijn beschikking heeft.
Tip: maak een projectplanning mbt externe events en resources.
Project kosten besparen door geen externe resources in te huren.
De meeste Digitale & IT projecten zijn projecten die flink wat tijd vragen van bestaande (interne) medewerkers. Medewerkers die vaak al zijn met hun huidige werkzaamheden om de producten en diensten te leveren die je organisatie uniek maakt. Om project kosten te besparen krijgen deze medewerkers vaak additionele projecttaken zoals requirements specificeren, testen en extra project overleggen. Maar zeg nou zelf hoeveel toegevoegde waarde blijft er nog over als je medewerkers andere dingen gaan doen?
Tip: Besteed projectactiviteiten die geen toegevoegde waarde voor je eigen business zoals business analyse, project management en testen uit. zie ook mijn artikel over het ideale scrum team
Niet documenteren.
Er zijn maar weinig mensen die het leuk vinden om systeem documentatie op te stellen. Daardoor wordt het schrijven van systeemdocumentatie vaak zo ver uitgesteld tot het moment dat er geen tijd meer voor is. Hierdoor ontstaan er situaties in Live producten die moeilijk oplosbaar of aanpasbaar zijn doordat niet te achterhalen is waar het zit. Behalve dan als er iemand door de code heen gaat. Maar degene die de code geschreven zit op het moment supreme op een ander project of heeft het bedrijf al weer verlaten
Ook al heeft working software de prioriteit boven documentatie, dat betekent dus toch echt dat documentatie de tweede plek heeft.
Tip: een project is pas af als alle systeem documentatie is opgeleverd.
Beheer komt later wel
Veel projecten houden zich alleen maar bezig met het realiseren van requirements/stories die gewenst zijn door de eind klant. Requirements ten behoeve van het applicatie beheer worden niet opgehaald of vallen van de kar af. Hoe onhandig is het als je Digital / IT project op tijd en binnen budget opgeleverd is, maar binnen 3 maanden vastloopt omdat beheerders geen nieuwe gebruikers kunnen toevoegen wijzigen of fouten in het systeem kunnen herstellen.
Tip: Beschouw je applicatiebeheerders als belangrijke stakeholders en ontwikkel DEV/OPS zodat het beheer van de applicatie gewaarborgd is ook nadat het project is afgelopen.
Virtual BA
Als Virtual BA helpen we je graag met het voorkomen van deze fouten in jou automatisering of digitaliseringsprojecten.
Bekijk bijvoorbeeld onze Business Analyse as a Service of we nemen graag contact met je op.
Op de hoogte blijven?
Schrijf je dan in voor de periodieke Virtual BA update en krijg een bericht zodra er weer een nieuw artikel is.
Lees meer in ons Blog
Virtual BA – Slimme Analyses voor succesvolle projecten
Nieuwe producten, verbeteren van dienstverlening, één ding is zeker er is IT impact. Zelfs als je denkt dat er niets is, is er zeer waarschijnlijk toch wat. Immers je gaat iets veranderen en dat zal er ergens iets anders opgeslagen moeten worden. Misschien is de...