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
De 5 meest voorkomende soorten automatisering
Automatisering kan veel verschillende vormen aannemen, misschien is dat ook wel de reden dat er zo veel automatiseringsprojecten mislukken. Simpelweg omdat men elkaar niet begrijpt of omdat men denkt het over hetzelfde te hebben. Vaak gaat het over het automatiseren...
Het ideale SCRUM Team
Het ideale SCRUM Team SCRUM is hot, maar of het nu een zegen of een vloek is, daar zijn de meningen over verdeeld. Een van de belangrijkste key succesfactoren is het SCRUM Team. De inrichting van het team bepaalt het succes van het project. Immers in SCRUM bepaalt het...
Een Digitaliseringsstrategie in 3 stappen
Stap 1: Ontwikkel een digitaliseringsvisie Stap 2: Bepaal de digitale oplossingsrichting Stap 3: Bepaal de benodigdhedenStap 1: Ontwikkel een digitaliseringsvisieDe eerste stap voor een digitaliseringsstrategie is bepalen wat u wil bereiken en waarom. Niet in termen...
4 stappen van een goede business analyse
Of u nu uw Customer Experience wil verhogen, uw efficiëntie wil verbeteren of nieuwe producten wil introduceren. Één ding is zeker er is verandering nodig. Om te weten wat u moet veranderen zal u uw business moeten analyseren. Niet alleen om te bepalen wat er in uw...
Nieuw SCRUM Backlog Generator
Druk? Veel wensen van verschillende gebruikers maar eigenlijk geen tijd om het allemaal netjes te verwerken in goede User Stories? Maak dan gebruik van de Virtual BA – SCRUM Backlog Generator De SCRUM Backlog Generator van Virtual BA vertaalt losse emails, word...
Hoe herken je een goede business analist
Een Business Analist zorgt er voor dat wensen van de business vertaalt kunnen worden naar IT oplossingen. Dit doet de Business Analist door enerzijds goed te luisteren naar wat de Business (afdelingen) willen bereiken en dit zo te formuleren dat de Technische...
User stories vs Requirements
User stories dat klinkt best soft, misschien zelfs wel een beetje zweverig voor iets waarmee u uw project definieert. U heeft vast ook liever harde requirements. Toch verliezen de harde requirements het tegenwoordig van de softe user stories. En dat lijkt wel een...
Automatiseren, Digitaliseren of Robotiseren?
Automatiseren, Digitaliseren en Robotiseren drie termen in de IT, die over het zelfde lijken te gaan. Vaak worden deze termen door elkaar heen gebruikt terwijl ze toch verschillende dingen betekenen. In deze blogpost duid ik de verschillende betekenissen. Wat is...
Opgedroogde Backlog
De SCRUM purist zal nu zeggen als de backlog leeg is dan is het project klaar. Mission Accomplished. Iedereen mag naar huis en op naar het volgende project. In de werkelijkheid zal een backlog nooit echt leeg zijn, er zullen altijd wel "dingetjes" zijn die opgelost...
Zorgeloos op vakantie
U kent dat vast wel zo begin juni/juli raakt iedereen in de vakantie modus, in gedachten of in real life verdwijnen collega's naar verre oorden. Sommige doen dat net voor de schoolvakanties maar de meeste gaan er midden in. Vaak...