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
Using ChatGPT for Process Modeling: Flowcharts, Sequence Diagrams, and More
In my last post, I shared how you can use ChatGPT to generate user stories. But did you know that ChatGPT is also highly effective for creating flowcharts, sequence diagrams, and other essential diagrams for Process Modeling? Creating diagrams is a core skill for...
Het schrijven van User Stories met ChatGPT
Sommige mensen denken dat het schrijven van user stories hetgeen is waar Business Analisten (BA's) het meest van genieten. Per slot van rekening bestaat een groot deel van het werk van BA’s uit user stories, epics (grote verhalen), of soms PowerPoint-presentaties, die...
Omgaan met Wettelijke Requirements
u
Hoe je je Epics Episch maakt
Een Epic is een user story die niet binnen één sprint te ontwikkelen is, is een vuistregel die veel projecten hanteren om Epics te identificeren. Als je het mij vraagt ben je dan eigenlijk net te laat en mis je heel veel aspecten van een Epic waarmee je effectief je...
Type Business Analyses
3 Situaties die baat hebben bij een Business Analyse In dit artikel leg ik uit in welke situaties een Business Analyse toegevoegde waarde biedt en waarom. Digitalisering van bedrijfsprocessen Integratie van verschillende systemen Introductie nieuw product of...
10 Tips for creating perfect User Stories
Often it is believed that a perfect User Story is written like: “As a user X I want to do Y So I can achieve Z”. Some people also believe that this is all what needs to be written down for a development team to create the right results. Therefore, it is not surprising...
De 5 soorten analisten in het Digitale/IT domein
Een ruit is een vlieger maar een vlieger is geen ruit, dit zei mijn wiskunde leraar vroeger altijd. Waarmee hij bedoelde dat vormen op elkaar kunnen lijken maar dat de eigenschappen verschillend zijn. Deze filosofie is ook van toepassing op een Business Analist,...
5 Tips voor het effectief optimaliseren van bedrijfsprocessen
Klinkt natuurlijk wel lekker dat optimaliseren van bedrijfsprocessen. Maar hoe weet je nu eigenlijk dat je bedrijfsproces is geoptimaliseerd en wat is een bedrijfsproces eigenlijk. In dit artikel leg ik uit wat een bedrijfsproces is, hoe je weet dat het...
Why Digital and IT projects need Business Analysts
10 Tips voor de perfecte User Story
Als een gebruiker X wil ik zus en zo kunnen zodat ik dit en dat kan bereiken, is toch al bijna de perfecte User Story? Veel mensen denken dat een User Story alleen bestaat uit bovenstaande zinsconstructie. En dat gebruik van die zinsconstructie voldoende is om er voor...