Raines rules
Op 25 oktober 1996 vaardigde Franklin Raines, directeur van het Office of Management and Budget (Amerikaanse overheidskantoor belast met de regie en inkoop van ICT), een memo uit: "Information Systems Investments." Dat memo kreeg al snel de naam Raines' Rules en werd het leidende document voor overheidsinstellingen bij het investeren in IT. Dit jaar vieren ze hun 30ste verjaardag en nog steeds van waarde, ook bij Nederlandse IT projecten. Kees heeft ze getransponeerd naar de Nederlandse situatie en met een 9e en 10e regel aangevuld.
1. Is het nodig?
De ICT-oplossing moet onontbeerlijk zijn om de kernprocessen van de organisatie ondersteunen.
2. Kan het niet anders?
De voorgenomen ICT oplossing is nodig omdat er geen (bestaande) alternatieven zijn die grotendeels tot hetzelfde doel leiden. Niet in de private sector en evenmin in de overheidssector.
3. Is en blijft het simpel?
Het is ter ondersteuning van processen die zelf eerst zo simpel, goedkoop en effectief mogelijk gemaakt zijn, èn met speciale aandacht voor gebruik van (commerciële) standaardoplossingen.
4. Is het snel terugverdiend?
Het laat een duidelijk ROI zien die significant beter is, vóór de komma, dan bestaande alternatieven of werkwijzen.
5. Past het (qua IT)?
De ICT-oplossing moet consistent zijn met al aanwezige informatiearchitectuur. Hierbij is de goede en integere integratie van proces- en informatiestromen essentieel. Het vereenvoudigt daarbij het uitwisselen van data en delen van toepassingen en waarborgt een brede keus in leveranciers en vrijheid in de feitelijke uitvoering van de processen.
6. Kun je bewijzen dat het werkt?
De oplossing reduceert risico’s door individuele maatwerkoplossingen te voorkomen of hoogstens geïsoleerd toe te staan. Er wordt uitsluitend gebruik gemaakt van volledig geteste pilots, simulaties, of prototypes, met een sterke betrokkenheid en verantwoordelijkheid van de (eind)gebruiker. Er zijn duidelijke doelstellingen en mijlpalen, en er wordt getest volgens een van te voren ontworpen testprotocol. Elke test moet gedocumenteerd zijn en herhaald kunnen worden.
7. Zijn echt het losse blokjes?
Het ICT-project dient opgedeeld te worden in deeloplossingen welke zo klein zijn als praktisch mogelijk is. Elk van die deeloplossingen moet een aantoonbaar en zelfstandig nut c.q. rendement hebben. Onafhankelijk van latere te realiseren onderdelen of het eindproduct. Denk aan Agile als methode.
8. Blijf je de baas, ook later?
Te grote afhankelijkheid van één specifieke opdrachtnemer moet worden voorkomen door een duidelijke selectie in concurrentie met anderen. Alleen deelbetalingen worden overeengekomen en op basis van feitelijke mijlpalen. Er moet maximaal gebruikt worden gemaakt van de laatste technologieën.
En twee extra:
9. Blijft het schuurtje bij het huisje?
Staat de oplossing qua inspanning, kosten en/of belasting van de organisatie (dat is meer dan een ROI) in de juiste verhouding tot (de kosten van) het probleem?
10. Kan het snel?
Doorlooptijden van een totaal project moet bij voorkeur niet langer zijn dan 6-9 maanden met een duidelijke kop en staart. Een jaar of langer zorgt voor extra risico’s: De focus neemt af na verloop van tijd en dat begint al na een paar maanden. Het is erg moeilijk om bij een te lang durend project het goede overzicht te bewaren en de gezonde spanning verdwijnt. De werkelijkheid, die ook niet stil staat, haalt het project zeker in. Alles wat niet in de directe scope past, moet naar een vervolg project (en kan dan ook zelf weer worden ingehaald door de tijd).