0
(0)

Alle nieuwe ontwikkelingen en methodieken ten spijt. Digitale en IT projecten blijven keer op keer dezelfde fouten maken.

Hieronder de belangrijkste 7 denkfouten:

  1. Requirement overslaan want dat is waterval
  2. Opstellen van oplossingsgerichte requirements
  3. Oplossing baseren op 1 systeem
  4. Niet plannen want dat is niet agile
  5. geen externe resources huren om kosten te besparen
  6. Niet documenteren
  7. 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 efficient 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. 

Lees meer in ons Blog

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 zins constructie. Dat gebruik van die zins constructie voldoende is om er voor...

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...

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...

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...

 145 total views

Wat vond je van dit artikel?

Rating:

Gemiddelde rating 0 / 5. Aantal stemmen: 0

Nog geen stemmen, je mag als eerste!

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

Neem contact op

Laat je gegevens achter en wij nemen zo snel mogelijk contact met je op. 

We nemen zo snel mogelijk contact met je op

BA Netwerk

Schrijf je nu in voor het BA netwerk en wij helpen je met vinden van een goede Business Analist!

Wij nemen zo snel mogelijk contact met je op!

Neem Contact op

Neem Contact op

Laat je gegevens achter en wij nemen zo snel mogelijk contact met je op

Dank je wel voor het inschrijven wij nemen zo snel mogelijk contact met je op!