In veel projecten die ik leid kom ik het tegen. Mensen die uitgeblust zijn door (te) lang aan een project te werken, vaak zijn ze vastgelopen in netten van formele en informele regels. Kan je ontsnappen aan de greep op het project(-leider)?

Moeten de regels aangepast worden of is het zaak dat het project / de projectleider zich aanpast aan de regels?

Vaak is het zaak om creatief vooruit te denken en pro-actief doorbraken te vinden.

Als we het hebben over kwaliteit binnen projecten zie je veel wenbrauw fronzen en ogen staren omdat we dat verbinden met geavanceerde statistiek, controle diagrammen en process control theorien.

De uitdaging is, natuurlijk, dat een statistisch controle proces goed past bij een productie bedrijf (of proces) waar sprake is van consistentie, herhaling en betrouwbaarheid. Projecten spelen zich af in een compleet ander context, ze zijn van nature inconsistent, niet herhalend en (betwistbaar) onbetrouwbaar.

Is dan alle hoop verloren voor kwaliteit management binnen projecten? Moeten we ons er bij neerleggen en het maar vergeten? Of is er een betere manier om kwaliteit te meten en besturen?

Er is één fase in elk IT project dat belangrijker is dan alle andere, belangrijker dan ontwerpen, bouwen of uitrollen. Elke fout op dit gebied kost simpelweg geld en vertraagt het project. Goede 'requirements' of eisen en wensen vaststellen aan het begin van het project verhoogt de kwaliteit.

Het is een kunst om de eisen te verzamelen. 'Graven' naar een set eisen vereist contact met klanten. Klanten weten niet altijd wat ze binnen het project willen of hoe ze het moeten beschrijven. Combineer dat met het feit dat we in de IT niet altijd even goed luisteren naar de vragen en antwoorden. Soms zijn we al bezig met de oplossing voordat de klant het heeft beschreven. Er is een simpele formule om de juiste kwaliteit eisen te bepalen in een project.

http://www.youtube.com/watch?v=uiOyrEi8zd4

Governance: waarom hebben we rollen?

Hoeveel mensen in je projecten begrijpen de specifieke rollen en verantwoordelijkheden die toegewezen zijn? Als de rol niet wordt begrepen, hoe kunnen ze dan je project voorzien van de juiste governance? Dit is een grote uitdaging; veel organisaties hebben geen governance structuur die het mogelijk maakt om de juiste maatregelen te treffen. Een effectieve governance structuur bestaat bij de gratie van goed gedefinieerde rollen en verantwoordelijkheden die begrepen en gebruikt worden. Zonder dit is governance niet meer dan een lege huls.

De definitie van governance

Laten we eerst de term governance, in mijn bewoording, uitleggen. Eenvoudig gezegd; project governance zijn de structuren, rollen en verantwoordelijkheden die besluiten nemen over de projecten in een organisatie. De juiste projecten starten het juiste tijdstip en de risico’s van de de projecten en organisatie worden actief geminimaliseerd. In mijn ogen is het creëren van een goede governance structuur vitaal voor het succes van een project. Een sleutelrol hierin spelen het vaststellen en toepassen van rollen en verantwoordelijkheden. Zonder duidelijke rollen en verantwoordelijkheden zal project governance nooit succesvol zijn.

Op wikipedia staat meer informatie over governance: http://nl.wikipedia.org/wiki/Governance

Vaak wordt er gevraagd om Agile project methoden. De grote vraag is dan ‘wat is Agile?’ en ‘wanneer passen we Agile projectmanagement toe?’.

Beschrijving Agile projectmanagement

Agile projectmanagement is een methode die gericht is op een specifiek type project. Projecten die geoptimaliseerd zijn voor risico’s, klant focus, veranderlijkheid en snelheid. Dit in tegenstelling tot andere project methodes die geoptimaliseerd zijn voor onder andere omvang, complexiteit, kosten, kwaliteit en scope. Om echt te begrijpen hoe we een prestaties meten in Agile project management moeten we de onderliggende waarden begrijpen.

De algemene aanname is dat IT’ers intelligent zijn. In de afgelopen 15 jaar in IT projecten blijkt dit vaak het geval te zijn. Ze zijn analytisch, snelle denkers, initiatiefrijk, creatief en bovendien vaak prestatie gericht.

Het is niet omdat ze intelligent zijn ze alleen complexe taken hebben. Het zijn de IT project managers die teamleden moeten managen. Het is logisch dat complexiteit in het project niet alleen gevolgen heeft voor de IT’er , maar ook voor de project manager. Als project manager probeer ik dingen niet complexer te maken dan noodzakelijk en zeker geen onnodige uitdagingen te creëren.

Hoe maken we van een complex project nu een simpel(er) project?
Zodat het voor onszelf maar ook voor de teamleden en vóóral voor de klant eenvoudiger is?
Grofweg zijn er 4 wegen om dat te bereiken:

• Gebruik ervaring
• Vereenvoudig taken
• Creëer een focus op het einddoel
• Verwijder aannames uit het plan

Hieronder licht ik de punten in detail toe.

Gebruik ervaring uit het verleden om inzicht te krijgen in de toekomst

Om je project zo goed als mogelijk te begrijpen, en ze zoveel mogelijk te versimpelen, moet de projectmanager en teamleden zoveel mogelijk ervaring opdoen in verschillende projecten. Deze ervaring gebruiken we om nieuwe projecten goed te plannen. Het is van groot belang om deze kennis te delen om  steeds beter te worden als organisatie. ‘Lessons learned’ die niet gebruikt worden zijn waardeloos.

Vereenvoudig taken

Bij het opstellen van een project taken en planning is het van belang om naar het versimpelen van taken in plaats van het toevoegen van complexiteit. Meer complexiteit leidt al gauw tot (meer) verwarring. Als een taak in 2 stappen kan in plaats van 4, kies dan 2 stappen. Het toevoegen van complexiteit in de belangrijkste taken door complexe subtaken is gevaarlijk en kan frustrerende en vervreemdend zijn voor de teamleden waaraan ze worden toegekend. Deze manier van plannen leidt tot onnodige risico factoren.

Focus alle inspanning op het einddoel

Tijdens het plannen van het project, de projectmanager en het team moeten zeker stellen dat alle taken bijdragen aan het bereiken van het einddoel. Als een taak geen bijdrage levert aan het einddoel dan wordt dit onderdeel van een probleem. Onnodige taken voegen complexiteit toe aan het project en het projectmanagement en verhogen het risico op succes. Geen enkele taak zou uitgevoerd moeten worden, of onderdeel kunnen zijn van het projectplan, als deze taak niet direct bijdraagt aan het einddoel.

Verwijder aannames uit het projectplan

We doen allemaal aannames bij de start van elk project. Echter, de projectmanager, het projectteam en de klant moeten oppassen dat ze aannames in het project niet gaan zien als een feit. Met name dat ze ze niet als zodanig plannen. Een misplaatste aanname kan gevolgen hebben voor de gekozen aanpak en de manier waarop de project-realiteit wordt gezien. Dat verhoogt de complexiteit van het project.

Samenvattend

Het onderliggende probleem waar we mee te maken hebben is dat simpel project vrijwel altijd goedkoper en sneller uit te voeren is. Het is altijd uitdagend om in de richting meer complexiteit te bewegen.

Redenen hiervoor: er is meer uitdaging, om het ego te versterken, om beter te zijn dan anderen.

Als je project te eenvoudig lijkt, dan loop je de kans dat je als werknemer wordt gevraagd om je toegevoegde waarde voor onderneming aan te tonen. We moeten er voor zorgen dat we niet zo denken. De aloude spreekwijze ‘slimmer werken, niet harder.’ blijkt nog steeds op te gaan.

Complexe projecten of plannen hebben het nadeel dat ze ontzettend lastig te managen zijn en even lastig om te volgen. Het project, de project planning en de processen moeten zo eenvoudig mogelijk te managen zijn. Uiteindelijk betekent dat dat het team en de klant ze begrijpen, ze gebruiken en volgen. Daarmee verhoog je de kans op een succesvol project!

Meer informatie over het vereenvoudigen van projecten? Neem contact met ons op.