Posts Tagged ‘Project’

mei 3rd, 2013 · by John · Weblog NL

Aristoteles (384 – 322) wordt beschouwd als een van de meest invloedrijke klassieke filosofen in de westerse traditie. Hij had een brede interesse en zijn invloed is terug te vinden in vakgebieden als logica, literatuurstudie en biologie. Velen weten echter niet, dat hij ook een expert op het gebied van IT project management was. Beter gezegd hij zou het zijn geweest als IT al had bestaan in de klassieke oudheid.

Aristoteles heeft namelijk geschreven over verandering, over hoe iets kan ontstaan. En dat is zeer relevant voor projectleiders. Aristoteles ziet verandering als het overgaan van potentie (het vermogen om te veranderen) naar een bepaalde graad van volmaaktheid. Bij elke verandering kun je volgens hem vier vragen stellen: Wat is er veranderd? Hoe is dat tot stand gekomen? Wat heeft de verandering teweeggebracht? En, met welk doel heeft die verandering plaatsgevonden?

Om deze vragen te beantwoorden geeft Aristoteles vier “oorzaken”. Het voorbeeld van een beeldhouwer die een bronzen beeld van prinses Beatrix maakt, kan deze enigszins abstracte begrippen verduidelijken:

  • De materiële oorzaak is het brons, het materiaal waarvan het beeld wordt gemaakt.
  • De formele oorzaak is het idee van de beeldhouwer over hoe het beeld er uit moet gaan zien.
  • De bewegende oorzaak is de beeldhouwer, die zorgt dat het beeld er komt.
  • De finale oorzaak is het doel waarvoor het beeld is gemaakt: een herinnering aan het vorige staatshoofd.

Aristoteles zag de finale oorzaak als de belangrijkste. In de middeleeuwen die sterk schatplichtig aan Aristoteles waren, werd deze dan ook de oorzaak der oorzaken genoemd. Het concept van de vier oorzaken kunnen we zondermeer toepassen op IT projecten.

  • De materiële oorzaak is de hardware, software en andere componenten die moeten worden gecombineerd om tot een oplossing te komen.
  • De formele oorzaak is de architectuur, het ontwerp van de oplossing.
  • De bewegende oorzaak wordt gevormd door de activiteiten om de oplossing te bouwen.
  • Dat wat met de oplossing wat moet worden bereikt, de waarde die de oplossing gaat toevoegen vormt de finale oorzaak.

IT projectmedewerkers weten veel van hard- en software, ze kunnen heel goed een architectuur maken en zijn experts in het realiseren van een dergelijk ontwerp. Wat echter vaak wordt vergeten is zeker te stellen dat het doel wel wordt bereikt. Wordt er waarde gecreëerd met het realiseren van het systeem? Zonder waarde is de “oplossing” immers waardeloos.

Bij het samenstellen van het project team moet er daarom rekening mee worden gehouden, dan niet alleen de technische kennis voor wat betreft materiaal, ontwerp en ontwikkeling wordt meegenomen, maar dat er ook een sterke focus ligt op het bereiken van het doel. Dat doel is niet een systeem bouwen. Dat kunnen onze IT-collega’s wel. Het doel is de finale oorzaak, de waarde die het systeem gaat creëren voor de organisatie. En dat is geen IT-verantwoordelijkheid; dat is een business verantwoordelijkheid.

John Greijmans

 

 

 

 

augustus 24th, 2012 · by John · Weblog NL

Vraag aan honderd managers om één paar woorden te noemen dat regelmatig in één zin voorkomt. Ik weet zeker dat “project + mislukken” in de top vijf staat. Het kost mij inderdaad geen moeite projecten te noemen die langer duren dan verwacht, die meer kosten dan begroot en die niet het gewenste resultaat opleveren.

Waarom mislukken projecten toch zo vaak? Er zijn veel redenen te noemen. Deze overlappen elkaar vaak of staan in een oorzaak-gevolg relatie tot elkaar. Vanuit mijn ervaring zie ik de navolgende oorzaken van mislukte projecten als de belangrijkste.

Project Management: een slecht of zelfs geen plan

Als je ergens naar toe moet rijden, kijk je eerst hoe je er moet komen. Vroeger moest dat met een kaart, tegenwoordig zijn navigatiesystemen een uitkomst. In projecten zie ik echter nog steeds dat “men” begint met vaak niet meer dan een vaag idee van wat “men” wil bereiken. Over het hoe iets te bereiken, tegen welke kosten en binnen hoeveel tijd wordt al helemaal niet gesproken.

Zonder plan kan een project per definitie niet lukken. Je hebt immers nog niet eens gedefinieerd wat lukken is! Toegegeven, het is wat werk om een plan te schrijven, maar als het er ligt, bespaart het veel tijd. Een plan schrijf je zowel voor jezelf, als voor de opdrachtgever. Er staat in wat je in het project gaat doen, hoe, wanneer, tegen welke kosten en met wie.

No Time is just another word for No Priority”

Je ziet het zo vaak. “Iemand” heeft in de krant gelezen dat het bijvoorbeeld heel belangrijk is “iets” aan corporate sustainability te doen. Er is altijd wel ergens een ambitieuze medewerker te vinden die dat wel wil doen. Ambitie is goed, maar er wordt vaak niet gekeken of die persoon wel tijd heeft, of beter gezegd of het haar is toegestaan tijd voor dit project vrij te maken. Je hoort het die “iemand” al zeggen: och dat kan zij er toch wel even bij doen.

 Als iets belangrijk is, geef je het prioriteit en dus maak je voldoende tijd vrij om het te doen. Is het niet belangrijk of hebben andere zaken een hogere prioriteit, dan moet je of extra mensen aantrekken of het goede idee nog even in de ijskast laten.

Scope Creep ofwel uitdijende projecten

Dan hebben we een project met een goed project plan en mensen die aan het project werken hebben daarvoor voldoende tijd. Wat kan er dan nog mis gaan? Nou, het project kan bijvoorbeeld aan zijn eigen succes ten ondergaan. Het gaat goed met het project. Iedereen ziet dat en denkt, maar dan zouden ze “dat” er ook nog wel bij kunnen doen. Voor je het weet, dijt “dat” zoveel uit dat het project te duur wordt en misschien zelfs helemaal nooit af komt.

Een project plan wordt gemaakt op basis van een projectdoel. Moet, om welke reden dan ook het doel worden aangepast, dan moet eerst worden onderzocht welke consequenties dat heeft. Desnoods moet een nieuw plan, met een nieuw budget en een nieuwe planning worden gemaakt.

De situatie was 25 jaar geleden niet anders dan nu. Ondanks tientallen projectmanagementboeken en -trainingen lopen projecten nog steeds uit de kosten en wordt het doel niet of te laat gehaald. Er is hier geen simpele oplossing voor. In toekomstige blogs zal ik ingaan op twee methoden die in ieder geval helpen de meest voorkomende oorzaken te voorkomen: de business case en contract management.

John Greijmans