Anforderungen an Projektmanagementsoftware
Projektmanagementsoftware - Anforderungen versus Wünsche
Warum werden Werkzeuge genutzt? Weil Sie uns eine Erleichterung bei der Umsetzung unserer Arbeit bringen. Oftmals nährt sich die Hoffnung auf ein gutes Werkzeug aus schwierigen Situationen, in denen vorhandene Mittel nicht ausreichen. Je schwieriger die Situation, desto größer der Wunsch nach einem funktionierendem Tool, welches die Probleme lösen kann. Oftmals vermischen sich dabei jedoch konkrete Anforderungen mit den Wünschen an ein solches Projektmanagement Tool.
Dieser Umstand führt insbesondere im Projektmanagement zu einer wahren Flut von Anforderungen an Projektmanagement-Softwarelösungen. Problematisch wird es immer dann, wenn die Anforderungen diffus formuliert werden. Den Wunsch nach einem besseren Projektmanagement kann keine Software erfüllen. Ebenso kann eine Software fehlende Führungskompetenzen nicht ersetzen. Ebenso erschweren Anforderungen, die in Teilen konträr zueinander stehen den Einführungsprozess.
Praxisbeispiel
Das Controlling benötigt monatsgenaue Kennzahlen auf Projektebene und in Bezug auf die tatsächlich verbrauchten Arbeitstage. Der Betriebsrat hingegen fordert eine anonymisierte Zeiterfassung in Monatsperioden. Diese Anforderungen stehen in keinem Widerspruch zueinander. Im Gegenteil, sie sind durchaus kompatibel. Allerdings stellt sich für das Einzelprojektmanagement die berechtigte Frage, woher diese Daten kommen und was man damit ggf. anfangen kann. Die ehrliche Antwort: „nichts“! Kein Mensch kann sich die geleisteten Stunden eines Projektes (geschweige denn mehrerer Projekte) für einen ganzen Monat merken. Folglich werden einfach die Projektplan-Werte als Ist-Werte gemeldet oder eine Schattenbuchhaltung auf Tages- oder Wochenebene je Mitarbeiter geführt, um am Monatsende halbwegs plausible Werte abgeben zu können. Effizient ist das jedoch nicht.
Keines der beiden Szenarien ist zufriedenstellend. Die Mitarbeiter werden nicht geschützt (was in der Regel der vermeintliche Hauptgrund für solche Vorgaben ist) und Überlastungen können auf diese Art und Weise vertuscht werden. Das Controlling erhält keine verlässlichen Daten und es wird ein enormer, unproduktiver Mehraufwand erzeugt.
Die Verlierer sind die Akteure des Einzelprojektmanagements. Sie erhalten keine Möglichkeit, die Projektsteuerung professionell umzusetzen und müssen zudem für sie nutzlose Kennzahlen erfassen und melden. Da die Kennzahlen für eine ernsthafte Projektsteuerung viel zu grob sind, muss hierfür eine Schattenbuchhaltung geführt werden. Der Mehraufwand für die Monatsmeldung kommt on top.
Vom Nukleus zum Anforderungskatalog
Eine Bewegung vom Nukleus des Einzelprojektmanagements in Richtung der Anforderungen wäre an dieser Stelle sinnvoller gewesen. Dann wäre klar, dass insbesondere Ressourcenmanagement Steuerungsdaten auf wochen- und ressourcenebene für ein professionelles Projektmanagement unverzichtbar sind. Immerhin soll der Projektleiter in das Geschehen eingreifen können, bevor das »Kind in den Brunnen gefallen« ist. Eine wöchentliche Steuerung des Geschehens ist somit eine Standardanforderung. Das Verwalten überzogener Budgets und verfehlter Terminvorgaben im Monatsrückblick hat mit Projektmanagement hingegen wenig zu tun.
In der Praxis entstehen die gravierendsten Verwerfungen nicht aufgrund von Projektplanfehlern oder geringer Motivation der Projektmitarbeiter. Dieser Umstand liegt vielmehr in ungenügend geklärten Projektaufträgen mit zu gering unterfütterten Ressourcenkapazitäten begründet. Wird diese Problematik nicht erkannt, so werden immer wieder neue Projekte initiiert, ohne zu erkennen, dass das »Wasser im See« aufgebraucht ist.
Multiprojektmanagement-Software soll eingeführt werden um die Performance der Projektlandschaft und damit die Erfolgschance der Projekte zu steigern. Mit den oben genannten, konträr formulierten Anforderungen wird dies nicht gelingen. Im Ergebnis wird das Werkzeug als Ballast wahrgenommen, der noch mehr Daten von denen abfordert, die sowieso schon in den Projekten zu kämpfen haben. Ein Werkzeug, welches eher behindert als unterstützt, wird nicht genutzt. Im Ergebnis wird nach zwei bis drei Jahren ein neues Werkzeug gesucht, weil das alte nicht die erhofften Ergebnisse gebracht hat und alles beginnt aufs Neue.
Auch das Zwischenschalten einer Ausschreibungsplattform hilft an dieser Stelle nicht wirklich. Denn die Praxis zeigt, dass oftmals nur »unabgestimmte« Anforderungen professioneller ausgeschrieben werden.
Um all das zu vermeiden wird ein Einführungskonzept benötigt, welches sich auf die wesentlichen Projektmanagement-Anforderungen konzentriert und diese zum Nukleus erklärt. Erst danach sollten angrenzende Anforderungen aufgenommen werden. Gegen den Nukleus verstoßende Anforderungen sollten rausgelassen oder abgewandelt werden bzw. keinen Widerspruch zu den Kernanforderungen bilden. Erst im Anschluss daran ist eine Beschäftigung mit Werkzeugen und Pilotierungsszenarien sinnvoll.
Der Nukleus ist nicht verhandelbar
Anforderungen aus dem Einzelprojektmanagement (NUKLEUS)
- Klassische und/oder agile Projektplanung mindestens auf Wochenebene
- Zuweisung von Projektressourcen auf Projekt- und Aktivitätenebene
- Wöchentliche Erfassung von Fortschritten und Arbeitszeiten je Ressource und Aktivität
- Auswertung der PLAN- und IST-Daten hinsichtlich Arbeit und Kapazität wöchentlich und monatlich
- Auswertung nach Earned Value auf Grundlage der erfassten Daten
Im nächsten Schritt werden ggf. weitere Anforderungen aus dem Multiprojektmanagement und dem Project Management Office (PMO) ergänzt. Diese dürfen jedoch nicht im Widerspruch zu den Anforderungen aus dem Einzelprojektmanagement stehen. In weiteren Schritten könnten Anforderungen aus dem Ressourcenmanagement, dem Controlling, der Buchhaltung und der Geschäftsleitung hinzugefügt werden. Dies sollte jedoch immer unter Beachtung des primär definierten Nukleus aus dem Einzelprojektmanagement geschehen.
Angrenzende und/oder organisatorische Anforderungen bilden den Rahmen und somit den Abschluss der Beschreibung. Auch diese dürfen nicht konträr zum Nukleus formuliert werden. Jedoch dürfen die Anforderungen aus dem Multi-Projektmanagement, Ressourcenmanagement oder Management eingrenzen oder beschränken. Gegebenenfalls muss in einem abschließenden Priorisierungsworkshop auf konträre Anforderungen eingegangen und diese sinnvoll aufgelöst werden.
Nun soll noch einmal auf die Sorge des Betriebsrates vor einem Missbrauch der Zeiterfassung für Leistungsbewertungen oder gar arbeitsrechtliche Auseinandersetzungen aus unserem letzten Beitrag eingegangen werden: »Der Betriebsrat fordert eine anonymisierte Zeiterfassung in Monatsperioden.«
Nun ist es so, dass die Zeiterfassung in ihrem Umfang nicht eingeschränkt werden kann, weil dies gegen den verabschiedeten Anforderungsnukleus spräche. Hier müssen Lösungen außerhalb des Nukleus gefunden werden.
In diesem Fall wird eine organisatorische Lösung benötigt, die keinen Einfluss auf die Anforderungen an ein Multi-Projektmanagement-Tool hat. So kann z.B. die Betriebsvereinbarung eine Regelung zur Verwendung der im Rahmen des Einzelprojektmanagements erfassten Daten mit dem Tool XY enthalten. Für die Betriebsvereinbarung bedeutet dies, dass sie Ausschlusskriterien in der Nutzung aufweist, die z. B. die Verwendung der Daten für arbeitsrechtliche und disziplinarische Auseinandersetzungen unterbindet. Damit haben diese Daten keinen rechtswirksamen Charakter mehr.
Alternativ könnte eine technische Lösung darin bestehen, dass die Daten nach Projektabschluss gelöscht werden. Das schränkt zwar den Erfahrungsprozess ebenso wie die Verwendung von IST-Daten für zukünftige Projektplanungen ein, aber es betrifft dann nicht mehr die Anforderungen aus dem Nukleus.
Organisatorische Anforderung an eine Multiprojektmanagement Software /Anforderungen aus dem Betriebsrat:
- Löschen der erfassten Arbeitszeiten von abgeschlossenen Projekten möglich
- Prüfung auf Löschung durch den Betriebsrat (Rechtrolle) über Oberfläche möglich
Fazit
Die Multi-Projektmanagement-Software der Wahl sollte im ersten Schritt einem durchgängigen Gedanken folgen und eine übergreifende Betrachtung des Einzelprojektmanagement, des Multi-Projektmanagement bzw. des Ressourcenmanagement zulassen. Ist das nicht der Fall, dann empfiehlt es sich, alle Anforderungen noch einmal entlang dieser Leitlinie zu formulieren. Ausgehend von Mindestanforderungen aus dem Einzelprojektmanagement, die im Unternehmen abgestimmt und akzeptiert sein müssen, werden alle weiteren Anforderungen darauf aufbauend aufgenommen. Hierbei können angrenzende Anforderungen ggf. gegeneinander abgewogen werden. Allerdings niemals zu Lasten der Mindestanforderungen. Dieser Diskussionsprozess liefert am Ende einen Anforderungskatalog, der nicht als Kombination aller am Markt verfügbaren Funktionen entstanden ist und sich inhaltlich durch einschränkende Anforderungen widerpicht. Vielmehr enthält er tatsächliche funktionale Anforderungen auf Grundlage echter Bedürfnisse, die untereinander abgestimmt sind und somit Synergie-Effekte auf unterschiedlichen Ebenen im Unternehmen entfalten können.
