De (overheids)projectparadox

Geplaatst op 7 maart 2018 in Economische groei en ontwikkeling

Overheden hebben het voortouw genomen bij de innovatie van projectbeheer, zoals blijkt uit deze D-Day infographic van Sterren en strepen. En, toch zijn er veel mislukkingen bij de implementatie van bedrijfssoftware bij de overheid.

Mislukkingen van overheidsprojecten

De meeste regeringen eisen dat de aanbieders beste praktijken voor projectbeheer toepassen, in overeenstemming met de Project Management Body of Knowledge (PMBOK) van de Project Management Institute. Systeemintegratiebedrijven hebben strikte projectbeheerpraktijken. Overheden hebben vaak gecertificeerde projectmanagers in dienst.

Ik dacht dat we het toppunt van mislukte overheidssoftware en ERP hadden gezien bij het Amerikaanse ministerie van Defensie, met 4 van de 13 projecten die tussen 200% en 1050% van de oorspronkelijke budgetten kostten. Dat is totdat de "Phoenix-salarissysteem" in de regering van Canadaeen aangepaste versie van Oracle PeopleSoft, geïmplementeerd door IBM. Macleans legt de huidige stand van zaken uit in onderstaande video:

De projectmanagementparadox

Waarom werken projectmanagement best practices in sommige contexten wel en in andere niet? Waarom gebruiken internetgiganten agile methodologieën?
Traditioneel projectbeheer gaat ervan uit dat projecten ingewikkeld, maar voorspelbaar zijn. De bouw van een brug, bijvoorbeeld, kan gecompliceerd zijn en technische expertise vereisen. Ingenieurs begrijpen de sterkte van materialen, hoe te bouwen in verschillende bodemomstandigheden en om te gaan met temperatuursveranderingen. De voortgang van het project kan worden voorspeld op basis van soortgelijke projecten. Natuurlijk is de werkelijke voortgang heel gemakkelijk te zien.
Implementaties van bedrijfssoftware zijn complex. Government Resource Planning (GRP) projecten zijn transformerend. Financiële, personeels- of inkoopdeskundigen van de overheid zijn nodig. Net als IT-experts. Gebruikers hebben speciale training nodig. (Bruggebruikers hebben geen nieuwe training nodig). Het belangrijkste is dat GRP projecten processen transformeren en automatiseren waardoor aanzienlijke weerstand tegen verandering ontstaat.
Wat we kunnen voorspellen van overheidssoftwareprojecten is dat ze zeer onvoorspelbaar zijn. Leveranciers voldoen vaak 100% aan gedocumenteerde eisen van de overheid, zoals IBM met het Phoenix betaalsysteem. Toch voldoen systemen niet aan de oorspronkelijke eisen. Dat komt een beetje omdat het traditionele projectmanagement bij de overheid zich richt op documentatie als substituut voor echte eisen. En contracten, in plaats van gebruikerseisen, staan voorop.

Paradoxale patronen

Veel overheidsklanten staan erop om sterk gestructureerde watervalprocessen te volgen. FreeBalance, een van de weinige fabrikanten van bedrijfssoftware die daadwerkelijk software voor klanten implementeert, heeft veel patronen ontdekt die tot risico's leiden:

• Verankering: Software-implementaties zijn vaak verankerd in de bestaande oplossing. Gebruikers willen iets vertrouwds. Bestaande systemen zitten echter vaak vol inefficiënties en fouten. Software wordt vaak aangepast om verouderde processen te volgen. Projectbeslissers verankeren zich aan de "As-Is" processen. Onnodige rapporten worden gemaakt. De kwaliteit van de informatie verbetert vaak niet. De aanpassingen leiden tot meer fouten. Het is natuurlijk allemaal een beetje vreemd als je bedenkt dat het doel van een nieuw systeem de tekortkomingen van het oude systeem zijn.
• Documentatie: Bij traditioneel projectbeheer worden pagina's en pagina's gedetailleerde documentatie gemaakt. Elke fase vereist documentatie die door de besluitvormers moet worden goedgekeurd. Hoe meer documentatie, hoe moeilijker het is voor besluitvormers om zich voor te stellen hoe het uiteindelijke systeem eruit zal zien. Bijvoorbeeld, de meeste methoden voor het verwoorden van specificaties zijn voor de meeste mensen erg moeilijk te begrijpen. Gemakkelijk voor software ingenieurs. Dit leidt tot vertragingen. Veel vertragingen.
• Contracten: Het gewenste resultaat voor systeemintegratiebedrijven is te leveren op basis van contractuele verplichtingen. Kostenoverschrijdingen en schemawijzigingen zijn prima zolang de overheid maar betaalt. Documentatie, contracten en contractwijzigingen herdefiniëren succes van oorspronkelijke overheidsdoelstellingen tot contractnaleving. Daarom worden systeemintegratiebedrijven ook betaald als de gebruikers ontevreden zijn.
• Weerstand tegen verandering: Mensen zien bruggenbouw in uitvoering. Software is een ander verhaal. Veel projecten wachten op volledige ondertekening van de documentatie alvorens aanpassingen en configuraties door te voeren. Dit leidt tot meer weerstand tegen verandering. Gebruikers, projectteamleden van de overheid en besluitvormers raken ontkoppeld van de implementatie. De veronderstelling is dat het project niet goed verloopt omdat er niets te zien is.
• Team Bloat: De behoefte aan contractonderhandelaars, documentatieschrijvers en uitleggers leidt tot grotere teams. Dit lijkt misschien een goede zaak voor degenen die de Mythische Man Maandvoor het eerst gepubliceerd in de jaren 1970. Coördinatie- en communicatieproblemen worden exponentieel.

We hebben een evaluatie afgerond van FreeBalance implementatieprojecten, ERP in overheidsprojecten en goede agile praktijken. Onze methodologie is bijgewerkt tot A-i³+qM (versneld, geïntegreerd, iteratief, uitvoeringsgericht, kwaliteitsbeheer):

• Versneld door zoveel mogelijk oude watervalprocessen die tot projectproblemen leiden te elimineren. Dit omvat onnodige documentatie en gedetailleerde projectplannen, ten gunste van workshops en korte processtappen. De teamgrootte wordt klein gehouden om communicatie met de klant mogelijk te maken en coördinatieoverhead te verminderen.
• Geïntegreerd via één enkele methodologie ter ondersteuning van de ontwikkeling en de implementatie van diensten. Dit wordt geïntegreerd met de eisen van de klant via de klantgerichte processen. Dit zorgt voor transparantie tussen de klantmedewerkers, de uitvoerders en het ontwikkelingsteam. Implementatie- en productontwikkelingsteams zijn geïntegreerd volgens DevOps-praktijken.
• Iteratief om in te spelen op veranderingen van de klant en de implementatie door middel van fasen. De methodologie maakt gebruik van het beste van bewezen "lean" softwareontwikkeling en dienstenmethodologieën met workshops, korte iteraties, user stories, mijlpalen en de mogelijkheid om vooruitgang aan te tonen. Deze technieken worden uitgebreid tot buiten de ontwikkelingsorganisatie voor implementatiediensten, waardoor de productiviteitswinst en het vermogen om te reageren op de eisen van de klant worden vergroot.
• Uitvoeringsgericht met goede praktijksjablonen en bewezen programmamanagementprocessen. Deze methodologie is gericht op het succes van de klantimplementatie, eerder dan op een softwarerelease die interne of willekeurige doelstellingen bereikt. Implementatie en productontwikkeling worden beheerd via een Program Management Office.
• Kwaliteit aanpak zorgt ervoor dat de software wordt vrijgegeven en ondersteund volgens de goede praktijken van Commercial Off-the-Shelf (COTS) met unit-, systeem-, stress- en regressietests. Kwaliteit is geïntegreerd met implementatie waarbij FreeBalance test op basis van klantomgevingen.

A-i³+qM erkent de tekortkomingen van traditionele projectmanagementprocessen bij GRP implementaties. En, de patronen voor mislukking.

• Verankering: Aspiraties worden het anker. Workshops worden gehouden na aanvang van het project. Overheidsprojectteams worden getraind op de FreeBalance software om te laten zien wat zou kunnen zijn. Onze mensen zijn deskundig op het gebied van beheer van overheidsfinanciën, ambtenarenzaken, begrotingsplanning, overheidsopdrachten, enz. Wij weten alles over hoe overheidsfinanciën werken, en zouden moeten werken. Wij richten ons op hoe onze software kan worden geconfigureerd om problemen op te lossen.
• Documentatie: De FreeBalance Accountability Suite is enorm configureerbaar. Dit betekent dat we bedrijfsregels, workflow, taal en gegevens snel kunnen wijzigen zonder te coderen. Het is een massaal no-code aanpak. Gebruikers kunnen zien of aan de eisen is voldaan. Geen behoefte aan enorme hoeveelheden documentatie.
• Contracten: Contracten zijn belangrijk voor FreeBalance. Als sociale onderneming richten we ons op het financieel duurzaam maken van implementaties door overheden. En we hebben een prikkel om zo snel mogelijk te leveren wat nodig is, zodat we zo snel mogelijk betaald worden.
• Weerstand tegen verandering: Veranderingsweerstand begint te smelten door het demonstreren van vooruitgang bij het verbeteren van softwareconfiguraties. Dat wil niet zeggen dat workshops en demonstraties alle weerstand tegen verandering wegnemen. De methodologie heeft een diepere focus op veranderingsmanagement dan algemeen projectmanagement.
• Team Bloat: Onze aanpak houdt de teamgrootte optimaal. We komen vaak overheids- of systeemintegratieprofessionals tegen die vertrouwd zijn met teamgroottes voor ERP- of maatwerkprojecten. Voor FreeBalance-projecten is het maatwerk veel kleiner.