Warum werden Angebote nicht immer mit einem professionellen Projektplan präsentiert?

Als Hersteller einer Projekt- und Ressourcenmanagementsoftware ist es für Can Do selbstverständlich, genau dies zu tun. Denn: Wenn wir nicht spitzenmäßiges Projektmanagement, natürlich mit der eigenen Software, können, wer dann? Aber warum wird in vielen anderen Bereichen dies nicht genauso dargestellt?

Die einfache und schnelle Antwort liegt auf der Hand: Die Anbieter können es einfach nicht!

Die Unternehmen sind völlig auf ihre fachliche Kompetenz fokussiert und wollen ausschließlich damit überzeugen. Dem eigentlichen Projektmanagement wird wenig Aufmerksamkeit geschenkt.

Vielleicht gibt es noch einen anderen Grund, der aber keine unbegründete Unterstellung ist:

Alle Projektplanungs-Elemente in einer Verkaufspräsentation, wie ich sie im vorherigen Beitrag vorgestellt hatte, enthalten einen wesentliche Punkt: Sie stellen eine Zusage dar. Eine Zusage an Termine, Kapazitäten und Abläufe, verbindliche Vereinbarungen – wenn auch in Teilen ungenau –, die wenig Spiel für Abweichungen und Ausreden bietet. Es ist eine Festlegung, die auf der Sicherheit der eigenen Kompetenz und Erfahrung basiert. Bei guten Anbietern sollte das auch kein Problem sein.

Ist die kompetente Darstellung des Projekts der Game Changer?

Nein, das ist sicher nicht so. Die fachliche Qualifikation und das Vertrauen in die Personen des Anbieters, seine Referenzen und die vorzeigbaren thematischen Erfolge wiegen deutlich schwerer. Aber drei oder vier Folien bei der Präsentation und auch als Teil des Angebots können einfach Pluspunkte in Sachen Vertrauen bringen und somit ausschlaggebend sein.

Das zeigt dem zukünftigen Kunden, dass der Anbieter eben nicht nur fachlich gut ist. Die anderen Anbieter sind natürlich auch nicht schlecht, sonst dürften sie nicht vor einem solchen Gremium ihr Angebot präsentieren. Es zeigt, dass der Anbieter den Kunden wirklich ernst nimmt und den gemeinsamen Erfolg wirklich will. Es schafft partnerschaftliches Vertrauen und die Basis für eine zielorientierte Zusammenarbeit.

Stilblüten

Nach über 20 Jahren in diesem Umfeld, in allen Rollen, als Anbieter, Kunde, Berater und von Firmen eingesetzter Entscheider, erlebt man natürlich amüsante und manchmal sogar schockierende Momente.  Selbstverständlich kann ich hier keine Firmen, Projekte oder gar Personen nennen. Daher umschreibe ich die Beispiele.

1. Als Lenkungsausschuss in einem Projekt eines Bundeslands sollte ich über Förderprojekte im Umfeld der Digitalisierung entscheiden. Kommunen und Gemeinden beantragten erhebliche Fördermittel, um die Digitalisierung voranzutreiben. Ein Projektantrag wurde damit begründet, dass die Gemeinde pleite sei, ein Grundstück für das Projekt besitzt und der lokale Bauunternehmer gerade eine Auftragsflaute hat. Für die Bewertung des Projektablaufs bat ich um einen Zeitplan (Projektplanung) und eine – wenn auch kurze – Beschreibung des Projekterfolgs. Handschriftlich wurde nachgereicht, dass der Bauunternehmer dann wieder einen Auftrag bekommen würde. Das wäre der Projektnutzen. Die Projektzeitraum hängt davon ab, wann der Bauunternehmer Personal dafür hat (Ressourcenplanung) und immer dann Personal abstellt, wenn seine Leute nichts anderes  zu arbeiten haben. Mein Einwurf, dass das Projekt nie fertig wird, wenn das Unternehmen jetzt viele Aufträge von anderen Bauherren bekommt, wurde dargestellt: Wenn das so ist, brauchen wir das ganze Projekt nicht. Ich habe eine Genehmigung des Projektes nicht empfohlen. 

2. In einem Genehmigungsausschuss, in dem der Vorstand eins Unternehmens mich bat, über anstehende IT-Projekte eine Einschätzung abzugeben, wurde ein Projekt vorgestellt, das einige Millionen Kosten verursachen würde. Obwohl das Unternehmen über eine gute Projektsoftware verfügte (Can Do), wurde die Planung in einer PowerPoint-Folie dargestellt. In einer Sitzungspause riet ich dem Vorstand, das Projekt in Erwägung zu ziehen, aber es möge 2 Monate vorgezogen werden. Der Direktor, der das Projekt präsentiere, wurde gebeten, doch in PowerPoint seinen gesamten Plan schnell per Drag n Drop zu bewegen und dann eine Aussage zu machen, ob das auch möglich wäre. Dies war ihm nicht möglich. Die Entscheidung wurde vertagt, die Planung in die Software übertragen und erneut dargestellt. Dabei kam heraus, dass das Projekt so mit den vorhandenen Kapazitäten gar nicht zu realisieren ist. Es wurde abgelehnt. Möglicherweise wurde damit ein Schaden in Millionenhöhe vermieden.

3. Bei einem Unternehmen, dessen Projekt- und Kapazitätsplanung weit von der Realität entfernt war, wurden wir gebeten, die Machbarkeit mit unserer Lösung zu überprüfen. In Fachgesprächen stellte sich heraus, dass das Unternehmen seit 8 Jahren erfolglos nach einer professionellen im Markt erhältlichen Lösung sucht. Diese – recht einfachen – IT-Projekte sowie deren Bedingungen und Prozesse seien weltweit so einmalig, dass einfach niemand das mit Software abbilden könne.
Es gehe nur mit einem vom Entscheider selbst erstellen Excel-File. Unser Hinweis, dass dies normale IT-Projekte seien, die quasi alle Computerprogramme abbilden können, wurden wortgewaltig mit unglaublichen Detailproblemen abgetan. Der Entscheider wollte einfach seine Excel-Datei und damit die Hoheit über die Daten und Informationen behalten. Das Management war fachlich nicht in der Lage, die Situation zu erkennen. Daher haben wir uns aus dem Projekt sehr früh zurückgezogen.

4. In einem Projekt wurden wir mit einem Unternehmen konfrontiert, das jeglichen Überblick über Projekte und eingesetzte Ressourcen verloren hatte. Die Situation des gesamten Unternehmens wurde kritisch, da sehr viel Geld verbrannt wurde. Eine schnelle Lösung war erforderlich, und wir schlugen vor, alle Projekte einfach mit deren Namen und Anfang und Ende mit den generischen Ressourcen in der Software zu hinterlegen, um einen Überblick zu erhalten.

Dabei stellte die Software fest, dass zwei thematisch gleiche Projekte am gleichen Standort parallel liefen. Es wurden erhebliche Ressourcenkonflikte gefunden. Mitarbeiter arbeiteten simultan in zwei verschiedenen Softwareprojekten mit dem gleichen Projektauftrag. Die Projekte wurden in zwei Geschäftsbereichen nahezu gleichzeitig von unterschiedlichen Gremien freigegeben. Da die Spezialisten für die beiden Projekte aber die gleichen Personen waren, arbeiteten diese doppelt. Die beiden bereichsübergreifenden Projekte wurde dann zu einem Projekt zusammengefasst.

5. Bei einem Rollout unserer Software konnte ein Projektleiter nicht davon überzeugt werden, dass eine detaillierte Planung über mehrere Jahren mit genauen Arbeitspaketen, die auf einen Tag genau terminiert wurden, nicht sinnvoll ist. Der Projektleiter erstellte tatsächlich eine Detailplanung mit fast 1000 Arbeitspaketen und namentlichen Zuweisungen von Ressourcen. Im Lenkungsausschuss wurde die Planung tatsächlich immer so genau und ohne Risiko dargestellt. Jede Abweichung wurde mit hohem Aufwand für die gesamte Restplanung kompensiert. Ich hatte nichts als den Aufwand für diese Planung zu bemängeln. Aber bei einer Sitzung fand die Software doch ein Problem, das der Projektleiter nicht bedacht hat: Eine seiner Schlüsselressourcen würde in 18 Monaten hilflos überlastet sein. Eine Lösung für die Kapazitätsplanung dieser Ressource konnte auch nicht durch die KI gefunden werden: Der Mitarbeiter ging einfach in 18 Monaten in den Ruhestand. 

6. Bei einem Unternehmen wurde durch spezielle Apps sehr genau kontrolliert, ob die Mitarbeiter korrekt ihre Ist-Zeiten für die im Konzern vorgeschriebene Leistungsverrechnung durchführen. Wer es vergaß, wurde erinnert. Ein Abteilungsleiter konnte immer korrekt nachweisen, dass alle seine Mitarbeiter in einem Projekt absolut richtig zurückmelden. Ein Projektleiter hegte Zweifel an dieser Erfassung. Ich wies ihn darauf hin, dass unsere Software eine durch einen komplexen Algorithmus gestützte Möglichkeit hat, bei der der Mitarbeiter einfach eingeben kann, dass er diese Woche 40 Stunden gearbeitet hat. Der Algorithmus rechnet dann aus, wie es optimal gewesen wäre und erzeugt die passenden Zeiterfassungen im Namen des Mitarbeiters (diese Funktion kann auch abgeschaltet werden). Ich riet dem Projektleiter, für den nächsten Monat ein Arbeitspaket mit dem Titel „Nase bohren“ zu planen. Am Monatsende konnte gezeigt werden, dass zwei Mitarbeiter wirklich 10 Stunden in der Nase gebohrt haben, aufgrund der Zeiterfassung. Der Algorithmus, der dazu gedacht ist, die Zeiterfassung bei „Problemfällen“ zu erleichtern, wurde daraufhin abgeschaltet. 

7. In einem agilen Projekt zeigte eine Earned Value Analyse für ein Projekt eine extrem positiven Wert. Das agile Team hat viel besser gearbeitet und mehr „Value“ in dem Projekt erzeugt, als jedes andere Projekt im Konzern. Eine detaillierte Analyse dieser, sehr positiven, Abweichung ergab, dass das Team in JIRA^® den Sprint verwechselt hatte und immer zwei Wochen in der „Zukunft“ gelebt hatte.

8. Ein Administrator eines On-Prem-Kundensystems meldete unseren Administratoren eine ungewöhnliche hohe Prozessorauslastung des Systems – rund im die Uhr. Dazu muss man wissen, dass Can Do durch seine Fähigkeit, ungenau zu planen, alle zukünftig entstehenden Szenarien aller Projekte ständig simuliert, um allen Anwendern die wahrscheinlichsten Fälle in Echtzeit darzustellen. Die Möglichkeiten sind aber nicht unendlich und gerade am Wochenende, wenn die am wenigsten wahrscheinlichen Situationen simuliert werden, kommt das System quasi an ein Ende, es hat alle Möglichkeiten berechnet und bewertet. Bei diesem System aber nicht. Der Server nutzte auch am Wochenende – wenn kein Anwender im System war – alle Ressourcen aus, um mit hoher Priorität zu rechnen. Natürlich vermuteten wir einen Fehler in der komplexen Struktur der Algorithmen und begannen mit der Analyse. Das Problem war, dass ein Abteilungsleiter einfach alle Aufgaben, auch Tätigkeiten von einer halben Stunde, die er im nächsten Jahr irgendwann mit seiner Abteilung machen wollte, erfasst hat. Als Termin zur Umsetzung hat er einfach das Jahr als Zahl eingetippt, was in Can Do möglich ist. So hat er für 500 Arbeitspakete, die alle irgendwann im nächsten Jahr anstehen, eine kombinatorische Vielfalt geschaffen, die zur Berechnung der Wahrscheinlichkeit, wie es wirklich ablaufen wird, jeden Computer überfordert. Der Anwender hat hier nichts falsch gemacht, die Softwaredesigner haben nur nicht damit gerechnet, dass jemand so etwas macht. Der Algorithmus wurde darauf hin so erweitert, dass ein anderer Algorithmus erkennt, wenn es sich nicht mehr lohnt, alle möglichen Szenarien zu berechnen. Dann werden bei einer entsprechend hohen Wahrscheinlichkeit die unwahrscheinlichen Szenarien so generalisiert, dass das Ergebnis aussagekräftig, aber eben nicht ganz genau ist. Gerade bei den extrem leistungsfähigen Cloudsystemen kam dieser Notfallalgorithmus bisher nicht mehr zum Einsatz. 

Fazit

(Hybrides) Projektmanagement mit Can Do kann viel leisten – im Projekt-Alltag genauso wie bei der Angebots-Präsentation. Die Fähigkeit, diese PM-Software sinnvoll einzusetzen, ist gefragt. Hierbei unterstützt Dich Can Do natürlich! Du möchtest alles über Hybrides Projektmanagement, Can Do und die Verbindung von Vertrieb und PM wissen? Lass Dich von uns unverbindlich beraten – nimm einfach Kontakt auf!

Unser Blogpost-Zweiteiler in der Übersicht:

• Teil 1: Warum eine gute Projektpräsentation Angebote attraktiver macht
  
• Teil 2: Aus dem Erfahrungsschatz: Beispiele, wie man es nicht macht
  (dieser Beitrag)