Een risicomatrix is een tabel die de dingen die mis kunnen gaan sorteert op twee vragen: hoe waarschijnlijk is het, en hoe erg zou het schaden? Elk risico krijgt een positie in het raster, en die positie bepaalt hoeveel aandacht en budget het nu verdient.
De meeste teams gebruiken een raster van vijf bij vijf. Je beoordeelt de waarschijnlijkheid van 1 (zeer onwaarschijnlijk) tot 5 (vrijwel zeker) en de impact van 1 (vervelend) tot 5 (funest voor het bedrijf), en vermenigvuldigt de twee. Een score van 20 tot 25 heeft deze maand nog een plan nodig. Een score van 1 tot 4 komt op een lijst die je twee keer per jaar bekijkt.
Een voorbeeld met drie risico's. Belangrijkste leverancier valt weg: waarschijnlijkheid 2, impact 5, score 10. Hoofdontwikkelaar vertrekt: waarschijnlijkheid 3, impact 4, score 12. Nieuwe concurrent onderbiedt je prijs: waarschijnlijkheid 4, impact 3, score 12. Twee risico's staan gelijk op 12, dus vergelijk je wat een oplossing zou kosten. Je codebase documenteren en een tweede ontwikkelaar opleiden kost een paar weken werk. Voorkomen dat een concurrent de markt betreedt, is niets waar je controle over hebt. Dus richt je je op het ontwikkelaarsrisico en volg je het prijsrisico alleen.
Een matrix is alleen nuttig met vier kolommen ernaast: het risico, de score, de tegenmaatregel en de verantwoordelijke persoon met een datum. Zonder eigenaar is het een decoratieve tabel.
Een gegenereerd businessplan bevat meestal een risicomatrix in het risicohoofdstuk, omdat banken en investeerders er een verwachten. Daar maken oprichters twee fouten. Ze beoordelen alles als hoog, wat de rangschikking platslaat en niemand helpt. Of ze vermelden alleen voor de hand liggende externe risico's, zoals een recessie, en slaan de specifieke interne risico's over die ze zelf konden oplossen, zoals één persoon die het enige beheerderswachtwoord bezit. Werk de matrix elk kwartaal bij.
