HealthCare.gov-Lektion: Machen Sie Stakeholder zu den Hauptkontakten für die Eskalation von Problemen

Der verpfuschte Start der Registrierungsportal-Website des US-Bundesgesetzes über den Affordable Care Act brachte eine Reihe von Kommentaren darüber hervor, wie eine angemessene Überwachung des Projektmanagements (PM) hätte verhindern können, dass die meisten, unabhängig von ihrer politischen Zugehörigkeit, ein ziemlich massiver Fehler waren. Ich mischte mich ein und schlug vor, dass realistische Startpläne und ein festes Engagement für Tests geholfen hätten.

(Die Hauptportalseite des Bundes scheint viele seiner Probleme behoben zu haben, aber einige Berichte, wie dieser von Forbes, deuten darauf hin, dass das System möglicherweise immer noch Probleme mit der Weitergabe der Schlüsseldokumentation an Versicherungsunternehmen hat, die bis zu sechs Monate dauern können Entschlossenheit.)

Der Fall für einen einzigen Verantwortungspunkt

Andere Kommentatoren haben sich auf einen Bericht der Washington Post vom November 2013 gestützt, wonach in den Zentren des Ministeriums für Gesundheit und menschliche Dienste für Medicare und Medicaid, dem Hauptsponsor des Projekts, kein einziger Administrator "verantwortlich" war (wenn Sie tatsächlich einen "Hauptsponsor" identifizieren können Sponsor "im Morast einer so großen Bürokratie wie die Bundesregierung).

Diese Aufschlüsselung, so argumentieren diese Kommentatoren, spricht für einen einzigen Punkt der Projektverantwortung. Ein Artikel von Eric Thomas bei CIO Insight beschreibt die Funktionsstörung als "autoritätsdichte Umgebung" und legt nahe, dass ein formelles Programmverwaltungsbüro (PMO) oder ein anderer einzelner Ansprechpartner wahrscheinlich dazu beigetragen hätte, die sich überschneidende Bürokratie zumindest zu vermeiden bis zu einem gewissen Grad plagte das Projekt.

Der interessanteste Punkt im CIO Insight-Artikel ist, dass der Autor, ein Berater für Projekt- und Portfoliomanagement, sagt, dass dieser einzelne Punkt der PM-Autorität unabhängig vom Entwicklungsteam sein sollte. Dies ist selbst in mittelständischen Unternehmen eine weit verbreitete Praxis, obwohl PMs und QS-Ingenieure dazu neigen, sich auf die "technische" Seite des Gesamtprojekts zu konzentrieren - und daran ist nichts auszusetzen.

Einige sehr große Unternehmen haben PMOs für Unternehmen, die direkt an den COO oder sogar an den CEO berichten, aber diese Erhöhung der PM - obwohl ein beliebtes Thema unter PM-Autoren - ist immer noch ziemlich selten. Fast alle PMs melden sich immer noch über die IT-Abteilung und können daher dem politischen Druck ausgesetzt sein, Projektprobleme zu maskieren, genauso einfach, als würden sie dem Hauptentwickler Bericht erstatten. In kleineren Organisationen verschwimmen die Linien schnell, insbesondere wenn jeder etwa ein Dutzend Hüte trägt und der CTO Peer-Code-Überprüfungen durchführt, weil niemand anderes sie durchführen kann.

Daher sind die meisten PMs (und niemand anderes außer dem CEO) nicht wirklich "verantwortlich" für ein organisationsweites Projekt - solche Projekte sind zu groß und beinhalten zu viele Aspekte des Geschäfts, um so einfach vereinfacht zu werden. PMs bewerten, dokumentieren und verfolgen den Projektlebenszyklus (was für den Projekterfolg von entscheidender Bedeutung ist), aber das macht sie nicht "verantwortlich" dafür.

Wie der CIO Insight-Artikel feststellt, benötigen PMs einen klaren Eskalationspfad zu den Projektbeteiligten, wenn etwas offensichtlich nicht funktioniert. Programmmanager sollten jedoch nicht in eine Whistleblower-Rolle gezwungen werden - dies ist eine letzte Denkweise, die letztendlich die Beziehungen im Projektteam gefährdet.

Halten Sie die Stakeholder über Fortschritte und Einschränkungen auf dem Laufenden

Die beste Vorgehensweise besteht darin, sicherzustellen, dass die Stakeholder über den Projektfortschritt informiert bleiben, indem sie an regelmäßigen Statusbesprechungen und / oder einer Echtzeit-Projektkalendersoftware teilnehmen, die die Stakeholder der Branche intuitiv erhalten - etwas in der Art von Tom Planer oder Basislager. Diese Art des ständigen Kontakts und der klaren Übersicht über den Stand der Dinge wird hoffentlich verhindern, dass wichtige Themen zu einem Eskalationspunkt aufsteigen, oder den Ball vor Gericht Ihrer Stakeholder legen, um auf klare Probleme am Horizont zu reagieren.

In einer Kolumne, die ich vor ein paar Monaten geschrieben habe, schlug ich vor, dass ein Schlüsselmerkmal der Stakeholder von Nicht-IT-Projektteams die Bereitschaft ist, das Management auf C-Ebene wegen realistischer Projektbeschränkungen zurückzudrängen. Ich sollte diese Anforderung dahingehend ändern, dass ich bereit bin, zu rennen und dem Chef mitzuteilen, wenn etwas offensichtlich aus dem Ruder läuft. Diese Quelle der "Eskalation" ist weitaus effektiver als die roten Fahnen von PM.

Dies bedeutet nicht, dass PMs nicht befugt sein sollten, sich zu äußern, wenn sie feststellen, dass es ernsthafte Probleme mit einem Projekt gibt - sie sollten. Die harte Realität ist, dass eine Organisationskultur, die zu solchen "Momenten der Wahrheit" führt, Probleme hat, die solide PM-Methoden bei der Bekämpfung nur so weit bringen können.

Endeffekt

Viele PM-Fehler sind keine Unterlassungssünden durch schlechte PM-Praxis. Sie sind Sünden der Provision durch Rasenkriege und einfach nur alte Unternehmens-BS. Mein Bauch sagt mir, dass dies die wahre Geschichte hinter dem Startdebakel von HealthCare.gov ist.


© Copyright 2021 | mobilegn.com