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. Eine andere während des Aufbaus und der Lieferung eines neuen Computersystems. Obwohl die Medien viel über eine "neue Website" gesprochen haben, war das neue Computersystem, das in Betrieb genommen wurde, tatsächlich eine neue digitale Plattform mit E-Commerce und anderen Datenverarbeitungsfunktionen, auf denen Hertz alle seine Unternehmen und Marken betreiben würde. ganze Welt. .
Auf den ersten Blick war das Projekt eine rechtzeitige Antwort auf die wachsenden Erwartungen von Unternehmen und Einzelpersonen, die jetzt in vielen Bereichen ihres beruflichen und privaten Lebens digitale Omnichannel-Lösungen (z. B. mobile Geräte) einsetzen. Es war auch eine clevere Möglichkeit, die enormen Effizienzvorteile der Digitalisierung zu realisieren. Obwohl der Streit für beide Seiten eine traurige Sache ist, kann er dazu dienen, uns an die Nachteile von Systementwicklungsprojekten im Allgemeinen zu erinnern und Systementwicklungsprojekte im Besonderen auszulagern.
Auf den ersten Blick deuten diese Behauptungen darauf hin, dass Unternehmen nicht von den Erfahrungen eklatanter Projektfehler zu profitieren scheinen, die Unternehmen vor langer Zeit hätten lernen müssen. Selbst wenn die Anklage erfolgreich verteidigt wird, werden viele Organisationen auf der ganzen Welt die in diesem Fall aufgeworfenen Fragen anerkennen. Im Jahr 2012 sagte McKinsey, dass "17% der IT-Projekte so schlecht laufen, dass sie die Existenz der Gesellschaft bedrohen können." Na, was is los?
Werden Sie ein guter Käufer
Ein guter Käufer von ausgelagerten Systementwicklungsdiensten und eine gute Zusammenarbeit mit Anbietern während der Projekte sind wichtige Fähigkeiten für Unternehmen. Das Fehlen dieser Fähigkeiten erklärt jedoch mehr als jeder andere Faktor das Scheitern von Projekten von Drittanbietern. Einige mögen argumentieren, dass Lieferanten ü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 Lieferanten verlässt, hält Vermögen als Geisel. Wenn Sie kein "guter Käufer" sind, wird dies möglicherweise nicht bemerkt, wenn der Lieferant und / oder das Projekt fehlschlagen.
Ein guter Käufer für die externe Systementwicklung verfügt über ausgezeichnete Kenntnisse, Kenntnisse und Erfahrungen darüber, was wann, warum und wie zu tun ist, wenn Systementwicklungsprojekte definiert, geplant, geleitet, überwacht, gesteuert und gemeldet werden. Dies bedeutet nicht, dass sie all dies 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 eine hervorragende Programm- und Projektverwaltung der entscheidende Faktor für den Erfolg und nicht das Wissen über die 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).
(Bild: © Bildnachweis: Rawpixel / Pexels)
Bei großen kritischen Projekten sollten weder der Lieferant noch der Kunde einen Aspekt des Projekts isoliert ausführen, da dies das Ausfallrisiko erhöhen würde. Es ist nicht nur ein Bedürfnis nach Transparenz, es ist ein Bedürfnis nach aktiver Kommunikation sowie nach aktiver Bestätigung und Überprüfung, ob Nachrichten empfangen und verstanden wurden (denken Sie an militärische Kommunikationsprotokolle).
Im High Court des Totalausfalls des Projekts funktionieren drei Abwehrmechanismen nicht: (1) Ich war betrunken, (2) ich dachte, der Kunde oder Lieferant wüsste, was es tat, und (3) ich dachte, der Kunde oder Lieferant tat es Ich tat es, nicht ich. Wenn Sie der Kunde sind und nicht über alle Fähigkeiten und Erfahrungen verfügen, um wichtige Projekte zu definieren und zu steuern (was vollkommen verständlich ist, da sie in den meisten Unternehmen nicht häufig vorkommen), sollten Sie ein sehr erfahrenes Personal einstellen. Stellvertretender Administrator, der in Ihrem Namen handelt, auch wenn der Anbieter sich noch mit dem Projektmanagement und anderen Aufgaben befasst. Sie können die Befugnis zum Verwalten 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, dem Kunden. Ihr sehr erfahrener Interim Executive kann in Ihrem Namen delegierte Verantwortung übernehmen, aber das bedeutet, dass er oder sie Ihr Vertreter wird und Sie diese Person daher niemals für irgendetwas verantwortlich machen können (zum Beispiel auf die gleiche Weise, wie Sie dem Anbieter die Schuld geben könnten). Der Lieferant wird Ihnen für Ihre Klarheit beim Nachdenken über Verantwortung und Autorität danken, da es für einen Lieferanten nichts Schlimmeres gibt als einen Kunden, der nicht in der Lage oder nicht bereit ist, Verantwortung für ein sinnvolles Engagement zu übernehmen.
Bildnachweis: Shutterstock
Hertz gegen Accenture
Dies ist einer der überraschendsten Aspekte des Geschäfts von Hertz gegen Accenture: Ein Kunde scheint im Falle eines Lieferantenausfalls auf seine Haftung zu verzichten. Aus einigen Beispielen des Falles:
"Hertz entschied sich letztendlich für Accenture und nutzte seine weltbekannte Erfahrung in der Entwicklung von Websites und mobilen Anwendungen."
Cavtor Emptor mein lieber Junge, Caveat Emptor. Es liegt in der Verantwortung des Kunden, die Ansprüche eines Lieferanten zu validieren.
"Hertz hat Monate damit verbracht, das Projekt zu planen ... die Ziele und die Strategie für sein digitales Geschäft festzulegen und eine Roadmap zu entwickeln ..."
Dies ist keine gute Praxis, wenn dies zutrifft (obwohl die Aussagen im Beschwerdeabschnitt der Klage darauf hindeuten, dass Accenture diese Arbeit tatsächlich ausgeführt hat). Stellen Sie keine große professionelle Dienstleistungsfirma ein, planen Sie das Projekt für sie. 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 mögliche Kandidaten. Testideen und Prototypen für diese Optionen; Erhalten Sie an jedem Punkt Kundenfeedback. wähle eine Lösung; und ändern Sie aktiv Ihre Ideen und Designs für diese Lösung basierend auf Kundenfeedback während des Projekts. Wenn Sie am Ende die Idee haben, dass Sie den ersten Tag hatten, haben Sie sich geirrt. Alle Ideen müssen sich weiterentwickeln.
"Hertz vertraute darauf, dass Accenture das Projekt leitet und eine Website und Anwendungen erstellt, die den Anforderungen von Hertz entsprechen."
Kunden können die Verantwortung für den Erfolg eines Projekts nicht delegieren, aber sie können die Befugnis zur Leitung eines Projekts delegieren. 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 so vorgeht, wie er sollte. Wenn es so aussieht, als würde ich den Kunden die Schuld geben, denken Sie daran, dass ein guter Lieferant Missverständnisse des Kunden erkennen, melden und ihn bitten sollte, seine eigenen Interessen zu schützen (was auch zum Vorteil des Lieferanten ist). .
"Ohne das Wissen oder die Genehmigung von Hertz hat Accenture die Skalierbarkeitsanforderungen absichtlich ignoriert und den Code so entworfen, dass er spezifisch für die Marke Hertz in Nordamerika ist und nicht für die globale Marke Hertz sowie die Marken Dollar und Thrifty verwendet werden kann."
Der informierte Leser wird wissen, dass die dritte Regel der Systementwicklung lautet, dass es für jede Anforderung einen gültigen Test geben muss, einen Test, den der Kunde unterschreiben muss. Ergebnisse, die den Fall beweisen sollten; und Ergebnisse, die der Kunde verstehen und akzeptieren kann (oder nicht). Wenn der Kunde anhand des vereinbarten Tests nicht so schnell wie möglich feststellen kann, ob seine Anforderungen erfüllt wurden oder nicht, sollte ein weiterer Test abgeleitet werden. Wenn es keinen Beweis für diese Anforderung gibt, müssen beide Parteien die Verantwortung übernehmen: Der Kunde, der nicht von seiner Verantwortung entbunden wurde, alles zu validieren, was im Projekt getan wird, und der Lieferant, der ihn nicht in eine Position gebracht hat, die die Validierung aller ermöglicht Anforderungen.
"Accenture hat nicht viele Systemkomponenten getestet. Als Accenture die Tests durchführte, waren sie ernsthaft unzureichend und irreführend."
Lieferanten sind zunehmend bereit, ihre eigenen Produkte zu testen. Führen Sie auch Benutzerakzeptanztests im Auftrag des Kunden durch, dh 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 Kundenanbieter sollten neue Software und Systeme testen, nicht Hersteller. Und diese Tester müssen in der Lage sein, Software zu nutzen, und müssen sich nicht gezwungen fühlen, die Arbeit ihrer Kollegen zu validieren.
(Bild: © Bildnachweis: Pixabay)
Fehlende Kommunikation
Leider ist keiner der in diesem Fall wahrgenommenen oder angenommenen Mängel neu oder einzigartig. Am Ende ist das Scheitern eines Projekts immer auf das Versagen der Menschen zurückzuführen, insbesondere auf die Unfähigkeit der Menschen, zu kommunizieren. Diese Kommunikationsfehler sind selten oder nie auf eine grundlegende Maßnahme wie schwache Intelligenz zurückzuführen. Stattdessen mangelt es ihnen im Allgemeinen an Erfahrung, Wissen und Fähigkeiten. Zu viele Personen, die an Systementwicklungsprojekten beteiligt sind, wissen nicht, wie sie Systementwicklungsprojekte definieren und ausführen sollen. So einfach ist das. Im Allgemeinen wissen sie, wie man eine der erforderlichen Aufgaben erledigt. Noch wichtiger ist, dass sie nicht wissen, wie sie an solchen Projekten arbeiten sollen. Sie wissen nicht, wie das alles zusammen passt.
Wenn eine große Anzahl von Personen, die an einem globalen Projekt beteiligt sind, nicht konsistent und korrekt über die Definition, Planung, Verwaltung, Überwachung, Steuerung und Berichterstattung von Systementwicklungsprojekten von Drittanbietern sprechen können, besteht ein ernstes Ausfallrisiko. Selbst Probleme wie die Nichteinhaltung des Sicherheitscodes resultieren aus Mängeln in diesen Bereichen des Projekt- und Programmmanagements (weil ein gut gemachtes Projekt- und Programmmanagement die Umsetzung des Programms nicht ermöglicht hätte). Codierung findet nicht statt).
Wenn Sie ein Thema aus dieser traurigen Geschichte entdecken, werden Sie feststellen, dass bei allen Projektfehlern von Drittanbietern sowohl der Kunde als auch der Lieferant versagt haben. Niemals absichtlich, oft ohne Vorsicht, manchmal unbewusst, aber immer beides. Denken Sie auch daran, dass alle Fehler mit mehr Wissen und / oder besseren Ratschlägen hätten vermieden werden können.
Cliff Moyce, Vorsitzender des DataArt-Beirats
