Het succes van een project is afhankelijk van vele factoren. Maar er is één factor die met kop en schouders boven de rest uitsteekt: de kwaliteit van het team. En APS implementaties zijn hierin niet anders dan andere projecten.
Natuurlijk wordt de kwaliteit van een team voornamelijk bepaald door de kwaliteit van de individuele mensen in het team. Voor elke rol in het team wil je de beste man of vrouw. Vakbekwaamheid, ervaring, gedrevenheid, initiatief, allemaal eigenschappen die je graag ziet. Maar er is meer dan individuele kwaliteiten. Een team moet ook werkelijk een team zijn, er moet sprake zijn van een klik tussen de teamleden en teamleden moeten elkaar en elkaars rol respecteren. Onderlinge strijd of irritatie kan een behoorlijk negatief effect hebben op het resultaat en de voortgang. Het team moet ook mandaat hebben om beslissingen te nemen, voldoende tijd hebben en de middelen hebben om het werk goed uit te kunnen voeren.
Ik heb veel APS projecten gezien waar aan het begin van het project veel aandacht werd besteed aan de team samenstelling. De beste mensen uit de organisatie werden vrijgemaakt om hun bijdrage te leveren, en voor rollen die niet vanuit de organisatie zelf konden worden ingevuld, werden externe adviseurs aangetrokken. De beste mensen op de juiste plek, geen vuiltje aan de lucht. Het resultaat van deze projecten liet dan ook vaak weinig te wensen over. Tenminste, in eerste instantie...
Een project heeft een kop en een staart, en dus heeft een projectteam ook een eindig bestaan. Aan het einde van een implementatie project wordt het team ontbonden, gaat de geimplementeerde applicatie in beheer, en is het aan de organisatie om het geimplementeerde proces uit te voeren. De A-team leden gaan weer over tot de orde van de dag of starten nieuwe projecten, het B-team doet haar intrede. En daar gaat het vaak mis.
Sleutelposities zoals key-users, applicatiebeheerders, worden in de post-project fase vaak ingevuld door mensen die het op vele fronten afleggen tegen de oorspronkelijke A-team leden. Ze hebben het project niet of minder intensief meegemaakt en zijn dus niet op de hoogte van het hoe en waarom van belangrijke ontwerpbeslissingen, ze hebben niet het aantal vlieguren en ze zijn vaak minder emotioneel betrokken. Hoe goed de overdracht ook is, je ziet toch vaak een terugval in de kwaliteit van het gebruik van applicaties, het naleven van het afgesproken proces, etc. En hoe langer hoe meer wordt er afgedwaald van wat oorspronkelijk het plan was, en verdwijnen doelen steeds verder uit zicht. Een paar jaar na de implementatie is er vaak weinig over van de ambities en kijken gebruikers geirriteerd terug op alles wat er is fout gegaan.
Betekent dat dat een projectteam nooit ontbonden kan worden? Nee, natuurlijk niet, dat zou niet realistisch zijn. Het is wel van belang om dit risico te onderkennen bij de start van het project, en continuiteit zoveel mogelijk te borgen, door onder meer op tijd te beginnen met het overdragen van kennis en lange termijn afhankelijkheid van individuele medewerkers te voorkomen. Maar het aller belangrijkste is om tijdens de implementatie een mechanisme in te richten om de kwaliteit van het planproces in uitvoering te monitoren en daarmee te kunnen bijsturen zodra de klad erin dreigt te komen. Een goede toets om te ontdekken of je werkelijk het A-team hebt opgelijnd is even checken of dit goed geregeld is...
Afgelopen week was de jaarlijkse zorg en ict beurs. Ik ben een middagje langsgewipt om te zien hoe de verschillende leveranciers van personeelsplanning software zich pesenteerden. Alle groten der aarde waren van de partij: Ortec met Harmony, Pink Roccade met DRP, Monaco, Planning IT met SP-Expert en Ayton. Heugelijk nieuws voor iedereen die op zoek is naar een peroneelsplanning pakket: het maakt helemaal niets uit voor welke oplossing je kiest! Het is een pot nat! Ze kunnen allemaal alles! 
