Was uns Hertz vs. Accenture über Fehler in Systementwicklungsprojekten lehrt

Was uns Hertz vs. Accenture über Fehler in Systementwicklungsprojekten lehrt
Kürzlich wurden zwei der renommiertesten Unternehmen der Welt, The Hertz Corporation und Accenture LLP, verklagt, weil sie behaupteten, eines von ihnen habe die Erwartungen des Unternehmens nicht erfüllt. Ein weiterer während des Baus und der Lieferung eines neuen Computersystems. Obwohl in den Medien häufig von einer „neuen Website“ gesprochen wurde, handelte es sich bei dem neuen Computersystem, das in Betrieb genommen wurde, tatsächlich um eine neue digitale Plattform mit E-Commerce- und anderen Datenverarbeitungsfunktionen, auf der Hertz alle seine Geschäfte betreiben würde. und Marken. ganze Welt. . Auf den ersten Blick war das Projekt eine zeitgemäße Reaktion auf die wachsenden Erwartungen von Unternehmen und Privatpersonen, die mittlerweile in vielen Bereichen ihres beruflichen und privaten Lebens „Omnichannel“-Digitallösungen (zum Beispiel mobile Geräte) nutzen. Es war auch eine clevere Möglichkeit, die enormen Effizienzgewinne der Digitalisierung zu realisieren. Obwohl der Streit für beide Seiten etwas traurig ist, kann er uns doch an die Nachteile von Systementwicklungsprojekten im Allgemeinen und der Auslagerung von Systementwicklungsprojekten im Besonderen erinnern. Auf den ersten Blick deuten diese Behauptungen darauf hin, dass Unternehmen die Erfahrungen mit eklatanten Projektfehlschlägen offenbar nicht ausnutzen, von denen Unternehmen schon vor langer Zeit hätten lernen sollen. Selbst wenn die Anklage erfolgreich verteidigt wird, werden viele Organisationen auf der ganzen Welt die in dem Fall aufgeworfenen Probleme anerkennen. Im Jahr 2012 sagte McKinsey, dass „17 % der IT-Projekte so schlecht laufen, dass sie die Existenz der Gesellschaft gefährden.“ Na, was is los?

Werden Sie ein guter Käufer

Ein guter Käufer von ausgelagerten Systementwicklungsdiensten zu sein und während Projekten gut mit Anbietern zusammenzuarbeiten, sind wichtige Fähigkeiten für Unternehmen. Das Fehlen dieser Fähigkeiten erklärt jedoch mehr als jeder andere Faktor das Scheitern von Drittprojekten. Manche mögen argumentieren, dass Anbieter über alle notwendigen Fähigkeiten verfügen müssen, um ihre Projekte zum Erfolg zu führen, aber jedes Unternehmen, das sich ausschließlich auf die Fähigkeiten eines Anbieters verlässt, nimmt sein Vermögen in Geiselhaft. Wenn Sie kein „guter Käufer“ sind, bemerken Sie möglicherweise nicht, wenn der Lieferant und/oder das Projekt scheitert. Ein guter Einkäufer für externe Systementwicklung verfügt über hervorragende Kenntnisse, Verständnis und Erfahrung darüber, was, wann, warum und wie zu tun ist, wenn er Systementwicklungsprojekte definiert, plant, leitet, überwacht, kontrolliert und berichtet. Dies bedeutet nicht, dass sie dies alles tun werden: In vielen Projekten muss der Lieferant diese Prozesse ausführen, um dem Kunden zu helfen, sein Geschäftsziel zu erreichen (schließlich muss der Lieferant eine große Anzahl solcher Projekte abgeschlossen haben). ) – aber das bedeutet, dass der Kunde selbst wissen muss, was zu tun ist. Bei den meisten großen IT-Projekten ist Exzellenz im Programm- und Projektmanagement der entscheidende Erfolgsfaktor und nicht die Kenntnis der Technologie. Der Kontext, in dem dies zutreffen kann, ist insbesondere dann der Fall, wenn ein Projekt in einem Unternehmen (insbesondere einem globalen Unternehmen) ausgeführt wird; durch eine Gruppe von Kooperationspartnerschaften; oder im Namen eines zentralen Marktes und seiner Teilnehmer (z. B. einer Börse).

Bildnachweis: Pexels. (Bild: © Bildnachweis: Rawpixel / Pexels) Bei großen unternehmenskritischen Projekten sollten weder der Lieferant noch der Kunde einen Aspekt des Projekts isoliert durchführen, da dies das Risiko eines Scheiterns erhöhen würde. Es geht nicht nur um ein Bedürfnis nach Transparenz, sondern auch um ein Bedürfnis nach aktiver Kommunikation sowie einer aktiven Bestätigung und Verifizierung, dass Nachrichten empfangen und verstanden wurden (denken Sie an militärische Kommunikationsprotokolle). Vor dem Obersten Gerichtshof wegen totalem Scheitern eines Projekts funktionieren drei Verteidigungsmöglichkeiten nicht: (1) Ich war betrunken, (2) Ich dachte, der Kunde oder Verkäufer wüsste, was er tat, und (3) Ich dachte, der Kunde oder Verkäufer wüsste, was er tat , nicht ich. Wenn Sie der Kunde sind und nicht über alle erforderlichen Fähigkeiten und Erfahrungen verfügen, um wichtige Projekte zu definieren und zu steuern (was völlig verständlich ist, da sie in den meisten Unternehmen nicht häufig vorkommen), müssen Sie als Nächstes ein sehr erfahrenes Personal einstellen. Interimsverwalter, der in Ihrem Namen handelt, auch wenn der Anbieter noch mit der Projektleitung und anderen Aufgaben befasst ist. Sie können die Befugnis zur Verwaltung des Projekts an den Anbieter delegieren, aber Sie können die Verantwortung nicht delegieren. Die Verantwortung für das Projekt, einschließlich der Verantwortung für dessen Scheitern, liegt letztendlich bei Ihnen als Kunde. Ihr sehr erfahrener Interimsmanager kann die Verantwortung in Ihrem Namen delegieren, aber das bedeutet, dass er oder sie Ihr Stellvertreter wird und Sie dieser Person daher niemals die Schuld für irgendetwas geben können (z. B. auf die gleiche Weise, wie Sie dem Anbieter die Schuld geben könnten). Der Anbieter wird Ihr klares Denken über Verantwortung und Befugnisse zu schätzen wissen, denn für einen Anbieter gibt es nichts Schlimmeres als einen Kunden, der nicht in der Lage oder nicht bereit ist, die Verantwortung für eine wesentliche Verpflichtung zu übernehmen.

Bildnachweis: Shutterstock Bildnachweis: Shutterstock

Hertz gegen Accenture

Dies ist einer der überraschendsten Aspekte des Deals zwischen Hertz und Accenture: Ein Kunde scheint auf die Haftung im Falle eines Zahlungsverzugs eines Lieferanten zu verzichten. Aus einigen Fallbeispielen: „Hertz entschied sich letztendlich für Accenture und nutzte dessen weltweit anerkannte Expertise in der Entwicklung von Websites und mobilen Apps.“ Cavtor Emptor, mein lieber Junge, Vorbehalt Emptor. Es liegt in der Verantwortung des Kunden, etwaige Ansprüche des Anbieters zu überprüfen. „Hertz hat Monate damit verbracht, das Projekt zu planen …“ legten die Ziele und die Strategie für ihr digitales Geschäft fest und entwickelten eine Roadmap ...“ Dies ist keine gute Praxis, wenn das wahr ist (obwohl Aussagen im Beschwerdeteil der Klage darauf hindeuten, dass Accenture diese Arbeit tatsächlich durchgeführt hat). Beauftragen Sie kein großes professionelles Dienstleistungsunternehmen, sondern planen Sie das Projekt für dieses. Sie wissen viel mehr über die Definition, Planung und Durchführung dieser Art von Projekten als jeder andere Kunde. Arbeiten Sie stattdessen mit ihnen zusammen, um die Probleme zu identifizieren und zu validieren, die Sie mit diesem Projekt für sich und Ihre Kunden lösen möchten. Bewerten Sie mögliche Lösungen und berichten Sie über potenzielle Kandidaten. Testideen und Prototypen für diese Optionen; Erhalten Sie zu jedem Punkt Kundenfeedback; wähle eine Lösung; und modifizieren Sie aktiv Ihre Ideen und Entwürfe für diese Lösung basierend auf dem Kundenfeedback während des Projekts. Wenn Sie am Ende den Eindruck erwecken, Sie hätten es am ersten Tag getan, dann haben Sie sich geirrt. Alle Ideen müssen sich weiterentwickeln. „Hertz beauftragte Accenture mit der Leitung des Projekts und der Erstellung einer Website und Anwendungen, die den Anforderungen von Hertz entsprechen.“ Kunden können die Verantwortung für den Erfolg eines Projekts nicht delegieren, sie können jedoch die Befugnis delegieren, ein Projekt zu leiten. Diese delegierte Befugnis bedeutet jedoch, dass der Kunde die Verantwortung für das Projekt behält, was bedeutet, dass er in jeder Phase des Prozesses (nicht nur am Ende) bestätigen kann, dass er ordnungsgemäß vorgeht. Wenn es den Anschein hat, als würde ich den Kunden die Schuld geben, denken Sie daran, dass ein guter Anbieter etwaige Missverständnisse auf Seiten des Kunden erkennen, es melden und ihn bitten sollte, seine eigenen Interessen zu wahren (was auch zum Vorteil des Anbieters ist). . „Ohne das Wissen oder die Zustimmung von Hertz hat Accenture die Skalierbarkeitsanforderung bewusst ignoriert und den Code so geschrieben, dass er spezifisch für die Marke Hertz in Nordamerika und unbrauchbar ist. für die globale Marke Hertz und die Marken Dollar und Thrifty.“ Der informierte Leser wird wissen, dass die dritte Regel der Systementwicklung darin besteht, dass es für jede Anforderung einen gültigen Beweis geben muss, einen Beweis, den der Kunde unterzeichnen muss; Ergebnisse, die den Fall beweisen sollten; und Ergebnisse, die der Klient verstehen und akzeptieren kann (oder auch nicht). Kann der Kunde durch den Einsatz des vereinbarten Tests nicht schnellstmöglich feststellen, ob seine Anforderungen erfüllt sind, muss ein anderer Test abgeleitet werden. Wenn es keinen Nachweis für diese Anforderung gibt, müssen beide Parteien die Verantwortung übernehmen: der Kunde dafür, dass er nicht von seiner Verantwortung entbunden wird, alles zu validieren, was im Rahmen des Projekts getan wird, und der Lieferant dafür, dass er ihn nicht in die Lage versetzt, alle Anforderungen zu validieren . „Accenture hat viele Komponenten des Systems nicht getestet. Als Accenture die Tests durchführte, waren sie völlig unzureichend und sogar irreführend. „Lieferanten sind zunehmend bereit, ihre Produkte selbst zu testen. Führen Sie sogar Benutzerakzeptanztests im Auftrag des Kunden durch, d. h. beziehen Sie Benutzer nicht in ihre eigenen Tests und Genehmigungen ein. Es ist verrückt. Objektivität beim Testen ist alles. Kunden und andere Subunternehmer und Lieferanten von Kunden müssen neue Software und Systeme testen, nicht Entwickler.

Bildnachweis: Pixabay. (Bild: © Bildnachweis: Pixabay)

Fehlende Kommunikation

Leider ist keiner der wahrgenommenen oder angeblichen Mängel in diesem Fall neu oder einzigartig. Am Ende ist das Scheitern eines Projekts immer auf das Versagen von Menschen zurückzuführen, insbesondere auf die Unfähigkeit von Menschen zur Kommunikation. Diese Kommunikationsfehler sind selten oder nie auf ein grundlegendes Maß wie etwa eine schwache Intelligenz zurückzuführen. Stattdessen mangelt es ihnen im Allgemeinen an Erfahrung, Wissen und Fähigkeiten. Zu viele Leute, die an Systementwicklungsprojekten beteiligt sind, wissen nicht, wie sie Systementwicklungsprojekte definieren und ausführen sollen. So einfach ist das. Im Allgemeinen wissen sie, wie eine der erforderlichen Aufgaben zu erledigen ist. Noch wichtiger: Sie wissen nicht, wie sie an solchen Projekten arbeiten sollen. Sie wissen nicht, wie das alles zusammenpasst. Wenn eine große Anzahl von Personen, die an einem globalen Projekt beteiligt sind, nicht konsistent und korrekt über die Definition, Planung, Verwaltung, Überwachung, Kontrolle und Berichterstattung von Systementwicklungsprojekten Dritter sprechen können, besteht ein ernsthaftes Risiko des Scheiterns. Sogar Probleme wie die Nichteinhaltung von Sicherheitsvorschriften sind auf Mängel in diesen Bereichen des Projekt- und Programmmanagements zurückzuführen (da ein gut durchgeführtes Projekt- und Programmmanagement die Programmumsetzung nicht ermöglicht hätte). Eine Kodierung findet nicht statt). Wenn Sie ein Thema dieser traurigen Geschichte entdecken, werden Sie feststellen, dass bei allen gescheiterten Drittprojekten sowohl der Kunde als auch der Lieferant scheiterten. Nie absichtlich, oft unvorsichtig, manchmal unbewusst, sondern immer beides. Bedenken Sie auch, dass alle Fehler mit mehr Wissen und/oder besserer Beratung hätten vermieden werden können. Cliff Moyce, Vorsitzender des DataArt Advisory Board