Software project management – hoe schrijf je een projectplan

In het voorjaar van 2016 hebben Joost, Jeroen en Sieuwert het vak software project management gegeven aan de Vrije Universiteit in Amsterdam. In 10 weken hebben 60 studenten de principes van het leiden van software-projecten geleerd. We hebben dit gedaan aan de hand van een eenvoudige opzet in zeven hoofdstukken, omdat dit goed leesbare en daarmee waardevolle projectplannen oplevert.

De uitdaging van eenvoudig projectmanagement

De grootste uitdaging in het geven van het vak software project management is het feit dat software-projecten zeer verschillend in omvang zijn. De eerste software-projecten, uit de periode 1960-1990, waren mega-operaties met honderden mensen die jaren aan een project werkten. Neem bijvoorbeeld het maken van de software voor de space shuttle: dit is een groot project met veel uitdagingen en een harde deadline.  Dit soort projecten bestaan nog steeds, vooral bij overheden en multinationals. In deze tijd zijn er allemaal formele methodes ontwikkeld die ieder veel tijd kosten, maar voor deze grote projecten heel waardevol zijn. Er zijn tegenwoordig echter ook veel moderne, kleine projecten. Zeker bij een agile aanpak worden projecten klein gehouden. Ook kan er gebruikt gemaakt worden van bestaande componenten. Het gevolg is dat er ook veel IT-projecten zijn van 1000 uur uur minder. Ook deze projecten kennen risico’s en hebben behoefte aan projectleiding. De klassieke tools en methodes voor projectmanagement zijn er echter veel te log en zwaar voor dit soort projecten, zeker als je ze allemaal toepast.

In dit vak hebben we geprobeerd beide kanten te belichten. We hebben een basisopzet gemaakt die voor elk project geldt, en vervolgens toegelicht hoe deze per onderwerp uitgewerkt en ingevuld kan worden. Het is vervolgens aan de projectleider om de tijd goed te verdelen over alle onderwerpen. De basisopzet is hieronder weergegeven, met voor elk onderwerp een link naar een meer uitgebreid Engelstalig artikel.

1. Definieer een visie

De kern van elk software-project is het idee dat iets in de wereld beter geregeld kan worden. Een groep mensen (studenten, bakkers, kinderen) heeft nu een behoefte of probleem, en met extra middelen (inclusief software) kunnen zij beter gaan werken. Het is belangrijk deze visie helder en goed op te schrijven, zodat iedereen weet waarom het project gedaan wordt. Als er dan later in het project keuzes gemaakt moeten worden, kan je teruggrijpen op deze visie, en de optie kiezen die het beste past bij de oorspronkelijke visie. In veel software-projecten wordt de visie onvoldoende omschreven, of wordt de visie onvoldoende gedeeld met mensen die later bij het project betrokken worden. Hierdoor wordt er software gemaakt die wel aan de technische eisen voldoet, maar die niet echt tot resultaat leidt. Met een goed omschreven visie die ook voor iedereen toegankelijk is, wordt dit voorkomen. Zie ‘why having a vision is key in project management‘ voor meer toelichting.

Maak de scope helder en beheersbaar

De ‘scope’ van een project, oftewel reikwijdte, is een omschrijving van alles wat het project gaat maken of opleveren. Bij software-projecten is dit vaak een lijst van functies die vertellen wat gebruikers kunnen met het op te leveren systeem. Bijvoorbeeld het zoeken of reserveren van restaurants. Wij raden aan de scope op te schrijven in user stories. Deze stories zijn eenvoudig om te maken en ook begrijpelijk voor de opdrachtgever.In het artikel ‘managing scope‘ geven we meer uitleg over niet alleen het opschrijven aan het begin, maar vooral ook het beheersen van scope tijdens een project.

Denk na over niet-functionele requirements

Bij het maken van software is het niet alleen belangrijk welke functies de software bevat. Ook aspecten zoals gebruiksvriendelijkheid, snelheid, onderhoudbaarheid, en beveiliging zijn van belang. Het is verstandig om ook aan het begin van het project al na te denken over deze aspecten. Stel aan het begin doelen vast en spreek af hoe er wordt getest. Dit voorkomt problemen en conflicten aan het eind van het project. In het artikel ‘Getting non-functional requirements right‘ bespreken we het opstellen en het flexibel maken van niet-functionele requirements.

Schatten van inspanning en kosten

Het schatten van de hoeveelheid ontwikkeltijd die nodig is voor software is lastig. Er is veel onderzoek gedaan maar geen enkele methode werkt echt goed. Elk software-project is namelijk uniek. Er zijn vier hoofdmethodes die we in meer detail hebben uitgelegd in het artikel Four methods for effort estimation. Echter: de perfecte schatting bestaat niet. We raden aan om wel een schatting te doen, maar de schatting gedurende het project bij te stellen. Zie het artikel Software project effort estimation – the agile way over hoe om te gaan met het schatten van effort.

Maak een eenvoudige planning

Het hebben van een goede planning van de activiteiten is belangrijk, omdat iedereen die bij het project betrokken is moet weten wanneer zij of hij in actie moet komen. Ook wil je praktische zaken, zoals vakanties van projectleden en feestdagen, goed kunnen regelen. Een Gantt Chart is een goed en eenvoudig hulpmiddel. Bij het vak hebben we de studenten dringend geadviseerd om een moderne planning te maken met meerdere opleveringen. Vervolgens kan men ook een kritisch pad bepalen om te zien of de planning optimaal is. Meer informatie hierover staat in ‘Tips and tricks for creating a software project schedule‘.

Plan ook de organisatieveranderingen

Bij elk IT-project komen ook, niet-IT aspecten kijken. Zoals in deze blogpost uitgelegd, is COPAFIJTH een goede ezensbrug om deze aspecten te onthouden: communicatie, organisatie, Personeel, Administratie, Financieel, Informatie, Juridisch, Technologie en Huisvesting. Een goed projectplan benoemt al deze aspecten en besteed dus niet alleen aandacht aan IT. Waarom dit ze belangrijk is, staat in de blogpost ‘There are no IT projects’ – organsiational aspects.

Denk na over risico’s

Risicomanagement is een belangrijk onderdeel van projectmanagement. Elk project heeft enige mate van onzekerheid en dus ook risico’s. Deze hoeven niet vermeden te worden, maar moeten wel benoemd worden en herkend. Een eenvoudig systeem voor risicomanagement bestaat uit een risicolog, een matrix voor prioritisatie en een lijst van mogelijke maatregelen. Zie de post project risk management voor meer informatie.

Tot slot: deel je plan en houd het eenvoudig

Tijdens het vak Software Project Management hebben alle studenten in groepen van vier gewerkt aan projectplannen voor projecten van hun eigen keuze. Elk week is een hoofdstuk geschreven en ingeleverd voor feedback. Aan het eind van het vak, op 27 mei, worden al deze plannen aan elkaar gepresenteerd. We vinden het namelijk belangrijk, en ook passend bij de agile principes, om geen documenten te schrijven voor de bureaula. Als je als projectleider ervoor kiest een plan te schrijven, dan moet je dit plan ook naar buiten brengen en gebruiken in de communicatie over het project. Alleen op deze manier heeft het plan waarde. De keuze voor een eenvoudige opzet, zoals hierboven beschreven, wordt dan heel nuttig: een korter en eenvoudiger plan bevat misschien niet alle details over een project, maar is wel beter leesbaar, zal meer mensen bereiken en daardoor meer effect hebben dan een uitgebreid en meer formeel plan.

Meer weten over projectmanagement, of suggesties en aanvullingen? Neem dan contact op. We geven graag meer informatie, reviewen IT-projecten en plannen en kunnen ook workshops geven over software project management.

Afbeelding: Veer – Thomas van de Vosse. Space shuttle : NASA public domain