Activiteiten inrichten SaaS projectmanagement

Iedere stap binnen het selecteren van een SaaS oplossingen bestaat uit een aantal activiteiten. Het Inrichten van het SaaS projectmanagement bevat de volgende activiteiten:

Activiteit 1: De projectinitiatie

Tijdens de projectinitiatie komen een aantal onderwerpen aan de orde die later onderdeel van het projectplan zullen zijn. De opdrachtgever voert samen met de projectleider de initiatie uit. Ze hoeven dat echter niet alleen te doen. Enkele sleutelfiguren en/of materiedeskundigen kunnen hen daarin bijvoorbeeld bijstaan. Met elkaar zullen zij de volgende onderdelen vaststellen:

• Aanstellen van de projectleider en vaststellen van zijn verantwoordelijkheden.
• De projectleider wijzen we definitief aan en we stellen tevens vast hoe ver hij of zij met het nemen van projectbeslissingen kan gaan.
• We stellen de opdracht en de afbakening van het project vast.
  Deze beslissingen zijn namelijk bepalend voor de omgang en de personele bezetting van het project. De doelstellingen moeten dus aan het eind van de initiatie vastliggen.
• We stellen de projectorganisatie vast.
• We bepaald wat voor structuur het project krijgt en welke teams we moeten samenstellen.
• Opstellen van een lijst met projectaannames

Alle betrokken dienen op de hoogte te zijn van de belangrijkste aannames die gelden voor het project. Bekende aannames zijn de uitgangspunten en randvoorwaarden. Vaak gaan we al uit van een cloud-platform of een standaard interface met leveranciers en klanten. Het wijzigen van de aannames tijdens het project kan leiden tot grote gevolgen voor de planning en de kosten.

Opstellen van lijst met succesfactoren

Iedereen die betrokken is moet weten welke factoren het project tot een succes maken. Een aantal algemene succes factoren zijn:

• Betrokkenheid van de gebruikersorganisatie.
• Commitment van het management.
• Competente projectleden.
• Heldere communicatie.

Verder zijn er in ieder project specifieke succesfactoren te bedenken, die gelden voor die organisatie. Bijvoorbeeld, hoe zal de   software bijdragen aan de business van de organisatie? De lijst met succesfactoren stemmen we af met de opdrachtgever. Het project geven we tevens een duidelijke herkenbare naam. Als er over het project wordt gesproken weet iedereen welk project we bedoelen.

De basis leggen voor het communicatieplan

Definieer een communicatiedoelstelling en bepaal wat de betrokken partijen zijn, wat hun behoefte is, hoe we ze moeten benaderen en welke beschikbare middelen hebben we hiervoor hebben. Vanuit deze basis kan het communicatieteam verder.

Activiteit 2: Projectorganisatie, activiteiten voor het selecteren van de juiste medewerkers

Na de projectinitiatie gaat de projectleider aan de slag om de projectgroep te formeren. Vanuit de projectinitiatie weet hij eveneens welke andere teams samengesteld moeten worden. De teams die gelijk aan de slag gaan moeten het eerst worden samengesteld, de andere teams kunnen alvast worden benoemd. Deze teams komen dan nog niet bij elkaar maar krijgen wel de stukken zodat zij zich een oordeel kunnen vormen over hun toekomstige bijdrage. Als daar behoefte aan is staat het hen vrij om ook in een eerder stadium bijeen te komen.
Binnen deze activiteit kan ook worden bepaald wat de vergader frequentie moet zijn.

• Opdrachtgeversgroep.
  De opdrachtgeversgroep komt iedere maand bij elkaar en bemoeit zich echter alleen met de grote lijnen. De stukken die daar namelijk op tafel komen gaan over de voortgang, de besteding van het budget en de eventuele knelpunten.
• Projectgroep.
  Binnen de projectgroep worden alle mijlpaalproducten besproken en beoordeeld. Afhankelijk van de fase waarin het project zich bevindt kan de vergaderfrequentie variëren.

Activiteiten om de juiste mensen te vinden

Een verkeerde samenstelling van een team kan veel leed veroorzaken voor een project. Daarom is het belangrijk om zorgvuldig te selecteren. Om te beginnen kunnen we aan de afdelingsmanagers die in de projectgroep zitten vragen om medewerkers voor het project vrij te stellen. Zij moeten namelijk bereid zijn om hun beste mensen te leveren. Alle taken die in de projectinitiatie zijn gedefinieerd moeten we bovendien aan medewerkers kunnen toewijzen. Als blijkt dat de organisatie niet zelf de gevraagde capaciteit kan leveren, zullen we deze moeten inhuren.

Vragen bij samenstellen van het projectteam

Bij het samenstellen van de teams moet de projectleider met de volgende vragen rekening houden:

• Zijn alle, volgens de projectinitiatie benodigde bekwaamheden binnen de organisatie te vinden?
• Is bij de selectie van medewerkers rekening gehouden met de bekwaamheden van deze medewerkers?
• Bevat het project ook voldoende elementen om de vaardigheden van de medewerkers tot hun recht te laten komen?
• Is bij de indeling van de medewerkers eveneens rekening gehouden met de beschikbaarheid van deze medewerkers?
• Zijn de medewerkers voldoende gemotiveerd om de geplande producten op tijd op te leveren?
• Is de afdelingsmanager duidelijk gemaakt hoeveel tijd zijn medewerkers aan het project moeten besteden?
• Worden voor de activiteiten medewerkers ingezet die waarschijnlijk ook in latere fases gaan deelnemen?
• Is het aantal geselecteerde medewerkers zo klein mogelijk?

Activiteit 3: Projectplanning: Schatten van kosten en doorlooptijd.

Voorafgaand is ingeschat hoeveel uren werk de komende stappen bij benadering in beslag gaan nemen. Daarbij houden we tevens rekening met de uren die nodig zijn voor het maken van documentatie, rapportages en projectleiding. De tijd die nodig is voor projectleiding hangt af van de ervaring van de projectmedewerkers en de mate waarin het plan wordt gevolgd. Als ervaren medewerkers het projectplan strak volgen is minder aansturing nodig. Daarom moeten we 10 tot 20 procent van de tijd reserveren voor de projectleiding.

Gevoel voor kosten

Het schatten gebeurt in meer dan 90% van de projecten op basis van ervaring en gevoel. Omdat nog niet duidelijk is wat de echte omvang van de in te voeren software is kunnen we geen definitieve antwoorden gegeven op de kosten en doorlooptijden hiervan.
Bedenk echter het volgende:

• Als de het projectplan met de schatting eenmaal geaccepteerd is, wordt de tijdschatting ineens een deadline. Communiceer helder over de betrekkelijkheid van de planning.
• Na het kiezen van de SaaS oplossing of software pakket, zullen we daarom de planning en het budget bijstellen.
• Aan het eind van het project is de schatting dus een maatstaf waarop de opdrachtgever het projectteam zal “afrekenen”.

Globale functionaliteit

De gewenste functionaliteit van de software is in dit stadium nog niet concreet, ook niet voor de opdrachtgever. De organisatie heeft behoefte aan software dat een bedrijfsproces moet ondersteunen. Hoe deze software er precies uitziet is echter nog niet helemaal duidelijk.
De definitie van de functionaliteiten die de software moet ondersteunen (requirements) wordt pas in de volgende stappen gemaakt. Toch moeten de functionaliteiten van de software oplossing in zekere mate duidelijk zijn bij de start van een project. Zodoende kunnen we ook uitzoeken wat zulke SaaS oplossingen ongeveer kosten.

Andere bronnen

Om enigszins een richtingsgevoel te krijgen, kan informatie worden verzameld uit verschillende bronnen.

• Eerdere ervaringen van de medewerkers binnen de organisatie.
• Ervaringen van collega organisaties van een vergelijkbare omvang die soortgelijk software hebben ingevoerd.
• Benchmark gegevens.
• Publicaties in vakliteratuur en internet.

Licentie kosten

Voor het bepalen van de licentiekosten moeten we meestal bepalen hoeveel gebruikers van de software gebruik gaan maken. Dit kunnen zijn:

• Concurrent users.
• Named users.

Nauwkeurigere schatting

Voor projecten die in deze globale schatting boven de 200.000 euro of de geldende aanbestedingsgrens komen moeten we de Driepunten techniek inzetten voor een meer nauwkeurige schatting. Dit is namelijk nodig in verband met een meer nauwkeurige berekening van de projectrisico’s.

Activiteit 4: Risico analyse

Een belangrijk onderdeel van het werk van de projectgroep is het beheersen van de projectrisico’s. De projectgroep voert daarom een risicoanalyse uit. Risicobeheersing heeft als doel het opsporen van risico’s die het project bedreigen en deze risico’s vervolgens beheersen. Het is echter niet nodig om alle risico’s te elimineren. Dat zal waarschijnlijk te veel geld en inspanning kosten. Als blijkt dat het project grote risico’s met zich meebrengt moeten we twijfelen aan de haalbaarheid van het project. Mogelijk moeten we de projectdoelstellingen bijstellen.

Berekenen project risico

Risico = de Kans dat een dreiging zich voordoet maal de Schade die dat tot gevolg heeft:
R = K * S
Een kleine kans met veel schade levert een laag risico op (evenals een grote kans op een kleine schade). Een grote kans gecombineerd met een hoge schade zal dus een groot risico vormen voor het project.

Risico’s van gehele project overzien

Een projectleider moet zich vanaf het begin van het project bewust zijn van de risico’s van het gehele project en zich niet beperken tot bijvoorbeeld de selectie. Naarmate het project vordert nemen de risico’s voor het project echter af. Iedere stap kent bovendien zijn specifieke risico’s.
Risicobeheersing houdt dus in dat we de risico’s die het project bedreigen onderkennen en het nemen van maatregelen op deze risico’s.

Acties en activiteiten op risico’s

Er zijn vijf soorten acties die we kunnen ondernemen met betrekking tot de risico’s: acceptatie, preventie, reductie, overdracht en escalatie. Een klein risico kunnen we gemakkelijk accepteren. Een groot risico moeten we aan de opdrachtgever voorleggen. Kan het project wel doorgaan?
Als de projectbegroting lager is dan 200.000 kunnen we volstaan met een lijst van risico’s en maatregelen. Bij grotere projecten is het echter noodzakelijk om het risico beter te berekenen. Deze rekenmethode is uitgewerkt in het verdiepende artikel “Uitgebreide risico-analyse voor IT projecten”.
Veel voorkomende projectrisico’s zijn:

• Geen duidelijke opdrachtgever.
• Geen goede projectleider.
• Een onduidelijk doel, onduidelijke afbakening.
• Geen goed projectplan.
• Niet alle competenties zijn in de projectgroep aanwezig.
• Tijdens het project verandert het doel.
• De nieuwe software blijkt achteraf niet in de behoefte te voorzien.
• Leveranciers die niet op tijd leveren.
• Overschrijding van de kosten en looptijd schattingen.
• Onvoldoende tijd om de deliverables te maken leidt tot kwaliteitsverlies.
• Onvoldoende tijd om de deliverables te controleren leidt tot kwaliteitsverlies.
• De beslisstructuur binnen het project is te complex.
• Onvoldoende betrokkenheid van de ICT afdeling.
• Onvoldoende betrokkenheid van de gebruikersorganisatie.
• Bedreigingen van buitenaf zijn niet onderkend.

Activiteiten voor het bepalen van specifieke risico’s

Ieder project kent zijn eigen specifieke risico’s. Voor al deze risico’s dienen we een analyse te maken. Het complete beeld van de risico’s is namelijk bepalend voor de haalbaarheid van het project. Het is te hopen dat de kans op alle risico’s klein is want de schade kan enorm zijn.
Bovendien nemen de risico’s toe naarmate meerdere projecten die elkaar raken tegelijkertijd lopen.

Activiteit 5: Samenstellen projectplan

Nadat de activiteiten 1 tot en met 4 zijn afgerond kan de projectleider het projectplan maken. Alle producten uit de eerdere activiteiten neemt hij op in het plan.

Activiteit 6: Activiteiten voor de validatie van het projectplan

Laat het projectplan reviewen door meerdere betrokkenen. Het gaat hier niet alleen om de opdrachtgever maar ook om de projectgroep en de materiedeskundigen. Iedereen kijkt er bovendien naar vanuit een eigen perspectief. Zodoende kunnen er soms verrassende opmerkingen komen waar de anderen helemaal niet aan gedacht hebben.
Het valideren van het projectplan vindt plaats vanuit 3 verschillende perspectieven.

Inhoudelijke validatie

In de eerste plaats is dat natuurlijk inhoudelijk.

• Kloppen de bedragen?
• Kloppen de namen?
• Zijn de datums correct?
• Klopt de planning?
• Zijn alle risico’s benoemd?
• Is de fasering juist?
• Is de afbakening van het project juist?
• Zijn alle bedrijfsprocessen die gekoppeld worden benoemd?
• Kan een Go-nogo beslissing worden gemaakt op basis van het plan?

Validatie opzet

In de tweede plaats kijken we naar de opzet van het plan.

• Kloppen de paginanummer?
• Klopt de inhoudsopgave?
• Kloppen de verwijzingen?
• Zijn de schema’s goed leesbaar?
• Klopt de huisstijl?
• Is het taalgebruik foutloos?

Procedurele validatie

Ten derde moeten we kijken naar de procedurele aspecten:

• Is de validatietermijn duidelijk?
• Zijn de reviewers benoemd?
• Zijn de distributie en de routing van het document aangegeven?

Discussieer mee op LinkedIn.