Ik vraag me af of projectmanagementexperts denken dat goede documentatie Othello ervan zou hebben weerhouden Desdemona te vermoorden. Zou Othello in een woedeaanval 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 reikwijdte van documentatie een "best practice" geworden bij IT-implementaties bij de overheid. Ondertekeningen worden uitgesteld omdat de ondersteunende documentatie niet zwaar genoeg is. Het lijkt mij dat veel waarnemers het gebrek aan documentatie, of de nauwkeurigheid van documentatie, voor zo veel IT- en ERP-fouten bij de overheid. Dit bericht gaat verder in op een documentatiefout patroon beschreven in mijn posts van vorig jaar: De paradox van het overheidsproject en Schandalig fortuin van watervalprocessen bij de overheid. Het introduceert ook een op risico's gebaseerde agile benadering van projectdocumentatie.
Wat is de reden voor gedetailleerde projectdocumentatie?
Projectdocumentatie voor complexe software-implementaties kent een lange traditie. Het wordt vaak beschouwd als een oplossing voor het probleem dat vaak voorkomt bij de overheid: bedrijfssoftware volgt de vereiste processen niet. De gedachte is dat een diepgaande beschrijving van de huidige processen ("as-is") ervoor zorgt dat de resulterende software voldoet aan de operationele behoeften. En een diepgaande analyse van deze processen zal vaststellen wat er moet veranderen ("fit-gap") om een verbeterde situatie ("to-be") volledig te beschrijven.
Hiervoor moeten systeemintegratiebedrijven vaak aan tafel gaan zitten met procesdeskundigen van de overheid om complexe processen in kaart te brengen. Deze bedrijven zullen de experts van de overheid vaak de schuld geven van het niet volledig in kaart brengen van processen wanneer implementaties gaan mis.
Wat is de context voor documentatie als oplossing?
Ik heb het gevoel dat de ceremonie van het naleven van documentatie eerder leidt tot het mislukken van een project dan tot succes. De gedetailleerde articulatie van "as-is" is ongeveer net zo 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 vervangen moeten worden. Dus, "to-be" bedrijfsprocessen staan op het kritieke pad. Er is een meer samenhangende aanpak nodig.
Wat gebeurt er tijdens de langdurige ontdekking en documentatie van het "as-is" proces?
- Weerstand tegen verandering neemt toe omdat belanghebbenden en gebruikers geen vooruitgang zien, geeft dit de krachten tegen verandering de tijd om het project te saboteren
- "As-is" rijdt "to-be" omdat de eerste set documentatie het conceptuele anker wordt, vooral omdat de weerstand tegen verandering toeneemt
- Te veel aangepaste code omvang, tijd en toekomstige upgradekosten die toeneemt omdat belanghebbenden eisen dat het nieuwe systeem zich net zo gedraagt als het oude
- De werkelijkheid is zelden gedocumenteerd omdat overheidspersoneel zelden workarounds beschrijft die worden gebruikt in de huidige systemen, praktijken die niet conform zijn zoals het niet respecteren van scheiding van taken, of hoe systemen echt worden gebruikt zoals het gebruik ervan 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 van boekhoudkundige classificaties, of het scheiden van uitvoerende en ministeriële systemen, of vreemde methoden voor het beheren van vastleggingen of contanten 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 documentatie overtroeft vaak de kwaliteit van 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 verbeteren door de hoeveelheid documentatie te verminderen?
Projecttransparantie zou op niemand moeten wachten. Maar ik krijg de indruk dat men van mening is 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 aan het gebeuren is?
A risicogebaseerd benadering van projectmanagement nodig is.
Dat is waar agile processen en technieken het meest effectief zijn: de status van projecten bijna in realtime laten zien. Agile processen kunnen kanban-, scrum- of scrumban-borden gebruiken om de voortgang, to do's, prioriteiten en taaktoewijzingen te laten zien. De kloof tussen werkelijke en geschatte user stories maakt het mogelijk om de voltooiing van mijlpalen veel beter te voorspellen dan met 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 er 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 documentatie. En om vroegtijdig te waarschuwen. Stakeholders zullen begrijpen dat de e-mailwaarschuwing van cruciaal belang is, en niet zomaar weer een set bijgewerkte projectdocumentatie.
Hoe kan projectdocumentatie verschillen afhankelijk van de context?
De documentatiementaliteit in overheidsprojecten is zelden gebaseerd op risico's. Alles documenteren levert steeds minder op. Toch is dat het geval bij veel overheidscontracten waarbij de uiteindelijke goedkeuring afhankelijk is van een volledige gebruikersacceptatietest die ook de projectdocumentatie omvat. Dit maakt de testprocedures complexer. We hebben een andere methode die we elke overheid aanraden die COTS-software (Commercial-Off-The-Shelf) wil implementeren, inclusief die van FreeBalance:
- Het project anders verankerenbeginnen met het trainen van de projectmedewerkers van de overheid in 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 de vorige COTS-software.
- Configuratie scheiden van maatwerkworkshop configuratiewijzigingen met overheidsprojectmedewerkers en eindgebruikers met configuratie-ondertekening wanneer aangetoond terwijl code-aanpassing agile processen volgt
- Op risico en waarde gebaseerd maatwerk: kosten-batenrisico's identificeren en documenteren voor elk aanpassingsinitiatief om de besluitvorming over projecten te verbeteren
- Agile documentatieprototypes en storyboards gebruiken en documenteren om goedkeuring voor aanpassingen te krijgen, in plaats van te vertrouwen op traditionele documentatie
- Agile testenConfiguratietesten tijdens de implementatie verminderen de last van de uiteindelijke acceptatietesten die meer gericht zijn op risico's: maatwerk, waarbij de kwaliteit van de documentatie van cruciaal belang is.
Hoe lost deze agile aanpak de projectdocumentatiedrama op?
- Weerstand tegen verandering neemt af omdat belanghebbenden en gebruikers de voortgang van de configuratie zien en de workshops de bereidheid tonen om de inbreng van gebruikers op te nemen
- "To-be" stuurt het project omdat iteraties zich richten op overheidsdoelstellingen
- Aanpassing bevat 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 experts van leveranciers (dit veronderstelt dat de leverancier het domein begrijpt) redenen uitleggen voor veranderingen in praktijken
- Wat kunstmatig is wordt gerationaliseerd omdat de COTS-software deze beperkingen niet oplegt, ervan uitgaande dat de software effectief werd ontworpen
- Wat belangrijk is, is zichtbaar binnen minder pagina's documentatie met effectieve traceerbaarheid en het gebruik van agile boards voor voortgangsrapportage