Vijf handige tips

1. Harmoniseer processen vóór je start met een nieuw systeem

Geharmoniseerde processen vormen een stevige basis voor de start met een nieuw roostersysteem. Niet alleen is een nieuw systeem hierdoor veel makkelijker in te richten, ook maken afspraken over bijvoorbeeld vaste bloktijden, het een stuk eenvoudiger om een flexibel en conflictvrij rooster te produceren. Mijn ervaring is dat er uniforme afspraken nodig zijn over:

• Een Uniforme Jaarkalender (met een gelijke semester en periode indeling).
• Uniforme bloktijden (vaste begin- en eindtijden van lesblokken en gebruik van dezelfde tijdseenheden).
• Uniforme activiteitstypen en andere stamtabellen (een activiteitstype is bijvoorbeeld een hoorcollege of een werkcollege; bij de VU zijn we van 69 varianten teruggegaan naar 15).
• Vaste deadlines voor het vaststellen van: het curriculum, de datacollectie voor roostering, de docentinzet, de docentbeschikbaarheid, het communiceren van het concept- en het definitieve rooster. En niet te vergeten, misschien wel met stip op één: de deadline van het beschikbaar stellen (en weer vrijgeven) van lokalen ten behoeve van de onderwijsplanning.

2. Werk met het juiste team

Een goed team bestaat niet alleen uit goede mensen, maar heeft ook de juiste grootte. Met goede mensen bedoel ik: slim, gedreven, positief, consciëntieus, flexibel en met enige ervaring. Investeer daarbij in stevige projectleiding, dat betaalt zich altijd terug. Ook moet een team de juiste grootte hebben: te groot en het wordt stroperig, te klein en niemand voelt zich gehoord. In mijn ervaring werkt het goed om het kernteam klein te houden, voor optimale slagvaardigheid, en de vertegenwoordiging groot, voor een groot draagvlak binnen de organisatie. Een kernteam kan bestaan uit een Algemeen Projectleider, een IT Projectleider, een Business Vertegenwoordiger (de Product Owner) en een Specialist (in dit geval een Onderwijsplanner). Samen maken zij de beslissingen, gebaseerd op brede input vanuit organisatie. Een stuurgroep bewaakt de kwaliteit van de beslissingen.

3. Maak wel/geen* plan (*doorhalen wat niet van toepassing is)

Het is gebruikelijk om bij de aanvang van een project een lijvig projectplan te schrijven. Ik heb dan ook heel wat schrijfwerk achter de kiezen. Dit zijn mijn bevindingen:

• Begin altijd met een helder omschrijving van het bestaansrecht van het project. Waarom is het in het leven geroepen? Een duidelijke why verwoorden, met daarbij aandacht voor de meerwaarde voor de organisatie, de stakeholders die na afronding tevreden moeten zijn, de business case en de kwalitatieve en kwantitatieve voordelen, is geen verloren moeite. Wanneer een project in zwaar weer terecht komt (en dat komt elk project), moet je terug kunnen vallen op de basis: waarom zijn we hieraan begonnen? Elk uur extra dat in dit hoofdstuk wordt geïnvesteerd, wordt later in het project dubbel terugverdiend.
• Een planning kan niet ontbreken, maar is altijd onzeker omdat de uitvoering in de toekomst ligt en beïnvloed wordt door vele variabelen. Een detailplanning is daarom nutteloos. Beperk je daarom tot een goed onderbouwde planning op hoofdlijnen, die richtingbepalend is voor het projectteam: wat doen we eerst, wat later, hoelang zijn we er mee bezig, wanneer moet het klaar zijn. Voor externen vormt dit een handige communicatietool voor de voortgang van het project.
• Ook voor de financiële paragraaf geldt: houd rekening met interne flexibiliteit. Het exact inschatten van hoeveel uren een mijlpaal kost is vrijwel onmogelijk, zeker als het over IT-gerelateerde onderdelen gaat. Maak daarom een budget op hoofdlijnen, monitor de benutting en stuur op effectiviteit en efficiëntie. Stem afwijkingen gedurende het project steeds af met de stuurgroep (en maak er een sport van om geld over te houden, in plaats bij te vragen).
• Schets een helder beeld van het eindresultaat. Welke tastbare zaken worden opgeleverd: welke systemen worden geïmplementeerd, welke koppelingen met andere systemen zijn er, welke globale datastromen worden gerealiseerd, welke functionaliteiten worden opgeleverd. Benoem daarbij vooral ook wat níet opgepakt wordt binnen het project en wat níet gerealiseerd wordt. Dit kan zowel gedurende het project als bij de oplevering veel discussie voorkomen.

4. Werk (soort van) Agile

Tegenwoordig werken veel IT-organisaties met Scrum en/of Agile en dit zou ik daarvan in ieder geval meenemen:

• Werk binnen het project kortcyclisch, gelijkend aan sprints. Dit legt automatisch de focus op een overzichtelijk aantal issues, waardoor alle resources volledig daar op gericht worden. Nieuwe issues kunnen doorgeschoven worden naar latere sprints of een plek krijgen op de roadmap.
• Stand up’s, korte staande ontmoetingen, helpen om de focus op het resultaat te houden. Het is prettig om niet alleen via email contact te onderhouden, om elkaar geregeld in de ogen te kijken en mondeling kan er altijd snel geschakeld worden. Binnen ons project hielden we per week twee stand up’s van vijftien minuten en dat was voldoende.
• JIRA is een handig hulpmiddel om het overzicht te behouden over alle punten die aandacht behoeven én om hierover met alle betrokkenen te communiceren (bijvoorbeeld tijdens de stand up). Ik raad het van harte aan.
• Als verschillende afdelingen met hun eigen sprint teams werken en daarbij hun eigen storyboards en sprintplanning bijhouden, doen zich diverse problemen voor: de verschillende sprints sluiten niet op elkaar aan, issues komen op meerdere JIRA borden te staan en resources worden geclaimd terwijl onduidelijk is of ze nodig zijn, omdat andere teams nog aan het sprinten zijn. Kortom: niet doen.

5. Positioneer de leverancier als verlengstuk van jouw organisatie

Het gezamenlijk doel van de leverancier en de instelling is altijd het succes van het project. Een goede relatie tussen de twee zorgt voor korte lijnen, waardoor eventuele onenigheden snel boven tafel komen en in de kiem gesmoord kunnen worden. Neem daarom de volgende punten in ogenschouw:

• De relatie moet gelijkwaardig zijn en structurele dominantie van een van beide partijen leidt op termijn tot verlies voor beiden. Blijf altijd gericht op een win-win situatie.
• Besef vooraf dat niet alle afspraken tijdig en volledig nagekomen zullen worden, bezien van beide zijden. Wees er daarom op voorbereid om excuses aan te bieden en te aanvaarden en blijf altijd je uiterste best doen om de relatie goed te houden. Het project tot een succes maken blijft altijd het gemeenschappelijke doel.
• Zorg dat je in het vroegste stadium betrokken bent bij de ontwikkeling van nieuwe functionaliteiten. Het was bij ons bijvoorbeeld gebruikelijk dat wij meekeken in het JIRA-systeem van de leverancier en feedback gaven op hun mock up’s en stories, zodat zij in één keer konden ontwikkelden wat wij bedoelden.

De implementatie van een nieuw roostersysteem is aan de VU succesvol verlopen. Wil je daar meer over weten en/of starten jullie ook in de nabije toekomst met een nieuw systeem? Neem contact met ons op!