Checklisten
Checklisten zijn een goede zaak. De gedachte achter checklisten is moeilijk te betwisten. In principe breekt een checklist een ingewikkelde procedure op in een reeks logische, gemakkelijk te begrijpen stappen. Dit helpt een professionele medewerker een werkproces succesvol af te ronden. De oorsprong van de moderne checklist gaat terug naar 1935 en de introductie van de B17 Flying Fortress Bomber door de Amerikaanse luchtmacht. De B17 checklist heeft ongevallen voorkomen die anders door menselijke fouten zouden zijn veroorzaakt en de afgelopen 80 jaar zijn er vele de versies de vliegtuigindustrie in gebruik. Checklists zijn zo effectief dat ze niet alleen in de luchtvaart worden gebruikt. Ze hebben een rol in van alles, van: “Wat neem ik mee op reis” tot “Hoe sluit ik mijn kernreactor af”. Checklisten zijn nuttig in een complexe omstandigheden waar het menselijke brein verward of verstoord kan raken, met name in een stressvolle situatie. Het is dus geen verrassing dat we checklisten voor Project Management in de ICT en automatisering tegenkomen. ITpedia staat overvol met checklisten voor allerlei IT professionals.
In een artikel in Nature wordt gesproken over een voorbeeld van 200.000 procedures uitgevoerd in 101 ziekenhuizen in Canada, waar er geen aanwijzingen waren dat het aantal complicaties en sterfgevallen daalde na de invoering van checklisten. Het artikel maakt een heel duidelijk punt: De checklist is niet het probleem, het gaat er om dat de medewerkers ervoor moeten kiezen om ze te gebruiken. Er zijn een aantal ‘issues’ die hierbij spelen:
De ITpedia checklisten kunnen IT professionals helpen bij het beoordelen van IT producten en IT organisaties. Omdat het kant en klare checklisten zijn kan je meteen aan de slag en dat scheelt veel tijd. Daarbij kunnen de checklisten je op punten wijzen waar je nog niet eerder aan hebt gedacht. Niet te min schuilt er een aantal gevaren aan het gebruik van checklisten. Voordat je lukraak begint met invullen moeten we je eerst op deze punten wijzen.
Stel je hebt een ontwerp voor je liggen. Je leest het even door en legt het vervolgens langs de bijhorende checklist. Stjap Stjap Stjap, klaar.
Deze werkwijze kan tot vervelende situaties leiden waarbij de makers van het ontwerp met je in discussie zullen gaan. Je moet vooraf duidelijk maken dat het ontwerp tegen een bepaalde checklist gehouden zal worden en wat er wordt verwacht. Daarnaast moet je ook de checklist goed doorlezen en de vragen als het ware ‘mappen’ op het ontwerp. Er moet in je hoofd een soort synchronisatie plaatsvinden tussen het ontwerp en de checklist. Van beide moet je de bedoeling begrijpen.
Niet iedere organisatie en iedere methodologie gebruikt hetzelfde jargon. De invulling van het begrip Ontwerp kan in jou project anders zijn als in het checklistensysteem. Je moet dus wel opletten welke checklist je pakt en eventueel bepaalde checklisten combineren als dat nodig is.
Een ander voorbeeld van een verkeerde checklist is als er wordt gewerkt aan een speciaal project. Opdrachten die niet vaak voorkomen of onder speciale omstandigheden plaatsvinden kunnen afwijken van het in de checklist gevraagde. Het is vervelend als je er als Projectmanager achter moet komen als je halverwege de checklist bent.
Soms kom je op checklisten vragen tegen waarvan je je afvraagd waarom ze er op staan. Bepaalde vragen zijn inderdaad niet altijd in alle gevallen relevant. Ze staan echter vanwege de volledigheid op de lijst. Deze vragen kunnen eenvoudig geskipt worden of als gemiddeld worden beoordeeld.
Dit is het grootste gevaar van het gebruik van checklisten. Je vertrouwt op de checklist, rond hem af en denkt dat alles goed is. Alleen net die ene cruciale vraag ontbreekt waardoor het project toch nog tegenslag krijgt te verduren. Het bestaan van de checklisten is fijn, maar ontslaat je er als IT professional niet van om na te blijven denken.
Het invoeren van een checklist gaat om het overbrengen van Best Practices.
Als voorbeeld van bewezen Best Practices is die van de luchtvaart. Deze is eert op veel plaatsen enthousiast aangenomen en vervolgens verplicht gesteld. Er zijn echter voorbeelden waar checklisten niet de gewenste impact hadden. Op basis van ervaringen blijkt dat het problem ligt in het implementatieproces en de overdracht van de Best Practices. Een goede implementatie is niet altijd een simpele overdracht van een vel papier. Maar als de checklisten eenmaal goed geïmplementeerd zijn levert dat ook wat op.
We willen natuurlijk geen afbreuk doen aan het checklistensysteem want de voordelen wegen ruim op tegen de nadelen. We willen je echter wel waarschuwen voor de genoemde gevaren. Het advies is om de beoordeling van IT producten goed voor te bereiden en wel overwogen de checklisten te kiezen. Blijf nadenken en maak gebruik van je eigen kennis en ervaring. Lees hier meer over het gebruik van de checklisten van ITpedia. De project checklisten van ITpedia vind je hier.
Discussieer mee op LinkedIn.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.