Misschien zijn de projecten nu inderdaad te groot, te complex gedefinieerd.
 
Wat ik in het bovenstaande artikel mis, is de verantwoordelijkheid van de projectmanagers voor het aannemen van die opdrachten. Ik dacht namelijk dat dat een essentieel onderdeel van hun vak was.
 
Volgens mij geeft een professional door het aannemen van een opdracht aan, dat deze, volgens hem, door hem uit te voeren is.
 
Dat lijkt mij dan ook voor projectmanagers te gelden.
 
Achteraf zeggen dat het aan de omvang en de complexiteit van de opdracht lag, komt op mij niet zo professioneel over.
 
Misschien is het wel nuttig om dit vanaf nu expliciet te benoemen, als dat tenminste nog niet gebeurde, en dan zowel door de opdrachtgever als door de opdrachtnemer.

Ik wil de uitspraak van Victor ondersteunen: Agile biedt naast allerlei bruikbare ideeen/practices vooral een denkwijze die je helpt om in specifieke omstandigheden tot resultaten te komen. "Good thinking, good products". is een motto van Toyota en past ook hier. Agile zien als een panacee is de valkuil. Om dit te ontwikkelen en te ondersteunen is het onafhankelijke) Agile consortium opgericht: Agileconsortium.nl en Agileconsortium.be

Uit de literatuur blijkt dat de Agile werkwijze hoge eisen stelt aan projectmedewerkers (zeer ervaren, zeer kundig, communicatief sterk, teamwerkers, kwalitatief gedreven, etc.) en projectmanager (coachend en niet directief). Met zo'n team kun je m.i. nagenoeg ieder project succesvol afronden.
(zie ook mijn proefschrift: "Success and failure factors in ICT Projects: A Dutch Perspective).
 
=======
De overheid heeft te maken met Europese Aanbestedingen. Het lijkt mij lastig om dan Agile te werken, waarbij je voortdurend wendbaar moet zijn. Ik benieuwd naar Agile ervaringen met substantiele projecten binnen de overheid. Zijn die er?
 
aart.vandijk@planet.nl

Bouwman heeft gelijk; het besturingsmodel van de Overheid (maar ook van tal van andere organisaties) staat succesvolle verandering in de weg. De Functionele organisaties, waar vaak verantwoordelijkheden in de lijn, maar macht/control bij stafafdelingen liggen, veroorzaakt enorm veel schade bij verandering door onduidelijke rollen en grote noodzaak tot overleg en communicatie.
 
Een andere grote oorzaak van de problemen is dat er gesproken wordt over ICT projecten. Die bestaan namelijk niet. Een project gaat altijd om zakelijk te rechtvaardigen verandering; ICT speelt een rol maar geen leidende rol. ICT is altijd slechts een deel van de verandering. ICT projecten zorgen ervoor dat de werkelijke verandering uit het oog wordt verloren, het project niet wordt gezien als een investering maar als een kostenpost. ICT projecten zorgen ervoor dat gebruikers niet ge?nteresseerd zijn. Het is toch puur technisch?
 
Speelt de ervaring van de Projectmanager een rol? Misschien. Vaak wordt het project geleid door een manager van de ICT afdeling of leverancier. Dit is geen projectmanager maar een technisch teammanager. En wederom (zie hierboven) wordt het project gezien als een technisch project. Veel beter is om een projectmanager vanuit de business (waar de verandering plaatsvindt) de zaak te laten managen. Hierdoor verandert de focus en betrokkenheid.
Ik ben het dan ook niet eens met de suggestie van Frank. Dit lost het fundamentele probleem niet op. Zie ook www.viergever.info/nl/methodes.aspx
 
Dan nog iets over de discussie over grote en kleine projecten. Het grote risico van opsplitsen in kleine projecten is dat je te maken krijgt met een verzameling stuurloze projecten zonder samenhang. Het merendeel hiervan zal, door hun omvang, onzichtbaar falen. Je kunt hier de analogie trekken met de clusterbom. Heel veel kleine bommetjes die enorme schade aanrichten. Veel meer dan een grote bom.
 
Het antwoord zit hem in de aansturing. Beter projectmanagement, inclusief het opdrachtgeverschap. En in een groot aantal gevallen (beter) programmamanagement (zie www.viergever.info/nl/msp_p2.aspx), hoewel dit vaak wordt afgedwongen door een verkeerd besturingsmodel en daarmee ook weer een moeilijk verhaal wordt

Om iets beter te doen lijkt altijd wel een goed idee. Beter "opdrachtgeverschap"; betere "aansturing" meer "ervaring" het is prima, maar daarmee nog niet duidelijk wat er dan precies beter moet. Nico is wel duidelijk dat in wat je niet moet doen: goed nadenken! Daar moet ik nog even op reageren.
 
Dit artikel gaat over het aspect ervaring en stelt dat meer of minder ervaring niet garandeert dat een project goed omgaat met risico's en onzekerheden. Dat lijkt me een een goede waarschuwing. Het blijkt keer op keer dat opdrachtgevers en projectmanagers het geheel niet kunnen overzien en niet tot de juiste bijsturingen kunnen komen. Dat meer "control" op de projectprocessen (soms) leidt tot disproportionele maatregelen en (soms) intelligente mensen tot minifabriekjes reduceert die je moet "aansturen" anders doen ze niets meer. En dat risico mijdend gedrag (soms) leidt tot inertie.
 
Dus het lijkt heel verstandig om naar andere invalshoeken op deze materie te kijken. "thinking tools" zoals Agile die veranderingen juist aanmoedigen in plaats van buitensluiten. Er valt veel nieuws te leren op dit gebied. Dus ik zeg: Stel je open voor nieuwe inzichten en denk na! (en laat je niet zomaar "aansturen"!)

In essentie ben ik het eens met Nico. Mijn samenvatting: van Business IT Alignment is nauwelijks of geen sprake in overheidsorganisaties. Daarnaast of beter gezegd de oorzaak daarvan is dat er binnen overheidsorganisaties geen verandernoodzaak bestaat (zoals we dat in het bedrijfsleven kennen), zolang dat politiek gezien niet strikt noodzakelijk is. 'ICT' processen (b.v. COBIT en ValIT) krijgen dan ook aan de busineskant weinig of geen aandacht. Het gaat dan over de verantwoordelijkheid voor investeringsbeslissingen en portfoliomanagement (inderdaad meer dan alleen ICT projecten). Het programma- en projectmanagement (b.v. Prince2) wat daarop volgt lijkt, gezien de resultaatgerichtheid, niet te passen binnen de cultuur van overheidsorganisaties. Een ook vrijwel geheel onontgonnen gebied is (enterprise) architectuur. Kortom, alle randvoorwaarden voor succesvolle verandering lijken te ontbreken. Dus mee eens, een projectleider mag in dat geval niet zondermeer een projectopdracht aannemen. Doet hij of zij dat wel, dan moet de opdrachtgever worden gewezen op de risco's (de randvoorwaarden waaraan vooraf niet wordt voldaan). Maar misschien scheer ik nu, te kort door de bocht, alle overheidsorganisaties over ??n kam. Er zijn ongetwijfeld uitzonderingen maar ik denk te weinig om ? 100.000.000,00 te bezuinigen. Want daar gaat het toch om, minder belasting betalen met behoud van of liever verhoging van de kwaliteit van de overheidsdienstverlening?

Projecten in bedrijfsleven of overheid staan of vallen met de wijze waarop het vertrekpunt en het eindpunt is gedefinieerd. Veelal is het eerste wel helder, maar het laatst wil nogal eens veranderen. Het politieke primaat en het besturingsmodel binnen de overheid dragen bij aan de onzekerheidsmarge, welke overigens te (be)sturen is.
 
Even terug in de historie. Prof Looijen heeft diverse publicaties geschreven, weliswaar met als vertrekpunt de informatievoorziening, maar het P-B-I model (beheersen proces/ te besturen systeem, wijze van beheersing / organisatie systeem, informatievoorziening / informatie systeem) en het besturingsparadigma met de omgevingsvariabelen gaan nog steeds op (zie beheer van informatiesystemen 2de druk blz 27-33).
 
Opdrachtgever- en opdrachtnemerschap is een samenspel. Het gaat naar mijn idee om "besturen" van de omgeving, het project en de realisatie van het project binnen de context van de gewenste "project" matige veranderingen van een bestaande situatie.
 
Het is jammer dat er dikwijls gezocht wordt naar een "schuldige" indien een overheid project niet volgens plan verloopt. Met de komst van het Gateway mechanisme verwacht ik binnen de overheid een gezonde leercurve maar ook een bevestiging dat er veel projecten goed gemanaged worden. Helaas vieren we de successen binnen de overheid onvoldoende.

Projecten gaan om verandering, niet om stabiliteit.
ICT is een middel, geen doel.
Een Gateway Review zal daarom moeten vanuit deze visie moeten plaatsvinden.
 
De huidige opzet van de Gateway Reviews wordt geleid door ICT-ers (de Rijks-CIO) met een ITIL achtergrond (stabiliteit). Echte fundamentele problemen zullen daarom niet herkend worden, alleen symptomen; daar heb ik de eerste bewijzen al van gezien.

Als ervaren projectmanager, momenteel ingezet bij een overheidsinstantie, ben ik het ermee eens dat ervaring alleen onvoldoende is. Tegelijktijd kan je wel heel ver komen met voldoende kennis en ervaring. De onvolkomenheden van de overheid als opdrachtgever zijn actief te managen. Mijn motto hierbij is altijd "wel helpen, niet de verantwoordelijkheid overnemen". Alle bovengenoemde aspecten spelen een rol. De eindverantwoordelijkheid van de stuurgroep, het nemen van verantwoordelijkheid van de PM, de gekozen projectstrategie.
Een ervaren PM die dit alles weet te belanceren kan erg ver komen. Ik heb zelf 2 slecht lopende projecten overgenomen van 2 PM collega's. Een standaard waterval project met PRINCE2 en een Scrum project met een PRINCE2 sturingslaag erom heen. Het Scrum project loopt fantastisch, het waterval project liep erg slecht maar is de schade aan het inhalen. Dezelfde klant, dezelfde mensen, dezelfde business.
 
Het kan dus wel bij de overheid, maar ze moeten actief geholpen worden. Een goede PM kan hierbij veel bereiken. De combinatie van PRINCE2 met Scrum zie ik daarbij als een erg goede aanpak voor overheidsprojecten. Wel de controle van PRINCE2 maar ook de effectiviteit en samenwerking van Scrum.
 
http://www.borselaer.org