Er zijn legio verhalen bekend van software projecten die faliekant zijn mislukt. Met de beste intenties van alle betrokken partijen wordt vol bravoure gestart en na verloop van tijd ontstaan de eerste haarscheurtjes.
Dit zijn de meest voorkomende oorzaken, en manieren om dit bij een volgend project te voorkomen:
1. De software wordt niet op tijd en vaak genoeg getest
Op een gegeven moment wordt er besloten om de huidige (oude) software te vervangen. Dit kan zijn omdat het niet meer volledig aansluit bij de werkwijze die wordt gehanteerd, of bijvoorbeeld omdat men niet meer de juiste ondersteuning krijgt die noodzakelijk is doordat de software gewoon domweg te oud is.
Na een uitgebreid selectieproces, vele Excelsheets en tig- gesprekken met potentiële leveranciers later, wordt er keuze gemaakt voor een softwareleverancier. De kogel is door de kerk!
Wat je vaak ziet is dat er een compleet nieuw pakket ontwikkeld gaat worden om de oude software te kunnen vervangen. Het is ons allemaal geleerd om niet direct je oude schoenen weg te gooien, daarom zal het nieuw te bouwen softwarepakket volledig de oude functionaliteit moeten overnemen. Dit heeft als gevolg dat er aan het begin van het proces al ontzettend veel ontwikkeluren worden gestoken in het herbouwen van bestaande functionaliteiten, voordat er getest kan gaan worden. Dit is valkuil nummer één!
Door constant kleine “plukjes” software op te leveren, kan de opdrachtgever al veel eerder in het proces testen. Misschien wordt dan wel geconstateerd dat wat wij met z’n allen bedacht hebben, in de praktijk toch wat weerbarstiger is. Hiermee voorkom je dat je er pas na een lange periode van ontwikkelen achter komt dat dingen toch anders hadden gemoeten.
Eerder en vaker testen gedurende het ontwikkelproces kan je ontzettend veel tijd en geld schelen.
2. Onvoldoende mandaat van de projectverantwoordelijke
Waar het in het verleden ook vaak mis ging, is het feit dat vanaf hogerhand besloten wordt dat er een nieuw softwarepakket aangekocht moet worden en er vervolgens “een mannetje” van ICT (of inkoop) deze schone taak op zich moet nemen.
Met alle respect voor deze persoon, maar vaak zie je dat deze uiteindelijk voor goedkeuring weer naar zijn meerdere moet. Met als gevolg dat je niet snel beslissingen kunt nemen.
Je wilt als organisatie maar ook als softwareleverancier een contactpersoon met mandaat!
Zo mag je ook aan de de kant van de leverancier een daadkrachtige projectmanager verwachten. Een goede projectmanager kenmerkt zich door beide partijen strak te houden en laat zich niet verleiden tot het bijstellen van de scope gedurende het proces. Daarmee voorkomt hij of zij dat tijdens het ontwikkelproces constant nieuwe features toegevoegd worden die buiten de scope van het project vallen. Dit heeft vaak een negatief effect op de gebruiksvriendelijkheid van het software product en zorgt bovendien vaak voor veel uitloop van het project.
Mocht het project naar verwachting erg lang gaan duren, probeer er dan ook zeker van te zijn dat je geen wissel krijgt in je contactpersoon. Ook daarom is het fijn dat er iemand zoals de directeur/eigenaar aan tafel zit.
3. Onduidelijke doelstellingen voorafgaand aan het project
Als opdrachtgever en opdrachtnemer is het goed om te weten waar naartoe gewerkt dient te worden. Maar al te vaak zie je dat de stip op de horizon erg ver te zoeken is en als hij al in zicht is, dat er zigzaggend naar toe wordt bewogen.
Daarom is het op voorhand goed om te bepalen wat er gedaan moet worden en welke inspanningen daarvoor nodig zijn om daar zo snel en efficiënt mogelijk te komen.
4. Onduidelijke afspraken
Het is misschien een open deur, maar maak duidelijke afspraken. Spreek van tevoren af wie wat doet en wanneer wat wordt opgeleverd. Het moet geen strijd zijn tussen opdrachtgever en opdrachtnemer: jullie hebben elkaar hard nodig om tot een succesvol eindproduct te komen!
Leg de afspraken vast een beknopt document en hang hier de bijbehorende acties en verantwoordelijke personen aan. Wij maken hiervoor gebruikt van Trello, een handige tool om orde in de mogelijke chaos te scheppen.
Een tip: Blijf communiceren, ook als het niet altijd goed nieuws is!
In het kort:
Lever software op in kleine plukjes. Als je software laat bouwen, vraag dan je software partner volgens welke software methodologie ze software ontwikkelen. De agile manier is een mooi voorbeeld van een flexibele methode waarbij de software constant wordt opgeleverd en getest.
Zorg ervoor dat de projectverantwoordelijke binnen jouw organisatie voldoende mandaat heeft. Iemand die verantwoordelijk is voor een project, maar niet daadwerkelijk de bevoegdheid heeft om beslissingen te nemen is niet de juiste persoon om projectverantwoordelijke te maken. Vaak is het daarom prettig als de directeur en/of eigenaar ook aan tafel zit, waardoor snel geschakeld kan worden.
Bedenk van te voren welk doel je wilt behalen met het software project. Leg vast welk probleem je product moet oplossen of welke kans het product moet benutten. Bepaal vervolgens hoe je dat gaat meten en met welke resultaten je tevreden bent. Deel dit, zodat iedereen hiervan op de hoogte is en naar een gemeenschappelijk doel wordt gewerkt.
Maak onderling duidelijke afspraken. Spreek af wie onderdeel is van het projectteam (vanuit de opdrachtgever en opdrachtnemer) en leg vast wie verantwoordelijk is voor wat. Zo voorkom je dat je project vertraging oploopt omdat de verwachtingen naar elkaar toe niet duidelijk waren.
Het is dus heel goed mogelijk een software project met succes af te ronden. Met de juiste softwareleverancier, capabele mensen aan beide kanten en goede afspraken is het recept aanwezig voor succes!
