… so könnte man sich blauäugig den anstehenden Projektverlauf nach der heutzutage um sich greifenden Vollkasko-Mentalität vorstellen. Aber weit gefehlt. Viele unzufriedene Kunden zeugen vom Gegenteil. Die Kosten laufen aus dem Ruder, Zeitschienen werden gerissen, Business-Ziele werden nicht erreicht und die Schuldfrage steht viel zu oft im Mittelpunkt der Diskussionen, trotz Festpreis. Worin liegen die Haupt-Treiber für diese Unzufriedenheit, wie können diese vermieden werden und ist man - selbstkritisch betrachtet - als Auftraggeber tatsächlich immer so schuldlos daran?
Im ersten Teil des Artikels wurden verschiedene Beratungsstrategien für eine SAP-Einführung dargestellt. Die Praxis lehrt dabei, dass jene Unternehmen klar erfolgreichere Einführungen realisieren, die sich vorab die eigenen Stärken und Schwächen im anstehenden Projekt transparent machen, auf dieser Basis dann ihren Implementierungs-Partner gezielt auswählen und nicht lediglich die günstigsten Angebote berücksichtigen. Damit ist ein erster grundlegender Schritt zu einem professionellen Projekt getan!
Um dann die verhandelten Kosten im Griff zu behalten, liegt es nahe, das Einführungs-Projekt zum Festpreis zu verhandeln. Entgegen einem Time & Material-Vertrag suggeriert dies, alle Kosten im Griff zu haben. Voraussetzung dafür ist aber, dass sowohl der Projekt-Umfang als auch die Verantwortlichkeiten und Mitwirkungspflichten des Auftraggebers oder anderer Partner eindeutig festgelegt wurden. Genau dies ist vor Beginn des Projektes aber in der Realität kaum machbar und öffnet Tür und Tor für möglichen späteren Misserfolg.
Fachliche Grob-Konzepte täuschen Sicherheit vor
Selbst detaillierte Fein-Konzepte, in denen die vielfältigen Prozessvarianten der SAP Business Suite mit den aktuellen und den zukünftig gewünschten Geschäftsprozessen des Auftraggebers abgeglichen und aufwandstechnisch bewertet werden, sind nur bedingt gute Aufwandsschätzungen. Es ist die Regel, dass im Verlaufe des Projektes sowohl sich ändernde Kundenwünsche als auch gegenseitig falsch verstandene Begrifflichkeiten oder Annahmen aufeinander treffen. Aus Erfahrung klug, kalkuliert ein Berater dies vorab mit ein. Nicht minder erfahren, wissen Kunden um diese Puffer und streichen sie in den Vertragsverhandlungen wieder raus. Klar, dass darin im Bedarfsfall Konflikt-Potenzial besteht. Vor allem wenn man bedenkt, dass nicht wenige Kunden SAP-Implementierungen auf Basis eines Grob-Konzeptes zum Festpreis verhandeln und dies so ihrer Geschäftsführung gegenüber auch vertreten. Jeder weiß, dass ein solches Versprechen dann nicht einfach korrigiert werden kann.
- 1. Unklare Arbeitslast
Bryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen. - 2. Undefinierte Erwartungen
Alle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia. - 3. Fehlende Management-Unterstützung
Die Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv. - 4. Methodik nach Schema F
Im Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt. - 5. Überlastete Mitarbeiter
„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet. - 6. Ungeteiltes Herrschaftswissen
Projekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann. - 7. Unklare Entscheidungsfindung
Im Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht. - 8. Fehlende Software
Exel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software. - 9. Gefahr des Ausuferns
Change Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist. - 10. Nicht "Nein" sagen können
Im Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man "nein" sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat. - 11. Mangelnder Zusammenhalt
Projektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3. - 12. Vergessener Arbeitsalltag
Hilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen. - 13. Zu häufige Meetings
Meetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren. - 14. Gut genug ist nicht immer gut
Sergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes. - 15. Nicht aus Fehlern lernen
Liz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden. - 15 Fehler beim Projektmanagement
Es gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.
Die Crux mit den Mitwirkungspflichten
Und dann wäre da der Passus Mitwirkungspflichten. Es ist selbstverständlich, dass die Berater vor Ort Räumlichkeiten, Systemzugriff und sonstige Infrastruktur benötigen. Darüber hinaus werden in den Mitwirkungspflichten aber auch Leistungen wie die Bereitstellung eines qualifizierten Projektleiters durch den Auftraggeber, die Sicherstellung der Verfügbarkeit von fachlichen Ansprechpartnern mit Entscheidungs- und Durchsetzungskompetenz bzw. zeitlich verfügbare Eskalationsinstanzen für zu treffende Projektentscheidungen gefordert. Wem dies bekannt vorkommt, der weiß wahrscheinlich auch - oft aus eigener, leidiger Erfahrung - wie schwer dies im Laufe eines mehrmonatigen oder gar mehrjährigen Projektes einzuhalten ist. Anders ausgedrückt bedeutet dies, wenn die Chemie zwischen Beratung und Auftraggeber nicht stimmt, dann können hier enorme Risiken für signifikante und im schlimmsten Falle sogar rechtlich zu entscheidende Änderungen für den Projektaufwand (Change-Request) schlummern.
Verantwortlich sind immer die anderen
Es soll Menschen geben, die die Frage nach der Verantwortung für Qualität im Unternehmen mit dem Qualitätsbeauftragten beantworten. Übertragend hieße dies, dass die beauftragte Beratung für das Projekt verantwortlich in "meinem" Unternehmen wäre: für "meine" Mitarbeiter, für "meine" Prozesse, für "meine" Daten und für "meine" Erfolge.
Hier bin ich entschieden anderer Meinung. In meiner aktiven Zeit als Programm-Manager habe ich niemanden aus der Pflicht genommen. Jeder Einzelne trug auch Verantwortung für das große Ganze, egal welche Rolle er im Projekt bekleidete. Dies war Teil des Planes und Teil des Erfolges! Ich kann mir nur schwer vorstellen, dass es professionelle Manager auf Auftraggeberseite gibt, die dies anders sehen. Damit bleibt aber auch jeder Auftraggeber in der Verantwortung, auch wenn er einen externen Projektleiter beschäftigt. Ausreden und Schuldzuweisungen sind absolut kontraproduktiv und ein klares Signal von schwachem Projektmanagement. Man kann nicht alle Risiken outsourcen.
Foto: Kzenon/Fotolia.com
Diese Kollektiv-Verantwortung steht übrigens nicht im Widerspruch zur Management-Regel, möglichst klare Aufgaben zu vergeben und diese vom jeweils Verantwortlichen auch einzufordern. Im Gegenteil, jeder Projektmitarbeiter ist erfolgskritisch und genau diese Einstellung muss auch die Zusammenarbeit im Projekt prägen. Andernfalls ist er fehl am Platz, denn am Ende zählt für alle nur der gemeinsame Projekterfolg!
Die aufgezeigten Themen zeigen, dass eine SAP-Implementierung mehr als nur eine Vertragserfüllung sein muss. Hinter vorgehaltener Hand prüfen Beratungsunternehmen dazu stets auch die Auftraggeber-Fähigkeit des Kunden. Es ist bei weitem nicht so, dass ein professionelles Beratungsunternehmen froh um jeden Auftrag ist, denn wie für jedes Unternehmen muss die Leistungserbringung auch kaufmännisch sinnvoll sein. Dazu müssen absehbare Projektrisiken und verhandelte Projektpreise in einer für das Beratungs-Unternehmen sinnvollen Relation stehen. So gesehen ist eine solche Prüfung mehr als legitim und aus kaufmännischer Verantwortung heraus geradezu Pflicht, auch wenn es sich für den Kunden seltsam anhören mag.
Aus der Praxis
An einem selbst schmerzhaft durchlebten Beispiel möchte ich die beschriebenen Themen ins reale Licht rücken: Nach langen Verhandlungen war das Projekt bei einem großen deutschen Fertigungs-Unternehmen auf Basis des Grob-Konzeptes zum Festpreis zugesagt. Bereits zu Beginn der Fein-Konzeption wurden die fachlichen Inhalte mehrfach grundlegend geändert und unserer Meinung nach erweitert. Dies ist nicht ungewöhnlich, allerdings wurden resultierende kommerzielle Anträge auf Change-Requests regelmäßig mit dem Argument "Festpreis heißt Festpreis" abgelehnt. Dies roch nach Methodik, was tun?
Eigentlich hätten wir als Beratungsunternehmen unseren Einsatz stoppen müssen, die Auftraggeber-Fähigkeit war aus unserer Sicht nicht gegeben. Aus Angst vor Pönalen und schlechter Presse hat man sich aber bewusst entschieden das Projekt fortzusetzen. Schließlich kam es wie es kommen musste: Entscheidungen wurden nicht mehr getroffen, keiner wollte mehr Verantwortung übernehmen, Zeitschienen konnten dadurch natürlich nicht mehr eingehalten werden, so dass nur noch Schuldfragen diskutiert und gegenseitig mit den Juristen gedroht wurde. Das Projekt wäre inhaltlich sicher machbar gewesen, wurde aber letztlich gestoppt und rückabgewickelt. Für alle Beteiligten ein Desaster - nicht nur, dass die erhofften Wettbewerbsvorteile für den Kunden nach der Implementierung nicht erreicht werden konnten, es hat auch alle Parteien viel Zeit, viele Nerven und letztlich viel Geld gekostet.
Blieb die Frage: wer war schuld? Aus heutiger Sicht jeder für seinen Teil, aber schlussendlich war dies auch egal. Das gesamte Team hatte versagt und keine Schuldverteilung bringt verpasste Wettbewerbsvorteile wieder. Müßig zu erwähnen, dass jede Partei am Ende nur noch mit der Suche nach vertraglich belegbaren Versäumnissen des anderen im beschriebenen Sinne beschäftigt war. Auch wenn es seltsam klingen mag, ich möchte diese Erfahrungen dennoch nicht missen. Für mich war dieses Projekt eines der lehrreichsten meiner Projekt-Karriere und mir ist ähnliches später nie mehr passiert!
- Memonic
Bei Memonic handelt es sich um eine hochwertige Software, die durch ein umfangreiches Feature-Set überzeugt. Mit verschiedenen Clients für Web, Desktop und Mobile sorgt sie gleichzeitig für die Flexibilität, die von Kunden zunehmend erwartet wird. - Kippt Inc
Kippt Inc dient als eine durchdachte Informationsmanagement-Lösung mit Fokus auf Collaboration. Davon können Anwender profitieren, die eine einfachere Alternative zu Evernote suchen. - Diigo
Diigo ist ein kleiner Helfer für Arbeitsteams, die Themen gemeinsam recherchieren, an Notizen kollaborativ arbeiten und sie mit Kollegen und Partnern einfach teilen möchten. Dabei sind die integrierten Kommentierungswerkzeuge besonders praktisch. - Springpad
Mit Springpad bietet sich eine leistungsstarke und qualitativ hochwertige Wissens-Management-Lösung an, die mit einigen innovativen Features den Unterschied ausmachen kann. In puncto Usability muss sie den Vergleich mit Evernote nicht scheuen. - MindMeister
Bei MindMeister handelt es sich um eine anspruchsvolle Mind-Mapping-Lösung, die mit leistungsstarken Collaboration- und Sync-Funktionen Evernote nicht nur ergänzen, sondern auch problemlos ersetzen kann.
Nur im Team
Die Darstellung zeigt, wie wichtig das gemeinsame Teamverständnis für ein SAP-Projekt ist und damit über Erfolg oder Misserfolg entscheidet. Das Miteinander ist der Schlüssel zum Projekterfolg - leben und leben lassen, die Devise. Sportlich kalkulierte Projekte sind in Ordnung, aber sie müssen dann fair verhandelt sein und Veränderungen im laufenden Projekt Rechnung tragen. Überzogene Gewinnmargen sind genauso schädlich wie preislich geknebelte Berater, sonst werden oben beschriebene Register gezogen.
Wenn nun aber ein Festpreis eine nur bedingte Maßnahme zur Kostendeckelung darstellt, welche Weichen kann man dann stellen, damit das Projekt nicht das ursprünglich geplante Budget übersteigt? Gibt es aus der erfahrenen Praxis zu empfehlende Leitsätze zur Kostendeckelung in SAP-Projekten? Ganz klar: Ja! Die aus meiner Sicht praktikabelsten von Heute und eine darüber hinausgehende Vision zukünftiger Vorgehensweisen bei einer SAP-Implementierung werde ich in Kürze im nächsten Teil des Artikels darstellen.