Het ‘scopespook’

Wel eens tegen gekomen? Aan het begin van een project bespreek je met de opdrachtgever welke resultaten hij met het project wil neerzetten. Je inventariseert vervolgens de ‘omgeving’ waar binnen het project zich afspeelt, zoekt naar raakvlakken en andere gerelateerde activiteiten.
In overleg met de opdrachtgever bepaal je de definitieve ‘scope’, wat valt er binnen de grenzen van het project, waarvoor ben je als projectmanager verantwoordelijk. Je legt dit vast in je projectplan. Vol enthousiasme start je met de uitvoering van het project. En dan begint het…

Tijdens een regulier voortgangsoverleg met je opdrachtgever brengt hij een nieuw issue in. Bij de implementatie van een nieuw automatiseringssysteem moet er nog een extra interface komen met een ander systeem. Je wilt de opdrachtgever niet teleurstellen en zegt dat je dit verzoek meeneemt in je project. Terwijl je de mogelijkheden onderzoekt roept een eindgebruiker dat hij in het nieuwe systeem een aantal functionaliteiten mist die er wel in moeten komen. De Senior User brengt dit in bij de Stuurgroep en de opdrachtgever geeft vervolgens aan jou de opdracht om ook voor deze aanvullende functionaliteit te zorgen. Om je draagvlak in de gebruikersorganisatie te behouden heb je geen andere keus dan deze opdracht te accepteren.
Bij de proefconversies van de data uit het huidige systeem naar het nieuwe systeem worden tenslotte nog een aantal aanvullende eisen neergelegd waarvoor de conversieprogrammatuur moet worden aangepast terwijl in de projectdocumentatie was vastgelegd dat er een standaard conversieprogramma gebruikt zou worden. Ook deze aanpassing moet je oppakken omdat dit meetelt voor de acceptatie door de gebruikers en het succes van de implementatie.

Uiteindelijk is je projectopdracht uitgebreid met drie aanvullende functionaliteiten terwijl je budget en  opleveringsdatum van je project gelijk zijn gebleven. Het lukt je niet binnen die voorwaarden je projectresultaat nog op te leveren.

Opeens wordt je ervan bewust dat je het ‘scopespook’ bent tegengekomen: onbewust is de scope van je project toegenomen terwijl de projectvoorwaarden gelijk zijn gebleven. Wat nu?
Je zult de opdrachtgever op de hoogte moeten stellen van de situatie. Hij zal er zeer waarschijnlijk niet blij mee zijn. In overleg met hem zullen er keuzes gemaakt moeten worden in de aspecten tijd, geld of kwaliteit.

Belangrijk is ieder issue wat wordt ingediend te toetsen aan je projectplan, past het binnen de scope van mijn project, welke risico’s brengt dit met zich mee, wat zijn de consequenties van dit issue? Bespreek dit met de opdrachtgever en maak een bewuste keuze.
Ik wil niet zeggen dat iedere uitbreiding van je scope per definitie een gevaar voor je project oplevert maar wees je steeds bewust van iedere opdracht die er komt. Dat voorkomt problemen in een later stadium.

Ben benieuwd naar jou ervaringen hiermee.

Ik kan mijn opdrachtgever niet vinden.

Je doet je project en je hebt een vraag die je met je projectteam niet kan beantwoorden. Je legt het voor aan degene die je altijd je projectrapportage toestuurt. Die reageert afhoudend: “Tsja, dat weet ik ook niet. Vraag maar eens rond.” Naar wie ga je toe, je dacht immers dat hij de opdrachtgever was?

 Je vraagt je af wie er antwoord gaat geven op je vraag. Voor wie doe ik het eigenlijk? Van wie is het project eigenlijk? Wie is nu eigenlijk de opdrachtgever?

Helaas zal deze situatie te vaak herkend worden. Wanneer de opdrachtgever onbekend is, is het project gedoemd te mislukken.

 Hoe vind ik mijn opdrachtgever?

“Follow the money”.
Wie betaalt eigenlijk voor het project? De betaler heeft doorgaans een probleem dat opgelost moet worden. Wanneer die oplossing door je project wordt opgeleverd, is de betaler is de opdrachtgever. Als dat toch niet het geval is, zijn er twee mogelijkheden: de toegevoegde waarde van het project voor de organisatie is nooit aangetoond. Je moet je afvragen of je wel door moet gaan met het project! Andere mogelijkheid is dat de eigenlijke betaler hiërarchisch te hoog zit om zich over de details van het project te buigen. Daarvoor is een lagere manager aangesteld als gedelegeerd opdrachtgever.

Gedelegeerd opdrachtgever: handig of niet?
Bij gedelegeerde opdrachtgevers is het niet altijd duidelijk wat hun bevoegdheden zijn. Welke afspraken zijn er gemaakt tussen feitelijke en gedelegeerde opdrachtgever? Heeft de gedelegeerde opdrachtgever voldoende zeggenschap om je vraag te beantwoorden? Of moet er een nieuwe vergadering gepland worden om de vraag met de feitelijke opdrachtgever te bespreken. Gevolgen? Meer tijd nodig om een gedegen beslissing te krijgen met kans op vertraging van het project.

Oplossing?
Altijd aan het begin van het project de projectorganisatie op stellen, inclusief de opdrachtgever en zo nodig een gedelegeerde opdrachtgever. Stel de verantwoordelijkheden op zodat iedereen weet wat er van elkaar verwacht wordt.

Hoezo risico’s? We doen dit al jaren en het gaat nooit fout.

Herkent u dit? Wilt u als projectmanager aandacht besteden aan de beheersing van uw project o.a. door het uitvoeren van een risico inventarisatie, krijgt u commentaar van projectteamleden dat dit niet nodig is. Hoe gaat u hiermee om? 

Welkom

Leuk dat je op de weblog van de projectcoach bent. Ik werk hard om mijn site zo snel mogelijk in de lucht te krijgen. Mocht je al eerder een vraag hebben dan kan je die stellen via Twitter @Deprojectcoach