Zoveel IT checklisten, zoveel vragen

Meer dan 500 checklisten en met meer dan 20.000 vragen, alleen al over IT. Is dat niet een beetje to much?

Het antwoord daarop is ja en nee. Niet iedereen zal altijd alle checklisten gebruiken, en zeker niet in één project. De ene taak is de andere niet en een project kan niet tegelijkertijd maatwerk en een standaard software zijn. Voor sommige functies zijn er voldoende checklisten aanwezig. ITpedia wil echter volledig zijn en dekkend voor het gehele IT spectrum. D.w.z. van Business analyse tot en met uitfaseren van een applicatie; van het inrichten van een afdeling tot en met het wijzigen van die ene instelling. Op die manier heb je aan 500 checklisten niet genoeg.

Opzet van het checklisten-systeem

Met het toenemen van het aantal checklisten zal ook het aantal vragen toenemen. Dit loopt echter niet zo snel op als je verwacht. Onder de motorkap gaat ITpedia namelijk op een slimme manier om met de vragen. Als je alle vragen van alle checklisten bij elkaar optelt kom je inderdaad tot 20.000+ vragen. In werkelijkheid zitten er ‘slechts’ zo’n 8.000 vragen in de database. Dat komt omdat een vraag op meerdere checklisten kan voorkomen. Een vraag als ‘Zijn alle werkzaamheden ingepland?’ komt op alle checklisten voor die met het beoordelen van een planning te maken hebben. En dat zijn er nog al wat want bij de start van iedere fase maken we wel een planning gemaakt. Het is echter niet zo dat de planningschecklist voor iedere fase gelijk is. Per fase liggen de accenten immers anders zodat er telkens een aparte checklist voor is.

IT deelgebieden

Er zijn in de IT deelgebieden waarbij medewerkers niets met het ander deelgebied te maken hebben en elkaar waarschijnlijk nooit tegen zullen komen. Zo zal een acceptatietester waarschijnlijk nooit te maken krijgen met de hardware leverancier. De kans dat de IT-auditor ooit de destijds ingehuurde programmeur zal leren kennen is eveneens gering. Deze medewerkers hebben elkaars checklisten ook niet nodig. Misschien zullen we uit nieuwsgierigheid eens kijken hoe we de deliverable later gaan beoordelen, maar veel verder hoeven we niet te gaan.

Omdat we deliverables op verschillende aspecten kunnen beoordelen zijn er in ITpedia clustertjes van checklisten ontstaan. Bij het maken van een programmaontwerp bijvoorbeeld kunnen we kijken naar de manier waarop het ontwerp tot stand is gekomen (werkwijze), het idee achter het ontwerp (inhoudelijk) en de wijze waarop we het ontwerp valideren (procedureel). Deze checklisten zijn onderdeel van een groter geheel, het beoordelen van het ontwerp. Het ontwerp in dit voorbeeld kunnen we daarom op verschillende niveaus beoordelen. De bovenliggende checklist is een subset van de onderliggende checklisten. Het ontwerp kunnen we dus op een globaal niveau (intake) of dieper op de verschillende aspecten (review) beoordelen.

Zoeken naar een geschikte IT checklist

Het vinden van een geschikte checklist kan een hele uitdaging zijn. Belangrijk probleem daarbij is de definitie kwestie. Wat in de ene organisatie een technisch ontwerp is kan voor de andere organisatie een systeemontwerp zijn. Wat het ene bedrijf een functioneel beheerder noemt is voor het andere bedrijf een informatie analist. Om dat probleem te vermijden en het zoeken zo gemakkelijk mogelijk te maken biedt ITpedia de checklisten in een bepaalde structuur aan.

Uitgangspunt is de klassieke waterval methodiek, ITpedia noemt dit IT projectfasering. Getracht is om alle checklisten onder die paraplu te brengen. Iedere IT-er is min of meer bekend met de standaard projectfasering en kan bedenken welke activiteit in welke fase thuis hoort. Als je klikt op IT-projectfasering is te zien hoe de fasering is opgedeeld. Door op een fase te klikken komen steeds gedetailleerder activiteiten en deliverables in beeld. Bij het klikken op “Checklist” komt de daadwerkelijke checklist in beeld en kunnen we de beoordeling vastleggen. Naast de IT projectfasering zijn dezelfde checklisten ook de vinden via andere indelingen.

Dit zijn:Application Services Library (ASL), Continuïteit, Kwaliteitsattributen, Functies in de automatisering en Webdesign. Soms zijn deze indelingen aangevuld met eigen meer specifieke checklisten.

Checklisten en Scrum

Je zou al snel denken dat de checklisten vanwege hun indeling niet geschikt zijn voor Agile – Scrum projecten. Dit is echter schijn. We beoordelen immers deliverables en deze zijn inhoudelijk niet zo verschillend. Een acceptatietest blijft een acceptatietest en een technisch ontwerp blijft een technisch ontwerp. De indeling moeten we dan ook meer zien als een kapstok om op een snelle manier de juiste checklist te vinden dan als een dogmatische project aanpak. Als het niet helemaal duidelijk is waar een checklist onder valt kunnen we altijd op trefwoord zoeken. Het woord ‘Acceptatietesten’ levert 11 checklisten op verdeelt over verschillende fases en methodieken. Daarbij wordt gezocht op het woord in de checklist benaming. Het aanvinken van de Fulltext checkbox levert zo’n 50 checklisten op die betrekking hebben op ‘Acceptatietest’. In dat geval zoekt ITpedia namelijk ook naar het trefwoord in alle checklistvragen.

Checklisten verlanglijstje

Is 500+ checklisten voldoende om alle IT aspecten te beoordelen? Nee, bij lange na niet. ITpedia is nog lang niet af en een aanvulling voor de bezoekers om zelf checklisten op te kunnen voeren staat hoog op het verlanglijstje. Het aantal checklisten waar behoefte aan is groeit ook gestaag. Denk aan onderwerpen als SaaS, Agile-Scrum, BiSL, ITIL, TMap, Het Nieuwe Werken, Cloud computing en Search Engine Optimalisatie, allemaal onderwerpen waarvoor mooie checklisten zijn te maken. Mocht je een checklist hebben die geschikt is neem dan contact met ons op, dan kijken wij of we hem in ITpedia kunnen opnemen.

Discussieer mee op LinkedIn.