Het implementeren van een nieuw HR-systeem zoals SAP SuccessFactors is een klassiek project: duidelijke scope, vaste oplevermomenten, mijlpalen en een heldere eindverantwoordelijkheid. Steeds vaker voeren we bij HuRis zulke projecten uit binnen organisaties die Agile werken waarbij dit kan zorgen voor enkele uitdagingen. Hoe houd je als projectleider grip als je afhankelijk bent van Agile teams? In deze blog bespreken we de belangrijkste knelpunten — én hoe HuRis deze bij voorkeur managet.

 

Agile versus klassieke projecten: de verschillen in een overzicht.

Om onze tips goed te kunnen begrijpen zoomen we eerst nog kort in op de belangrijkste verschillen tussen klassieke projecten en de Agile werkwijze.

We verwijzen in deze blog, vanwege het verschil met Agile, met de term “klassieke projecten” naar een container van projectmethodieken met duidelijke projectfaseringen, welbekende mijlpalen en deliverables die vrijwel altijd bekend / passend zijn in de verschillende methodieken binnen deze container. Bij HuRis hanteren we een projectmethodiek pragmatisch gebaseerd op SAP Activate.

Agile teams leveren (kleine) onderdelen aan en ze doen dat in hun eigen ritme, via sprints en backlogprioritering. Het project daarentegen stuurt op voorspelbaarheid en planningszekerheid. Het onderstaande overzicht toont de belangrijkste verschillen tussen beide werkwijzen.

ThemaKlassiek ProjectAgile Team
PlanningLange termijn, harde deadlinesSprint-based, korte termijnprioriteiten
LeveringAlles in één keer (eindoplevering)Incrementele oplevering per sprint
ScopeVaste scope met change controlScope evolueert met voortschrijdend inzicht
EigenaarschapProjectmanager stuurtProduct Owner prioriteert
AcceptatieFormele test- en goedkeuringsmomentenIteratieve feedback via demo’s
VerantwoordelijkheidProjectteam verantwoordelijk voor eindresultaatTeam verantwoordelijk voor individuele deliverables

De wereld tussen klassiek en agile zal wat dat betreft altijd blijven verschillen, het zijn  immers verschillende methodieken. We kunnen wel proberen die verschillen te mitigeren. Onderstaand gaan we in op de belangrijkste punten die we zien bij de implementatie van SAP SuccessFactors in een Agile organisatie.

Tip 1: Harde deadlines vs. Sprintplanning: zoek de afstemming!

Een klassiek project plant op deliverables en deadlines: bijvoorbeeld vanwege gebruikersacceptatietesten waarbij gebruikers uit de hele organisatie worden uitgenodigd om te testen, moeten de integraties met SAP SuccessFactors echt testklaar zijn. Het Agile team daarentegen werkt in sprints en bepaalt kort voor aanvang wat opgepakt wordt. De “definition of done” moet voor alle deliverables vóór de deadline van het klassieke project zijn behaald. Zonder afstemming kan projectwerk simpelweg “van de backlog vallen”.

Daarom vindt HuRis het cruciaal om al vroeg in het project — bij voorkeur vóór de start — te identificeren waar de samenwerking nodig is en afstemming te zoeken met het Agile team over de globale projectplanning, inclusief mijlpalen en verwachte levermomenten.

Afbeelding met tekst, kleding, person, persoon  Door AI gegenereerde inhoud is mogelijk onjuist.Projectopleveringen mogen niet zomaar worden weggeprioriteerd. HuRis adviseert de klant om expliciet af te spreken dat projectdeliverables worden behandeld als harde verplichtingen binnen de teambacklog. Dit kan desnoods worden vastgelegd in een werkafspraak of samenwerkingscontract met het team of de Product Owner.

Daarbij is het ook essentieel dat de Product Owner regelmatig afstemt met de projectleiding, om afhankelijkheden tijdig te signaleren en sprintinhoud af te stemmen op de projectbehoefte.

Ook in de testfase vraagt dit om coördinatie: plan de projectacceptatiefase als één of meerdere sprints, en claim hiervoor dedicated capaciteit binnen het team. Zo voorkom je dat testondersteuning onder druk komt te staan door andere prioriteiten in de sprint.

Tip 2: Een definitief datamodel vóór de sprints

Voor vrijwel alle HR-implementaties zijn gegevensstromen tussen systemen cruciaal. Ook tijdens de implementatie van SAP SuccessFactors is dit een belangrijk onderdeel. Agile teams bouwen dan interfaces of datakoppelingen. Maar zonder vast datamodel kunnen ze niet bouwen — of bouwen ze op basis van aannames, wat leidt tot rework.

Daarom stuurt HuRis  in een project er altijd op dat er een definitief, vastgesteld datamodel is vóór de start van de sprints waarin interfaces worden gebouwd. Het datamodel moet projectbreed zijn afgestemd én geaccepteerd door het ontvangende team. Dit is een harde projectvoorwaarde vóór oplevering van koppelingen of technische specificaties.

Dit vraagt ook van de klant dat er, al aan het begin van de workshops, helderheid is over de benodigde datavelden ten behoeve van o.a.:

  • De uitvoering van de processen
  • Voeden van gekoppelde systemen
  • Gewenste rapportages
  • Benodigde document generatie (bijvoorbeeld bij gebruik van de HuRis Document Manager)

Toch kunnen er later in het project nog uitzonderingen of nieuwe inzichten ontstaan.

Om te voorkomen dat deze ad hoc het team ontregelen of de projectplanning in gevaar brengen, kan er expliciet ruimte in de planning opgenomen worden voor één of meerdere change-sprints. Deze sprints zijn bedoeld om wijzigingen op het datamodel of aanvullende technische aanpassingen op een gecontroleerde manier te verwerken — zonder dat ze de lopende backlog verstoren of eerdere opleveringen overschrijven.

Tip 3: Capaciteit claimen voor test- en opleverfasen – hoe je testcapaciteit niet van de backlog valt.

In klassieke projecten wordt capaciteit gereserveerd. In Agile omgevingen is dat anders: het team bepaalt zelf wat haalbaar is, per sprint. Je kunt dus niet zomaar verwachten dat iemand beschikbaar is voor ondersteuning bij bijvoorbeeld testen of foutoplossing.

HuRis adviseert daarom de project testfase als één of meerdere sprints te plannen, afhankelijk van de omvang van het werk. Zorg ervoor dat er dedicated capaciteit wordt gereserveerd binnen het team — bijvoorbeeld een ontwikkelaar, tester of integratiespecialist — zodat testondersteuning en foutcorrecties niet tussen wal en schip vallen.

Hierbij houden we rekening met de verschillende testfases in het project zoals de functionele acceptatietest, ketentesten en gebruikersacceptatietesten, elk met een eigen planning en benodigde capaciteit.

Tip 4: Scopebeheersing: overbrug de verschillen in deliverables

In een klassiek project ligt de scope vaak vast in een uitgebreid functioneel ontwerp, met scherpe acceptatiecriteria en formele oplevermomenten. Agile teams werken iteratief, leveren kleinere onderdelen op en bepalen tijdens het project hun prioriteiten. Dit kan leiden tot misverstanden over wat precies “af” is en wat er verwacht wordt.

Om die kloof te overbruggen, helpt het volgens HuRis om:

  • Deliverables te vertalen naar concrete afspraken: Bijvoorbeeld niet alleen “de interface moet werken”, maar “de interface moet deze specifieke gegevens overdragen, met minimaal deze foutafhandeling en deze validaties”. Zo wordt het abstracte “werkt” concreet.
  • Gebruik te maken van een gezamenlijke ‘Definition of Done’: Een lijst met eenvoudige, duidelijke criteria waaraan een oplevering moet voldoen om als ‘klaar’ te gelden. Dit helpt Agile teams te begrijpen wat de formele projectverwachting is, en het projectteam om te accepteren wat er geleverd wordt.
  • Regelmatige demo’s of reviewmomenten: Waar het team laat zien wat het heeft gebouwd en het projectteam feedback geeft. Dit voorkomt dat er pas aan het eind discussie ontstaat.
  • Documentatie en testresultaten expliciet mee laten leveren: Niet alleen de werkende code, maar ook de beschrijving van de functionaliteit en een kort testrapport helpen het project om de oplevering formeel goed te keuren.
  • Heldere afspraken over wijzigingen: Als tijdens het project blijkt dat iets anders of uitgebreider moet, zorg dan voor een proces om die scopewijzigingen formeel te beoordelen en prioriteren.

Door de “spreektaal” van klassieke projecten en Agile teams op elkaar af te stemmen, wat al vanaf de kickoff kan worden gedaan, voorkom je dat klassiek en Agile langs elkaar heen werken, en ontstaat er een gemeenschappelijk kader om te sturen en op te leveren.

Tip 5: Testen vs. beschikbaarheid van systemen

Een veelvoorkomend knelpunt: het team wil vroeg testen, maar het SAP SuccessFactors systeem is nog niet klaar. Er is geen testdata, geen toegang, geen omgeving. Dat frustreert de voortgang van de technische teams.

De oplossingen hiervoor kunnen bijvoorbeeld liggen in het gebruik van dummy data, tijdelijke omgevingen, mockups etc. Hiervoor is echter wel tijd nodig om te bespreken wat mogelijk is en om deze voor te bereiden. Het is dus belangrijk om dit al bij de start van het project — of zelfs eerder — af te stemmen met het technische, agile team..

Bij HuRis adviseren we bij het afstemmen van de projectplanning rekening te houden met het inplannen van een “sprint 0” voor het project binnen de Agile organisatie. De product owner kan hiermee analyse van de mogelijkheden inplannen van de resources in de agile teams. Zo is kans kleiner dat er verrassingen ontstaan tussen project en agile teams.

 

Conclusie

Een klassiek project hoeft zich niet aan te passen aan Agile werkwijze — maar moet wél slim samenwerken met teams die zo werken. Dat betekent vooral:

  • Vroeg plannen en afstemmen, bij voorkeur al vóór de start van het project
  • Neem de uitdaging op in de kickoff en betrek het Agile team erbij
  • Vorm de klassieke projecttaken in Agile deliverables.
  • Afstemmen met de Product Owner, maar sturen vanuit het project
  • Duidelijke afspraken en commitment over capaciteit en deadlines
  • Afspraken dat er geen concessies kunnen worden gedaan aan de projectbeheersing
  • Sponsoring en begrip inregelen bij het management en de stuurgroep voor de situatie.

Belangrijk is dat HuRis met haar klanten al vóór de start van het project — idealiter in de salesfase — herkennen en erkennen dat de combinatie van een klassiek project met Agile levering leidt tot meer afstemming, meer schakelmomenten en dus potentieel meer doorlooptijd. Het integreren van twee planningsmethoden vraagt om structuur, overleg en flexibiliteit aan beide kanten.

Een alternatief om die complexiteit te reduceren, is om resources uit de Agile organisatie tijdelijk in het project op te nemen. Daarmee verschuift de verantwoordelijkheid naar het project, ontstaat er directe aansturing en vervalt een deel van de coördinatielast. Dit vraagt wel om commitment vanuit de lijn, maar kan zeer effectief zijn, met name voor kritieke onderdelen.

Met de juiste afspraken, voorbereiding en rolverdeling kun je zo ook binnen een hybride omgeving een voorspelbaar, succesvol HR-implementatieproject realiseren.

HuRis is een HR Consultancy organisatie, die zich volledig richt op het snijvlak van HR processen en IT. Hierbij richten we ons op de ondersteuning van HR processen middels SAP SuccessFactors met als doel organisaties verder te helpen bij het optimaliseren en automatiseren van hun HR processen. Meer weten over HuRis en hoe wij projecten aanpakken?

Ga naar www.huris.nl voor meer informatie