Deutliche Anzeichen, dass Ihr Cloud-Projekt in Schwierigkeiten ist

Jeder von uns hat seine Erfahrungen mit erfolgreichen und gescheiterten Softwareprojekten. Und jeder hat seine ganz persönliche Lieblingsstory. Aber für Softwareprojektmanager, egal ob Sie in einer Firma arbeiten oder als IT-Consultant tätig sind, gibt es überraschend wenig aktuelle Informationen über die Ursachen von Budgetüberschreitungen und Zeitplanverzögerungen. [...]

Managementberater werden Ihnen natürlich versichern, dass die Methoden der Berater solche Probleme lösen. Meistens werden die Berater ein 2-dimensionales Chart präsentieren, auf dem man sehen soll, wie deren Fachkenntnisse Ihre Firma auf den richtigen Weg bringen werden. Aber die Dinge sind nicht so einfach. Der Erfolg von Softwareprojekten ist von Dutzenden Faktoren abhängig.

Die Standish Group hat im Rahmen ihrer CHAOS-Studie, die sich mit den Erfolgs- und Misserfolgsfaktoren in IT-Projekten beschäftigt, 16 Jahre lang Analysen durchgeführt und kann eine deprimierende Konsequenz der Problembereiche und eine Rate der Projektfehlschläge aufzeigen. Die Daten beziehen sich besonders auf On-Premise-Software, Softwareerweiterungen und individuelle Programmentwicklung.

Leider ist es noch etwas zu früh um vernünftige Aussagen über Cloudprojekte zu treffen, ich werde aber trotzdem Dinge aus dem „150 Salesforce System“, das meine Firma entwickelt hat, analysieren.

NICHT FATALE PROBLEME
Ich beginne mit einer Liste von Dingen, die zum Erfolg oder Misserfolg von Cloudprojekten beitragen, aber keinen maßgeblichen Einfluss auf das Kosten/Zeit/Kundenzufriedenheits-Ergebnis von Cloudprojekten haben:

• Anforderungen, die zu keinem Verhältnis von Kosten oder Aufwand stehen. So etwas ist einfach Verschwendung, anders kann man es nicht sagen. Aber es verurteilt das Projekt meist nicht zum Scheitern.
• Unzureichende Ausbildung für ein bestimmtes System oder Programm sind ebenso ein Problem – gute Lernkurven sind oft schwer, aber es ist bloß eine einmalige Ausgabe wenn Sie die richtigen Leute haben.
• Was wirklich ein Problem ist, sind Programmier- oder Konfigurationsfehler vom Grundmodell oder von anderen Teilen des Codes, aber auch das ist meistens sehr einfach zu beheben weil die Fehler nicht systemweit sind. Man müsste schon eine gewaltige Anzahl derartiger Fehlern machen, um ein Projekt aus der Bahn zu werfen.
• Die mangelnde Bereitschaft den Fehler einzusehen und an alten Dingen festhalten, das ist ein Problem. Aber auch so etwas wird normalerweise das Budget nicht negativ beeinflussen.

PROBLEME, DIE BEHOBEN WERDEN KÖNNEN
Die nächsten Probleme haben eine größere Auswirkung, aber können hoffentlich erkannt – und korrigiert – werden, bevor das Projekt bereits zu weit fortgeschritten ist:

• Teammitglieder, die Kommunikationsprobleme haben. Achten Sie auf solche Dinge im Auswahlverfahren. Teammitglieder die keine guten Kommunikationsfähigkeiten haben, besonders wenn es ums Finden von Problemlösungen geht, sollten bereits im Auswahlverfahren erkannt werden. Das kann man mit entsprechenden Tests herausfinden.
• Teammitglieder die nicht mit dem Development-, Review- und Testteam mithalten können und Programmier/Konfigurations- und Integrationsfehler die mehrere Objekte und Cloudservices betreffen, werden zum Problem. Um solche Fehler zu beheben, benötigt jedes Teammitglied ein ausreichend technisches Verständnis und die verschiedenen Abteilungen müssen Hand in Hand zusammenarbeiten.
• Hier kann es nützlich sein, wenn man ein gemeinsame Dokumentationssystem hat. Agile Entwicklungstechniken sind ebenfalls nützlich. Man hat oft zu viele „B“-Player und zu wenig „A“-Player. Es gibt keinen Ersatz für talentierte und begabte Mitarbeiter. „B“-Players werden die Kosten erhöhen, egal wie klein die Kosten für solche Leute sind.
• Oft hat man schlechte Vorstellungen über die Arbeitsweise von Objekten und RDBMS (z.b. man denkt, dass Updates über mehrere Objekten einfach so passieren. Oder, dass deduping von Datenbanken von sich aus passiert). Das führt dann zu der falschen Annahme „natürlich wird das System auf mich aufpassen“.

PROBLEME, DIE MAN GLEICH LÖSEN MUSS
Die letze Kategorie von Problemen beinhaltet ernsthafte Probleme, die unbedingt identifiziert und korrigiert werden müssen, bevor das Projekt beginnt. Oftmals betrifft das ein „kleines Problem“, speziell im Bereich Kommunikation, Geschäftspolitik und Geschäftsprozesse:

• Ein Mangel an Verständnis über die Qualität und Bedeutung von bestehenden Datenquellen wird schnell zum Problem. Die Kosten für eine Datenbereinigung, Umwandlung und Integration hängen sehr von deren Umfang ab. Es ist sinnlos, wenn man Kosten- und Zeitrechnungen macht, aber keinen Zugang zu Detailfakten hat. Ebenso ist es wichtig, dass man Leute hat, die diese Fakten interpretieren können. Das kann schnell „politisch“ und kostspielig werden.
• Wenn das Management nicht die richtigen Personen für das Design, Erstellung von Prototypen und Implementierungs-/Entwicklungsstufen auswählt, treten Probleme auf. Das erste böse Erwachen passiert mit überraschender Häufigkeit dann, wenn man an einer „Mein Weg oder gar nicht“-Metalität festhält. Das ist eine schwache und falsche Managementcharakteristik.
• Führungskräfte neigen dazu, sich zu verhalten als wäre die Gewährung vom Budget ihre Verantwortung. In Wirklichkeit sind sie nur ein Teil von einem Prozess, der sich über verschiedene Abteilungen hinzieht. Wenn eine unaufmerksame Person für das Budget verantwortlich ist, ist er in etwa so gefährlich wie ein unaufmerksamer Autofahrer. Die Fähigkeit, Tatsachen oder schlechte Nachrichten früh genug zu erkennen und einen anderen Weg zu gehen, muss ein Leiter haben.
• Falls man immer „Ja“ oder „Kein Problem“ sagt, wird man schnell ein Problem haben. Wenn man davon ausgeht, die Verwaltung von Software sei wie Hardwareverwaltung, wird es ebenfalls Probleme geben.
• Es ist immer schlecht, wenn man die Entwicklung/Wartung von langfristigen Projekten mit großen, voneinander abhängigen, Teams durchführt, besser man hält Dinge klein, einfach und voneinander abgetrennt.
• Schreiben von schlecht definierten Anforderungen, oder die Angabe von nicht präzisesen Anforderungen. Oft werden Anforderungen ins Dokument geschrieben, die eigentlich keine Rolle spielen.
• Geschäftsvorgänge entwicklen sich sehr schnell, besonders wenn es eine große organisatorische Änderung gibt. Inbesondere bei Fusionen oder Veräußerungen können sich viele Vorgänge ändern. In solchen turbulenten Situationen sollten nur die wichtigsten Dinge gemacht werden, wie z.b. Systemwartungen. Geschäftsprozesse die unbekannt sind oder falsch beauftragt werden: Wir haben Fälle gesehen, in denen Führungskräfte Geschäftsabläufe festgelegt haben, die seit Jahren nicht mehr sinnvoll waren – oder es nie waren.

EINE TAKTIK ERSTELLEN
Sie denken wahrscheinlich, ich reite endlos lange auf dem selben herum. Nein, stattdessen werde ich eine Taktik erstellen.

Als ein Projektleiter müssen Sie sich jedes dieser Problemen beachten. Aber man kann nicht auf alle eventuellen Probleme vorbereitet sein. Daher müssen Sie Prioritäten setzen. Wargaming ist ein PR-„Tool“, dass beste Möglichkeiten zum Üben und priorisieren bietet.

Im ersten Teil der Übung müssen Sie die Top 5 identifizieren, die Ihr Projekt zum sicheren Scheitern verurteilen können – und welche Notfall- und Korrekturmaßnahmen es geben sollte. Im zweiten Teil sollen Sie die Top 3 finden, die Ihnen ernsthaftere Probleme machen könnten. Mit dieser zweiten Liste, setzen Sie sozusagen ein paar Kanarienvögel in die Kohlengrube – als Frühwarnsystem.

Eine normale Wargaming-Übung sollte nicht länger als eine Stunde dauern. Es sollte eine Simulation sein, die sowohl das Management als auch das Team mit einbezieht.

* David Taber ist der Author des Buches „Salesforce.com Secrets of Success“. Außerdem ist er der CEO von SalesLogistix.