1. Bei Entscheidungen zum weiteren Verlauf eines Projektes werden die bereits investierten Kosten als Argument für eine Weiterführung des Projektes aufgeführt:
Bei einer Entscheidung zur Weiterführung eines Projektes dürfen die bisherigen Investitionen nicht als Argument herangezogen werden. Vielmehr gilt es, an den entscheidenden Stellen des Projekts einen zukunftsbezogenen Business Case durchzuführen.
2. Projekte werden häufig ad hoc gestartet, ohne dass ausreichend Ressourcen verfügbar sind:
Eine wesentliche Ursache dafür besteht oftmals darin, dass die Berechtigungen zur Ausgabe des Projektmandates unklar sind und daher keine Ressourcen benannt werden können. Bei der Einführung eines Projektmanagement-Prozesses sollte deshalb eine Zuständigkeitsmatrix erstellt werden, durch welche Rollen ein Projektauftrag – differenziert nach Projektgröße und -typ – erteilt werden darf. Auf Basis dieser Rollenmatrix des Projekts kann eine Zuordnung zu konkreten Stellen in der Organisation erfolgen, so dass die Verantwortlichkeiten zur Erteilung von Projektaufträgen klar geregelt sind.
3. Bei der Projektplanung wird zu schnell über Lösungsansätze und erforderliche Aktivitäten gesprochen, ohne dass ein einheitliches Verständnis der genauen Ziele besteht:
Die Projektplanung sollte konsequent auf die zu liefernden Ergebnisse ausgerichtet werden. Dabei sind alle zu erstellenden Ergebnisse in messbarer Form möglichst genau zu beschreiben (Spezifikation des Ergebnisses, Form, Umfang, Qualität etc.). Eine Beschreibung der Abnahmekriterien- und verfahren beugt zudem eventuellen Streitigkeiten vor. Die Aktivitäten sind erst im zweiten Schritt zu diskutieren, wenn eine Definition der Lieferergebnisse erfolgt ist.
4. Ansprechpartner sind sich ihrer Rolle in Projekten nicht bewusst:
Aktive Einbindung in Projekte über Use-Case-Definitionen und gemeinsame Entwicklung eines Kommunikationsplans.
5. Bei Projektbeginn ist das Projektteam relativ gut informiert, jedoch fehlt es mit zunehmender Projektdauer sowie außerhalb des Projektes an Informationen:
Eine Stakeholder-Analyse zu Projektbeginn erstellen, aus der die Form und der Umfang von Informationen und Einbeziehung der beteiligten Akteure strukturiert abgeleitet werden können. Daraufhin lässt sich ein Stakeholder-spezifisches Kommunikationskonzept aufsetzen.
6. Der vereinbarte Input aus Fachabteilungen wird nicht geliefert:
Eindeutige Verantwortlichkeiten sowie die Abhängigkeit ihres Inputs für das Gesamtprojekt (Visualisierung über Produktstrukturplan) definieren, aus denen die Folgen bei Nichtlieferung eindeutig ablesbar sind.
7. Neue Projekte und Service-Änderungen werden „on the fly" und ohne Spezifikationen direkt an einen Mitarbeiter der IT adressiert:
Entwurf eines strukturierten Verfahrens für Projektantragstellung und -freigabe, verbunden mit der Definition von Verantwortlichkeiten zur Steuerung dieses Prozesses – beispielsweise durch einen entsprechenden IT-Koordinator.
8. Mit Kunden sind klare Aufgaben und Termine definiert, diese werden aber immer verschoben:
Workshop zur genaueren Definition der Arbeitspakete mit Abschätzung der Dauer durch Experten durchführen. Dabei eine genaue Priorisierung vornehmen, Unterstützung anbieten, den Abstimmungsprozess überdenken und den Dokumentationsbedarf klären.
9. Der Status des Projektes ist während der Projekt-Durchführung häufig unbekannt:
Eine kleine Webseite sowie einen Newsletter nebst Reporting erarbeiten, die für jeden Stakeholder jederzeit abrufbar sind. Außerdem sollte in der Verantwortung des Projektleiters ein Kommunikations-Konzept eingeführt bzw. verbessert werden.
