Als je naar de geschiedenis van (modern) projectmanagement kijkt dan zie je dat het vak van projectmanager zich vooral heeft ontwikkeld in periodes waarin er veel technologische vernieuwing was. Bijvoorbeeld tijdens de bouw van wolkenkrabbers en spoorwegen in de eerste decennia van de 20^e eeuw.

En later tijdens de race naar de maan. Daarna en tot nu tijdens de verschillende golven van digitale ontwikkelingen (automatisering, internet, AI).

Je zou kunnen zeggen dat projectmanagement als discipline in de technische wereld is ontstaan en pas later ook in andere organisaties nuttig bleek (overheid, zorg, dienstverlening).

Competenties van de technische projectleider

Technisch projectmanagement is dus niet anders dan ‘regulier’ projectmanagement. Wel vraagt een technische omgeving soms een andere focus en competenties dan projectmanagement in een dienstverlenende omgeving, bij de overheid of in de zorg.

Omdat techniek in vele vormen bestaat is de stijl van projectmanagement vaak in de verschillende technische sectoren ook specifiek. Chemische industrie, landbouw, energietechniek, de bouw, installatietechniek, productontwikkeling, techniek bij defensie, logistiek, recyclingbedrijven, waterbeheer, ICT, onderhoud en infrastructuur zijn allemaal voorbeelden van omgevingen waar je veel technische projecten tegen zult komen.

Wat is belangrijk voor een technische projectmanager om zijn vak goed uit te oefenen in zo’n technische omgeving?

Aanbevolen trainingen

De ProjectCheck als ondersteunend instrument

Door Antonie Reichling en Tineke Jacobs. Dit artikel verscheen eerder in Kwaliteit In Bedrijf.

Evalueren is vaak een verplicht nummer: het moet, maar het is niet écht leuk en bovendien komt van de goede voornemens veelal bar weinig terecht, met name als een project pas aan het eind wordt geëvalueerd. Toch is het zeker voor mensen uit het kwaliteitsvak evident dat evalueren erbij hoort: de ‘Act’ uit de Deming-cirkel (een vierstappen-model voor continue procesverbetering en kwaliteitsmanagement) is er niet voor niets. In dit artikel geven we handreikingen om meer te halen uit projectevaluaties en presenteren we De ProjectCheck als ondersteunend instrument.

Mogelijk redenen waarom projecten niet geëvalueerd worden

‘Gebrek aan tijd’ en ‘er wordt toch niets met de conclusies gedaan’ zijn veelgehoorde redenen om projecten niet te evalueren. Herkenbaar, maar ook onbevredigend. Is de uitleg werkelijk zo simpel en waarom slagen maar weinigen erin deze drempels te overwinnen? Wat is het ‘probleem-achter-het-probleem’?

In een recent artikel noemden wij een aantal aanvullende redenen, waaronder een te eenzijdig – instrumenteel – perspectief op het project, leren en verantwoorden zijn een slechte combinatie, en het niet betrekken van alle belanghebbenden bij de evaluatie (Jacobs, Reichling 2014). Opmerkende dat zelfs een eenduidige definitie voor projectevaluatie ontbrak, stelden wij de volgende voor: ‘Het tijdens het project met regelmaat met alle stakeholders vaststellen van de stand van zaken van het project, waarbij twee vragen centraal staan: Wat hebben we gedaan en gelaten zodat we op dit moment dit (tussen-) resultaat hebben?, en: Welke acties zijn nodig om in het vervolg van het project, en in vol-gende projecten, zeker zo effectief te werk te blijven gaan?’

Evaluaties het ondergeschoven kindje?

Wat valt ons nog meer op als we kijken naar projecten? Vergaderingen, die inspireren? Waar vind je die? Projectevaluaties, die inspireren? Hetzelfde. Het lijkt wel of projecten evalueren niet leuk kan zijn. En dan hebben we nog het jargon, dat helpt ook al niet. End of stage reports, business objectives, changelogs, product owners, team members, de ‘list of impediments’… het is om horendol van te worden… Sterker nog: het vergroot de kans dat de deelnemers elkaar misverstaan.

Vanuit de constatering dat evaluaties onnodig het ondergeschoven kindje zijn, en dat een aantal redenen daarvoor eenvoudig geadresseerd kunnen worden, hebben de auteurs samen met collega Bart Terlingen het ondersteunend instrument De ProjectCheck ontworpen. In dit artikel geven wij een aantal aanvullende handreikingen voor het gebruik daarvan.

Vergroting effectiviteit: verbreed het perspectief van uw evaluatie

De reikwijdte van de evaluatie draagt veel bij aan de effectiviteit. Standaard staan twee onderwerpen op de agenda: Wat ging goed? En: Wat kan of moet beter?

Voor de verbetering van dat laatste ligt het voor de hand antwoorden te zoeken in de samenwerking binnen het eigen team of in de wijze waarop de projectmanagementmethode is toegepast. Dit zijn namelijk factoren die zelf te beïnvloeden zijn, en zo kom je niet – of in elk geval minder – te zitten met het gevoel dat ‘er toch niets met de conclusies wordt gedaan’.

Je beperken tot deze twee vragen vergroot echter de kans dat in een volgend project dezelfde fouten worden gemaakt. Er zijn, behalve de samenwerking binnen het projectteam, meer factoren die het projectverloop beïnvloeden. Denk daarbij aan het krachtenveld rond het project, de keuze van het project en het projectmanagementklimaat. Zij zijn wellicht lastiger te beïnvloeden dan de teamsamenwerking, maar het zijn wel dé factoren die bepalen of ook in nieuwe projecten de lering uit eerder gemaakte fouten wordt toegepast.

Het project reikt verder dan het projectteam, de evaluatie dus ook

We zeiden het al: Een project bevindt zich in een krachtenveld. En dat heeft grote invloed op het verloop van het project. Dat is niets nieuws. Wat echter zelden gebeurt, is dat alle belanghebbenden betrokken zijn bij het evalueren van het project. Doet u dat wel, dan voorkomt u dat er ‘over’ mensen en partijen wordt gesproken en niet mét hen, en komen belangenverschillen zo niet makkelijker, dan toch in ieder geval eerder, op tafel.

7 typen betrokkenen

Zo onderkent De ProjectCheck zeven typen betrokkenen (rollen) met evenveel verschillende perspectieven. Van directie via projectleider tot aan de projectomgeving. Voor iedere rol is op vierentwintig succesfactoren voor projectmanagement in de eigen taal en vanuit het eigen belang een stelling geformuleerd die de succesfactor weergeeft.

De drempel reduceren

Voor het projectteamlid is een voorbeeld: ‘In de voorbereidingsfase is er voldoende ruimte voor onze bijdragen’. De drempel om vanuit een generieke projectsuccesfactor te associëren naar wat maatgevend is voor het eigen project en de eigen organisatie, is zo tot een minimum gereduceerd.

Creëer een veilige omgeving

Het begint er soms al mee dat een ander ‘voor ons evalueert’, dat wil zeggen: er wordt een (technisch) evaluatierapport geschreven en dat wordt dan in het team besproken. Fout, weerstand, discussies, ingraven, afschuiven, verkeerde volgorde. En dan wordt evalueren vaak pas aan het eind van het project gedaan, waarbij het primaire doel is: verantwoording van proces, resultaten en financiën aan de opdrachtgever.

Verantwoording versus veilig leren

Verantwoording verhoudt zich slecht met ‘open’ evalueren om iets te leren. Immers, als de opdrachtgever een oordeel moet geven, kan het verstandig zijn om niet het achterste van je tong te laten zien. Voor leren heb je juist een veilige situatie nodig.

Dit heeft gevolgen voor de vraag welke belanghebbenden u wanneer bij elkaar brengt. Belanghebbenden laten zich groeperen in strategische, tactische en operationele belanghebbenden, waarvoor u evenzovele evaluaties kunt organiseren.

Worden de beste projecten gekozen?

Doe eens een stap naar achteren en wees eens heel eerlijk: Is het verstandig geweest juist dit project uit te voeren? Hierbij is de vraag of het project een succes was niet eens zo relevant. Waar het om gaat is: in hoeverre heeft het project werkelijk bijgedragen aan de strategie van uw bedrijf? Zou u met de kennis van nu nog steeds…? En wat betekent dat voor de toekomstige keuzes die u gaat maken?

Strategie en projecten

Het gaat dan over programmamanagement, vaak een impopulair onderwerp. Programmamanagement, gepositioneerd tussen strategie en projecten, maakt enerzijds zichtbaar waar in de organisatie projecten uitgevoerd worden die niet bijdragen aan de strategie, maar maakt ook duidelijk waar de projectcapaciteit – projectmanage-mentcapaciteit, uitvoeringscapaciteit, verandercapaciteit – overschreden wordt. Met andere woorden: Het maakt zichtbaar waar het management tegen de capaciteitsgrenzen van de organisatie oploopt en daadwerkelijk zal moeten prioriteren.

Het zal duidelijk zijn dat niet alleen de betrokkenen op het strategisch niveau goed in staat zijn iets over deze vraag te zeggen! Vijf van de vierentwintig stellingen van de projectcheck betreffen dit onderwerp.

Bezie alle projecten in de context van de reguliere processen

Evalueren gebeurt op projectniveau. Wat we minder tegenkomen is dat gekeken wordt naar de grootste gemene deler van alle projecten in de organisatie. Natuurlijk gaat het dan om de vraag of de projecten voldoende bijdragen aan de gestelde doelen, en of de resultaten behaald worden binnen tijd en met de juiste kwaliteit. Maar daaraan kunnen nog andere aspecten worden toegevoegd.

Spagaat tussen project en reguliere business

Bekend is de spagaat tussen project en reguliere business waarin projectmedewerkers zich al snel bevinden. Tenzij het project in een volledige projectorganisatie uitgevoerd wordt, zal er altijd sprake zijn van die spanning.

De vraag is in welke mate hogere echelons zich bewust zijn van dit gevaar en daarnaar handelen. Hoe vaak staat een opdrachtgever in het MT op de bres voor het project door de problemen op bemensingsgebied ter discussie te stellen? Of, in welke mate accepteren collega-managers dat projectleden apart aan hen rapporteren over een project, waarbij de projectleider wordt gepasseerd? U kent vast nog meer van zulke voorbeelden.

Intrinsiek gemotiveerde verantwoordelijkheid als visie

Uiteindelijk is een succesvol project in hoge mate afhankelijk van wat we zouden kunnen noemen intrinsiek gemotiveerde verantwoordelijkheid van alle betrokkenen in en rond het project. De betrokkenen doen de noodzakelijke dingen proactief en niet omdat ze daartoe bij voortduring aangezet moeten worden. Misschien utopisch, maar als visie het nastreven waard. Een visie die we in De ProjectCheck verwerkt hebben met behulp van het teameffectiviteitsmodel (Fry, Rubin, Plovnick 1981).

Leuker evalueren: verbeter het proces

Een projectevaluatie vraagt een stevige inhoudelijke component en dat leidt kennelijk tot weinig aandacht voor de vorm. Terwijl het één het ander niet hoeft uit te sluiten. Laten we eens kijken. Zet met ‘alle’ betrokkenen (zie eerder) vier stappen:

1. warm bad;
2. koud bad;
3. oorzaakanalyse; en
4. concrete acties met gemotiveerde actiehouders.

Effectief evalueren: doen en dan bewijst het zichzelf

Vatten we alles samen, dan handelt het om een breed perspectief en een constructief proces. Betrek alle betrokkenen in het evaluatieproces, maar scheid verantwoorden van leren. Dat betekent mogelijk dat in verschillende samenstellingen het project of projectmanagement in het algemeen wordt geëvalueerd.

Bibliografie

Jacobs, T., Reichling, A. (2014) Projecten evalueren, Zes redenen waarom het er te vaak niet van komt – in Sigma, Nr. 4,  september 2014; Fry, R., Rubin, I., Plovnick, M. (1981); “Dynamics of Groups that Execute or Manage Policy.” In “Groups at Work” ed. Roy Payne and Cary L. Cooper, Hoboken: John Wiley, and Sons; Websites: Systeemdynamica, http://en.wikipedia.org/wiki/System_dynamics

Over de auteurs

Antonie Reichling helpt met zijn expertise in programma- en projectmanagement organisaties hun verandercapaciteit optimaal te benutten en oplossingen van strategische waarde te creëren. Als Certiked-beoordelaar is organisatie-leren voor hem speerpunt. Kijk voor meer informatie op www.reichling.nl.

Tineke Jacobs is projectmanagementspecialist met een focus op ICT-projecten. Zij is trainer en projectcoach, en staat ook regelmatig zelf ‘met de voeten in de klei’ als projectmanager.

Antonie en Tineke ontwikkelden samen met collega Bart Terlingen De ProjectCheck, een evaluatie-instrument voor projectmanagement.

Hoe voer je projecten uit in een zorgomgeving?

In de basis is projectmanagement in de zorg en welzijnssector niet anders dan projectmanagement in andere omgevingen, maar toch zijn er een aantal specifieke dingen waar je op moet letten.

Alle bovenstaande voorbeelden van projecten in de zorg hebben een heel verschillend en resultaat een zullen ook om een verschillende aanpak vragen. Dan is er ook nog variatie in aanpak het tussen (hele) grote projecten of programma’s en de kleinere projecten. Dat betekent dus dat er geen standaard methode is voor projecten in de zorgsector.

Hoe kan projectmatig werken helpen?

Stel dat je als projectleider aan het begin van een zorgproject staat, wat zijn dan de dingen die helpen? Als je kiest voor een projectmatige aanpak dan maak je gebruik van een aantal principes:

Helder over doelen, tussenresultaten en middelen

Transparant werken betekent dat je als projectteam en als beslissers weet waar je aan toe bent: Wat is het doel van dit project en wat is het resultaat? Hoe en hoe vaak gaan we dat meten? Hoeveel geld mag iets kosten? Wanneer moet iets klaar zijn? Enzovoort. Dit helpt bij het volgende punt: de verdeling van het werk en het mandaat

Verdeling van het projectwerk

Iedereen heeft het te druk en zeker in de zorg hebben medewerkers vaak last van werkdruk. Op het moment dat je in je project gaat werken met duidelijke rollen en taakverdelingen en ook duidelijkheid schept over de besluitvorming dan voorkom je dat werk dubbel, in de verkeerde volgorde, te laat of helemaal niet gedaan wordt. Dat brengt rust omdat de projectmedewerkers weten waar ze aan toe zijn.

Een project gaat in een aantal stappen

Of je nu een project meer lineair of meer agile aanpakt, in beide gevallen gaat het project in een aantal fases. Uitgangspunt is dat je eerst nadenkt over wat er allemaal moet gebeuren, dan besluit, prioriteert en een planning maakt. En dan die planning uitvoert. Dit voorkomt dat al het werk op een grote hoop komt te liggen en je er geen controle over hebt anders dan dat je elke dag maar een stukje doet van de berg werk doet. Als je planmatig werkt, geeft dat controle over het werk omdat je het in stukjes uitvoert. Dit biedt individuele voordelen (timemanagement!) en geeft ook grip op de doorlooptijd van het project in zijn geheel.

Onzekerheid bij projectmanagement

Projecten gaan nooit precies volgens planning waardoor je als projectleider moet kunnen leven met een bepaalde mate van onzekerheid en onvoorspelbaarheid. Dat wil niet zeggen dat je dus maar helemaal niet meer hoeft te plannen! Maar risico’s en onzekerheid horen bij projecten en de beste manier om daar mee om te gaan is om daar open over te zijn, met name naar de opdrachtgevers en andere stakeholders.

De cultuur van zorgorganisaties

Tenslotte doe je projecten in de regel samen. Het is dus groepswerk en je hebt te maken met de organisatiecultuur waarbinnen je het project moet doen. Organisatieculturen verschillen van land tot land, sector tot sector, organisatie tot organisatie en afdeling tot afdeling.

Je kunt je voorstellen dat als je een project moet doen, samen met een ICT leverancier en een aantal administratieve medewerkers van verschillende afdelingen dat daar een heel andere sociale dynamiek geldt dan bijvoorbeeld wanneer je een fusie moet regelen tussen twee afdelingen waar medisch specialisten de scepter zwaaien. Of bij een project in de jeugdzorg met zorgmedewerkers die dagelijks contact hebben met jongeren.

De cultuur van een werkomgeving is een belangrijke succes- of faalfactor bij projecten. Het is tenslotte mensenwerk. We zien aan de ene kant dus dat er een hele brede waaier is van soorten projecten binnen de zorg en dat de organisatiecultuur erg kan verschillen van plek tot plek en aan de andere kant moeten we rekening houden met een grote invloed van de werkcultuur in de zorg op het al dan niet slagen van je project.

Meestal wordt er gesteld dat je ‘in de zorg’ te maken hebt met een mensgericht cultuur, een warme omgeving waar men veel aandacht heeft voor de mensen die er werken (*). Dat is ook wel logisch omdat zorginstellingen gericht zijn op zorg voor mensen. Uiteraard is dit een vrij algemene omschrijving van ‘de werkcultuur’ in de zorg en zal het van organisatie tot organisatie maar ook van afdeling tot afdeling anders zijn.

Uitdagingen voor projectmanagement in de zorg

De mensgerichte cultuur brengt uitdagingen met zich mee in die zin dat de doelgerichte aanpak van projectmanagement wel eens botst met de mensgerichte focus van een organisatie. Wat is belangrijker? Een deadline, binnen budget werken of dat iedereen zich prettig voelt? De uitdaging voor projectmanagers in de zorg is dus om de projecten op tijd en binnen budget af te krijgen zonder dat ze focus op de menskant uit het oog verliezen.

Het helpt als een projectleider in de zorg vaardig is in de soft skills. Regelmatig zullen communicatieve vaardigheden ingezet moeten worden om het project op gang te houden. Een goed begrip van de (sociale) context van een project is ook nuttig om te begrijpen hoe belangen van stakeholders liggen en waar mogelijke weerstand te verwachten valt (en hoe daarmee om te gaan). De meeste professionals die in de zorg werken hebben al veel training gehad in soft-skills in hun eigen opleidingen. De bedrijfskundige en organisatorische kant van projectmanagement is in de regel nieuw terrein.

Andere uitdagingen voor projecten in de zorg kunnen zijn dat ze vaak in een overheid of semi-overheid omgeving plaatsvinden en moeten voldoen aan veel regels (bijvoorbeeld vanuit de zorgverzekeraars of de overheid).

Welke opleiding heeft een projectleider in de zorg nodig?

Een beginnende projectleider in de zorg heeft het meest baat bij een basisopleiding projectmanagement of projectmatig werken. Liefst een training waarin er ook soft skills geoefend worden.

Na die basisopleiding kan een gevorderde projectleider zich verder ontwikkelen met verdere soft skills trainingen (afhankelijk van de behoefte). Dit zijn dan meer trainingen gericht op zachte vaardigheden binnen de context van management en leiding geven, zoals:

Agile werken in de zorg

Agile is een relatief nieuwe vorm van samenwerken binnen projecten. De methode gaat ervan uit dat je bij sommige projecten niet goed alles kunt voorzien, waardoor het niet zo veel zin heeft om lang vooruit te plannen en dikke projectplannen te maken (die dan toch niet zo uitgevoerd gaan worden). De aanpak wordt daarom kort cyclisch gedaan: om de paar weken wordt een stukje van het project uitgevoerd, opgeleverd en dan wordt er dan besloten hoe verder te gaan.

Deze ‘lenige’ aanpak zien we succes hebben bij onder andere ICT gerelateerde projecten, communicatie afdelingen en bij innovatieve projecten. Voor sommige projecten in de zorg kan agile werken ook voordelen bieden, maar hou er rekening mee dat het niet voor alle projecten werkt. We adviseren projectleiders in de zorg eerst een (algemene) projectmanagement opleiding te volgen en daarnaast aanvullend agile te leren. Agile is een standaard training die we standaard als e-learning extra aanbieden bij onze basisopleiding projectmanagement.

IPMA

Mocht je overwegen om je te ontwikkelen tot projectmanagement professional in de zorgsector dan zou je kunnen overwegen om je IPMA certificaat te behalen. Binnen IPMA worden (onder andere) relevante bedrijfskundige onderwerpen zoals: begroten, plannen, contractvorming, kwaliteitsbeheer en andere behandeld. Dit zijn competenties die je als professionele projectmanager moet beheersen en die in de regel geen onderdeel zijn van de reguliere zorgopleidingen.

Als je nog vragen hebt over projecten in de zorg, agile of andere gerelateerde zaken, neem graag contact met ons op.

(*)Zie bijvoorbeeld het cultuurmodel van Handy

In de Scrum Guide staat over de rol van Scrum Master het volgende:

“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.” (bron)

Met andere woorden: het eerste wat je als Scrum Master goed moet beheersen zijn alle regels van het Scrum Proces. Jij weet wanneer iets wel of niet op de ‘scrum manier’ gaat. En als bij de mensen in het team de Scrum regels en procedures nog niet bekend zijn dan is het jouw taak om die uit te leggen en aan te leren.

Scrum Master Certificaat

Een manier om je ervan te verzekeren dat je de Scrum regels door en door beheerst is door het behalen van een Scrum Master certificaat. Het examen voor zo’n Scrum Master certificaat bestaat, afhankelijk waar je het afneemt, meestal uit zo’n 80 meer-keuze vragen waarvan je 85% goed moet beantwoorden. In onderstaande video zie je hoe het Scrum Master examen er bij ons eruit ziet:

Deze examens zijn best pittig omdat je Scrum vragen kunt krijgen over alle details. Ook is het Engels in de examens best lastig als het niet je moedertaal is. Bij Projectmanagement-training.nl kan je daarom de examens zowel in het Engels doen als in het Nederlands.

In de praktijk geeft het certificaat zelfvertrouwen omdat je de details van Scrum weet. Bij de implementatie van Scrum ontstaat er snel allerlei discussie en mogelijk ook weerstand en dan weet jij in ieder geval wat de spelregels van Scrum zijn. Het kan bijvoorbeeld best zo uitpakken dat het team besluit dat jullie het toch anders willen, maar dan jij weet tenminste hoe het zou moeten volgens de regels en welke nadelen er zijn van een ‘alternatieve’ aanpak. Lees hier meer over onze basistraining Scrum Master

Scrum Master in de praktijk

Een Scrum Master certificaat is pas het begin. Als je een PSM-1 certificaat hebt (of gelijkwaardig zoals ons eigen certificaat van Projectmanagement-training.nl) dan beheers je de basisregels van een Scrum project. In de praktijk zal je als Scrum Master niet alleen leiding moeten geven aan Scrum Teams, maar ook aan de moederorganisatie die misschien nog niet gewend is aan Scrum. Je zult moeten coachen, weerstand wegnemen, soms het Scrum team beschermen, de Scrum verandering in de organisatie moeten leiden en dat alles terwijl de projecten gewoon door moeten gaan.

Een Scrum Master moet dus zeer vaardig zijn in communicatie en weten hoe je met groepsdynamiek, complexe organisaties en weerstand moet omgaan.

Wat doet een Scrum Master?

In de Scrum Guide staan onder andere de volgende taken en competenties van een Scrum Master beschreven:

• Coachend
• Hulpvaardig
• In staat blokkades op te ruimen
• Scrum proces implementeren en bewaken
• Het aanleren en ondersteunen van de andere Scrum rollen: Product Owners en Developers
• Het faciliteren van samenwerking
• Leiding geven aan de Scrum implementatie in organisaties
• Werken op empirische basis

Trainingen voor gevorderde Scrum Masters

Voor gevorderde Scrum Masters hebben we een aantal trainingen die met name de gevorderde competenties van een Scrum Master helpen:

Wie als Scrum Master zelf gecoached wil worden kan ook bij ons terecht. Neem contact op om hierover verder te brainstormen met ons over de aanpak en mogelijkheden.

Er zijn veel hulpmiddelen en tools die soms handig soms noodzakelijk zijn voor het goed managen van een project. Hieronder staan een aantal (software-)tools die handig kunnen zijn bij de uitvoering van je project. Let op, we hebben sommige van onderstaande tools uitvoerig getest, andere alleen hebben we alleen even kort bekeken. Het zijn dus geen aanbevelingen voor een bepaalde tool. De lijst is bedoeld als een service voor onze klanten. Als u een tool overweegt voor uw organisatie en u wilt overleggen of hulp bij de implementatie van een projectmanagement tool, neem dan contact op. Ook als er een (goede) tool is die ontbreekt horen we dat graag van u.

1. MS project is een bekende en zeer complete tool voor het maken van planningen (gannt charts, balkenschema’s), resourceplanning, taakverdelingen maar ook voor zaken als het bijhouden van uren en voortgang. In theorie kan je met deze tool alles administreren wat er in een project gebeurt. Toch zijn er veel projecten waar deze tool niet van toepassing is (dit geldt ook voor de alternatieven voor MS project). Ook zijn er projecten waarbij MS project (of een alternatief) noodzakelijk is. Reken op een flinke inspanning om MS project te leren.
2. Ganntproject is een gratis open source alternatief voor MS project, dat bovendien ook op Mac Osx en Linux werkt.
3. Open Project is een ander open source software pakket voor projectplanning
4. Toms Planner
5. Smartdraw
6. TeamGannt
7. Prinzi
8. Er zijn nog veel andere Alternatieven voor MS project . MS project is een prijzig softwarepakket dat men soms maar beperkt nodig heeft. De kans is groot dat u met een (gratis) open source variant goed uit de voeten kunt. Ook als u werkt met Apple computers of als u op zoek bent naar planningssoftware die draait op een tablet (bijvoorbeeld omdat u de gegevens op locatie wilt bijwerken en niet met een dikke laptop wilt rondlopen) zult u op zoek moeten naar een alternatief. Hier is nog een lijst van vergelijkbare software voor het maken van balkenschema’s te vinden. Bedenk goed welk(e) onderdelen van MS project of ander ‘Gannt chart programma’ u eigenlijk nodig heeft. Zelden gebruikt een organisatie alle mogelijkheden en vaak is een simpele (soms gratis) tool voldoende.

Portfolio en multiprojectmanagement tools

• Epic flow
• Fortes
• Spider
• Aurora
• Allex

Tijdschrijven

Tijdschrijven, een gevoelig onderwerp in veel organisaties, is soms onontkoombaar bij de beheersging van een (groter) project. Hieronder een aantal softwarepakketten waarmee je kan tijdschrijven (we doen geen aanbeveling!) :

1. Timewriter
2. Clockwise
3. Replicon
4. Worktimer

Er is nog veel meer tijdschrijfsoftware, ook gratis. Let op! Tijdschrijven voor een project vraagt om een aantal instellingen en mogelijkheden die niet geboden wordt door alle software pakketten voor tijdschrijven. Het gaat bij projecten bijvoorbeeld vooral om het bewaken van de voortgang en minder of niet alleen om de financiële bewaking (het bijhouden van het aantal verbruikte uren per project). Veel tijdschrijfsystemen hebben een te sterke financiële insteek en zijn daarom niet zo handig voor gebruik voor projectadministraties.

Integrale systemen

Met de opmerking dat we liever van simpele oplossingen houden dan van zeer uitgebreide ‘oplossingen voor alles’ hieronder een lijst van integrale projectmanagement softwarepakketten. Hierin zitten vaak planning, tijdschrijf, facturering, communicatie, koppelingen naar bedrijfsplanning software (ERP) en administratiemodules. Let op, niet alle bedrijfsbeheerssystemen zijn zomaar geschikt voor projecten (en het vaak grillige verloop ervan), ook al claimt de fabrikant van de software dat er een ‘projectmodule’ in zit.

1. 4cis
2. AllSolutions
3. Basecamp
4. Exact
5. Primavera
6. Bitrix
7. BamBam (ook geschikt voor agile)
8. Trello
9. Teamwork

Ook deze lijst is ver van compleet. Kijk hier voor meer opties.

Agile / Scrum tools

Tools voor agile / scrum projecten richten zich meestal op het beheersen van de product requirements lijst (product backlog of story lijst), met andere woorden op de verdeling van de taken in het team. Voorbeelden van min of meer bekende agile tools zijn:

1. Jira
2. Teampulse
3. EasyBacklog
4. DevPlanner
5. Monday
6. Rally
7. TargetProcess

Kijk hier voor meer agile hulpmiddelen.

Vergelijkingssites project management tools:

Er zijn websites waar je features kan vergelijken van de diverse aanbieders van projectmanagement software. Dat is handig, maar let erop dat je goed weet wat je wilt en dat het aanwezig zijn van een feature niet wil zeggen dat die feature ook handig werkt in de praktijk.

1. Projectmanagement software vergelijkingssite 1
2. Projectmanagement software vergelijkinssite 2

Simpele tools voor uw project

Vaak is eenvoudig het beste.

1. Templates voor projectmanagement in word en excel
2. Dropbox of een ander cloud alternatief

Tenslotte een belangrijk algemeen advies: neem eerst je projectmanagement processen zelf onder de loep voordat je aan allerlei tools gaat denken.

Projectmanagement komt in heel veel sectoren en vormen voor: in de zorg, bij overheden, in het onderwijs, in de industrie, bij start- en scale-ups, in de logistiek, bij maatschappelijke projecten, bij de ontwikkeling van duurzaamheid, in onderzoek, enzovoort. Bij onze opleidingen komen we dus ook mensen met en van diverse achtergronden tegen en dat maakt ons werk als opleiders alleen maar heel erg leuk.

Geen IT!

Een deel van de cursisten is expliciet op zoek naar projectmanagement kennis “zonder IT”.  Dat zien we niet alleen bij onze meer traditionele projectmanagement opleidingen, maar ook bij de Agile en Scrum opleidingen. En dat is best opmerkelijk, want Scrum en Agile zijn ontstaan en ontwikkeld in de wereld van software ontwikkeling en pas later ging men zien dat de principes van Scrum en Agile ook buiten de IT wereld (soms) toepasbaar zijn. Ook het meer klassieke projectmanagement heeft een grote ICT geschiedenis en wordt ook nog steeds veel toegepast bij IT projecten. Denk ook aan hardware en de aanleg van communicatie netwerken.

Angst voor techniek is niet nodig

Maar feit is – en dat zien we regelmatig- dat veel mensen een drempel ervaren als projecten te technisch worden. Want zeg nou zelf, zodra het over programmeercode gaat of zelf al het IT jargon is voor de meeste mensen totale abracadabra. Voor de meeste mensen zijn dit soort stukjes BASIC of Javascript code net zo lastig te lezen als een onbekende vreemde taal:

let myCity = "Eindhoven";

Maar alles wat hier in Javascript staat is: We geven de variabele myCity een tijdelijke ‘waarde’, namelijk “Eindhoven“. Dus bijvoorbeeld als iemand bij een invulveld van een website de postcode van het gebied Eindhoven invult (5600-5658), dan krijgt de variabele myCity de waarde “Eindhoven” . En dat kan je dan daarna verder gebruiken om bijvoorbeeld een controle te doen op adresgegevens of om een t-shirt te drukken met “hup PSV” erop. Als een ander persoon vervolgens 3000 invult dan geven we de myCity variabele de waarde “Rotterdam”. Dat doe je dan met de code: let myCity = “Rotterdam”.

Niet iedereen hoeft programma code te snappen maar iedereen kan het tot op zeker hoogte leren. En in ieder geval beter leren snappen wat het werk van programmeurs en IT-ers inhoudt. Want als je weinig van de techniek begrijpt doe je jezelf als projectleider, maar zeker als product owner te kort. Hoe beter je snapt wat programmeurs doen hoe beter je ook hun uitdagingen begrijpt en hoe beter je ook met hen in gesprek kunt gaan over je project. Over technische uitdagingen, over kwaliteitsborging en -zeker niet als laatste- over realistische planningen.

IT zit in (bijna) elk project

Niet alle projectleiders en zelfs niet alle Scrum Masters zullen kennis van IT nodig hebben in hun werkveld. Maar toch ook op plekken waar je het niet direct verwacht steekt er snel een IT component de kop op:

• De projectleider “zorgkaart” die meewerkt aan de ontwikkeling van een informatiesysteem waarop mantelzorgers en medische begeleiders informatie kwijt kunnen en kunnen opzoeken van patiënten
• Het duurzaamheidsproject van een Gemeente waarbij er een nieuwe mobiele app gemaakt moet worden voor betere communicatie met de bewoners
• De nieuwe website die studenten moet werven om komend jaar op jullie HBO instituut zich aan te melden
• De nieuwe kwaliteitseisen in de zorg die zoveel administratie opleveren dat je niet onder computerondersteuning uitkomt
• De inzet van een app voor het geschikt maken van een landbouwgebied voor het beheersen van onkruid met minder bestrijdingsmiddelen
• De organisatie van een hybride congres waarbij deelnemers aanwezig zijn, maar waarbij een groot deel ook online wordt gestreamed

Zelfs als een project niet een IT focus heeft, is er op zijn minst vaak al een subproject waarbij er bijvoorbeeld een website gemaakt moet worden voor de communicatie van het projectresultaat. En als een project groot wordt heb je snel ook IT middelen nodig voor de planning en projectbeheersing. Met de opkomst van AI zal er alleen maar meer vraag zijn naar kennis van IT.

IT is -helaas- vaak ook een struikelblok bij projecten en nodige veranderingen. Soms lukt het organisaties niet te veranderen omdat het niet lukt de IT op orde te krijgen. Een bekend voorbeeld is de belastingdienst die geen beleidswijzigingen van het kabinet kan doorvoeren door ICT problemen, waardoor belangrijke maatschappelijke veranderingen zoals pensioenhervormingen of vergroeningen uitgesteld moeten worden. Maar ook op kleinere schaal komen we IT als belemmerende projectfactor veel tegen bij organisaties.

Voor die mensen die open staan om meer te begrijpen van IT hebben we een online training BASIC ontwikkeld . BASIC is een veel gebruikte programmeertaal die bovendien  gemakkelijk te leren is. Het kent toepassingen bij het maken van Databases, Videogames, het intelligent laten werken van diverse Microsoft applicaties en voor de ontwikkeling van diverse algemene apps. BASIC is voor veel mensen het beginpunt van het leren van code, waarna ze daarna eventueel andere meer geavanceerde programmeertalen leren.

Programmeren voor Scrummers

Bij onze cursussen Scrum Master en de cursus Product Owner krijgt elke deelnemer nu een jaar lang gratis toegang tot de Programmeren in Basic cursus en/of de cursus Programmeren in Javascript (e-learning). Basic en Javascript zijn veel toegepaste programmeertalen in bijvoorbeeld office applicaties, websites, games en AI. In 10 lesblokken leer je stap voor stap hoe het coderen werkt en leer je eenvoudige programmacode te schrijven (met voorbeelden uit de wereld van videospelletjes).

Deze extra cursussen zijn niet verplicht, maar mocht je -zoals velen- de IT niet uit je project kunnen weren, dan kan je het beter omarmen. Je hoeft geen code expert te worden, maar een keer je eigen stukje code geschreven hebben zal je zelfvertrouwen en werk als product owner of scrum master goed doen. Neem contact met ons op als je vragen hebt over deze (aanvullende) opleidingen.

Als je een Scrum Master en/of een Product Owner examen wilt gaan doen bij Scrum.org dan hebben we een paar nuttige tips voor je:

1. Als je meedoet met onze Scrum Trainingen: Doe het examen pas als je onze eigen examen bij de cursus een aantal maal gedaan hebt. Dan heb je de meeste thema’s en standaard vragen wel voorbij zien komen en weet je of je de stof voldoende beheerst.
2. De oefenexamens bij de cursus geven een goede indicatie of je zult slagen bij Scrum.org, maar geen garantie. Als je bij onze examens een keer een voldoende hebt behaald (85% van de vragen goed) dan is dat nog niet genoeg: zorg ervoor dat je een aantal keer geslaagd bent voor de oefentoetsen (je mag ze toch zo vaak doen als je wilt bij onze trainingen).
3. Zorg er ook voor dat je een flink aantal maal 90-100% hebt gescoord bij de oefenexamens van Scrum.org zelf. Je kunt eventueel ook online op zoek gaan naar andere  scrum examenvragen, maar let goed op punt 7 hieronder. Bij twijfel kan je de vraag altijd voorleggen aan een van onze trainers via ons elearning platform en aan je medecursisten natuurlijk. Dat levert vaak interessante discussies op zeker als het gaat over hoe je Scrum moet toepassen in de praktijk. Geen organisatie is hetzelfde.
4. Zorg ervoor dat je de Scrum Guide bij de hand hebt. In de digitale versie kan je snel zoeken met trefwoorden, maar sommige mensen vinden een papieren versie erbij ook handig om snel dingen op te zoeken.
5. Het examen is weliswaar open boek maar zorg ervoor dat je de stof wel uit je hoofd beheerst, er is geen tijd om veel vragen op te zoeken. De meeste vragen moet je dus toch zo uit het hoofd kunnen beantwoorden. Bij onze Scrum trainingen krijg je een aantal tabellen met dingen die je paraat moet hebben (bijvoorbeeld wie moet bij welk Scrum event aanwezig zijn, wie niet en wie optioneel?). Zorg ervoor dat je deze tabellen bij de hand hebt.
6. Beantwoord eerst alle vragen en sta niet te lang stil bij de twijfelgevallen. Maak een notitie van de vragen waar je over twijfelde en ga daarnaar terug als je alle 80 vragen beantwoord hebt. Zo kom je niet in tijdnood en kan je de tijd die over is aan het einde gebruiken om twijfelgevallen op te zoeken.
7. Pas op met het online opzoeken van antwoorden. Sommige discussies over bepaalde vragen gaan aan de hand een oude versie van de Scrum guide die op details anders is dan de nieuwe.
8. Oefen dit alles met onze Scrum Examen simulatie. Dit zijn een aparte module bij de Scrum Master training en de Product Owner training waarmee je op realistische wijze een examen kunt oefenen. Deze modules zijn een extra kosteloze manier om te oefenen met examinering. Er is een examenmodule voor het Scrum Master certificaat en eentje voor het Product Owner certificaat (achter de link heb je een gratis voorproef van hoe deze oefenexamens eruit zien).

impressie van de scrum examen modules (beschikbaar voor Scrum Master en Product owner certificaten).

Tenslotte de laatste tip: het examen voor het Product Owner is uitgebreider dan het examen voor Scrum Master maar er is veel overlap in de stof en dus ook in de examenvragen. Het is zeker nuttig om ook te oefenen met Scrum Master vragen als je het Product Owner examen gaat doen en vice versa. Omdat er zoveel overlap is hebben wij onze basis scrum training ook gericht op beide rollen. Maar als je wilt kan je natuurlijk altijd alleen de Scrum Master of Product Owner module volgen.

Veel succes met je Scrum Examens!

PM Toolbox – Best practices in projectmatig werken

Als je je projecten wilt verbeteren dan is er een heel scala aan interventies die je kunt proberen. Sommige ingrijpend zoals het omschakelen naar agile werken en andere verbeterpunten heel klein zoals het doen van een onderzoek of er al een soortgelijk project eerder heeft plaatsgevonden voordat je start met een nieuw project. In onderstaande tabel staan een hoop verbeterpunten voor jouw project en het is aan jou om na te gaan in welke mate jullie die leerpunten in jullie aanpak van projecten hebben geïntegreerd. Let op dat de verbeterpunten soms in samenhang werken maar soms ook niet en het is zeker geen doel op zich om alle ‘vinkjes’ te halen. Bij sommige projectorganisaties helpt het wat meer te veranderen om stap te maken in projectvolwassenheid bij andere organisaties helpt een klein beetje meer structuur in een project al veel en is dat ook genoeg. Of leert de praktijk dat een paar kleine verbeteringen het maximaal haalbare is, bijvoorbeeld omdat de cultuur van projectmatig werken ontbreekt en de wens om dit te veranderen er ook niet is.

Zie hieronder verder de zelfscan voor je projecten. De lijst is niet uitputtend, maar een aantal belangrijke inzichten staan erin verwerkt. Neem gerust contact met ons op als je hier vragen over hebt.

(0 = niet; 1 = onvoldoende; 2 = kan nog beter; 3 = geïntegreerd)

 en vraag jezelf af: “Waarom doe ik dat niet ?”, “Hoe zou ik dat toch kunnen doen ?”

Dit is een bijdrage van Tom Jacobs. Hij is een van onze trainers projectmanagement, timemanagement en agile uit ons team.

Wie een Scrum of Agile certificaat wil behalen kan kiezen uit heel veel verschillende certificaten en uitgevende organisatie. Waar moet je nu op letten en wat zijn de overwegingen om wel of niet voor een bepaald examen met bijbehorend Scrum certificaat te gaan?

Een aantal dingen zijn van belang bij de keuze voor een certificaat:

1. De inhoud en kwaliteit van het certificaat
2. De bekendheid van het certificaat en acceptatie bij organisaties
3. Kosten en kosten op lange termijn
4. De duurzaamheid van een certificaat

Inhoud van Scrum certificaten

De meest gebruikte Scrum certificaten van de diverse uitgevende organisaties sluiten in de eerste plaats aan bij de rollen die je hebt in een Scrum team: Scrum Master, Product Owner, en Developers. Met het behalen van een Scrum Master, Product Owner of Developer certificaat bewijs je dat je de spelregels van Scrum voor die rol kent. Daarnaast zijn er (nieuwere) certificaten bedacht die gaan over Agile Leiderschap, Scaling Agile, Scrum en Kanban, Certified Scrum Enterprise coach en zo nog een paar. Deze certificaten gaan over hoe je Scrum moet implementeren in grotere organisaties of ze specialiseren op een specifiek onderdeel van Scrum (bijvoorbeeld het toepassen van Kanbantechnieken of hoe je User Interfaces moet ontwikkelen in een Scrum omgeving.

Bekendheid van verschillende Agile en Scrum certificaten

Scrum is het meest toegepaste agile framework. Volgens het Agile Adaptation rapport over 2021 gebruikt 45% van de onderzochte organisaties Scrum met Kanban op een tweede plaats met een score van 24%. Andere onderzoeken geven zelfs een hogere score voor de ingebruikname van Scrum. Waarschijnlijk heb je dan ook het meeste aan een Scrum certificaat en minder aan (andere) Agile certificaten. Veel andere Agile stromingen hebben trouwens ook helemaal geen certificering, bijvoorbeeld XP of Chrystal clear.

De 2 bekendste Scrum organisaties die certificaten uitgeven zijn Scrum.org en Scrum Alliance. Daarnaast kan je een Scrum certificaat behalen bij minder bekende organisaties en bij trainingsbureau’s direct zelf, zoals bijvoorbeeld ons eigen Scrum Master Certificaat.

Voorbeelden van minder bekende Scrum certificaten zijn die van SAFE, PMI en Scrum.inc. Het SAFe raamwerk is een raamwerk voor grotere Agile projecten (geschaalde Agile). SAFe heeft Scrum  geadopteerd binnen het Safe raamwerk: je kunt dus binnen het SAFe certificaten systeem  je  Scrum Master module behalen. Ook het bekende Project Management Institute heeft een eigen Scrum Master certificaat. Deze minder bekende uitgevers van Scrum certificaten zijn inhoudelijk in orde maar als je een Scrum certificaat wilt behalen dan geven we de voorkeur aan de bekendere Scrum Master certificaten van Scrum.org of Scrum Alliance. Deze zijn het meest geaccepteerd  en ze worden uitgegeven door de oorspronkelijke bedenkers van Scrum.

De Meest bekende organisaties waar je Scrum Certificaten kunt behalen:

• Scrum.org
• Scrum Alliance

Minder of zelfs nauwelijks bekende certificaten:

• PMI
• SAFe
• Scrum.inc
• Exin Scrum Master
• iiABC
• CS@SP
• ESC
• EXIN Agile Scrum Master
• IBQMICertified Scrumban Practitioner
• iSQI Scrum Master Pro
• SMAC Scrum Master Accredited Certification
• PAL Personal Agile Leadership
• CAHF Certified AgilityHealth Facilitator
• Eigen Scrum certificaten van trainingsbureau’s
• En vele andere!

Er zijn dus heel veel certificaten in omloop: de teller staat op meer dan 250 verschillende agile of scrum certificaten.

Wat betreft certificering zou ons advies zijn om vooral een bekend (lees: ‘erkend’) certificaat te kiezen. Dan blijven eigenlijk alleen de certificaten van Scrum.org en de Scrum Alliance over. Alle andere certificaten hebben gewoonweg te weinig achterban en we verwachten dat de meeste binnen een paar jaar weer zullen verdwijnen.

Een verkenning in Linkedin (binnen ons netwerk) geeft het volgende beeld:

Scrum Masters in het bezit van het volgende certificaat (peiling augustus 2022):

PSM-1 (Scrum.org): 3100
CSM (Scrum Alliance): 34.000

Het Certified Scrum Master certificaat is dus meer behaald dan het Professional Scrum Master certificaat van Scrum.org. Maar de Scrum Alliance is opgericht in 2001 en Scrum.org pas in 2009, dus ze hebben meer tijd gehad om certificaten uit te schrijven. Bovenstaande vergelijking is binnen ons eigen (Nederlandse en Belgische) Netwerk. De aantallen gecertificeerde mensen wereldwijd die de organisaties zelf noemen zijn (meting augustus 2022):

Scrum.org (alle certificaten): 716.552
Scrum Alliance (alle certificaten): 1.221.482

Alhoewel de Scrum Alliance nog steeds een stuk meer certificaten heeft uitgegeven is Scrum.org een goede tweede en het zou niet verbazen als ze binnen een paar jaar meer certificaten hebben uitgeschreven dan Scrum Alliance. Dit heeft mogelijk ook te maken met de kosten waarover verderop meer. Interessant is ook om te kijken naar de bekendheid bij wervers van personeel. Een peiling op Nationalevacaturebank.nl:

vacatures Scrum Master met CSM: 1739 (Scrum Alliance)
vacatures Scrum Master met PSM: 18063 (Scrum.org)
Vacatures Scrum Product Owner met CSPO: 1711 (Scrum Alliance)
vacatures Scrum Product Owner met PSPO: 1715 (Scrum.org)

De ‘waarde’ op de banenmarkt van beide certificaten is dus op dit moment hoog en verschilt ook niet erg veel. Beide certificaten worden veel gevraagd in vacatures. We zien ook vaak zinnen als: “Je bent in ten minste CSM of PSM gecertificeerd”. Met andere woorden: beide certificaten zijn voor ons geschikt. Opvallend is ook dat er zelden naar advanced certificaten wordt gevraagd: een PSM-1 of CSM wordt het meest genoemd.

Kosten van een Scrum certificering

Wie een certificaat van Scrum Alliance wil behalen zit ook aan hun eigen trainingsorganisaties vast. Reken dan op hogere bedragen dan wanneer je een Scrum.org certificaat wilt behalen en zelf een Scrum trainingsbureau erbij zoekt. Een Scrum.org certificaat zou je zelfs helemaal met zelfstudie kunnen behalen, wat veruit de voordeligste manier is. Maar de grootste kostenpost zit hem op de lange termijn in het feit dat de certificaten van Scrum Alliance elke 2 jaar vernieuwd moeten worden. Het vernieuwen van een CSM certificaat kost op dit moment 100 dollar per 2 jaar. De certificaten van Scrum.org zijn eenmaal behaald een leven lang geldig.

Het is echt de vraag of het vernieuwen van deze certificaten veel meerwaarde biedt, zoveel verandert het Scrum raamwerk niet en de ontwikkeling van mensen is ook af te lezen uit hun werkervaring en andere scholingen. Lees anders ook de mening van een trainer uit Chicago die een aantal van zijn (dure) Agile en projectmanagement certificaten laat verlopen.

De duurzaamheid van een certificaat

Met duurzaamheid van een certificaat bedoelen we nu niet milieuvriendelijkheid maar of het certificaat nog bestaat over een paar jaar. Wie gaat zoeken op het internet komt makkelijk een stuk of 50 Agile certificaten tegen en een deel van de certificaten uit de begintijd van het ‘Agile tijdperk’  bestaan al niet meer.  Ook om die reden is het verstandig om te kiezen voor een certificaat van een grote, oude en bekende organisatie omdat die waarschijnlijk er nog steeds zullen zijn over pakweg 10, 20 jaar (geen garantie).  Scrum.org, Scrum Alliance, maar ook PMI, PRINCE2, IPMA voldoen allemaal aan dat criterium. Het is toch zonde als je tijd en geld steekt in een certificaat dat over een paar jaar weer verdwenen is.

Overige Scrum en Agile certificaten

De meest behaalde en gevraagde Scrum certificaten zijn Scrum Master en Product Owner, beide op het instapniveau. Wil je meer dan kan je je Scrum Master certificaat behalen op een hoger niveau of voor een van de andere certificaten gaan richting Agile coaching en organisatiebrede toepassing van Scrum. Waar de basisexamens vooral over de kennis en de spelregels van Scrum gaan, gaat het bij de vervolgcertificaten meer over implementatie en toepassen in de praktijk. Het is interessant om je daarin verder te verdiepen maar er zijn meer wegen om dat te leren.

Welke Scrum certificaten bestaan er eigenlijk?

De belangrijkste scrum certificaten zijn: Scrum Master en Product Owner. Daarnaast zijn er nog een paar certificaten voor verschillende Scrum rollen of posities:

• Scrum Developer
• Scaled Scrum professional
• Kanban certificaat
• Agile leader (evt met EBM)
• Scrum facilitator
• Scrum user experience
• Backlog management skills
• Agile voor de gezondheidszorg
• …en meer

Deze lijst lijkt te groeien in de tijd: er kwamen en blijken steeds nieuwe certificaten bij te komen. Inhoudelijk is er bij deze certificaten veel overlap en het is de vraag of deze (nieuwe) certificaten veel toevoegen aan de basiscertificaten: Scrum Master en Product Owner. Er is natuurlijk niets op tegen om meer diploma’s te halen, maar we zien dat er nauwelijks naar gevraagd wordt in de arbeidsmarkt. Naar alle bescheidenheid denken we dat gevorderde Scrum Masters en Product Owners meer kunnen leren buiten het circuit van Scrum. Bijvoorbeeld over groepsdynamica en weerstand of over communicatieskills.

Wil je namelijk organisaties meer Agile maken dan krijg je te maken met allerlei vraagstukken op gebied van verandermanagement, leiderschap, samenwerking en communicatie die je ook buiten het Scrum scholingsprogramma kunt leren. Wil je je organisatie Agile maken dan is bijvoorbeeld het werk van Caluwé over verandermanagement heel nuttig.

Maar ook kennis over hoe je meerdere organisaties moet laten samenwerken in programma’s kan nodig zijn bij het invoeren van eengrote Agile transformatie. Bovendien geldt op ‘advanced’ niveau dat werkervaring en brede scholing meer telt dan certificaten op basis van meerkeuzevragen examens. Overtuigingskracht, leiderschap, doortastendheid, luistervaardigheid, creativiteit, culturele antennes, vertrouwen, stevigheid en sympathie kan je moeilijk certificeren maar zijn allemaal essentiële competenties voor een Agile coach of Scrum Master.

Scrum certificering in het Nederlands?

Bijna alle scrum certificaten en bijbehorende examens zijn alleen beschikbaar in het Engels. Dat maakt de examens voor mensen die het Engels niet (goed genoeg) beheersen een stuk lastiger dan noodzakelijk. Scrum.org suggereert dat je de examens ook kunt afnemen met google translate erbij, maar de ervaring leert dat de translate apps (nog) niet goed overweg kunnen met de vraagstelling. Een product owner wordt dan opeens vertaald door product manager of projectmanager, wat toch echt hele andere rollen zijn. Voor wie graag het Scrum examen wil halen maar wie moeite heeft met het Engels hebben we een Nederlandstalige variant op het Scrum Master examen en een Nederlands Product Owner examen (NL) ontwikkeld.

Conclusie

Wil je in een Agile of Scrum omgeving werken dan is een Scrum certificaat een nuttig document om te hebben. Het is veelgevraagd in de arbeidsmarkt en je bewijst ermee dat je de spelregels van Scrum beheerst. Eigenlijk heb je in de meeste gevallen genoeg aan een Scrum Master of Product Owner certificaat. De bekendste twee uitgevers van deze certificaten zijn Scrum.org en Scrum Alliance, waarbij wij de voorkeur geven aan de certificaten van Scrum.org

klik hier voor een overzicht van onze Scrum en Agile trainingen

Projecten zijn zo oud als de mensheid en het realiseren van grootse bouwwerken zoals de Piramides van Egypte, de Chinese Muur, de Borobudur tempel op Java of het Paleis op de dam moeten georganiseerd hebben plaatsgevonden. Helaas is er weinig bekend van hoe de organisatie van dergelijke werk geregeld was of welke technieken er voor het management van deze projecten gebruikt werden.

Modern projectmanagement

Verschillende auteurs (1) vinden dat modern projectmanagement ergens is gestart begin 20e eeuw. Sinds die tijd is er wel documentatie van de werkwijze bij projecten. Bekende projecten uit de recente geschiedenis waarbij er duidelijke ontwikkelingen te zien zijn in het vakgebied komen vooral uit de Verenigde Staten.

Tot de jaren vijftig zijn dit projecten die vooral over de bouw van infrastructuur gingen (de bouw van fabrieken, steden, rails, havens, wegen en telecommunicatiemiddelen). Bekende voorbeeldprojecten uit die tijd zijn onder andere de bouw van de Hoover Dam (1936) en het Manhattan project (1945) (5). In de periode daarna tot medio jaren tachtig zijn bekende projecten het Apollo project van de NASA en het Polaris project (het bewapenen van onderzeeërs met kernrakketten) van de U.S. Navy.

Grote en snelle ontwikkelingen

Na de jaren tachtig barst de informatietechnologie-revolutie los met grote en snelle ontwikkelingen op hard- en softwaregebied. De veranderingen zorgen ervoor dat er veel projecten starten. Daarnaast biedt de nieuwe informatietechnologie nieuwe mogelijkheden om projecten te gaan managen: de hulp van software bij de communicatie, het plannen en beheersen van een project.

De opkomst van Scrum en Agile

Daarnaast ontstaan er ook nieuwe uitdagingen. Vooral bij het ontwikkelen van software blijken de oude technieken van projectmanagement te star. Waarbij het bouwen van infrastructuur en ‘harde’ tastbare resultaten het nuttig bleek om vooraf een goed ontwerp te maken is het bij het bouwen van software nodig om tijdens de bouw het ontwerp te kunnen wijzigen. Software is nooit af en verandert in de loop van de tijd. Denk aan alle versies van bijvoorbeeld Windows die er de afgelopen jaren zijn ontwikkeld. En die ontwikkeling loopt nog steeds door.

Extreme programming en Scrum

Vanuit die gedachte zijn rond de jaren 90 iteratieve projectmanagement methodes ontwikkeld zoals Extreme Programming en Scrum. Pas na 2000 is de verzamelnaam agile in gebruik geraakt voor deze en nog een aantal nieuwe methodes die uitgaan van de basisprincipes zoals verwoord in het Agile Manifesto (6).

Agile Manifesto

Belangrijke pijlers van het manifest zijn onder andere: werken in relatief kleine groepen met de nadruk op intermenselijke communicatie, het opleveren van het project in relatief kleine delen waarbij er na elke oplevering besloten wordt om het ontwerp en de werkplan aan te passen. Daarbij wordt er gewerkt in relatief korte tijdframes van in de regel niet meer dan een paar weken per iteratie. In Scrum heet zo’n iteratie een ‘Sprint’.

Agile voor geen ICT projecten

Vervolgens werd er in de periode na 2010 ontdekt dat Agile ook goed toegepast kan worden in projecten die niet over softwareontwikkeling gaan (zie bijvoorbeeld (7) en (8)). Agile werken vond zijn weg naar onder andere communicatieprojecten, marketing, HR, binnenhuisarchitectuur, projecten in de zorg en in het onderwijs.

Grotere groepen

In de oorspronkelijke Agile methodes werkt men het liefst in relatief kleine teams van niet meer dan ongeveer 10 personen. Bij veel organisaties en grote projecten lukt dat niet met zo’n klein team. Denk aan het wijzigen van software op honderden werkplekken bij een belastingdienst of het op de markt brengen van een nieuw product in honderden landen.

Raamwerk

Omdat sommige projecten nu eenmaal om de inzet van meer mensen vragen zijn vanaf de periode 2010 raamwerken bedacht om met grotere groepen mensen toch nog ‘agile’ te kunnen werken. Bekende scaled agile raamwerken zijn onder andere SAFe, LeSS, Spotify, Scrum at Scale en Nexus (9). Ook wordt er geëxperimenteerd met zogenaamde ‘hybride’ methodes waarin men traditionele structuren met een agile aanpak combineert (10).

Concluderend

Kijkend naar de jonge geschiedenis van modern projectmanagement dan heeft het een sterke oorsprong in engineering: het bouwen van min of meer technische objecten. Projecten gaan allang niet meer alleen over het bouwen van harde objecten zoals infrastructuur, ze gaan over het inrichten van nieuwe bedrijfsprocessen, over het bouwen of implementeren van informatiesystemen, over het veranderen of realiseren van nieuwe organisatieonderdelen.

Maar ook over – pogingen tot – het veranderen van gedrag van mensen zoals het klantvriendelijker maken van een afdeling. Of zelfs het ontwikkelen of uitdragen van visies kunnen onder de noemer van ‘projecten’ vallen. Het moge duidelijk zijn dat deze voorbeelden op een schaal van heel ‘harde’ naar zeer ‘zachte’ projecten lopen.

Oorspronkelijke technieken beter of slechter?

Opmerkelijk genoeg wordt in de vele projectmanagement opleidingen, boeken en certificeringen die er beschikbaar zijn veel teruggegrepen op de oorspronkelijke technieken van projectmanagement die ooit bedacht zijn voor engineering. Maar werken die technieken nog wel? Het bouwen van een wolkenkrabber in de jaren 30 is een heel ander project dan het ontwikkelen van nieuwe medicijnen anno 2022.

Agile versus traditioneel

Een van de vragen die nu regelmatig gesteld wordt en ook onderwerp is van soms felle discussies op de diverse online forums is: is Agile een betere methode dan de traditionele aanpak? De consensus is dat Agile en ‘traditioneel’ projectmanagement beide hun plek hebben: softwareprojecten heeft meestal de voorkeur voor Agile, het bouwen van een viaduct niet.

Maar de vraag welke methode het beste bij welke soort project gaat veel verder dan het onderscheid tussen Agile of traditioneel. Eigenlijk zou je per techniek moeten kijken in hoeverre die werkt of niet: heb je bij project X wat aan een gannt chart? Heb je bij project Y wat aan een fasering, en zo ja welke fasering? Welke mate van controle is wenselijk en haalbaar bij project Z?

Geciteerde werken:

1. The History of Project Management. Seymour, Tom Joseph. sl : International Journal of Management & Information Systems, 2014, Vol. Volume 18, Number 4.
2. Kwak, Y.H. en Anbari. The Story of Managing Projects by Carayannis. [boekaut.] Anbari. The Story of Managing Projects by Carayannis. sl : Quorum Books, 2003, Vol. Chapter 2.
3. Kent Beck, James Grenning, Robert C. Martin, e.a. Manifesto for Agile Software Development. Manifesto for Agile Software Development. [Online] 2001. https://agilemanifesto.org.
4. Ruler, Betteke van. Reflectieve Communicatie Scrum. Reflectieve Communicatie Scrum. Amsterdam : ADFO Groep, 2013.
5. de Boer, Petra, Bruggink, Martin en e.a. Scrum In Actie. Scrum In Actie. sl : Business Contact, 2015.
6. Portman, Henny. Scaling Agile In Organisaties. Scaling Agile In Organisaties, wegwijzer voor Projectmanagers en Agile Leaders. Houten : Van Haren Publishers, 2017.
7. Baars, Wouter. Project Management Handbook. Project Management Handbook. The Hague : DANS, 2006.
8. Weggeman, Mathieu. Essenties van Leidinggeven Aan Professionals. Essenties van Leidinggeven Aan Professionals. Schiedam : Scriptum, 2021.
9. P. Zuiker, Ernst Harting. Projectmatig Creeren 2.0. Projectmatig Creeren 2.0. sl : Scriptum Books, 2006.
10. Gert Wijnen, Peter Storm. Projectmatig werken. Projectmatig werken. sl : Spectrum, 2009.
11. Wikipedia. PRINCE2. Wikipedia. [Online] 19 Maart 2021. [Citaat van: 5 Mei 2021.] https://nl.wikipedia.org/wiki/PRINCE2.