Auswahlkriterien für Projektmanagement-Software

Die meisten Auswahlverfahren beginnen mit einer Liste von Anbietern und enden mit einer Funktionstabelle, in der alle Kandidaten fast überall ein Häkchen haben. Der entscheidende Teil der Arbeit liegt davor: in der Beschreibung dessen, was im eigenen Betrieb tatsächlich passiert.

Zuerst die eigenen Abläufe beschreiben

Eine Agentur arbeitet anders als ein interner IT-Bereich, und ein Team von fünf Personen braucht nicht dieselben Funktionen wie eine Organisation mit mehreren Standorten. Nützlich ist deshalb eine nüchterne Bestandsaufnahme: Wie lange dauern die Projekte, wie viele Beteiligte gibt es, wie oft ändern sich Prioritäten, und wo entstehen heute Reibungsverluste?

Fragen Sie dabei nicht nur die Projektleitung. Fachabteilung, Controlling und Administration erleben dieselben Abläufe aus anderer Perspektive und benennen andere Engpässe. Erst dieses gemeinsame Bild zeigt, wo eine Software entlasten soll – und wo sie nur eine bestehende Tabelle in bunter ersetzen würde.

Muss, Soll und Kann trennen

Eine Wunschliste mit dreißig Punkten wirkt gründlich und führt trotzdem zu unklaren Entscheidungen, weil sich jeder Anbieter irgendwo wiederfindet. Die Einteilung in drei Stufen hilft: Was muss am ersten Tag funktionieren, was wäre hilfreich, was wäre nur angenehm?

Ob ein Wunsch ein Kriterium ist, lässt sich an vier Fragen festmachen:

1. Beseitigt die Funktion einen konkreten Engpass? Wenn sich kein Engpass benennen lässt, ist es ein Wunsch.
2. Brauchen sie mehrere Rollen regelmäßig? Was nur eine Person gelegentlich benötigt, entscheidet keine Auswahl.
3. Gibt es einen vertretbaren Ersatz im bestehenden Prozess? Häufig ja, und dann sinkt die Priorität.
4. Entstehen ohne sie messbare Zusatzkosten oder Risiken? Das ist das stärkste Argument für eine Muss-Anforderung.

Zur Vorbereitung gehört außerdem, Rollen und Berechtigungen zu beschreiben, bevor irgendetwas ausprobiert wird: Wer legt Projekte an, wer verteilt Aufgaben, wer sieht Budgets, wer darf auswerten? Das ist keine technische Frage, sondern eine Abbildung von Verantwortung – und sie entscheidet mit darüber, ob Informationen gezielt geteilt oder unnötig breit sichtbar werden.

Merksatz: Eine Anforderung, die niemand an einem realen Vorgang zeigen kann, ist keine Anforderung. Sie ist eine Erinnerung an eine Produktdemonstration.

Planung und Steuerung an einem echten Ablauf prüfen

Nicht die Zahl der verfügbaren Ansichten entscheidet, sondern ob Aufgaben, Termine, Abhängigkeiten und Kapazitäten zusammenpassen. Ein Kalender beantwortet Terminfragen, ein Kanban-Board zeigt den aktuellen Arbeitsfluss, ein Balkenplan die zeitlichen Beziehungen. Entscheidend ist, dass alle Darstellungen auf denselben Daten beruhen und nicht jede für sich gepflegt werden muss.

Verschieben Sie im Probelauf einen Termin, der weitere Vorgänge nach hinten zieht, und sehen Sie sich an, was danach passiert: Wird die Folge sichtbar, bleibt sie nachvollziehbar, und wie viel Handarbeit kostet die Korrektur? Genau an dieser Stelle entscheidet sich, ob die Planung im Alltag gepflegt wird oder nach wenigen Wochen veraltet.

Bei mehreren parallelen Vorhaben kommt die Frage nach Kapazitäten hinzu. Sichtbar werden sollte, wer eingeplant ist, wo Konflikte entstehen und welche Daten dafür von Hand gepflegt werden müssen. Dashboards wiederum sollten verdichten statt aufzuzählen: Legen Sie vorher zwei oder drei konkrete Fragen der Geschäftsführung fest und prüfen Sie, ob die Antwort ohne manuellen Export zustande kommt.

Bedienung und Zusammenarbeit

Eine fachlich passende Lösung bleibt wirkungslos, wenn sie im Alltag als Zumutung empfunden wird. Akzeptanz entsteht dort, wo eine Aufgabe schnell erfasst, eine Rückfrage ohne Medienbruch geklärt und ein Dokument dort gefunden wird, wo der Arbeitsschritt liegt.

Lassen Sie deshalb mehrere Personen dieselbe Aufgabe erledigen, ohne jeden Schritt vorzugeben, und notieren Sie, wo Rückfragen entstehen. Diese kleinen Irritationen werden später zu den Gründen, aus denen Aufgaben nur noch halb gepflegt werden.

Bei verteilten Teams kommt hinzu, ob Änderungen zeitnah sichtbar werden und ob mehrere Personen ohne widersprüchliche Zwischenstände arbeiten können. Ein realistischer Probevorgang ist eine Übergabe zwischen zwei Abteilungen – dort zeigt sich, ob die Software Zusammenarbeit erleichtert oder vor allem Benachrichtigungen erzeugt. Mobile Nutzung und Bedienbarkeit per Tastatur, mit ausreichenden Kontrasten und verständlichen Beschriftungen, gehören in dieselbe Prüfung und nicht auf eine Sonderwunschliste.

Schnittstellen, Sicherheit und Datenschutz

Projektmanagement-Software arbeitet selten allein. Kalender, Identitätsverwaltung, Zeiterfassung, Buchhaltung und Dateiablage liefern oder erwarten Informationen. Notieren Sie deshalb nicht nur, welche Integration angeboten wird, sondern welchen Datenfluss Sie brauchen, wie aktuell er sein muss, was bei einem Fehler passiert und wer die Verbindung betreibt.

Die Datenschutzprüfung gehört in den Auswahlprozess, nicht auf eine Liste für danach. Zu klären sind die verarbeiteten personenbezogenen Daten und ihr Zweck, Zugriffsrechte, Verschlüsselung bei Übertragung und Speicherung, Aufbewahrungsfristen, Löschprozesse, Serverstandort und der Ablauf bei einem Ausfall. Fragen Sie ausdrücklich nach dem Fall des versehentlichen Löschens: Wie schnell lässt sich wiederherstellen, und was geht dabei verloren?

Diese Fragen stellen sich bei jeder betrieblichen Anwendung ähnlich, nicht nur bei der Projektsteuerung – ein Überblick dazu findet sich in der Übersicht der Werkzeuge nach Aufgabenfeldern.

Anpassbarkeit ohne Sonderlösung

Status, Felder, Vorlagen und Ansichten sollten sich an den eigenen Ablauf anpassen lassen, ohne dass daraus eine Konstruktion wird, die nur noch eine Person versteht. Legen Sie für die Erprobung einen typischen Prozess mit wenigen klaren Varianten an – nicht alle denkbaren Sonderfälle.

Automatisierungen verkürzen wiederkehrende Schritte, etwa Statuswechsel oder die Anlage standardisierter Aufgaben. Wichtig ist weniger, wie viel möglich ist, als ob eine Regel nachvollziehbar bleibt und sich im Zweifel schnell abschalten lässt. Beginnen Sie mit einem kleinen, risikoarmen Beispiel.

Jede Anpassung erzeugt Folgekosten für Dokumentation, Schulung und Pflege. Legen Sie deshalb früh fest, wer für Vorlagen, Rechte und Automatisierungen zuständig ist. Ohne diese Zuständigkeit entwickelt nach einem Jahr jedes Team eigene Regeln, und die gemeinsame Auswertung ist dahin.

Kosten und Vertrag im Ganzen betrachten

Der laufende Nutzungspreis ist nur ein Teil der Rechnung. Hinzu kommen Einführung, Datenübernahme, Schulung, Support, möglicher Zusatzspeicher, Integrationen und vor allem interne Arbeitszeit. Diese Arbeit verschwindet nicht dadurch, dass sie auf keiner Rechnung des Anbieters steht.

Klären Sie außerdem, welche Personen überhaupt gezählt werden: Brauchen gelegentlich Beteiligte, externe Dienstleister oder die Geschäftsführung ein eigenes kostenpflichtiges Konto, und was passiert bei wechselnden Projektteams? Ob gekauft, gemietet oder offen lizenziert wird, macht dabei einen erheblichen Unterschied für Pflichten und Bindung; die Unterschiede zwischen Kauf, Abo und offenem Quellcode gehören deshalb vor die Angebotsverhandlung.

Zum Vertrag gehört schließlich der Ausstieg. Laufzeit, Kündigungsfristen und die Bedingungen für die Herausgabe der Daten sollten verstanden sein, bevor unterschrieben wird. Wer weiß, was beim späteren Umzug der Daten schiefgehen kann, bewertet die langfristige Bindung realistischer.

Von der Auswahlliste zur Entscheidung

Auf die engere Liste gehören nur Lösungen, die die Muss-Anforderungen erfüllen oder bei einer offenen Frage plausibel geprüft werden können. Jede bekommt dieselben gewichteten Kriterien, damit nachvollziehbar bleibt, warum eine weiter betrachtet wird und eine andere ausscheidet.

Für die Erprobung ist ein begrenzter Ausschnitt aus einem echten Projekt aussagekräftiger als ein Beispieldatensatz – selbstverständlich mit freigegebenen oder angemessen anonymisierten Daten. Legen Sie vorher fest, welche Aufgaben, Rollen, Termine und Auswertungen abgebildet werden sollen und welches Ergebnis Sie erwarten. Sonst bleibt am Ende ein allgemeiner Eindruck statt einer überprüfbaren Aussage.

Am Ende führt eine Entscheidungsmatrix Anforderungen, Gewichtung, Beobachtungen und offene Punkte zusammen. Ergänzen Sie neben der Bewertung immer eine kurze Begründung in Worten: Eine Punktzahl ohne Begründung ist nach einem halben Jahr nicht mehr nachvollziehbar, und genau dann wird sie gebraucht.

Hinweis: Die passende Software ist nicht die mit den meisten Funktionen, sondern die, deren Einführung die Organisation tatsächlich tragen kann. Prüfen Sie vor der Entscheidung ausdrücklich, wer die Einführung begleitet, wer danach zuständig bleibt und woher die dafür nötige Zeit kommt.