No Results Found
The page you requested could not be found. Try refining your search, or use the navigation above to locate the post.
Wat zijn de 5 stappen van een goede evaluatie? En waarom worden die evaluaties zo weinig en met zo weinig aandacht uitgevoerd?
Waarom blijft de opvolging van de leerpunten zo vaak achterwege? Terwijl het gestructureerd uitvoeren evaluaties in mijn ervaring een fluitje van een cent is. Mits goed uitgevoerd. Met dit artikel hoop ik duidelijk te maken dat iedereen een goede evaluatie kan uitvoeren. En kan vertalen in een betere werkelijkheid. Volg de stappen en klaar is kees.
Constateerde het al in haar rapport: een van de belangrijkste oorzaken van het keer op keer mislukken van grote ICT-projecten bij de overheid, ligt in een gebrek aan lerend vermogen. En dit geldt waarschijnlijk niet alleen voor de overheid.
Toch blijkt uit promotieonderzoek van de Universiteit Twente dat ICT projecten binnen de overheid regelmatig onvoldoende geëvalueerd worden. Daardoor ontneemt men zich de kans om te verbeteren en te leren, aldus promovendus drs. Wouter Bronsgeest RI.
Een goede evaluatie bevat de volgende elementen: focus, zowel in de groep als op de juiste vraag; alle informatie op tafel; gedragen besluiten, en concreet uitvoerbare en controleerbare vervolgafspraken.
Hoe zet je zo’n evaluatie op? De vijf stappen van een goede evaluatie zijn als volgt:
(1) voorbereiding
(2) tijdlijn
(3) wat ging goed/wat ging niet goed
(4) oplossingen
(5) vervolgafspraken
We schreven hier ook een handboek over, waar we dit tot in detail bespreken.
Dit handboek vind je hier en is gratis te downloaden!
Een goede voorbereiding is het halve werk. Dit begint al met de samenstelling van de aanwezigen. Nodig alleen die mensen uit die een relevante bijdrage kunnen leveren. Dit kan gaan om informatie over wat wanneer gebeurde of over de mogelijke oplossingen en de keuze daarin. En zorg ook dat iedereen die een relevante bijdrage kan leveren aanwezig is, zodat niet later nieuwe informatie tot andere inzichten kan leiden. Dus ook mensen die er last van hadden, of personen die iets moet gaan doen of regelen. Zorg dus dat je het juiste team bij elkaar krijgt.
Begin de sessie met een introductie waarom we bij elkaar zitten. Daarna moet je zo snel mogelijk iedereen bij de sessie betrekken. Dit kan heel simpel met een voorstelrondje, een rondje waterstanden, of een eenvoudige vraag die iedereen kan beantwoorden: hoe begon jouw dag, wat was je eerste huisdier, wat voor lekkers onlangs gegeten, etc. Belangrijk is om op dit moment nog uit de inhoud te blijven.
Vervolgens schrijf je doelstelling van de sessie op. Dit heb je natuurlijk goed voorbereid. Kies een doelstelling waar niemand het mee oneens kan zijn. Zorg dat die doelstelling gedurende de hele sessie voor iedereen zichtbaar blijft, zodat eraan gerefereerd kan worden. Dit kan bijvoorbeeld door hem op een flip-over te schrijven en aan de muur te hangen. Anker het doel vervolgens door iedereen zijn persoonlijke doelstelling voor de sessie te laten opschrijven en eventueel te delen. Dat laatste (delen) mag wel, maar hoeft niet.
Tot slot van de introductie moet je zorgen voor de juiste omgeving. Dat is een waarin iedereen vrij durft te spreken en iedereen een gelijkwaardige gesprekspartner kan zijn. Dan helpt om spelregels expliciet en ook weer voortdurend zichtbaar op te hangen: elkaar uit laten praten, geen zijpaden en andere bekende verstoringen van een goed resultaat. Dit is belangrijk, want juist de mensen die vaak het stilst zijn, kunnen met hele goede ideeën komen.
In de tijdlijn probeer je alle feiten naar boven te halen. Feiten zijn in dit geval alles wat je met je zintuigen (kijken, horen, ruiken, proeven, voelen) kunt waarnemen. Probeer chronologisch met de groep alle gebeurtenissen die relevant zijn voor de evaluatie, op een rij te zetten. Beperkt je tot de feiten. Meningen zijn voor later.
In de derde stap ga je met elkaar brainstormen over wat er goed ging en wat niet. Dit kan bijvoorbeeld met twee flip-overs (voor elk een) of een white board met twee helften. Hoe je een goede brainstorm organiseert, staat op veel plekken op internet goed beschreven. Zorg dat daarbij iedereen aan bod komt. Breng niet teveel structuur aan. Dat gaat ten koste van de creativiteit.
Vervolgens ga je met elkaar brainstormen over oplossingen van de geconstateerde problemen. Belangrijk is ook hier dat iedereen aan bod komt en de creativiteit vrij spel krijgt. Ook mag er nog bijgeplakt worden bij wat ging goed/niet goed. Vraag verduidelijking als een oplossing niet concreet genoeg is: “Communicatie? Wie met wie? Waarover, Wanneer?” Beperk uitweidingen over stokpaardjes. Vaak zijn dat oude koeien die een goede reden hebben om in sloot te belanden. Het gaat om het krijgen van zoveel mogelijke oplossingen. Niet om het etaleren van het eigen gelijk.
Als je alle oplossingen zo’n beetje verzameld hebt, maak dan een selectie van de meest kansrijke oplossingen. Deze selectie doe je op de verhouding rendement/inspanning. Dit kan bijvoorbeeld door iedereen stippen te laten uitdelen. Iedereen mag dan 10 stippen verdelen over een aantal oplossingen. Beperkt het maximum aantal stippen per oplossing om te voorkomen dat iemand al zijn stippen op zijn of haar favoriete oplossing zet.
Nu we de meest kansrijke oplossingen hebben, is het een kwestie van vervolgafspraken maken. Wie moet wat wanneer doen en wat heeft hij of zij daarvoor van wie nodig? Vaak zijn degenen die de oplossing bedenken ook degene die de oplossing kunnen implementeren. Zorg ervoor dat iemand niet alleen maar taken erbij krijgt met het verzinnen van goede oplossingen. Regel ook ruimte en tijd in de agenda’s voor het uitvoeren van te verdelen taken. Daar is vaak een baas bij nodig die tijd, ruimte en middelen kan verzorgen. Als het probleem moet worden opgelost – en dat moet het volgens de aanwezigen in de zaal – dan moet je voor tijd, ruimte en middelen ook de handen op elkaar kunnen krijgen.
Zo kun je een actielijst maken met wie, wat, wanneer af heeft, wat daarvoor nodig is (tijd, middelen) en wie dat moet regelen. De kolommen met wie kunnen alleen gevuld worden met mensen die aanwezig zijn bij de sessie. Heb je iemand nodig buiten de groep? Spreek dan af wie binnen de groep dat regelt. Op die manier creëer je een werkgroep.
Vervolgens bespreek je aan de hand van de actielijst wanneer het zinvol is om weer bij elkaar te komen. En hoe dat geregeld wordt: ter plekke prikken, agendaverzoek, secretariaat, datumprikker. Ook dat levert vast weer een actiepunt op.
Tot slot maak je afspraken over de communicatie: wie moet/mag wat met wie communiceren. En hoe wordt dat dan gecommuniceerd: medium, inhoud boodschap. Mag alles met iedereen gedeeld worden wat hier besproken is? Moet er een samenvatting naar het MT? Is het nieuwswaardig voor intranet? Maak ook afspraken hoe je onderling communiceert als zaken anders lopen dan gedacht en over hoe de voortgang gemonitord wordt.
Een gestructureerde evaluatie uitvoeren hoeft niet ingewikkeld te zijn. Als je de vijf stappen voor een goede evaluatie volgt krijg je in mijn ervaring een hele vruchtbare evaluatie. Die iedereen als nuttig en zinvol zal ervaren. En de vervolgacties, mist goed geborgd en opgevolgd, krijgen ook het benodigde draagvlak.
Mocht je nog vragen hebben over de vijf stappen van een goede evaluatie, we komen je graag persoonlijk toelichten hoe jij dit binnen jouw organisatie op de juiste wijze implementeert. Alleen als dit systeem goed wordt toegepast benut je de maximale potentie van dit systeem.
Succes ermee!
Vond je dit artikel nuttig? Wil je een handboek dat je altijd overal bij je kunt hebben? En dat bovenstaande stappen tot in detail beschrijft? Laat dan hier je mailadres achter en we sturen het je direct toe!
Te veel organisaties hebben regelmatig te maken (grote) IT-storingen. Iedere keer dat ik die verhalen hoor, denk ik: hoe is dit toch mogelijk? In onze ervaring is dit probleem namelijk best wel eenvoudig en snel op te lossen.
Vaak denken mensen dat het probleem wel ingewikkeld zal zijn, of dat er enorme investeringen voor nodig zijn. Het tegenovergestelde is het geval! De meeste van dit soort problemen zijn zonder nieuwe techniek op te lossen. En vragen dus geen enorme investeringen in tijd en/of geld.
Het valt me ook op dat veel organisaties op een of andere manier gewend zijn geraakt aan dit soort storingen. Het hoort erbij. Of: we hebben nu eenmaal deze mensen zitten en die leveren (blijkbaar) deze kwaliteit.
Om deze organisaties te helpen en mijn kennis hiervan te delen, leg ik uit hoe je dit soort problemen in korte tijd en vrij eenvoudig kunt oplossen. En nou maar hopen dat iedereen dit leest!
Als een systeembeheerder te maken krijgt met een verstoring, gaat hij als eerste na welke wijzigingen er in de afgelopen periode zijn doorgevoerd. Dit is niet zonder reden. Verreweg de meeste ICT-verstoringen worden veroorzaakt doordat iemand iets heeft aangepast en daarbij iets over het hoofd heeft gezien. Ik moet dan altijd denken aan het stroomschema dat ik als plaatje bij dit document hebt bijgevoegd. Erg grappig om te lezen.
Maar als de meeste verstoringen door een menselijke fout veroorzaakt worden, zijn deze dus eenvoudig te voorkomen: door zorgvuldig te handelen. En precies daar zit de oplossing van dit probleem. En daarom zijn er ook geen enorme investeringen nodig. Overigens wordt de rest van de verstoringen veroorzaakt door fouten in de programmatuur, falende hardware, uitvallende stroom en vollopen van de capaciteit.
Als we nu de meeste van die menselijke fouten gaan voorkomen, dan worden incidenten opeens echte incidenten (uitzonderingen). Hoe? Door na elke grote verstoring een evaluatie uit te voeren. Je zult verbaasd zijn. Mijn ervaring is dat door het uitvoeren van vijf van deze evaluaties het aantal grote verstoringen met 80% kan worden teruggebracht. Zo eenvoudig kan het zijn!
Wat is binnen jouw organisatie de grootste oorzaak van ICT verstoringen?
Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.
ICT en overheid, het blijft een moeilijke combinatie. Sinds het rapport van de commissie Elias – die de tot dan toe gesneuvelde ICT-projecten namens de kamer onderzocht – hebben we o.a. de SVB (MRS, PGB), Defensie (SPEER), Amsterdam (Andreas), Belastingdienst (EPTM), VenJ (Radar) en BZK (BRP) moeten toevoegen aan het lijstje. Kandidaten voor de toekomst zijn: Investeringsagenda Belastingdienst, DSO (omgevingswet) en de DICTU cloudwerkplek (nu al 60M). Een van de belangrijkste aanbevelingen van de commissie Elias was overigens om overheid te laten leren van zijn fouten. En dat doet de overheid helaas niet, zo blijkt ook uit onderzoek van de Universiteit Twente.[1]
Als ik kijk naar een aantal van die projecten, zoals de recente blunders bij de SVB (MRS), Defensie (SPEER) en BZK (BRP), valt mij een aantal belangrijke overeenkomsten op in al die projecten. Het moe(s)t (1) een allesomvattend systeem worden, dat (2) van de grond af opnieuw opgebouwd moe(s)t worden met (3) de nieuwste techniek. Elke ICT-er weet dat dat leidt tot (1) veel complexiteit, (2) veel kinderziektes en jarenlange ervaring overboord gooien, en (3) veel gebreken en onontdekte ‘features’. Dus extra risico, extra risico en extra risico Vind je het gek dat al die projecten gefaald zijn? Onnodige risico’s bovendien, zoals we snel zullen zien.
Hoe dan wel? De oplossing is verbluffend eenvoudig. Kijk maar eens naar de redenen voor het introduceren van al die risico’s:
Die moet toekomstige uitbreidingen makkelijker maken. Fair, maar vaak niet de reden waarom het project gestart wordt.
Die heeft vaak als reden dat de systemen door aangebouwde features en nieuwe wetgeving onnodig complex zijn geworden. Het nieuwe project biedt dan de uitgelezen kans om met een schone lei te beginnen en het systeem wel logisch op te bouwen. Ook hier: begrijpelijk, maar heeft niets met de aanleiding/het oorspronkelijke doel van het project te maken.
Lijkt een nobel doel omdat de huidige systemen vaak verouderd zijn, met verouderde techniek, verouderde programmatuur en verouderde kennis die lastiger verkrijgbaar is. Ook wel legacy genoemd. Toch denk ik dat hier ook iets anders meespeelt: prestige van zittende managers. Zowel vanuit ICT – die het vaak maar wat leuk vinden om met het nieuwste van het nieuwste te werken, en zo hoort dat ook voor een ICT-er! – als door manager vanuit de business wordt maar wat graag gepocht dat gewerkt wordt met state-of-the-art techniek. Leuk, maar bezien vanuit de projectdoelstelling voegt het weinig tot niets toe.
Dus we zien dat met de overeenkomsten in de faalprojecten risico’s geïntroduceerd worden die niets te maken hebben het oorspronkelijke doel van het project. Bij BPR was dat bijvoorbeeld de kwaliteit van de gegevens verbeteren en informatie direct beschikbaar stellen. Bij de SVB was de doelstelling het integraal afhandelen van klantcontacten, sneller inspelen op gewijzigde wetgeving en “een wendbaardere organisatie”. En bij Defensie was dat de verbetering van het financieel en materieel beheer. Zoals u ziet: geen reden om (1) een allesomvattend systeem (2) met de nieuwste techniek (3) van de grond af opnieuw op te bouwen.
De oplossing van het probleem voor ICT en overheid zou dus zomaar eens heel simpel kunnen zijn. Kijk naar het oorspronkelijke doel van het project. en stel hiervoor KPI’s op. Probeer daar zo snel mogelijk en met zo min mogelijk nevendoelstellingen te komen. De andere doelen, hoe nobel ook, moeten hun eigen business case hebben en daarop beoordeeld worden. En niet meeliften op een project wat te belangrijk is om niet te realiseren!
[1] https://www.utwente.nl/nieuws/!/2016/10/335299/meer-vorm-dan-inhoud-onderzoek-naar-evaluaties-van-ict-projecten-bij-de-overheid
Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.
[tqb_quiz id=’19005′]
Wat is een succesvol team? Je hebt er hoe dan ook wel eens mee te maken gehad. Samenwerken. En dan met namen samenwerken in een team. Het lijkt een onoverbrugbare drempel. Als het gaat om het samenstellen van een succesvol team wordt er vaak gekeken naar de individuele kwaliteiten en niet naar hoe ze moeten samenwerken. Hooguit of ze een beetje “samen door een deur kunnen”. Maar hoe je nou een succesvolle samenwerking opzet? Daar wordt doorgaans nauwelijks tijd aan besteed.
Als je op internet zoek naar de ingrediënten van een succesvol team kom je uit op: Teamontwikkeling volgens Tuckman (Norming, Storming, Norming, Performing), Belbin, LIFO, DISC, managementdrives en andere kleurenschema’s. Het model van Tuckman biedt mooie aanknopingspunten om te zien waar je staat met de ontwikkeling van een team. Je weet dat er gelazer van komt als je mensen bij elkaar in een hok zet. En alle kleurenmodellen vertellen dat mensen verschillend zijn en dat het respecteren van die kwaliteiten erg waardevol is. Ja, mensen zijn verschillend, héél erg verschillend zelfs, en zeker, het gebruik van elkaars kwaliteiten is een belangrijk onderdeel van een succesvol team. Naar mijn mening is dat zelfs de kern van het model van Tuckman: het leren kennen en waarderen van elkaars kwaliteiten. Maar of dat gebeurt hangt dan in hoofdzaak af van de wil van mensen om samen te werken. En dat vind ik een te smalle basis om een succesvolle samenwerking af te dwingen.
Mijn ervaring is dat een succesvol team altijd bestaat uit vier basis-ingrediënten. Deze elementen heb ik ooit ontleent uit Keuning & Epping. Zij schrijven (op basis van McGregor en Likert) dat de recepten voor geslaagd teamwerk zijn: een duidelijk doel, openhartige communicatie, gedeeld leiderschap en een prettige informele sfeer.
Als je bovenstaande elementen allemaal aanwezig laat zijn in het team, gaat het samenwerken in een team als de brandweer!
The page you requested could not be found. Try refining your search, or use the navigation above to locate the post.
ICT Simpel uitgelegd. Tja, leg dat maar eens uit. Om te beginnen…
ICT-afdelingen hebben het druk, dat is algemeen bekend. Maar waarmee dan? Wat doen ze de hele dag eigenlijk? Waarom dan? En waarom zijn projecten die ze moeten opleveren nooit op tijd? Hoe komt het dat het oplossen van een melding altijd te lang duurt? Ze hebben NOOIT tijd voor mijn wensen. In dit artikel hoop ik voor eens en voor altijd eens haarfijn uit te leggen hoe dat zit. Leuk voor ICT-managers om door te sturen en voor mensen in de overige afdelingen om te lezen.
Heel erg platgeslagen is de opbouw van de ICT-afdeling vrij overzichtelijk. Er zijn twee hoofdstromen: instandhouding en wijzigen.
Instandhouding houdt zich bezig met het oplossen en voorkomen van verstoringen: oplossen natuurlijk zo spoedig mogelijk en in volgorde van prioriteit, en het liefst natuurlijk voorkomen. Dat betekent regulier onderhoud op zaken waarvan bekend is dat het anders (op termijn) tot storingen kan/zal leiden en verder actief speuren naar oorzaken van veel voorkomende verstoringen en/of verstoringen met grote impact.
Wijzigingen komen in mijn optiek in drie soorten: standaard, klein en planbaar. Standaard wijzigingen zijn die wijzigingen die relatief vaak voorkomen en waarvoor het loont om ze te standaardiseren. Dit betekent dat er een werkinstructie voor geschreven kan worden die altijd op dezelfde manier, met hetzelfde resultaat en met voorspelbare doorlooptijd uitgevoerd kan worden. Voorbeelden hiervan zijn: het aanmaken van een account, het verlenen van rechten op een applicatie, het resetten van een wachtwoord en een nieuwe medewerker voorzien van standaardapparatuur.
Kleine wijzigingen zijn alle wijzigingen die een relatief weinig werk zijn, niet ingepland hoeven te worden en, mits er voldoende capaciteit ingepland is, snel afgehandeld kunnen worden.
Alle overige wijzigingen zijn te plannen wijzigingen. Ik noem dat altijd projecten.
Als we weten welke werkstromen er door een ICT-afdeling gaan, kunnen we de aansturing van die afdeling daarop afstemmen. Zorg dat er voor elke werkstroom voldoende capaciteit ingeruimd wordt, en (heel belangrijk) dat de betreffende medewerker ook niks anders doet dan die bewuste werkstroom afhandelen. En laat de werkstromen vooral niet mengen!! Storingen oplossen, storingen voorkomen, standaard wijzigingen, kleine wijzigingen, en projecten hebben elk hun eigen dynamiek. En elk soort werk heeft een bepaald niveau van senioriteit nodig. Maak daarom een rooster met diensten waarin voor elke soort werk de juiste capaciteit (in uren en senioriteit) ingeruimd wordt. Daarna is het belangrijk om de capaciteit te managen. Ik zou zeggen: “Probeer het!”
Uiteraard gaat het voorkomen van storingen invloed hebben op de benodigde capaciteit voor het oplossen van storingen. Dit betekent het verregaand standaardiseren van wijzigingen met volledige uitvraag vooraf van de juiste informatie, dit voorkomt fouten en onnodig werk. Grote wijzigingen gepland en met beleid doorvoeren voorkomt verstoringen en herwerk. Het komt nogal eens voor dat er geen tijd is om werkzaamheden gestructureerd door te voeren en dan gaat er nog meer tijd op aan ongestructureerd (ad hoc) werk, waardoor de hele boel vastloopt. Dat moet voorkomen worden!! Bovenstaande manier van organiseren biedt daarvoor een kans.
Bij deze zijn alle ICT-ers uitgenodigd om deze tekst* in hun organisatie te verspreiden, om duidelijk te maken wat ‘ze’ nou eigenlijk doen bij ICT.
Is ICT simpel uitgelegd voor jou nu?
*graag met bronvermelding
Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.
[tqb_quiz id=’19005′]
Veel directeuren, businessmanagers en overige niet ICT-leidinggevenden durven er nauwelijks iets van te vinden: ICT. Ze lopen er met een grote boog omheen. Terwijl hun afhankelijkheid ervan steeds verder toeneemt. Dat zou ik graag willen veranderen. Daarom hierbij 5 KPI’s voor ICT waarop – naar mijn mening – elk MT-lid maandelijks zou moeten sturen.
Als we kijken naar de ICT-afdeling dan kunnen we twee hoofdtaken onderscheiden:
1. Zorgen dat de huidige functionaliteit beschikbaar is en blijft;
2. Zorgen dat huidige functionaliteit aangepast wordt aan nieuwe eisen en wensen.
Hieruit kunnen we gelijk twee KPI-s afleiden:
(1) beschikbaarheid van de top 10-applicaties en
(2) een lijst met wijzigingen (projecten) die gepland staan en wanneer die beschikbaar zullen komen.
Voor de niet-beschikbaarheid wil je ook graag
(3) een lijst met – de tien – langst openstaande verstoringen, waarom ze nog openstaan, benodigde actie om de storing op te lossen en wanneer de verwachting is dat die storing opgelost zal zijn.
Ook willen we graag dat nieuwe accounts snel aangemaakt worden, rechten snel toegekend worden en overige acties die regelmatig voorkomen snel uitgevoerd worden. Hiervoor zou je kunnen laten rapporteren op
(4) een lijst met standaard handelingen, afgesproken doorlooptijden, aantal meldingen deze maand, aantal meldingen met te lange doorlooptijd en gemiddelde overschrijding.
Tot slot wil je nog dat makkelijke kleine meldingen snel afgehandeld worden (in 1 tot 2 werkdagen). Spreek daarover ook een tijd af en laat een
(5) rapportage kleine meldingen maken (aantal totaal, aantal te laat en hoeveel te laat).
Hiermee hebben we 5 KPI’s voor ICT gedefinieerd waarop elk MT zou moeten kunnen sturen. Hoe je dit vervolgens in een boordroom aan tafel krijgt lees je hier. Ik hoor graag jullie reacties, ervaringen, bedenkingen en overig commentaar!
Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.
[tqb_quiz id=’19005′]