Vergleiche

Asana-Alternative für die Projektplanung

Asana ist eine leistungsfähige Plattform für das Arbeitsmanagement, und für ein Team, das über Aufgaben, Boards und Fälligkeitstermine läuft, reicht sie oft völlig aus. Reibung entsteht erst, wenn dasselbe Team ein Projekt planen muss, in dem Termine wirklich voneinander abhängen, in dem manche Abstände technologisch bedingt und nicht verhandelbar sind und in dem eine Verschiebung in einem Projekt still und leise die Arbeit in einem anderen verschiebt. An diesem Punkt verhält sich der Zeitstrahl nicht mehr wie ein Zeitplan, sondern wie eine Zeichnung, die jemand jede Woche von Hand neu anfertigen muss. Dieser Leitfaden betrachtet eine Asana-Alternative für die Projektplanung nur aus einem Blickwinkel: dem Modell unter dem Diagramm, also Abhängigkeitstypen, feste Verzögerungen, harte Beziehungen, Arbeitskalender und Basisplan. Lesen Sie weiter, um zu sehen, wo diese Linie tatsächlich verläuft und was sich ändert, sobald sich der Plan selbst neu berechnet.

Laptop mit einem Projektzeitplan auf einem Gantt-Diagramm im FlexiProject PPM-System als Asana-Alternative

Wichtigste Erkenntnisse:

  • Asana ist nicht schwach, es ist bei der Planung nur flach: Es bietet einen Zeitstrahl, vier Abhängigkeitstypen und eine Hervorhebung des kritischen Pfads. Was fehlt, ist die Ebene darunter: Verzögerung, harte Verknüpfungen, Kalender und Basispläne.
  • Die Semantik der Abhängigkeiten entscheidet, ob sich ein Plan selbst neu berechnet: Eine Beziehung ist eine Regel, kein gezeichneter Pfeil. Ohne feste Verzögerungen und harte Beziehungen sehen die Pfeile richtig aus, während die Termine still und leise aufhören zu stimmen.
  • Projektübergreifende Abhängigkeiten sind die Ebene, die Asana nicht hat: Wenn eine Aufgabe in einem Projekt eine Aufgabe in einem anderen antreibt, muss die Verknüpfung im System leben, nicht im Kopf eines Programmmanagers.
  • Ein Basisplan macht aus Nachverfolgung Verantwortlichkeit: Ohne einen gespeicherten ursprünglichen Plan gibt es keine ehrliche Antwort auf die Frage, wie weit das Projekt abgedriftet ist und warum.
  • Migration ist ein Umbau, kein Kopieren und Einfügen: Aufgaben und Termine lassen sich leicht übernehmen, aber die Planungslogik muss bewusst neu aufgebaut werden, und genau dort entsteht der Wert.

Wo Asanas Zeitstrahl aufhört, ein Zeitplan zu sein

Die meisten Artikel über eine Asana-Alternative für die Projektplanung beginnen mit der Behauptung, Asana habe kein Gantt-Diagramm. Das stimmt nicht, und von einer falschen Prämisse auszugehen ist eine schlechte Art, jemandem bei der Werkzeugwahl zu helfen. Asana hat eine Zeitstrahl-Ansicht, die Balken auf einer horizontalen Achse darstellt, sie mit Pfeilen verbindet, Meilensteine als Rauten markiert und auf Wunsch den kritischen Pfad hervorheben kann. Für eine Kampagne, einen Produktlaunch oder einen Einstellungsprozess ist das eine völlig vernünftige Art zu planen.

Die ehrliche Frage ist eine andere. Nicht, ob das Diagramm existiert, sondern ob ein Planungsmodell dahintersteht, also ein Satz von Regeln, die das System anwendet, wenn sich etwas bewegt. Ein Diagramm ohne Modell ist ein Bild von einem Plan. Ein Diagramm mit einem Modell ist ein Plan. Der Unterschied zeigt sich erst, wenn die Realität gegen die Termine zu drücken beginnt, was meist in der dritten Woche geschieht und nicht an dem Tag, an dem der Plan genehmigt wird.

Was Asana gut kann

Asana ist wirklich gut darin, Arbeit sichtbar zu machen und Menschen zum Handeln zu bewegen. Aufgaben haben Verantwortliche, Kommentare und klare Fälligkeitstermine, der Zeitstrahl lässt sich leicht bearbeiten, und abhängige Aufgaben verschieben sich, wenn ihr Vorgänger sich bewegt. Abhängigkeiten werden in einer Sprache beschrieben, die niemand erst lernen muss, blockiert und blockiert durch, weshalb Teams das Werkzeug an einem Nachmittag übernehmen. Für zehn Personen, die eine achtwöchige Kampagne durchführen, ist das kein Kompromiss, sondern genau das richtige Maß an Werkzeug für die Aufgabe. Jeder Vergleich, der etwas anderes vorgibt, verkauft, statt zu beraten.

Bemerkenswert ist, wo diese Einfachheit bezahlt wird. Jede Fähigkeit, die Asana aus dem Zeitstrahl weglässt, hätte das Produkt schwerer erlernbar gemacht, und für die meisten seiner Nutzer ist das der richtige Kompromiss. Die Frage ist, was mit den Teams geschieht, für die er es nicht ist.

Der Moment, in dem der Plan aufhört, sich selbst neu zu berechnen

Der Wendepunkt kommt leise. Ein Lieferant bestätigt die Lieferung zwei Wochen später als angenommen, und der Projektmanager verschiebt eine Aufgabe auf dem Zeitstrahl. Der unmittelbare Nachfolger folgt, denn diese Verknüpfung ist verstanden. Dann bemerkt der Manager, dass die für nach einer verpflichtenden zweiwöchigen Aushärtungszeit geplante Abnahmeprüfung jetzt zu früh beginnt, weil der Abstand zwischen diesen Aufgaben nie eine Regel war, sondern nur leerer Raum auf einem Diagramm. Die Aufgabe im Nachbarprojekt, die nach dieser Lieferung starten sollte, bewegt sich überhaupt nicht, weil die beiden Projekte nichts voneinander wissen. Eine halbe Stunde später zieht der Manager Balken von Hand und gleicht Termine mit einer Tabelle ab.

Das ist der Moment, in dem ein Zeitplan aufhört, ein Modell zu sein. Der Plan ist nicht mehr etwas, das das System pflegt, sondern etwas, das ein Mensch pflegt, und dieser Mensch wird zum einzigen Ausfallpunkt. Jede Neuplanung kostet Stunden, jede Stunde Neuplanung ist eine Stunde, die nicht am eigentlichen Problem verbracht wird, und nach der dritten oder vierten Iteration hören die Leute ganz auf, den Plan zu aktualisieren, weil sich der Aufwand nicht mehr lohnt. Ein aufgegebener Plan ist schlimmer als kein Plan, denn Berichte werden weiterhin daraus erstellt. Separat beschreiben wir, was eine Asana-Alternative für ein PMO leisten muss.

Teste FlexiProject!

Sieh, wie FlexiProject einen Zeitplan genau hält, wenn sich Termine in echten Projekten zu bewegen beginnen.

FlexiProject

Fünf Anzeichen, dass Sie der Planung in Asana entwachsen sind

Keines dieser Anzeichen hat mit Teamgröße oder Budget zu tun. Es geht um die Gestalt der Arbeit, weshalb ein zwölfköpfiges Entwicklungsteam sie treffen kann, während eine sechzigköpfige Marketingabteilung sie nie erreicht. Wenn zwei oder mehr Ihre Projekte beschreiben, ist die Planungsebene Ihr Engpass, nicht die Anzahl der Funktionen.

Sie planen in Arbeitstagen, nicht in Kalendertagen. Eine fünftägige Aufgabe, die am Donnerstag beginnt, sollte am folgenden Mittwoch enden, und ein Feiertag dazwischen sollte das Ende um einen weiteren Tag nach hinten schieben. Wenn Ihre Dauern still und leise Wochenenden enthalten, trägt jede Schätzung einen eingebauten Fehler, der sich über einen mehrmonatigen Plan aufsummiert.

Manche Abstände in Ihrem Plan sind Physik, keine Vorliebe. Beton härtet aus, Beschichtungen trocknen, eine Validierungsphase läuft, eine Kündigungsfrist läuft ab, eine Behörde hat dreißig Tage Zeit für eine Antwort. Das sind keine Aufgaben, die jemand ausführt, sondern Intervalle, die zwischen zwei Aufgaben verstreichen müssen. Teams ohne eine Möglichkeit, sie auszudrücken, erfinden Platzhalteraufgaben namens „Warten auf Freigabe“, was die Aufgabenliste verschmutzt und jeden darauf aufbauenden Bericht in die Irre führt.

Der Zeitplan eines Projekts treibt den eines anderen an. In dem Moment, in dem eine Lieferung im Infrastrukturprojekt den Start des Migrationsprojekts steuert und beide getrennt verwaltet werden, hält jemand diese Abhängigkeit in seinem Gedächtnis. Das Gedächtnis versendet keine Benachrichtigungen und überlebt keinen Urlaub.

Sie werden gefragt, wie weit das Projekt vom ursprünglichen Plan abgedriftet ist. Nicht, wie die aktuellen Termine lauten, sondern wie sie sich zu dem verhalten, was genehmigt wurde, und warum. Ohne gespeicherten Basisplan lautet die ehrliche Antwort, dass es niemand weiß, und die im Lenkungsausschuss verteilte Version ist eine Rekonstruktion.

Der Zeitplan braucht mehr als zwei Ebenen. Phasen, die Etappen enthalten, die Aufgaben enthalten, wobei der Fortschritt automatisch aufsummiert wird und jede Ebene eigene Termine hat. Eine flache Liste mit Abschnittsüberschriften sieht auf dem Bildschirm ähnlich aus und verhält sich völlig anders, wenn sich der Plan ändert. Wir zeigen außerdem, worauf es bei Apps wie Asana wirklich ankommt.

Abhängigkeitstypen und warum ihre Semantik den Plan entscheidet

Eine Abhängigkeit ist keine Linie zwischen zwei Balken. Sie ist eine Regel, die das System jedes Mal anwendet, wenn sich eines der beiden Enden bewegt, und der Typ der Beziehung ist der Inhalt dieser Regel. Genau diesen Teil überspringen die meisten Werkzeugvergleiche, denn eine Tabelle mit einem Häkchen neben „Aufgabenabhängigkeiten“ verbirgt den Unterschied zwischen einem System, das Pfeile neu zeichnet, und einem System, das Termine neu berechnet. Sowohl FlexiProject als auch Asana unterstützen die vier Standardtypen, die interessante Frage ist also, was sie umgibt.

Gantt-Diagramm im FlexiProject-System mit Aufgaben, Abhängigkeiten und Meilensteinen
Gantt-Diagramm im FlexiProject-System mit Aufgaben, Abhängigkeiten und Meilensteinen

Die Semantik richtig zu treffen ist keine Genauigkeit um ihrer selbst willen. Sie entscheidet, ob ein Projektmanager die Frage „wenn sich das um eine Woche verschiebt, wann sind wir fertig“ in drei Sekunden mit einem Blick auf das Diagramm beantwortet oder in drei Stunden durch den Neuaufbau des Plans. Wo mehrere Projekte um dieselben Menschen konkurrieren, entscheidet dieser Unterschied, ob überhaupt neu geplant wird.

EA, AA, EE und AE in der Praxis

Ende-Anfang ist überall der Standard und deckt die meiste sequenzielle Arbeit ab: Die Wand muss gebaut werden, bevor sie gestrichen wird. Anfang-Anfang beschreibt Arbeit, die aus einem gemeinsamen Auslöser parallel läuft, zum Beispiel Dokumentation, die in dem Moment beginnt, in dem die Entwicklung beginnt, und ungefähr im Gleichschritt mit ihr bleibt. Ende-Ende beschreibt Arbeit, die gemeinsam landen muss, etwa Anwenderschulungen, die am Tag des Systemstarts abgeschlossen sein müssen, unabhängig davon, wann sie begonnen haben. Anfang-Ende ist selten und tritt vor allem bei Übergaben auf, bei denen das alte System erst abgeschaltet werden kann, sobald das neue läuft.

Wer ernsthaft Zeitpläne erstellt, verwendet mindestens die ersten drei, und reife Projektorganisationen nutzen alle vier, um die Realität präzise abzubilden, statt alles in eine Kette von Ende-Anfang-Verknüpfungen zu zwängen. Wenn Sie einen ausführlicheren Durchgang mit ausgearbeiteten Beispielen möchten, haben wir separat über die Arten von Aufgabenabhängigkeiten im Gantt-Diagramm geschrieben.

Feste Verzögerung: die Tage, die einfach vergehen müssen

In FlexiProject kann jede Beziehung eine feste Verzögerung in Tagen tragen. Die Abhängigkeit bedeutet dann „starte diese Aufgabe vier Tage, nachdem die vorherige endet“, und die vier Tage sind Teil der Regel und nicht ein Abstand, den jemand auf dem Diagramm nach Augenmaß gesetzt hat. Wenn sich der Vorgänger bewegt, bewegt sich die Verzögerung automatisch mit, ohne dass sich jemand daran erinnern muss, dass sie da war.

Die geschäftliche Wirkung ist, dass technologische Zwänge aufhören, in den Köpfen der Menschen zu leben. Eine Aushärtungszeit, ein behördliches Prüffenster, eine verpflichtende Quarantäne zwischen Produktionschargen oder eine vertragliche Kündigungsfrist wird Teil der Logik des Plans. Niemand muss eine Scheinaufgabe anlegen, um den Raum offen zu halten, niemand muss einer Kollegin erklären, warum zwei Balken nicht zusammengeschoben werden dürfen, und keine Neuplanung kann still und leise einen Zwang beseitigen, den die Physik oder ein Vertrag vorgibt. In Projekten, in denen eine verpasste Reihenfolge Nacharbeit statt einer verspäteten E-Mail bedeutet, ist das der Unterschied zwischen einem Plan, dem man vertrauen kann, und einem Plan, den man doppelt prüfen muss.

Harte Beziehungen: wenn die Verknüpfung nicht gebrochen werden darf

FlexiProject unterscheidet zusätzlich harte Beziehungen, im Aufgabenbereich mit zwei ineinandergreifenden Ringen markiert. Eine harte Beziehung bedeutet, dass das verknüpfte Element nicht von Hand von seinem Vorgänger weggezogen werden kann. Das System lässt es nicht zu, dass ein Nutzer die Reihenfolge still und leise bricht, indem er einen Balken auf dem Diagramm verschiebt, was einschränkend klingt, bis man einen Zeitplan über sechs Monate gut gemeinter manueller Anpassungen verfallen gesehen hat.

Das ist am wichtigsten, wo ein Zeitplan ein gemeinsames Dokument ist und nicht die Datei einer einzelnen Person. In einem großen Projekt bearbeiten mehrere Personen den Plan, und jede von ihnen hat einen lokalen Grund, etwas zu verschieben. Eine harte Beziehung kodiert den Unterschied zwischen einer Reihenfolge, die eine Planungsannahme ist und daher zur Diskussion steht, und einer Reihenfolge, die ein harter Zwang ist und daher nicht. Der Projektmanager hört auf, den Plan manuell zu überwachen, und beginnt, sich auf ihn zu verlassen, was von Anfang an der ganze Sinn einer Planungssoftware ist.

Projektübergreifende Abhängigkeiten: die Ebene, die Asana nicht hat

Innerhalb eines einzelnen Projekts sind Abhängigkeiten eine Bequemlichkeit. Projektübergreifend sind sie der Unterschied zwischen einem Programm und einem Ordner unzusammenhängender Pläne. In FlexiProject kann eine Beziehung eine Aufgabe in einem Projekt mit einer Aufgabe in einem anderen verbinden, sodass die Infrastrukturlieferung, die eine Migration steuert, eine Verknüpfung ist, die das System kennt, und nicht eine Notiz im Besprechungsprotokoll von jemandem. Wenn sich der Termin auf einer Seite verschiebt, werden die abhängigen Aufgaben im anderen Projekt neu berechnet und ihre Verantwortlichen benachrichtigt.

Die praktische Folge zeigt sich in der Entscheidungsfindung, nicht im Diagramm. Bevor ein Programmmanager eine Änderung in einem Projekt genehmigt, kann er sehen, wie sich diese Änderung durch die übrigen Projekte fortpflanzt, den Zeitplan vorher und nachher vergleichen und die realen Kosten eines Ja beurteilen. Ohne das tauchen die Kosten Wochen später als eine Reihe getrennter Überraschungen auf, von denen jede wie ein lokales Problem aussieht und als solches behandelt wird. Mehrjährige Programme sind genau dort, wo sich das aufsummiert, denn eine im dritten Monat beiläufig getroffene Zweiwochenentscheidung kann einen Go-live-Termin im zwanzigsten Monat verschieben.

Alle Aufgaben eines Programms sind außerdem auf einem gemeinsamen Gantt-Diagramm sichtbar, sodass ein Programmmanager die Zusammenhänge an einer Stelle sieht, statt sie aus Statusberichten zu rekonstruieren. Teams, die das brauchen, entdecken es meist auf die harte Tour, nachdem sie zuerst versucht haben, dasselbe mit einem wiederkehrenden Meeting zu koordinieren. Wenn Ihre Organisation in diese Richtung geht, beschreibt unsere Software zur Verwaltung von Projektprogrammen, wie Programme strukturiert werden.

Teste FlexiProject!

Sieh, wie Beziehungen, Basispläne und Ressourcenauslastung in einem Projektzeitplan zusammenwirken.

FlexiProject

Das Modell unter dem Gantt-Diagramm

Beziehungen sind der sichtbarste Teil des Planungsmodells, aber nicht das Ganze. Vier weitere Mechanismen entscheiden, ob sich ein Diagramm wie ein Plan verhält, und sie trennen eine Gantt-Diagramm-Software von einem Zeitstrahl-Widget. Keiner von ihnen ist exotisch. Alle sind die Art von Dingen, die man erst vermisst, wenn man sie braucht.

Gantt-Diagramm in der FlexiProject PPM-Software mit mehreren parallelen Projekten, Status und Meilensteinen
Gantt-Diagramm in der FlexiProject PPM-Software mit mehreren parallelen Projekten, Status und Meilensteinen

Unbegrenzter PSP und Fortschritt, der sich von selbst aufsummiert

Projekte in einer Organisation variieren enorm im Umfang, vom zweiwöchigen Schnellerfolg bis zur mehrjährigen Kapitalinvestition, und eine einzige starre Struktur kann nicht beiden dienen. FlexiProject setzt keine Grenze, wie tief die Aufgabenstruktur reicht, sodass ein Projekt in Phasen, Etappen, Aufgaben und Meilensteine so weit hinunter aufgeteilt werden kann, wie es nötig ist. Ein kleines Projekt kann mit einer Handvoll Aufgaben flach bleiben, während ein Investitionsprojekt einen mehrstufigen Projektstrukturplan tragen kann, und beide nutzen dieselbe Oberfläche.

Fortschritt wird nur auf der Ebene einzelner Aufgaben eingetragen. Etappenfortschritt und Gesamtprojektfortschritt werden automatisch aus den darunterliegenden Aufgaben berechnet, sodass niemand daran denken muss, die Summen vor dem Versand eines Berichts zu aktualisieren. Das klingt nach einer kleinen Bequemlichkeit und ist tatsächlich ein Datenqualitätsmechanismus: Der Status auf Portfolioebene wird aus denselben Zahlen abgeleitet, die das Team täglich pflegt, und nicht aus einer Zusammenfassung, die jemand am Abend vor einem Lenkungsausschuss in Eile getippt hat.

Ein Arbeitskalender statt roher Kalendertermine

Ein Zeitplan, der Wochenenden als Arbeitszeit zählt, erzeugt Termine, die vom ersten Tag an falsch sind. FlexiProject berechnet Dauern gegen einen Arbeitskalender, sodass eine in Arbeitstagen ausgedrückte Aufgabe dort landet, wo sie tatsächlich landet, sobald Wochenenden und gesetzliche Feiertage berücksichtigt sind. Dieselbe Logik trägt wiederverwendbare Vorlagen: Aufgaben in einer Vorlage halten eine Dauer in Arbeitstagen und einen Satz von Abhängigkeiten statt fester Kalendertermine, sodass die Eingabe eines Projektstarttermins den gesamten Zeitplan automatisch erzeugt.

Für eine Organisation, die wiederholt ähnliche Projekte durchführt, kollabiert hier die Planungszeit. Statt einen Plan von Grund auf neu aufzubauen und jeden Termin neu abzuleiten, startet ein Projektmanager von einer genehmigten Struktur und passt an, was an dieser Instanz wirklich anders ist. Unser Modul für Projektvorlagen existiert genau für dieses Muster, und es ist auch der Grund, warum von einem erfahrenen PMO erstellte Vorlagen ihren Wert über Jahre behalten.

Basisplan und Abweichung vom Plan

Sobald ein Plan genehmigt ist, speichert FlexiProject ihn als Basisplan. Das Gantt-Diagramm zeigt dann den ursprünglichen Plan neben dem aktuellen Zeitplan, sodass jede Abweichung sofort sichtbar ist, statt erschlossen zu werden. Das System prognostiziert außerdem den Projektabschlusstermin gegen den genehmigten, was meist die einzige Zahl ist, die ein Vorstand tatsächlich will.

Der Wert liegt hier weniger in der Messung als in der Qualität des Gesprächs. Ein Projektmanager, der zeigen kann, was genehmigt wurde, wie die Lage jetzt ist und welche Entscheidung die Lücke verursacht hat, ist in einer anderen Position als einer, der nur die aktuellen Termine berichten kann. Die Diskussion verschiebt sich von der Frage, ob das Projekt zu spät ist, zu der Frage, was man wegen der konkreten Ursache tun soll, und das ist die einzige Version dieses Gesprächs, die in einer Entscheidung endet.

Kritischer Pfad und Puffer

FlexiProject identifiziert den kritischen Pfad automatisch und markiert ihn rot auf dem Gantt-Diagramm, sodass ein Projektmanager sofort weiß, welche Aufgaben Aufmerksamkeit verdienen. Der praktische Nutzen liegt in der Priorisierung. Eine Verschiebung von zwei Tagen bei einer kritischen Aufgabe ist eine Verschiebung von zwei Tagen für das ganze Projekt, während eine Verschiebung von zwei Tagen bei einer Aufgabe mit zehn Tagen Puffer Rauschen ist. Ohne diese Unterscheidung wird jede Verzögerung mit derselben Dringlichkeit eskaliert, was allen beibringt, Eskalationen zu ignorieren.

Bei mehreren parallelen Strängen, zum Beispiel Bau parallel zu Montage und Dokumentation, ist der kritische Pfad das, was einen Manager davon abhält, den falschen zu optimieren. Wenn das Konzept für Ihr Team neu ist, haben wir ausführlicher behandelt, was der kritische Pfad ist und wie man ihn steuert. Ebenso erklären wir, wie Risikomanagement im Projekt in der Praxis aussieht.

Ressourcen auf dem Gantt-Diagramm: Zeit und Kapazität gemeinsam geplant

Ein Zeitplan, der ignoriert, wer verfügbar ist, ist eine Wunschliste. FlexiProject zeigt die Ressourcenauslastung direkt aus dem Gantt-Diagramm, sodass ein Projektmanager auf einen Blick sieht, welche Personen in einem bestimmten Zeitraum überlastet sind und welche noch Kapazität haben. Aufgaben lassen sich entlang des Zeitstrahls verschieben, während man die Auslastung sich ändern sieht, was Neuplanung in eine Simulation statt in eine Vermutung verwandelt: Der Plan wird optimiert, bevor er genehmigt wird, nicht nachdem sich jemand beschwert.

Gantt-Diagramm mit dem Ressourcenmanagement-Modul im FlexiProject PPM-System: Aufgaben, Zeitplan und zugewiesene Ressourcen
Gantt-Diagramm mit dem Ressourcenmanagement-Modul im FlexiProject PPM-System: Aufgaben, Zeitplan und zugewiesene Ressourcen

Das schließt eine Lücke, die ständig in Organisationen auftaucht, die mehrere Projekte mit denselben Menschen durchführen. Ein neues Projekt zu planen bedeutet zu wissen, ob die benötigten Spezialisten bereits anderweitig verplant sind, und in den meisten Unternehmen geschieht diese Prüfung manuell, in einer Tabelle, mit einer Verzögerung, die lang genug ist, um die Antwort veralten zu lassen. Wenn Kapazität in derselben Ansicht wie die Termine sitzt, hört der Kompromiss zwischen früherem Fertigwerden und Überlastung eines Teams auf, unsichtbar zu bleiben, bis jemand kündigt.

Verzögerungen werden mit derselben Direktheit sichtbar gemacht. Aufgaben, die in Rückstand geraten sind, werden rot hervorgehoben, sodass das Öffnen des Projekts genügt, um zu sehen, wo eingegriffen werden muss, ohne erst einen Bericht zu erzeugen. Für Organisationen, die weiter gehen und Verfügbarkeit über das gesamte Portfolio hinweg steuern wollen, verwaltet unsere Software für Ressourcenmanagement die Auslastung über ein einzelnes Projekt hinaus.

FlexiProject und Asana: die Planungsfähigkeiten im Vergleich

Die folgende Tabelle ist bewusst schmal. Sie deckt nur die Planung ab und gibt Asana jede Fähigkeit, die es tatsächlich hat, denn ein Vergleich, der einen Wettbewerber untertreibt, ist für die lesende Person nutzlos. Zusammenarbeit, Workflow-Automatisierung und Integrationen sind ein anderes Gespräch, und in mehreren davon ist Asana das stärkere Produkt.

Asana FlexiProject
Gantt-Diagramm und Kanban-Board Ja Ja
Vier Abhängigkeitstypen (EA, AA, EE, AE) Ja Ja
Kritischer Pfad Ja Ja
Feste Verzögerung (Lag) innerhalb einer Beziehung Nein Ja
Harte Beziehungen, die nicht auseinandergezogen werden können Nein Ja
Abhängigkeiten zwischen verschiedenen Projekten Nein Ja
Unbegrenzte PSP-Struktur Nein Ja
Projektkalender mit Arbeitstagen Nein Ja
Basisplan und Abweichung vom Plan Nein Ja
Ressourcenauslastung auf dem Gantt-Diagramm Nein Ja
Zeitplanexport nach MS Project Nur CSV XML, PDF, PNG, Excel

Lesen Sie die Tabelle als Beschreibung einer Absicht, nicht als Punktestand. Asana ist so gebaut, dass jeder ohne Schulung planen kann, und jede oben ausgelassene Fähigkeit ist eine, die das Produkt schwerer erlernbar machen würde. FlexiProject nimmt einen etwas steileren Start in Kauf, im Gegenzug für einen Zeitplan, der unter Druck seine Form hält. Welcher Kompromiss richtig ist, hängt allein davon ab, ob Ihre Projekte einen ungenauen Plan bestrafen.

Einen Zeitplan aus Asana herausbewegen, ohne den Plan zu verlieren

Der mechanische Teil einer Migration dauert weniger lang, als die Leute erwarten. Ein Zeitplan importiert aus einer Excel-Datei oder einer Microsoft-Project-Datei und bringt Aufgaben, Verantwortliche, verfügbare Attribute und, wo vorhanden, die Abhängigkeitsstruktur mit, sodass Organisationen, die auf jahrelangen historischen Plänen sitzen, sie nicht abtippen müssen. Exporte laufen in die andere Richtung nach Excel, Microsoft Project XML, PDF und PNG, was zählt, wenn ein Auftragnehmer oder ein Prüfer auf einem bestimmten Format besteht.

Der Teil, der wirklich Nachdenken verdient, ist der Umbau. Ein in Asana gebauter Plan wurde unter Asanas Einschränkungen gebaut, was bedeutet, dass die Wartezeiten wahrscheinlich Scheinaufgaben sind, die Reihenfolge wahrscheinlich eine Kette von Ende-Anfang-Verknüpfungen ist und die Phasenstruktur wahrscheinlich aus Abschnittsüberschriften besteht. Das getreu zu übertragen reproduziert die Einschränkung in einem System, das sie nicht mehr hat. Der bessere Ansatz ist, ein repräsentatives Projekt zu nehmen, seine Logik richtig neu aufzubauen, mit den passenden Beziehungstypen, festen Verzögerungen, wo Intervalle verpflichtend sind, und harten Beziehungen, wo die Reihenfolge nicht verhandelbar ist, und das Ergebnis als Vorlage für alles Weitere zu nutzen.

Für den ersten Durchgang gibt es eine Abkürzung, die man kennen sollte. FlexiProject kann aus einer Beschreibung von Projektzielen und Anforderungen einen Zeitplanentwurf erzeugen und Aufgaben, Meilensteine, Abhängigkeiten und ein Gantt-Diagramm erstellen, das ein Projektmanager dann bearbeitet, statt es aus dem Nichts zu bauen. Es ersetzt nicht das Urteil eines erfahrenen Planers, aber es beseitigt das Problem des leeren Blattes, an dem die meisten Neuplanungsversuche stocken. Für einen strukturierten Durchgang haben wir darüber geschrieben, wie man Schritt für Schritt einen Projektzeitplan erstellt. Separat legen wir dar, was echte Budgetkontrolle im Projekt bedeutet.

Teste FlexiProject!

Sieh, wie FlexiProject deinem Team hilft, Projekte an einem Ort zu planen, zu verfolgen und zu liefern.

FlexiProject

Häufig gestellte Fragen

Unterstützt Asana alle vier Abhängigkeitstypen?

Ja. Asana unterstützt Ende-Anfang, Ende-Ende, Anfang-Anfang und Anfang-Ende, mit Ende-Anfang als Standard. Behauptungen, Asana biete nur einen Abhängigkeitstyp, erscheinen in einer Reihe von Vergleichsartikeln und sind veraltet. Die bedeutsamen Lücken in Asanas Planung liegen anderswo, bei festen Verzögerungen, harten Beziehungen, Arbeitskalendern, Basisplänen und projektübergreifenden Verknüpfungen.

Kann man in Asana eine Verzögerungszeit zwischen Aufgaben festlegen?

Nein. Asana lässt es nicht zu, einer Abhängigkeit eine feste Verzögerung anzuhängen, sodass ein verpflichtendes Intervall zwischen zwei Aufgaben auf andere Weise dargestellt werden muss, meist durch einen leeren Abstand auf dem Zeitstrahl oder eine Platzhalteraufgabe. Beide Behelfslösungen brechen, sobald sich der Vorgänger bewegt, weil keine die Verzögerung mit sich trägt. In FlexiProject ist die Verzögerung eine Eigenschaft der Beziehung selbst und wird in Tagen ausgedrückt.

Hat Asana einen Projekt-Basisplan?

Nein. Asana speichert keine genehmigte Version des Zeitplans zum Vergleich, sodass es keine eingebaute Möglichkeit gibt, zu sehen, wie weit der aktuelle Plan von dem abgedriftet ist, was ursprünglich vereinbart wurde. Teams, die das brauchen, halten meist eine Momentaufnahme in einer Tabelle, die die Frage einmal beantwortet und dann veraltet. FlexiProject bewahrt den genehmigten Plan als Basisplan und zeigt ihn neben dem aktuellen Zeitplan auf dem Gantt-Diagramm.

Kann man Aufgaben aus zwei verschiedenen Projekten verknüpfen?

In Asana nicht. Abhängigkeiten bleiben innerhalb eines einzelnen Projekts, sodass eine projektübergreifende Reihenfolge von Menschen koordiniert statt vom System gepflegt werden muss. FlexiProject erlaubt eine Beziehung zwischen Aufgaben, die zu verschiedenen Projekten gehören, berechnet die abhängigen Termine neu, wenn sich eine Seite bewegt, und benachrichtigt die betroffenen Verantwortlichen, was die Grundvoraussetzung dafür ist, ein Programm statt einer Reihe paralleler Projekte zu steuern.

Ist FlexiProject schwerer zu bedienen als Asana?

Es verlangt am Anfang mehr und danach weniger. Asana ist so gestaltet, dass jemand am ersten Tag planen kann, unter anderem indem die in diesem Artikel beschriebenen Konzepte weggelassen werden. FlexiProject erwartet, dass ein Projektmanager Beziehungstypen, Arbeitskalender und Basispläne versteht, und pflegt im Gegenzug den Plan, statt einen Menschen darum zu bitten. Teams mit einfachen Projekten werden Asana schneller finden. Teams, deren Projekte einen ungenauen Plan bestrafen, finden meist das Gegenteil.

Eine Asana-Alternative für die Projektplanung zu wählen ist eigentlich keine Wahl zwischen zwei Werkzeugen. Es ist eine Entscheidung darüber, ob Ihre Projekte einen Plan brauchen, den ein Mensch pflegt, oder einen Plan, den ein System pflegt, und das hängt davon ab, wie teuer es ist, wenn die Termine falsch sind. Wenn ein verschobener Termin ein verlegtes Meeting bedeutet, ist Asana eine gute Antwort, und Planungsmaschinerie hinzuzufügen würde das Team nur bremsen. Wenn ein verschobener Termin untätige Auftragnehmer, ein verpasstes behördliches Fenster, Nacharbeit an einer Produktionslinie oder eine Vertragsstrafe bedeutet, dann ist das Modell unter dem Diagramm kein Detail. Es ist das Produkt.

Was sich mit einem vollständigen Planungsmodell ändert, ist kleiner, als eine Funktionsliste vermuten lässt, und größer, als es sich anfühlt. Beziehungen tragen feste Verzögerungen, sodass verpflichtende Intervalle Teil des Plans sind statt Teil des Gedächtnisses von jemandem. Harte Beziehungen halten Reihenfolgen, die nicht zur Verhandlung stehen. Abhängigkeiten reichen über Projekte hinweg, sodass sich ein Programm wie ein Programm verhält. Ein Arbeitskalender lässt Dauern das bedeuten, was sie sagen, ein Basisplan macht Abweichung sichtbar, und der kritische Pfad sagt, welche Verzögerungen tatsächlich zählen. Einzeln sehen diese wie Feinheiten aus. Zusammen sind sie der Unterschied zwischen Neuplanung in Minuten und Neuplanung über ein Wochenende.

Wenn Sie die beiden Produkte über den vollen Umfang hinweg nebeneinander sehen wollen, nicht nur den Zeitplan, sondern auch Budgets, Risiken, Projektaufträge und Portfolio-Governance, haben wir einen ausführlichen Vergleich von FlexiProject und Asana zusammengestellt. Und wenn Ihre Projekte bereits gegen die hier beschriebenen Grenzen drücken, ist der nützlichste nächste Schritt, eines davon zu nehmen, seinen Zeitplan richtig neu aufzubauen und zu sehen, wie viel der manuellen Arbeit verschwindet.

Łukasz Celeda
Łukasz Celeda
Business Analyst at FlexiProject

Łukasz ist Business- und Systemanalyst mit umfangreicher Erfahrung in der Entwicklung von Unternehmenssoftware. Bei FlexiProject übersetzt er komplexe Anforderungen effektiv in intuitive Systemfunktionen – von der ersten Analyse und UX-Wireframes bis hin zu einsatzbereiten technologischen Lösungen. Er ist Absolvent der Naturwissenschaftlichen Universität Warschau und der Technischen Universität Warschau. In seiner täglichen Arbeit setzt er auf Pragmatismus und verbindet nahtlos die geschäftliche, technische und die Nutzerperspektive.