Ik vraag me af of projectmanagementdeskundigen denken dat goede documentatie Othello ervan zou hebben weerhouden Desdemona te vermoorden. Zou Othello in woede de dikke ordner hebben geraadpleegd die getuigde van Desdemona's liefde en trouw? Shakespeare kwam tot de kern van de tragedie: de informele communicatie van Iago.
Toch is de omvang van de documentatie een "best practice" geworden bij IT-implementaties bij de overheid. Goedkeuringen worden uitgesteld omdat de ondersteunende documentatie niet zwaar genoeg is. Het lijkt mij dat veel waarnemers het gebrek aan documentatie, of de nauwkeurigheid van de documentatie, voor zoveel IT en ERP-fouten bij de overheid. Dit bericht gaat dieper in op een documentatiefout patroon beschreven in mijn berichten van vorig jaar: De paradox van het overheidsproject en Buitensporig Fortuin van Waterval Processen in de Overheid. Het introduceert ook een op risico's gebaseerde agile benadering van projectdocumentatie.
Wat is de reden voor gedetailleerde projectdocumentatie?
Er bestaat een lange traditie van projectdocumentatie voor complexe software-implementaties. Het wordt vaak beschouwd als een oplossing voor het probleem dat vaak voorkomt bij de overheid: bedrijfssoftware volgt niet de vereiste processen. De gedachte is dat een diepgaande beschrijving van de huidige processen ("as-is") ervoor zal zorgen dat de resulterende software voldoet aan de operationele behoeften. En een diepgaande analyse van deze processen zal uitwijzen wat er moet veranderen ("fit-gap") om een verbeterde situatie ("to-be") volledig te beschrijven.
Dit vereist vaak dat systeemintegratiebedrijven met procesdeskundigen van de overheid om de tafel gaan zitten om complexe processen in kaart te brengen. Deze bedrijven zullen de regeringsdeskundigen vaak verwijten dat zij de processen niet volledig in kaart brengen wanneer implementaties gaan mis.
Wat is de context voor documentatie als oplossing?
Mijn indruk is dat de ceremonie van naleving van documentatie eerder tot mislukking dan tot succes leidt. De gedetailleerde articulatie van "as-is" is ongeveer even nuttig om systemen te laten werken als stukken kapot meubilair in de "as-is" sectie bij Ikea is voor het inrichten van een huis. Er is een reden waarom systemen moeten worden vervangen. Dus, "to-be" bedrijfsprocessen staan op het kritieke pad. Er is een meer coherente aanpak nodig.
Wat gebeurt er tijdens de langdurige "as-is" proces ontdekking en documentatie?
- De weerstand tegen verandering neemt toe omdat belanghebbenden en gebruikers geen vooruitgang zien, geeft dit de tijd aan de krachten tegen verandering om het project te saboteren
- "As-is" rijdt "to-be" omdat de eerste documentatie het conceptuele anker wordt, vooral omdat de weerstand tegen verandering toeneemt.
- Overdreven aangepaste code omvang, tijd en toekomstige upgradekosten die toeneemt omdat belanghebbenden eisen dat het nieuwe systeem zich gedraagt als het oude.
- De werkelijkheid is zelden gedocumenteerd omdat overheidspersoneel zelden beschrijft welke workarounds in de huidige systemen worden gebruikt, welke praktijken niet aan de eisen voldoen, zoals het niet respecteren van de scheiding van taken, of hoe de systemen werkelijk worden gebruikt, bijvoorbeeld om transacties te registreren die al hebben plaatsgevonden
- Wat kunstmatig is wordt evangelie vanwege beperkingen in eerdere systemen leidt ertoe dat regeringsdeskundigen concluderen dat kunstmatige structuren zoals het scheiden van begrotingsclassificaties en boekhoudkundige classificaties, of het scheiden van uitvoerende en ministeriële systemen, of vreemde methoden voor het beheer van vastleggingen of liquide middelen op de een of andere manier natuurlijk zijn.
- Wat belangrijk is, is verborgen binnen pagina's documentatie en traceerbaarheid tussen processen, configuraties en aanpassingen wordt moeilijk
De kwantiteit van de documentatie overtroeft vaak de kwaliteit van de documentatie, omdat kwantiteit het eerste tastbare bewijs levert dat het projectteam iets heeft gedaan. Maar, zoals een van mijn universiteitsprofessoren antwoordde op de vraag hoe lang het essay moest zijn: "20 pagina's, maar als je tijd hebt, maak er dan 12 van."
Hoe kan de kwaliteit van projectdocumentatie worden verbeterd door de hoeveelheid documentatie te verminderen?
Project transparantie moet op niemand wachten. Maar ik krijg de indruk dat men vindt dat er niets gebeurd is totdat het gedocumenteerd is. Het maakt niet uit of de boom die in het bos viel geluid maakte of niet. Bij bedrijfssoftware van de overheid viel de boom pas om als hij gedocumenteerd was. Waarom zouden belanghebbenden zo lang moeten wachten om erachter te komen of er iets is gebeurd, of gebeurt?
A op risico gebaseerde benadering van projectbeheer nodig is.
Dat is waar agile processen en technieken het meest effectief zijn: bijna in real time de status van projecten laten zien. Agile processen kunnen gebruik maken van kanban-, scrum- of scrumban-borden om de voortgang, to do's, prioriteiten en taakopdrachten te tonen. De kloof tussen werkelijke en geschatte user stories maakt het mogelijk de voltooiing van mijlpalen veel beter te voorspellen dan traditionele GANTT-diagrammen. Projectteams hoeven de status niet te documenteren door foto's van het bord te maken. Hoeveelheden onvoltooide taken waarschuwen projectteams. Problemen worden zichtbaar.
Deze problemen moeten worden gedocumenteerd en belanghebbenden moeten worden gewaarschuwd zodat beslissingen kunnen worden genomen. Er is een reden waarom business intelligence-regimes zich hebben gericht op uitzonderingsrapportage voor belangrijke belanghebbenden. Het is hoog tijd voor uitzonderingsrapportage in de documentatie. En vroegtijdige waarschuwing. Stakeholders zullen begrijpen dat de waarschuwing per e-mail van cruciaal belang is, en niet de zoveelste set projectbijgewerkte documentatie.
Hoe kan projectdocumentatie per context verschillen?
De documentatiementaliteit bij overheidsprojecten is zelden gebaseerd op risico's. Alles documenteren levert steeds minder op. Toch is dat het geval bij veel overheidscontracten waar de uiteindelijke goedkeuring afhankelijk is van een volledige gebruikersacceptatietest die ook de projectdocumentatie omvat. Dit maakt de testprocedures complexer. Wij hebben een andere methode die we aanraden aan elke overheid die Commercial-Off-The-Shelf (COTS) software wil implementeren, inclusief die van FreeBalance:
- Het project anders verankerenbeginnen met het opleiden van het overheidsprojectpersoneel over de nieuwe COTS-software en laten zien hoe de "to-be"-doelstellingen van de overheid kunnen worden bereikt en hoe de COTS-software op een andere manier aan de eisen voldoet dan in het vorige project is bedacht.
- Configuratie scheiden van maatwerk: workshop configuratiewijzigingen met overheidsprojectmedewerkers en eindgebruikers met configuratie-ondertekening indien aangetoond terwijl code-aanpassing agile processen volgt.
- Op risico en waarde gebaseerd maatwerk: identificeren en documenteren van kosten-baten-risico's voor elk aanpassingsinitiatief om de besluitvorming over projecten te verbeteren.
- Agile documentatie: prototypes en storyboards gebruiken en documenteren om goedkeuring te krijgen voor aanpassingen, in plaats van te vertrouwen op traditionele documentatie.
- Agile testen: configuratietests gedurende de gehele implementatie verminderen de last van de uiteindelijke acceptatietests die meer gericht zullen zijn op risico's: maatwerk, waarbij de kwaliteit van de documentatie van cruciaal belang is.
Hoe lost deze agile aanpak de tragedie van de projectdocumentatie op?
- De weerstand tegen verandering neemt af omdat belanghebbenden en gebruikers de voortgang van de configuratie zien en de workshops blijk geven van bereidheid om de inbreng van de gebruikers op te nemen
- "To-be" stuurt het project omdat iteraties zich richten op overheidsdoelstellingen
- Maatwerk bevatte omdat de volledige mogelijkheden van COTS-software worden verkend ten opzichte van de "to-be"-doelstellingen, en maatwerk als uitzondering is volledig gedocumenteerd
- De werkelijkheid is ingebed omdat overheidspersoneel praktijken beschrijft tijdens configuratieworkshops, en deskundigen van de leverancier (dit veronderstelt dat de leverancier het domein begrijpt) de redenen voor praktijkveranderingen uitleggen
- Wat kunstmatig is wordt gerationaliseerd omdat de COTS-software deze beperkingen niet oplegt, ervan uitgaande dat de software daadwerkelijk is ontworpen
- Wat belangrijk is, is zichtbaar binnen minder pagina's documentatie met effectieve traceerbaarheid, en het gebruik van agile boards voor voortgangsrapportage