Alternative zu Asana für das Risikomanagement im Projekt: ein Register, das keine Liste ist

Ein Risikoregister, das eine Aufgabenliste ist

Asana hat eine fertige Vorlage für ein Risikoregister und eine für eine Matrix. Ihre Logik ist stimmig: Sie beschreiben die Bedrohung, bewerten Wahrscheinlichkeit und Auswirkung, benennen einen Verantwortlichen und ergänzen einen Reaktionsplan. Bei einem Projekt und einem Dutzend Risiken reicht das. Es schlägt auch eine Tabelle, weil das Register dort sitzt, wo die Arbeit passiert, und ein Funktion-für-Funktion-Vergleich von FlexiProject und Asana zeichnet das größere Bild.

Die Grenze liegt in der Konstruktion. Ein Risiko ist hier kein eigenes Objekt, nur eine Aufgabe mit Zusatzfeldern. Alles, was daraus folgt, dass ein Risiko keine zu erledigende Arbeit ist, muss außerhalb des Tools organisiert werden.

Was die Vorlage leistet und was nicht

Die Vorlage ordnet die Informationen, und das ist ihr wahrer Wert. Drei Dinge gibt sie Ihnen nicht.

Ein Risiko kann nicht auf eine andere Aufgabe zeigen, weil es selbst eine Aufgabe ist. Sie können also nicht festhalten, dass eine bestimmte Bedrohung eine bestimmte Lieferung im Zeitplan betrifft. Risiken lassen sich auch nicht projektübergreifend vergleichen, weil eigene Felder nur innerhalb eines Projekts funktionieren. Und es gibt keine Ebene oberhalb des Projekts. Jedes Register ist in sich vollständig und blind für das, was daneben liegt. Drei Teams können dasselbe Lieferantenrisiko bearbeiten, und keines davon erfährt es.

Drei Anzeichen, dass das Register aufgehört hat zu funktionieren

Ein Register, das erst kurz vor dem Lenkungsausschuss aktualisiert wird statt laufend mit der Arbeit. Wenn das Aktualisieren eine gesonderte Tätigkeit ist, geschieht es, wenn jemand danach fragt. Meist zu spät, um noch etwas zu ändern.

Risiken, die von Hand in den Projektauftrag und den Monatsbericht abgetippt werden. Diese Arbeit erzeugt keine neue Information, und drei Versionen derselben Liste kursieren am Ende im Unternehmen.

Die Frage „bearbeitet das schon jemand“, ohne dass es jemanden zu fragen gäbe. Ohne eine Ebene, auf der Risiken aus verschiedenen Projekten zusammenkommen, wird jedes von Grund auf neu gelöst. Wir zeigen außerdem, worauf es bei Apps wie Asana wirklich ankommt.

Was Sie von einem Risikoregister verlangen sollten

Der Unterschied zwischen einer Liste und einem Modul läuft auf sieben Dinge hinaus. Jedes davon wird entweder vom System erledigt oder von Hand.

Zusammen beschreiben sie, was eine Software für das Risikomanagement leisten muss. Im Folgenden gehe ich die Anforderungen einzeln durch und zeige, wie FlexiProject sie umsetzt.

Eine Matrix in den Dimensionen, die Sie bereits nutzen

Das Konfigurieren der Risikomatrix wirkt wie ein Detail. Es ist einer der häufigsten Gründe, warum ein Risikomodul in einem PPM-System leer bleibt. Ein Unternehmen hat über Jahre eine Drei-mal-drei-Matrix entwickelt, und im eingeführten System ist Fünf-mal-fünf fest verdrahtet. Niemand schult dreißig Projektleiter auf eine neue Skala um, nur weil ein Anbieter es so beschlossen hat. Das Ergebnis ist absehbar: Das Modul bleibt ungenutzt und das Risiko landet wieder auf einer Folie.

In FlexiProject werden die Dimensionen der Matrix bei der Einführung festgelegt, ohne Programmierung. Das Unternehmen bringt die Skala mit, die seine Leute kennen, samt der Gewohnheit, dass eine bestimmte Bewertung eine bestimmte Reaktion verlangt. Der von Ihnen entwickelte Standard überlebt so den Werkzeugwechsel.

Eine Risikokarte statt einer Zeile in einer Tabelle

Im Projektmanagementsystem FlexiProject ist das Risikoregister ein eigenes Modul des Projekts. Jedes Risiko hat einen Namen, einen Status, einen Verantwortlichen, eine Verbindung zu einer Aufgabe im Zeitplan, eine Kategorie, eine Auswirkung, eine Wahrscheinlichkeit und ein Identifikationsdatum. Die Auswirkung auf den Zeitplan und die Auswirkung auf das Budget werden getrennt bewertet. Das zählt in der Praxis: Ein Risiko, das die Abnahme um einen Monat verzögert, und ein Risiko, das die Kosten um hunderttausend erhöht, verlangen verschiedene Reaktionen. Eine gemeinsame Bewertung „hohe Auswirkung“ unterscheidet sie nicht.

Über dem Register sitzt eine Risikokarte. Über die Registerdaten hinaus enthält sie Anhänge, den Steuerungsplan für diese Bedrohung und einen Messenger, in dem das Team dieses konkrete Risiko bespricht. Es wirkt wie eine Kleinigkeit, löst aber ein echtes Problem. Eine Diskussion in einem Team-Kanal ist in zwei Tagen verschwunden. Ein am Risiko festgehaltenes Gespräch bleibt bei ihm. Fragt jemand ein halbes Jahr später, warum diese Reaktion gewählt wurde, steht die Antwort am selben Ort wie die Entscheidung.

Risiko an eine Aufgabe im Zeitplan geheftet

Risikoregister sind meist flach. Sie behandeln ein Risiko, das das ganze Projekt betrifft, etwa Ressourcenknappheit, genauso wie ein Risiko, das eine einzelne Aufgabe betrifft, etwa eine Lieferung eines Subunternehmers. Das sind zwei verschiedene Situationen, und sie werden unterschiedlich gesteuert.

In FlexiProject lässt sich jedes Risiko mit einer konkreten Aufgabe im Modul Projektzeitplan verknüpfen. Sie ordnen ein Lieferantenrisiko der Aufgabe zu, die von der Lieferung abhängt, und ein regulatorisches Risiko der Genehmigungsaufgabe. Von da an trägt der Zeitplan Informationen über Bedrohungen. In der Aufgabenzeile erscheint ein Dreieck mit Ausrufezeichen und daneben ein Kreis: rot, wenn das Risiko aktiv ist, grau, wenn nicht. Der Projektleiter sieht die Stellen, die Aufmerksamkeit brauchen, ohne das Register zu öffnen.

Am meisten hilft das, wenn sich der Plan ändert. Verschiebt sich der Zeitplan, wissen Sie sofort, welche Risiken drängender geworden sind. Sie betreffen Aufgaben, die näher an einen harten Termin gerückt oder auf den kritischen Pfad gewandert sind. Diese Information steckt auch in einem flachen Register, aber Sie müssen sie sich selbst erarbeiten, indem Sie zwei Listen vergleichen. Also tut es meist niemand. Gesondert behandeln wir, was eine gute Alternative für die Projektplanung ausmacht.

Risiko als Wissen der Organisation, nicht eines Projekts

In den meisten Unternehmen läuft die Art, wie Teams Projektrisiken identifizieren und bewerten, auf ein Kick-off-Meeting hinaus, in dem sich jemand ausmalt, was schiefgehen könnte. Die Methode ist unzuverlässig. Menschen unterschätzen Bedrohungen, die sie noch nie erlebt haben. Das Unternehmen als Ganzes hat sie meist schon gesehen, nur in einem anderen Projekt.

Vorlagen mit einer Liste typischer Risiken

Eine Liste möglicher Risiken für einen bestimmten Projekttyp lässt sich in die Vorlage einbauen. Ein Team, das eine Kundeneinführung, ein Forschungsprojekt oder eine Investition startet, beginnt mit einer fertigen Basis und passt sie an seinen Fall an. Das ändert den Charakter des Meetings. Statt Bedrohungen zu erfinden, prüft das Team bekannte und entscheidet, welche zutreffen. Das ist schneller und wirksamer, gerade in weniger erfahrenen Teams.

Die Abschlusskarte und Risikoberichte

Die andere Seite dieses Mechanismus ist das Festhalten dessen, was tatsächlich passiert ist. Die Projektabschlusskarte kann die eingetretenen Risiken und ihre Lösung auflisten. Teams, die spätere Projekte planen, haben Zugriff auf historische Abschlusskarten.

Das dritte Element sind Berichte. Im Berichtsmodul können Sie eine Ansicht der Risiken für Projekte einer Kategorie oder aus einem Organisationsbereich bauen. Ein neues Team erhält eine konkrete Antwort: Das sind die Bedrohungen, die in ähnlichen Projekten aufgetreten sind. Zusammen sorgen diese drei Mechanismen dafür, dass das Risikomanagement nicht mehr von der Kompetenz eines einzelnen Managers abhängt.

Risikokategorien und die Ansicht für Fachbereiche

Risiko betrifft selten nur den Projektleiter. Die Rechtsabteilung will wissen, welche Pflichten und Streitigkeiten im Portfolio stecken. Die Produktion fragt nach technologischen Herausforderungen, der Einkauf nach Bedrohungen auf der Lieferantenseite. Mit einem im Projekt eingeschlossenen Register kann keiner von ihnen seine Frage stellen.

In den Einstellungen von FlexiProject definieren Sie Ihre eigene Liste von Risikokategorien, abgestimmt darauf, wie die Verantwortung im Unternehmen verteilt ist. Hier hört eine Risikostrukturierung (RBS) auf, ein Diagramm zu sein, und wird zu etwas, wonach das System filtern kann. Projektübergreifende Berichte bauen darauf auf. Die Rechtsabteilung sieht Rechtsrisiken über alle Projekte, die Produktion ihre eigenen, der Einkauf seine eigenen. Risiko ist nicht länger die Privatsache des Projektleiters. Separat legen wir dar, was echte Budgetkontrolle im Projekt bedeutet.

Portfolioebene, oder das Ende, dasselbe Risiko dreimal zu steuern

Bei mehreren Dutzend Projekten wiederholen sich manche Bedrohungen naturgemäß. Derselbe Lieferant, dieselbe Gesetzesänderung, dieselbe unreife Technologie. Sind Register in Projekten eingeschlossen, pflegt jeder Manager seine eigene Version dieses Risikos und kommt zu leicht abweichenden Schlüssen.

Die Projektportfolio-Software löst das anders. Jedes Portfolio in FlexiProject hat einen eigenen Risiko-Reiter. Er sammelt Bedrohungen aus allen Projekten dieses Portfolios. Der Koordinator sieht die Wiederholung und kann das Risiko zentral lösen, gestützt auf das gesamte verfügbare Wissen statt auf eine Perspektive. Dreifacher Aufwand wird zu einem Verantwortlichen und einer Reaktion. Es beseitigt auch die Situation, in der drei Projekte drei verschiedene Strategien auf denselben Lieferanten anwenden. Separat beschreiben wir, was eine Asana-Alternative für ein PMO leisten muss.

Schluss mit dem Abtippen: der Projektauftrag und der Statusbericht

Die auffälligste Ersparnis betrifft das Abtippen, nicht die Analyse. In vielen Unternehmen verlangt die Vorgabe, dass die wichtigsten Risiken in den Projektauftrag gelangen und einmal im Monat in den Bericht für den Vorstand. Mit einem separaten Register überträgt jemand dieselben Einträge an zwei Stellen und prüft, ob die Versionen übereinstimmen.

In FlexiProject zieht das Modul Projektauftrag die Risiken automatisch aus dem Register. Beide Dokumente sind von vornherein konsistent, nicht durch jemandes Sorgfalt. Die zyklische Statusberichterstattung funktioniert genauso. Enthält der Bericht einen Risikoabschnitt, füllt er sich selbst aus dem Register, und dem Manager bleibt ein Kommentar dazu, wie diese Bedrohungen gesteuert werden. Eine Tätigkeit, die keine neue Information erzeugte, verschwindet, und sie verschwindet aus der schlimmsten Woche des Monats.

Wann eine Vorlage genügt

Sie führen ein Projekt, steuern es selbst, haben ein Dutzend Risiken und niemand verlangt formale Berichte? Eine Register-Vorlage in einem Aufgaben-Tool genügt. Ein eigenes Modul fügt Formalität hinzu, nicht Kontrolle, denn die oben beschriebenen Probleme treten erst in größerem Maßstab auf. Wenn Sie einen breiteren Blick auf die Optionen wollen, haben wir die beste Software für das Risikomanagement gesondert verglichen.

Die Signale, dass dieser Maßstab erreicht ist, sind konkret. Ein zweites und drittes Projekt kommen hinzu, und Risiken müssen zwischen ihnen verglichen werden. Jemand außerhalb des Projekts fragt nach Bedrohungen in einem bestimmten Schnitt. Die Vorgabe verlangt Risiken im Projektauftrag und im Bericht. Ab diesem Punkt kostet eine Liste mit eigenen Feldern mehr Arbeit, als sie spart.

Wie Sie es in zwei Wochen an Ihrem eigenen Register prüfen

Funktionsvergleiche entscheiden wenig, denn jede Anbieterseite antwortet auf alles mit Ja. Ein Test an Ihren eigenen Daten sagt mehr. Nehmen Sie das Register eines laufenden Projekts und übertragen Sie es vollständig, samt Ihrer Bewertungsskala. Dieser erste Schritt zeigt, ob Ihre Matrix ins Tool passt, ohne die Gewohnheiten des Teams zu ändern.

Dann vier Tests. Verknüpfen Sie drei Risiken mit Aufgaben im Zeitplan und prüfen Sie, ob Sie sie im Gantt-Diagramm sehen. Verschieben Sie eine dieser Aufgaben um zwei Wochen und sehen Sie, ob sich das Bild der Bedrohungen ändert. Bauen Sie einen Risikobericht für eine Kategorie, etwa Lieferanten, über mehrere Projekte. Öffnen Sie den Risiko-Reiter des Portfolios und prüfen Sie, ob sich eine Bedrohung an mehreren Stellen wiederholt. Dieser letzte Test rechtfertigt den Wechsel meist für sich allein.

Häufig gestellte Fragen

Hat Asana ein Risikoregister?

Asana bietet eine Vorlage für ein Risikoregister und eine für eine Matrix. Sie erzeugen eine Liste mit Feldern wie Wahrscheinlichkeit, Auswirkung, Verantwortlicher und Reaktionsplan. Es ist kein eigenes Modul, nur ein Projekt aus Aufgaben. Sie können ein Risiko also nicht mit einer Aufgabe im Zeitplan verknüpfen, es projektübergreifend vergleichen oder auf Portfolioebene sehen.

Was ist der Unterschied zwischen einem Risikoregister und einer Aufgabenliste mit eigenen Feldern?

Derselbe Unterschied wie zwischen einem Risiko und zu erledigender Arbeit. Ein Register behandelt Risiko als eigenes Objekt mit eigenem Lebenszyklus, Bewertung, Verantwortlichem, Reaktionsplan und Verbindungen zum Zeitplan und zum Budget. Eine Aufgabenliste lässt Sie diese Informationen erfassen, aber nicht außerhalb eines Projekts nutzen.

Was bringt die Verknüpfung eines Risikos mit einer Aufgabe im Zeitplan?

Sie zeigt, wo im Plan die Bedrohung sitzt. In FlexiProject trägt eine Aufgabe mit verknüpftem Risiko ein Warnsymbol im Gantt-Diagramm, und die Farbe daneben sagt, ob das Risiko aktiv ist. Nach jeder Änderung des Zeitplans sehen Sie, welche Bedrohungen drängender geworden sind.

Können wir unsere eigene Risikomatrix behalten?

Ja. Die Dimensionen der Matrix werden bei der Einführung festgelegt, sodass ein Unternehmen mit einer Drei-mal-drei-Skala nicht auf Fünf-mal-fünf wechseln muss. Das ist eine der wichtigeren Bedingungen dafür, dass ein Risikomodul genutzt und nicht gemieden wird.

Wie fangen wir an, wenn unser Risikoregister heute in Excel liegt?

Indem Sie ein laufendes Projekt übertragen, samt seiner aktuellen Bewertungsskala und Kategorien. Die Tabelle enthält meist alle nötigen Informationen. Was ihr fehlt, sind die Verbindungen: zu Aufgaben, zu anderen Projekten und zu den Dokumenten, die Sie ohnehin von Hand ausfüllen. Diese Verbindungen sind der Grund für den Wechsel, nicht die bloße Tatsache, dass Sie ein Register führen.

Man sucht eine Alternative zu Asana für das Risikomanagement im Projekt nicht, weil es nirgends einen Ort gäbe, eine Bedrohung zu erfassen. Der Grund ist ein anderer: Eine erfasste Bedrohung tut danach nichts. Ein Register, das eine Liste ist, endet bei der Dokumentation. Die Information existiert, aber sie verbindet sich nicht mit dem Zeitplan, summiert sich nicht projektübergreifend, kehrt beim nächsten Projekt nicht ins Unternehmen zurück und muss in jedes Dokument einzeln abgetippt werden. Ein Register, das ein Modul ist, erledigt diese vier Dinge von selbst. Es lässt dem Manager das eine, was kein System für ihn übernimmt: zu entscheiden, wie reagiert wird. Wenn Ihr Register heute vor allem vor dem Lenkungsausschuss aktualisiert wird, ist der günstigste Weg, das zu prüfen, ein Projekt zu übertragen und drei Risiken mit Aufgaben im Zeitplan zu verknüpfen.