Doe niets zonder duidelijk doel

U zou niets mogen doen dat geen duidelijk doel heeft. Stelt u zich twee parallelle werelden voor waar alles hetzelfde is, behalve datgene wat u overweegt te doen: hoe verschillend zouden die werelden zijn? Is het verschil de moeite waard om er aan te werken?

Als je geen duidelijk doel voor ogen hebt en alleen maar iets doet omdat alle anderen het doen, of omdat iedereen zegt dat het belangrijk is om het te doen, dan:

• kan het zijn dat het in uw geval geen echt voordeel heeft, en dat u er dus niets uit kunt halen; of
• het kan ook dat het bij u nog steeds potentiële voordelen heeft, maar omdat u het doel niet in gedachten hebt, kan het zijn dat uw manier van werken niet bijdraagt aan het realiseren van die voordelen.

Voorbeeld: Portfolio’s en programma’s

Als u betrokken bent bij het selecteren en het initiëren van projecten, moet u ervoor zorgen dat u zich concentreert op de toegevoegde waarde en de problemen die moeten worden opgelost in plaats van op het product dat die dingen gaat realiseren. Het klassieke voorbeeld is de fabrikant van liften die vroeger klachten ontving over de snelheid van hun liften, en zo meerdere projecten had uitgevoerd om de snelheid te verhogen, zonder volledig succes. Dat ging door tot ze besloten om zich te concentreren op het probleem (de verveling of het ongemak van mensen) in plaats van op de “natuurlijke” oplossing (snellere liften). Als resultaat werden spiegels aan de liften toegevoegd, en het probleem werd eenvoudig en goedkoop opgelost.

Vergeet niet dat projectmanagement vooral gaat over het juist uitvoeren van de dingen, terwijl portfoliomanagement gaat over het uitvoeren van de juiste dingen. Het maakt niet uit hoe goed u uw projecten uitvoert; het zal niet goed werken als u de verkeerde projecten kiest. Het is allemaal een kwestie van het hebben van een duidelijk doel.

Voorbeeld: Het project als geheel

De flexibiliteit van het product verschilt per project. In sommige IT-ontwikkelingsprojecten is het product volledig flexibel en hangt de uiteindelijke vorm af van de feedback die de incrementele groei van het product tijdens het project zal genereren, wat een adaptieve (Agile) aanpak vereist. Dit is in de praktijk een combinatie van de portfolio-, de programma- en de projectlagen, en vereist maximale aandacht voor het uiteindelijke doel. Het is een goed idee om het doel te documenteren en toegankelijk te houden; het is één van de doelen van de “productvisie”, zoals gebruikt in sommige Scrum-projecten. De aandacht voor de bedrijfswaarde in Agile projecten is hun manier om te zorgen voor afstemming met het doel.

In andere soorten projecten, waar het product relatief vast ligt en er andere mechanismen zijn om ervoor te zorgen dat het uiteindelijke product aan het doel voldoet, is het mogelijk voor de projectteamleden om een groot deel van hun focus te verschuiven van het doel naar het product (vandaar het “focus op producten” principe van PRINCE2^®). Maar er is nog steeds minimale aandacht nodig voor het doel om ervoor te zorgen dat wat gebouwd wordt aan het doel voldoet. Dit kan worden gedaan door het vergelijken van de geplande voordelen met de verwachtte voordelen (vandaar het principe van de “continued business justification” en het “business case” thema in PRINCE2^®).

Wanneer een project voor een externe klant wordt uitgevoerd, heeft de klant voor zichzelf een doel voor het project, en heeft uw bedrijf een ander doel. U moet beide begrijpen en gebruiken om echt te slagen.

Voorbeeld: Monitoring van het project

Focussen op het uiteindelijke doel is noodzakelijk, maar dat doel kan te abstract zijn voor veel van de dagelijkse toepassingen. Daarom is een hiërarchie van factoren nodig om het praktischer te maken. Eerst worden de rechtvaardiging en de voordelen van het project gedefinieerd op basis van het uiteindelijke doel, en dan heb je expliciete en impliciete doelstellingen voor projectvariabelen (bv. tijd, kosten en kwaliteit) om aan de rechtvaardiging te voldoen, die ook op hun beurt aan het uiteindelijke doel zullen voldoen. Dit zijn doelen op lager niveau die nuttig zijn voor veel van onze dagelijkse taken.

Als het aankomt op monitoring, zal de low-level monitoring van het project worden gedaan met behulp van het laagste niveau van variabelen, omdat het niet altijd mogelijk is om het uiteindelijke doel te volgen. In dit geval moet u nog steeds de doelen voor ogen houden: wat is het doel van monitoring?

Een normaal en aanvaardbaar antwoord is om te bepalen of we op schema liggen, en zo niet, om een bepaalde reactie op gang te brengen die ons weer op schema brengt of de doelstellingen bijstelt en nagaat of het uiteindelijke doel nog steeds kan worden bereikt. Onze metingen moeten daarom in staat zijn om te helpen met dit lage doel, en de juiste metingen zijn voorspellingen voor de variabelen bij de voltooiing; bijvoorbeeld, wanneer zouden we het project kunnen voltooien? Hoeveel geld zouden we nodig hebben om het project af te ronden?

Alle andere metingen, zoals de geplande en werkelijke waarden tot nu toe, zijn slechts tussentijdse waarden die u nodig heeft om de voorspellingen te berekenen, niet de uiteindelijke waarden die u gebruikt voor managementdoeleinden.

Voorbeeld: Documenten

Welke aanpak je ook gebruikt bij de ontwikkeling van het project, planning is altijd noodzakelijk. De belangrijke vraag is de mate van detail in elk type plan. Als er niet voldoende detail in het plan zit, zal het plan niet genoeg kunnen bijdragen en zal de uitvoering van het project gebaseerd zijn op ad hoc beslissingen in plaats van op geïntegreerde, holistische beslissingen. Aan de andere kant proberen veel mensen voorzichtig te zijn en te veel details toe te voegen, wat hun plan te moeilijk maakt om het voor te bereiden en te onderhouden, en te star voor de onzekerheden van het project. Het gevolg is dat het plan onrealistisch en nutteloos wordt.

De beste manier om te beslissen over de mate van detaillering is om voor elk element in het plan een doel voor ogen te hebben. Als u bijvoorbeeld overweegt om middelen aan het plan toe te voegen, moet u er een doel voor hebben: hoe ga je ze gebruiken? Hoe zullen ze het project helpen? Hoeveel moeite zal het kosten? En is het de moeite waard?

Soms gaat het erom te beslissen of je een bepaald element in je plannen wilt hebben, soms gaat het om de manier waarop je iets wilt plannen of voorbereiden. Of het nu gaat om een business case, een projectcharter of een rapport: u moet zich nog steeds afvragen waarom u dat document voorbereidt en hoe dit het project kan helpen.

Het zoeken naar een “sjabloon” is het tegenovergestelde van iets doen op basis van een doel.

Voorbeeld: Statusrapporten

Het is gebruikelijk om in veel projecten lange statusrapporten te hebben. Op basis van deze NUP moeten we ons afvragen wat het doel van zo’n verslag is en hoe we dat doel kunnen bereiken, ongeacht wat de meeste andere mensen doen.

Dit kan er in veel gevallen toe leiden dat we zeer eenvoudige rapporten van één pagina opstellen die door de belanghebbenden echt gelezen en begrepen worden in plaats van lange rapporten. Dit is aandacht besteden aan het doel.

Als u echter rapporten van één pagina voorbereidt, kunnen sommige mensen bezwaar maken tegen u en denken dat u geen “goed” monitoringsysteem hebt. In de praktijk creëert dit een tweede doel voor u (naast het eerste doel, namelijk belanghebbenden helpen de status van het project te begrijpen), en om dat te bevredigen, kunt u eenvoudigweg een tweede type rapport maken dat erg lang is. U zult dat echter niet vermengen met het eerste rapport, omdat deze twee doelen niet hetzelfde zijn.

Voorbeeld: Business case en projectcharter

Het opstellen van documenten zoals een business case en een project charter is voor de meeste mensen meestal een saaie, vruchteloze, bureaucratische noodzaak, terwijl deze documenten allemaal geldige doelen hebben die voor de meeste projecten gelden. Als u een “sjabloon” probeert te vinden en in te vullen, is het werk gewoon verspild; wanneer u daarentegen de echte doelstellingen van die documenten controleert, kijkt of en hoe ze nuttig kunnen zijn in uw project, en vervolgens de documenten voorbereidt op eender welke manier die u verkeur uitgaat, en u tracht op deze manier aan de doelstellingen van de oefening te voldoen - zo verkrijgt u behoorlijke en nuttige documenten.

Terwijl u nadenkt over de manier waarop u de documenten kunt voorbereiden om aan hun doelstellingen te voldoen, denkt u misschien niet aan elk scenario en mist u misschien iets. Om dat te voorkomen, kunt u controleren wat bronnen zoals PRINCE2^®, PMBOK^® Guide, P3.express en DSDM^® suggereren, en deze suggesties kan u vervolgens evalueren op basis van uw doelstellingen.

Voorbeeld: Na afloop van het project

Hoewel het project een specifiek doel heeft, en we het halen van dat doel gedurende het hele project mogen beoordelen, wordt de realisatie van het doel voornamelijk geëvalueerd op basis van de voorspellingen die tijdens het project worden gedaan. We mogen de evaluatie na afloop van het project echter niet vergeten. Het is belangrijk om de realisatie van de doelen na het project te controleren, omdat

• we dan kunnen zien hoe de uiteindelijke doelen worden bereikt en daarvan kunnen leren voor toekomstige projecten, en
• soms de doelen alleen bereikt worden als we na de voltooiing van het project nog enkele bijkomende taken uitvoeren, en het begrip van de noodzaak van die extra taken vraagt om monitoring.

Die monitoring na afloop van het project is een noodzakelijke stap bij een doelgerichte aanpak. Dit is vooral de verantwoordelijkheid van programma- en portfoliomanagementsystemen, en omdat de meeste bedrijven niet over dergelijke managementlagen beschikken, wordt deze stap meestal verwaarloosd. Daarom voegen methoden zoals P3.express en DSDM^® deze stap toe aan hun projectmanagementmethoden.

Voorbeeld: Eenvoud

De wereld is complex en chaotisch, maar onze modellen benaderen delen van de wereld op een abstracte manier, en kunnen dus eenvoudig zijn. Daarenboven werken eenvoudige systemen meestal beter, omdat we ons op het hoofdidee kunnen concentreren.

Velen van ons proberen betere resultaten te bereiken door complexiteit aan onze systemen toe te voegen, in de hoop dat het zal overeenkomen met de complexiteit van de wereld, ook al maakt dit het systeem in de praktijk moeilijk werkbaar en blokkeert het ons meestal om aan het doel te voldoen.

Voorbeeld: Maatwerk

Een stuk software voor het streamen van muziek vereist heel andere eigenschappen dan een stuk software dat gebruikt wordt voor apparatuur in een ziekenhuis of een vliegtuig waar het leven van mensen van afhangt, of een stuk software dat gebruikt wordt in een satelliet waar het vele jaren zou moeten werken zonder te crashen, en ze zijn allemaal verschillend van het bouwen van een zomervilla, een brandweerkazerne, en een verwerkingsfabriek.

Wanneer u de doelstellingen in gedachten heeft, zal u beter begrijpen hoe u de systemen en de documentatie voor verschillende projecten kunt aanpassen.

▼ PDF