De belangrijkste vragen die je jezelf moet stellen als je begint met een software project

Het starten met een nieuw software project is een spannende onderneming. Het vereist zorgvuldige planning en aandacht voor verschillende belangrijke aspecten. Daarbij is het verstandig om voordat je begint de volgende vragen te stellen:

Is het helder wat er precies gebouwd moet gaan worden?

Één van de belangrijkste redenen waardoor software projecten vaak mis gaan is het goed uitwerken wat er precies gebouwd moet gaan worden. In technische termen noemen we dit de ‘requirements’ van het project. Dit lijkt vaak veel simpeler dan het is. Een softwareontwikkelaar heeft heel veel details nodig om te kunnen starten met het bouwen van de software. Indien deze kennis niet aanwezig is bij de developer zal dit in veel gevallen door de developer zelf worden ingevuld. Met een beetje pech blijkt achteraf dat dit niet is wat je graag zou willen en ontstaan er veel extra kosten.

Tip: zorg ervoor dat je iemand bij het project betrekt die kennis heeft van software ontwikkeling en kan helpen met het goed uitwerken van jouw idee. De kosten wegen absoluut op tegen de baten van het achteraf aanpassen van de software.

Wat is er minimaal nodig om live te kunnen gaan?

Veel software projecten worden groots aangepakt met een grote scope. Nadeel daarvan is dat het lang duurt voordat je live kunt gaan. Als je een nieuw product wilt lanceren is een ander groot nadeel dat er veel geld geïnvesteerd worden en het niet altijd duidelijk is of de business case wel of niet werkt.

Tip: zorg dat je helder prioriteert. Bijvoorbeeld door gebruik te maken van een acroniem: ‘Moscow’. Prioriteer al je wensen naar: must have, should have, could have en won’t have.

Tip: bouw eerste een ‘MVP’. Dit betekent Minimal Viable Product. Dus wat is het minimale product noodzakelijk om te kunnen testen of jouw product wel of niet gaat werken.

Welke risico’s zijn er bij dit project?

Het is goed om vooraf ook naar de risico’s te kijken. Veel te vaak in projecten wordt men verrast halverwege het project. Ik noem even wat voorbeelden: de kosten van het project lopen flink uit de pas. Of het systeem wordt gehackt omdat er niet over security is nagedacht. Een ander probleem zou kunnen zijn dat na lancering er zoveel gebruikers komen dat het systeem overbelast raakt en niet meer werkt.

Tip: denk vooraf goed na over de risico’s. Classificeer ieder risico op twee zaken: hoe waarschijnlijk is het dat dit probleem zich voor gaat doen en wat is de impact van dit risico. Op basis hiervoor kun je kijken wat de belangrijkste risico’s zijn en per risico nadenken over wat je nu al zou kunnen doen om dit risico te voorkomen. Bijvoorbeeld het plannen van een security test bij oplevering.

Welke stakeholders zijn er actief bij dit project?

Bij het live gaan van een nieuw software systeem zijn vaak veel stakeholders betrokken. Denk bijvoorbeeld aan de mensen die het systeem moeten gaan beheren. Het is daarbij ook belangrijk welke taken er moeten worden uitgevoerd en wie verantwoordelijk is. Daarbij is het ook belangrijk dat bekend is op wie de wijzigingen van het systeem impact hebben. Het kan erg vervelend zijn als je boze telefoontjes krijgt achteraf van mensen die je bent vergeten te informeren.

Tip: maak een ‘RACI’ overzicht van iedereen die betrokken is. In een RACI bepaal je welke taken er in het project zijn en wie op welke wijze daarbij betrokken is. RACI staat voor:

• Responsible: wie is er verantwoordelijk om ervoor te zorgen dat deze taak wordt uitgevoerd?

• Accountable: wie is er eindverantwoordelijk voor deze taak. Het kan goed zijn dat bijvoorbeeld de directeur van het bedrijf uiteindelijk wordt aangesproken als het project faalt.

• Consulted: personen die je kunt vragen voor hulp.

• Informed: wie moet je mee nemen in de informatie voorziening en op de hoogte houden.

Uiteraard zijn er veel meer zaken om rekening mee te houden voordat je een software project start. EchoNova ondersteunt hier graag in. Neem gerust contact met ons op om hier even over door te praten.