Eine Projektmanagement-Software einzuführen bedeutet mehr, als Benutzer anzulegen und das System technisch bereitzustellen. Unternehmen müssen auch festlegen, wie Projekte künftig strukturiert und bearbeitet werden, wer für welche Daten verantwortlich ist und welche Abläufe in der Software abgebildet werden sollen.
Wer diese Fragen vor dem breiten Einsatz klärt, schafft eine gemeinsame Grundlage für Projektstrukturen, Verantwortlichkeiten und Arbeitsweisen. Ein Pilotprojekt hilft anschließend dabei, diese Festlegungen unter realistischen Bedingungen zu überprüfen und vor dem weiteren Rollout anzupassen.
Die folgenden zehn Schritte zeigen, wie Unternehmen die Einführung einer Projektmanagement-Software von der Vorbereitung über den Pilotbetrieb bis zum schrittweisen Rollout strukturieren können.
Wie führt man eine Projektmanagement-Software ein?
Eine Projektmanagement-Software lässt sich schrittweise einführen: Ziele und Projektstrukturen festlegen, Verantwortlichkeiten und Stammdaten vorbereiten, zentrale Abläufe in einem Pilotprojekt erproben, Mitarbeitende schulen und die Ergebnisse auswerten. Anschließend kann die Nutzung auf weitere Projekte, Teams oder Unternehmensbereiche ausgeweitet werden.
Sie haben noch keine Lösung ausgewählt? In unserem Ratgeber [Projektmanagement-Software auswählen: 15 Kriterien] erfahren Sie, wie Sie Anforderungen definieren und verschiedene Lösungen systematisch vergleichen.
01 Ziele und Ausgangssituation festlegen
Zu Beginn sollten Unternehmen festhalten, welche Ziele sie mit der Einführung der Projektmanagement-Software verfolgen und wie Projekte bisher organisiert werden. Dabei geht es noch nicht um einzelne Einstellungen der Software, sondern um die wichtigsten Ausgangsprobleme und gewünschten Veränderungen.
Hilfreiche Fragen sind:
- Welche Projektabläufe sollen künftig über die Software unterstützt werden?
- Wo entstehen heute Medienbrüche, doppelte Eingaben oder manuelle Abstimmungen?
- Welche Informationen fehlen Projektleitung oder Mitarbeitenden?
- Welche bestehenden Werkzeuge und Datenquellen werden genutzt?
- Welche Bereiche oder Nutzergruppen sollen mit der Software arbeiten?
- Woran soll nach dem Pilot erkennbar sein, ob die gesetzten Ziele erreicht wurden?
Die Ziele sollten möglichst konkret formuliert werden. Statt beispielsweise nur „mehr Transparenz im Projektmanagement“ festzuhalten, sollte definiert werden, welche Informationen für welche Rolle künftig verfügbar sein sollen.
Praxisbeispiel: Müssen Projektleitende Informationen bisher aus mehreren Tabellen zusammentragen, kann ein Ziel darin bestehen, die benötigten Plan- und Ist-Daten in einem gemeinsamen Projektprozess verfügbar zu machen. Im Pilot lässt sich anschließend prüfen, ob dieser Ablauf funktioniert.
02 Projektarten und Standardstrukturen definieren
Nicht jedes Projekt benötigt denselben Aufbau. Unternehmen sollten deshalb prüfen, welche Projektarten regelmäßig vorkommen und welche Strukturen sich dafür sinnvoll standardisieren lassen.
Für wiederkehrende Projekte können beispielsweise typische Phasen, Vorgänge, Aufgaben oder Meilensteine festgelegt werden. Gleichzeitig sollte genügend Spielraum für Projekte bleiben, die vom Standard abweichen.
Dabei helfen folgende Fragen:
- Welche Projektarten kommen regelmäßig vor?
- Welche Phasen, Vorgänge oder Meilensteine wiederholen sich?
- Welche Informationen sollen bei vergleichbaren Projekten einheitlich gepflegt werden?
- Welche Bestandteile lassen sich standardisieren und wo sind individuelle Anpassungen notwendig?
- Können für wiederkehrende Abläufe geeignete Projektvorlagen genutzt werden?
Praxisbeispiel: Führt ein Unternehmen regelmäßig ähnlich aufgebaute Kundenprojekte durch, kann zunächst eine gemeinsame Grundstruktur für diese Projektart definiert werden. Im Pilot zeigt sich anschließend, welche Bestandteile tatsächlich wiederverwendbar sind und wo Anpassungen notwendig bleiben.ich wiederverwendbar sind und wo Anpassungen notwendig bleiben.
03 Rollen und Verantwortlichkeiten festlegen
Bevor Benutzer und Berechtigungen in der Software eingerichtet werden, sollte geklärt sein, wer für welche Arbeitsschritte und Daten verantwortlich ist. Je nach Organisation können beispielsweise Projektleitung, Projektmitarbeitende, Ressourcenplanung, Controlling oder Administration unterschiedliche Aufgaben übernehmen.
Vor der Konfiguration sollte geklärt werden:
- Wer legt neue Projekte an und pflegt die Projektstruktur?
- Wer plant Termine und Ressourcen?
- Wer bearbeitet Aufgaben und aktualisiert den Projektfortschritt?
- Wer erfasst oder prüft Projektzeiten, sofern diese benötigt werden?
- Wer ist für Stammdaten und grundlegende Systemeinstellungen verantwortlich?
- Wer benötigt welche Projektinformationen und Auswertungen?
- Wer entscheidet über Änderungen an gemeinsamen Standards und Arbeitsweisen?
Die Verantwortlichkeiten sollten zum tatsächlichen Arbeitsablauf passen. Erst wenn klar ist, wer welche Aufgaben übernimmt, lassen sich Benutzer und Berechtigungen gezielt einrichten.
Praxisbeispiel: Die Projektleitung kann für Planung und Projektfortschritt verantwortlich sein, während Projektmitarbeitende ihre Aufgaben bearbeiten und Projektzeiten erfassen. Die dafür erforderlichen Zugriffsrechte werden anschließend passend zu diesen Zuständigkeiten eingerichtet.
04 Stammdaten und Berechtigungen vorbereiten
Vor dem Pilotbetrieb sollten die benötigten Stammdaten geprüft und in geeigneter Qualität vorbereitet werden. Welche Daten erforderlich sind, hängt von den vorgesehenen Prozessen ab. Dazu können beispielsweise Mitarbeiter-, Kunden-, Projekt- oder andere organisatorische Stammdaten gehören.
Bestehende Daten sollten dabei nicht ungeprüft übernommen werden. Veraltete, doppelte oder uneinheitliche Datensätze sollten vor einer Übernahme identifiziert und gegebenenfalls bereinigt werden. Gleichzeitig werden die benötigten Benutzer und Berechtigungen entsprechend den zuvor festgelegten Verantwortlichkeiten vorbereitet.
Dabei helfen folgende Fragen:
- Welche Stammdaten werden für die vorgesehenen Projektprozesse benötigt?
- Aus welchen Systemen oder Dateien stammen diese Daten?
- Welche Daten müssen vor einer Übernahme geprüft oder vereinheitlicht werden?
- Welche Benutzer benötigen Zugang zur Software?
- Welche Berechtigungen benötigen die jeweiligen Nutzergruppen?
- Wer darf sensible Projekt-, Personal- oder Kostendaten einsehen oder bearbeiten?
- Wer ist später für Änderungen an Stammdaten und Berechtigungen verantwortlich?
Praxisbeispiel: Für den Pilot können zunächst nur die tatsächlich benötigten Stammdaten und Benutzer eingerichtet werden. Anschließend lässt sich mit unterschiedlichen Rollen prüfen, ob die Beteiligten auf die Informationen und Funktionen zugreifen können, die sie für ihre Aufgaben benötigen.
05 Ein repräsentatives Pilotprojekt auswählen
Bevor die Projektmanagement-Software breit eingesetzt wird, sollte sie zunächst mit einem überschaubaren, aber realistischen Pilotprojekt erprobt werden. Dafür eignet sich ein Projekt, das typische Abläufe, Rollen und Anforderungen des Unternehmens abbildet.
Ein sehr einfacher Sonderfall liefert möglicherweise zu wenig Erkenntnisse. Ein außergewöhnlich komplexes Projekt kann den Pilot dagegen unnötig erschweren. Sinnvoll ist deshalb ein Projekt, das möglichst nah am späteren Arbeitsalltag liegt.
Bei der Auswahl helfen folgende Fragen:
- Bildet das Projekt typische Arbeitsabläufe des Unternehmens ab?
- Sind die wichtigsten beteiligten Rollen vertreten?
- Lassen sich relevante Planungsschritte realistisch durchführen?
- Entstehen dabei die Daten, die später für Steuerung und Auswertung benötigt werden?
- Können bei Bedarf Ressourcenplanung, Projektzeiten oder Freigaben einbezogen werden?
- Bleibt das Projekt überschaubar genug, um Probleme und Rückmeldungen gezielt auszuwerten?
Vor dem Start sollte außerdem festgelegt werden, welche Ziele und Abläufe im Pilot überprüft werden sollen. So lässt sich anschließend besser beurteilen, welche Einstellungen und Arbeitsregeln funktionieren und wo Anpassungen erforderlich sind.
06 Zentrale Projektabläufe im Pilot testen
Im Pilotbetrieb sollten die Beteiligten die Software möglichst so nutzen, wie sie später im Arbeitsalltag eingesetzt werden soll. Statt möglichst viele einzelne Funktionen auszuprobieren, werden die zuvor festgelegten zentralen Projektabläufe zusammenhängend durchgespielt.
Ein typischer Ablauf kann beispielsweise so aussehen:
Projekt anlegen → Projekt strukturieren → Termine planen → Mitarbeitende einplanen → Aufgaben bearbeiten → gegebenenfalls Projektzeiten erfassen → Projektfortschritt aktualisieren → Projektdaten auswerten
Dabei sollte geprüft werden:
- Sind die vorgesehenen Arbeitsschritte für die jeweiligen Rollen praktikabel?
- Sind Verantwortlichkeiten und notwendige Eingaben eindeutig?
- Werden Informationen an den richtigen Stellen erfasst?
- Können erfasste Daten in nachfolgenden Arbeitsschritten weiterverwendet werden?
- Entstehen doppelte Eingaben oder unnötige manuelle Zwischenschritte?
- Fehlen Informationen für nachfolgende Prozessschritte?
- Welche Einstellungen oder Arbeitsregeln müssen angepasst werden?
Auch typische Änderungen sollten Teil des Piloten sein. Verschiebt sich beispielsweise ein Termin oder ändert sich eine Ressourcenzuordnung, lässt sich prüfen, wie der festgelegte Projektablauf mit solchen Änderungen umgeht.
07 Datenflüsse, Freigaben und Auswertungen prüfen
Im Pilot sollte nicht nur geprüft werden, ob einzelne Arbeitsschritte funktionieren. Ebenso wichtig ist, wie die dabei entstehenden Daten weiterverwendet werden. Informationen sollten dort verfügbar sein, wo sie für nachfolgende Projektprozesse benötigt werden.
Je nach Arbeitsweise können dabei Freigaben, Auswertungen oder der Datenaustausch mit anderen Systemen relevant sein.
Dabei sollte geprüft werden:
- Welche Daten entstehen in den einzelnen Arbeitsschritten?
- Wo werden diese Informationen anschließend weiterverwendet?
- Welche Daten müssen gegebenenfalls geprüft oder freigegeben werden?
- Wer ist für diese Freigaben verantwortlich?
- Sind die benötigten Plan- und Ist-Daten in den vorgesehenen Auswertungen verfügbar?
- Müssen Daten mit anderen Systemen ausgetauscht werden?
- Entstehen dabei manuelle Übertragungen oder doppelte Datenpflege?
- Erhalten die jeweiligen Rollen die Informationen, die sie für ihre Aufgaben benötigen?
Praxisbeispiel: Werden im Pilot Projektzeiten erfasst, kann der gesamte vorgesehene Datenfluss geprüft werden: von der Erfassung über eine gegebenenfalls erforderliche Freigabe bis zur Verwendung der Ist-Daten in einer Auswertung.
08 Mitarbeitende rollenbezogen schulen
Vor dem breiteren Rollout sollten die späteren Anwender wissen, wie sie ihre eigenen Aufgaben in der Projektmanagement-Software erledigen. Dafür müssen nicht alle Nutzer denselben Funktionsumfang kennenlernen.
Projektleitende benötigen beispielsweise andere Kenntnisse als Projektmitarbeitende oder Personen, die Stammdaten und Berechtigungen administrieren. Die Schulungsinhalte sollten deshalb an den zuvor festgelegten Rollen und Arbeitsabläufen ausgerichtet werden.
Für die Vorbereitung sollte geklärt werden:
- Welche Funktionen und Abläufe benötigt die jeweilige Nutzergruppe?
- Welche Eingaben müssen von wem vorgenommen und gepflegt werden?
- Welche gemeinsamen Regeln gelten für die Nutzung der Software?
- Welche Personen benötigen vertiefte Kenntnisse für Administration oder Projektsteuerung?
- Welche Anleitungen oder Hilfsmittel sollen anschließend verfügbar sein?
- An wen können sich Mitarbeitende bei Fragen wenden?
Statt ausschließlich einzelne Funktionen zu demonstrieren, sollten Schulungen möglichst typische Arbeitsabläufe aus dem Unternehmen aufgreifen. Projektmitarbeitende können beispielsweise anhand eines konkreten Ablaufs lernen, wie sie Aufgaben bearbeiten oder die für ihre Rolle benötigten Projektdaten pflegen.
09 Pilot auswerten und Regeln nachschärfen
Nach dem Pilotbetrieb sollten die beteiligten Personen ihre Erfahrungen systematisch auswerten. Ausgangspunkt sind die zu Beginn festgelegten Ziele: Funktionieren die vorgesehenen Projektabläufe und sind Verantwortlichkeiten, Datenpflege und Auswertungen ausreichend geklärt?
Dabei sollte geprüft werden:
- Welche Abläufe haben wie vorgesehen funktioniert?
- Wo entstanden Rückfragen oder unnötige Arbeitsschritte?
- Welche Daten wurden nicht einheitlich oder vollständig gepflegt?
- Waren Verantwortlichkeiten und Berechtigungen eindeutig?
- Welche Einstellungen oder Arbeitsregeln müssen angepasst werden?
- Welche Schulungsinhalte müssen ergänzt oder präzisiert werden?
- Welche offenen Punkte sollten vor dem Rollout gelöst werden?
Nicht jede Rückmeldung erfordert eine technische Änderung. Ursachen können auch unklare Verantwortlichkeiten, uneinheitliche Arbeitsregeln oder fehlendes Wissen über den vorgesehenen Ablauf sein. Erst danach sollte entschieden werden, ob Einstellungen, Berechtigungen oder Projektstrukturen angepasst werden müssen.n können auch unklare Verantwortlichkeiten, uneinheitliche Arbeitsregeln oder fehlendes Wissen über den vorgesehenen Ablauf sein. Erst danach sollte entschieden werden, ob Einstellungen, Berechtigungen oder Projektstrukturen angepasst werden müssen.
10 Rollout schrittweise erweitern
Sind die wichtigsten Erkenntnisse aus dem Pilot umgesetzt, kann die Projektmanagement-Software auf weitere Nutzer, Projekte oder Unternehmensbereiche ausgeweitet werden. Wie der Rollout aufgebaut wird, hängt von der Organisation ab und kann beispielsweise nach Teams, Abteilungen, Standorten oder Projektarten erfolgen.
Vor der Erweiterung sollte geklärt werden:
- Welche Nutzer, Teams oder Projekte kommen als Nächstes hinzu?
- Sind die benötigten Benutzer, Stammdaten und Berechtigungen vorbereitet?
- Welche erprobten Projektstrukturen und Arbeitsregeln können übernommen werden?
- Welche Schulungen benötigen die neuen Nutzer?
- Wer unterstützt bei Fragen während der Einführung?
- Welche Besonderheiten des nächsten Bereichs müssen berücksichtigt werden?
- Wer sammelt Rückmeldungen und entscheidet über notwendige Anpassungen?
Die im Pilot erprobten Standards müssen dabei nicht für jeden neuen Bereich neu entwickelt werden. Gleichzeitig sollte der Rollout genügend Spielraum lassen, um begründete Unterschiede zwischen Projektarten, Teams oder Bereichen zu berücksichtigen.
Projektmanagement-Software mit TimO® einführen
Mit TimO® können Sie direkt über den Browser starten, ohne die Projektmanagement-Software lokal zu installieren. Für den produktiven Einsatz richten Sie die benötigten Stammdaten, Benutzer, Berechtigungen, Projektstrukturen und Einstellungen passend zu Ihren Abläufen ein.
Bei der Einführung unterstützen wir Sie bei Bedarf persönlich. Neben Einrichtungshilfe und Support bieten wir auch Beratung und Produktschulungen an. Dabei können unterschiedliche Nutzergruppen berücksichtigt werden – beispielsweise Projektleitende, Teammitglieder oder Administratoren.
Sie möchten Ihre Projektabläufe zunächst selbst mit TimO® testen? Unsere Projektmanagement-Software können Sie 30 Tage kostenlos mit vollem Funktionsumfang testen. Für die Testphase benötigen Sie keine Kreditkarte und müssen nicht kündigen.
Fazit
Eine Projektmanagement-Software strukturiert einzuführen bedeutet, Technik, Projektprozesse und Verantwortlichkeiten aufeinander abzustimmen. Statt direkt mit einem breiten Rollout zu beginnen, sollten Unternehmen zunächst gemeinsame Strukturen und Zuständigkeiten festlegen und die vorgesehenen Abläufe in einem repräsentativen Pilotprojekt erproben.
Die Erkenntnisse aus dem Pilot können anschließend genutzt werden, um Einstellungen, Berechtigungen, Arbeitsregeln und Schulungsinhalte anzupassen. Danach lässt sich die Nutzung schrittweise auf weitere Projekte, Teams oder Unternehmensbereiche ausweiten.