Thema 5.1 — Projektgeführte Arbeit

In einem Satz: Projektgeführte Arbeit ist das richtige Werkzeug, wenn die Aufgabe einen definierten Umfang, eine endliche Dauer und einen klaren Endzustand hat – ein befristetes, kontrolliertes Vorhaben, geliefert nach vereinbarter Zeit, Kosten und Qualität und dann abgeschlossen.

Warum das in Gesundheit und Pflege wichtig ist#

Nicht alles ist ein lebender Dienst. Ein Teil der wichtigsten Arbeit in Gesundheit und Pflege ist wirklich endlich: die Migration von einer elektronischen Patientenakte zu einer anderen, die Einführung von WLAN über ein Krankenhausgelände, der Austausch von Servern am Ende ihrer Lebensdauer, die Stilllegung eines Altsystems, bevor ein Lieferantenvertrag endet, oder die Lieferung des digitalen Anteils eines Krankenhausneubaus. Diese Arbeit hat einen Anfang, eine Mitte und ein definitives Ende. Sie als offenes Produkt zu führen würde Geld verschwenden und Rechenschaft verwischen; sie braucht die Disziplin eines Projekts.

Projektmanagement verdient hier gerade deshalb seinen Platz, weil der Einsatz hoch und die Beschränkungen hart sind. Ein Cutover einer Datenmigration hat ein festes Go-live-Wochenende, ein Risiko für die Patientensicherheit, wenn Akten verloren gehen oder beschädigt werden, und eine vertragliche Klippe, wenn das alte System abgeschaltet wird. Öffentliches Geld ist gegen einen Business Case gebunden, und Parlament, Prüfer und Vorstände werden fragen, ob es wie genehmigt ausgegeben wurde. Projektgeführte Arbeit liefert die Governance – einen Business Case, Stage Gates und einen kontrollierten Abschluss –, die einem Vorstand erlaubt, Kapital mit Zuversicht zu binden und die Arbeit sauber zu beenden, wenn die Rechtfertigung wegfällt.

Die Gefahr ist, dieses Werkzeug für die falsche Aufgabe zu nutzen. Auf einen sich entwickelnden digitalen Dienst angewandte projektgeführte Governance erzeugt die in Thema 5.0 — Produktgeführte Arbeit beschriebene Pathologie „bauen und verlassen“. Dieses Thema erklärt, wo projektgeführte Arbeit das richtige Instrument ist und wo ihre Grenzen beginnen. Es steht neben Thema 5.2 — Programmgeführte Arbeit, das mehrere Projekte koordiniert, und Thema 5.3 — Enterprise-Projektportfoliomanagement (EPPM), das zwischen diesen Werkzeugen wählt.

Kernkonzepte#

Projekt. Eine befristete Organisation, geschaffen, um ein oder mehrere definierte Ergebnisse (Outputs) nach vereinbarter Spezifikation innerhalb von Beschränkungen aus Zeit, Kosten und Qualität zu liefern. Das definierende Merkmal ist, dass es befristet ist – es existiert, um ein definiertes Ende zu erreichen und sich dann aufzulösen.

Das eiserne Dreieck (Umfang, Zeit, Kosten). Das klassische Beschränkungsmodell: Umfang, Terminplan und Budget sind wechselseitig abhängig, und Qualität wird davon beeinflusst, wie sie ausbalanciert werden. Ändern Sie eines, ändern Sie die anderen; Projektsteuerung ist weitgehend die Disziplin, diesen Zielkonflikt transparent zu managen.

PRINCE2 (PRojects IN Controlled Environments). Die strukturierte Projektmethode der britischen Regierung, im NHS und öffentlichen Sektor weit verbreitet. Sie beruht auf Prinzipien (fortlaufende geschäftliche Rechtfertigung, definierte Rollen, Steuerung nach Phasen, Steuerung nach Ausnahmen, Fokus auf Produkte, aus Erfahrung lernen, an die Umgebung anpassen) und gliedert die Arbeit in kontrollierte Phasen, für die ein Projektvorstand die Richtung vorgibt.

PMI / PMBOK. Der Guide to the Project Management Body of Knowledge des Project Management Institute ist das dominierende internationale Gegenstück, das Projektarbeit um Leistungsdomänen und Prinzipien statt um einen vorgeschriebenen gestuften Prozess rahmt. PRINCE2 und PMBOK sind ergänzende Linsen auf dieselbe Disziplin.

Business Case. Das Dokument, das das Projekt rechtfertigt: das Problem, die bewerteten Optionen, der erwartete Nutzen, die Kosten und die Risiken. In PRINCE2 ist der Business Case lebendig – er wird an jeder Phasengrenze geprüft, und wenn die fortlaufende Rechtfertigung verschwindet, ist die richtige Entscheidung, aufzuhören. In britischen öffentlichen Stellen wird er meist nach dem Five Case Model des HM Treasury strukturiert (strategisch, wirtschaftlich, kommerziell, finanziell, Management).

Stage Gates. Ein PRINCE2-Projekt ist in Managementphasen gegliedert, die durch Entscheidungstore getrennt sind. An jeder Grenze trifft der Projektvorstand eine bewusste Stopp-/Weiter-Entscheidung: Er überprüft Fortschritt und Business Case, genehmigt den nächsten Phasenplan und bindet Ressourcen nur für diese Phase. So behält ein Vorstand die Kontrolle und vermeidet, gutem Geld schlechtes hinterherzuwerfen.

RAID-Log. Ein einziges Register von Risiken (Risks), Annahmen (Assumptions), Issues und Abhängigkeiten (Dependencies) – das zentrale Steuerungsartefakt der Projektleiterin. RAID macht Ungewissheit sichtbar und handhabbar: Risiken sind Dinge, die geschehen könnten, Issues sind Dinge, die geschehen sind, Annahmen sind das, worauf sich der Plan stützt, und Abhängigkeiten sind das, was der Plan von anderswo braucht.

Bewährte Praktiken#

1. Beginnen Sie mit einem ehrlichen Business Case und halten Sie ihn lebendig. Nutzen Sie eine anerkannte Struktur (das Five Case Model in britischen öffentlichen Stellen), um reale Optionen zu bewerten, nicht eine einzige vorbestimmte Antwort. Behandeln Sie den Business Case dann als lebendes Dokument, das an jedem Stage Gate überprüft wird – fortlaufende geschäftliche Rechtfertigung ist das erste PRINCE2-Prinzip, und sie zu verlieren ist ein legitimer Grund aufzuhören.

2. Definieren Sie den Umfang präzise und kontrollieren Sie Änderungen daran. Der Wert eines Projekts ist eine klare, begrenzte Definition von „fertig“. Vereinbaren Sie den Umfang, legen Sie ihn als Baseline fest und führen Sie jede vorgeschlagene Änderung durch einen Änderungskontrollprozess, damit Scope Creep nicht still Budget und Zeitplan verzehrt.

3. Steuern Sie nach Phasen mit echten Entscheidungstoren. Gliedern Sie die Arbeit in Managementphasen und halten Sie an jeder Grenze eine echte Stopp-/Weiter-Überprüfung ab. Ein Tor, das immer „weiter“ sagt, ist Theater; die Disziplin funktioniert nur, wenn Aufhören oder Neuplanen eine reale Option ist, die der Vorstand auch ausübt.

4. Führen Sie ein lebendes RAID-Log und eskalieren Sie nach Ausnahme. Pflegen Sie Risiken, Annahmen, Issues und Abhängigkeiten an einem Ort, überprüfen Sie sie regelmäßig und nutzen Sie das „Management by Exception“ von PRINCE2 – die Projektleiterin arbeitet innerhalb vereinbarter Toleranzen und eskaliert an den Vorstand nur, wenn eine Toleranz bedroht ist. So bleibt die Zeit der Leitung auf echte Entscheidungen konzentriert.

5. Weisen Sie klare Verantwortung an einzelne Personen zu. PRINCE2 besteht auf definierten Rollen: ein Projektvorstand mit einer leitenden Verantwortlichen/einem Executive, der den Business Case verantwortet, einer leitenden Nutzervertreterin, die diejenigen vertritt, die das Ergebnis nutzen werden, und einem leitenden Lieferantenvertreter. Mehrdeutige Rechenschaft ist die häufigste Ursache von Drift.

6. Planen Sie den Übergang in den Live-Betrieb, bevor Sie beginnen. Ein Projekt liefert einen Output; jemand muss ihn danach betreiben. Vereinbaren Sie das übernehmende Team, das Supportmodell und die Übergabe der klinischen Sicherheit (DCB0160 für den Einsatz) als Teil des Projekts, damit der Go-live keine Klippe in ein Verantwortungsvakuum ist.

7. Bauen Sie klinische Sicherheit, Informationsgovernance und Tests ein. Für jedes System, das Patientendaten berührt, sind der klinische Sicherheitsfall, die DPIA und Cutover-/Rollback-Tests keine optionalen Extras – sie sind Lieferergebnisse, die den Durchgang bestimmen. Eine Migration ohne getesteten Rollback-Plan ist nicht bereit für den Go-live.

8. Schließen Sie das Projekt bewusst ab und halten Sie Erkenntnisse fest. Ein definiertes Ende bedeutet einen definierten Abschluss: Bestätigen Sie, dass die Outputs abgenommen sind, übergeben Sie an den Betrieb, geben Sie das Team frei und halten Sie Lessons Learned fest (das Lessons Log von PRINCE2). Ein nicht abgeschlossenes Projekt lässt Ressourcen und Rechenschaft unbegrenzt versickern.

Fragen zur Diskussion im Team#

1. Ist die Arbeit vor uns wirklich endlich mit einem definierten Endzustand, oder greifen wir zu Projekt-Governance, weil es der Finanzierungsweg ist, den wir kennen? Das ist die entscheidende Frage, um die sich das Thema dreht, denn projektgeführte Disziplin ist nur dann das richtige Instrument, wenn die Aufgabe wirklich einen Anfang, eine Mitte und ein definitives Ende hat. In einer Organisation von Gesundheit und Pflege ist der Sog zur Projektform stark – Kapitalbudgetierung, Business-Case-Maschinerie und Vorstandsberichterstattung sind alle dafür gebaut –, sodass ein sich entwickelnder digitaler Dienst als Projekt verkleidet werden kann, einfach weil so Geld freigegeben wird, was dann die Pathologie „bauen und verlassen“ erzeugt. Die Debatte sollte jeden Kandidaten ehrlich prüfen: Der Ersatz eines Pathologiesystems, bevor ein Lieferant den Support einstellt, hat eine harte vertragliche Klippe und ist eindeutig endlich, während „die Patienten-App verbessern“ keinen Endzustand hat und in Thema 5.0 gehört. Bedenken Sie, ob es einen echten Go-live gibt, nach dem sich das Team auflösen sollte, oder ob jemand die Sache unbegrenzt weiterverbessern muss. Eine gute Antwort widersteht der Gewohnheit, Projekt-Governance zu nutzen, benennt den konkreten Endzustand und das Ereignis, das „fertig“ definiert, und ist bereit zu sagen, dass manches von dem, was wir derzeit als Projekte führen, nie ein Projekt hätte sein dürfen.

2. Würde dieser Vorstand an unseren Stage Gates tatsächlich ein Projekt stoppen oder neu planen, das seine Rechtfertigung verloren hat – und können wir auf einen Fall verweisen, in dem wir es taten? Stage Gates sind nur dann eine Kontrolle, wenn Aufhören eine echte Option ist, die der Vorstand ausübt; ein Tor, das immer „weiter“ sagt, ist Theater, und fortlaufende geschäftliche Rechtfertigung ist gerade deshalb das erste PRINCE2-Prinzip, weil ihr Verlust die Arbeit beenden sollte. Die Spannung in Gesundheit und Pflege ist akut: Eine halb gebaute EPR-Migration oder ein Cutover eines Laborsystems anzuhalten fühlt sich an wie das Eingeständnis eines Scheiterns, versunkener Kosten und Störung für Klinikpersonal, das seine Pläne schon geändert hat, sodass Vorstände das Weitermachen rationalisieren, während der Business Case still verdunstet. Bringen Sie ein reales Beispiel in die Diskussion – ein Projekt, bei dem Tests zeigten, dass das Risiko der Datenzuordnung schlimmer war als angenommen, oder bei dem Nutzen verrutschten – und fragen Sie, ob das Tor wie vorgesehen genutzt oder durchgewinkt wurde. Bedenken Sie, welche Toleranzen Eskalation auslösen, wer im Vorstand das Standing hat, einen Stopp zu rufen, und ob Versunkene-Kosten-Argumentation im Raum benannt und hinterfragt wird. Eine ehrliche Antwort räumt ein, wo Tore Formalitäten waren, beschreibt die Bedingungen, unter denen der Vorstand wirklich anhalten oder neu zuschneiden würde, und behandelt die Befugnis, vor einer öffentlichen Abschreibung zu stoppen, als den wahren Wert der Disziplin statt als Bedrohung.

3. Wer erhält den Output jedes Projekts als Live-Dienst, und wie machen wir die Übergabe der klinischen Sicherheit und die fortlaufende Verantwortung zu einem Lieferergebnis am Tor statt zu einer Klippe? Ein Projekt liefert einen Output; etwas Endliches endet, aber das, was es erzeugte, muss lange nach der Auflösung des Teams betrieben, verbessert und sicher gehalten werden – und das häufigste stille Versagen ist, dass auf der anderen Seite niemand es verantwortet. In einem System, das Patientendaten berührt, ist das keine administrative Ordentlichkeit: Der DCB0160-Sicherheitsfall des Einsatzes, die DPIA, ein getesteter Rollback und ein benanntes übernehmendes Team stehen zwischen einem kontrollierten Go-live und einem Verantwortungsvakuum, in dem sich Sicherheitsrisiken ungesteuert häufen. Die Debatte sollte Klarheit über den Übergang erzwingen, bevor das Projekt beginnt, nicht am Go-live-Wochenende: welches operative Team es übernimmt, wie das Supportmodell aussieht und ob dieses Team die Kapazität und Arbeitsweise (produktgeführt, nach Thema 5.0) hat, es weiter zu verbessern. Bedenken Sie konkrete jüngste Go-lives und ob die Übergabe geplant oder improvisiert war und ob „das Projekt ist fertig“ bedeuten durfte „und jetzt ist es niemandes Aufgabe“. Eine gute Antwort benennt von vornherein das übernehmende Team und das Supportmodell, behandelt die Sicherheitsübergabe als Tor, ohne das das Projekt nicht durchkommt, und weist die fortlaufende Verbesserung des Live-Dienstes ausdrücklich der richtigen Arbeitsweise zu, statt sie treiben zu lassen.

4. Wenn das eiserne Dreieck zubeißt und Umfang, Zeit und Kosten kollidieren, welche Beschränkung biegen wir, und darf Patientensicherheit je die Variable sein, die nachgibt? Jedes reale Projekt erreicht irgendwann den Moment, in dem Terminplan, Budget und zugesagter Umfang nicht alle halten können, und wie das Team diese Zange löst, zeigt, was es tatsächlich wertschätzt. In Gesundheit und Pflege ist die Falle besonders: Weil das Enddatum oft eine harte vertragliche Klippe ist – ein Lieferant, der den Support einstellt, ein auslaufender Mietvertrag, ein schließendes Rechenzentrum –, kann die Zeit häufig nicht bewegt werden, sodass der Druck still auf der Qualität landet, was in einem klinischen System heißt: Tests kürzen, Validierung verdichten oder mit bekannten Mängeln der Datenzuordnung ausliefern. Die Diskussion sollte im Voraus benennen, welche Ecke des Dreiecks die Organisation schützt und welche sie opfert, und ausdrücklich festhalten, dass klinische Sicherheit und Informationsgovernance nicht das Überdruckventil sind, auch wenn alles andere feststeht. Schauen Sie auf ein jüngstes Cutover und fragen Sie, was still nachgab, als die Termine hielten: die Rollback-Probe, das Fenster der klinischen Validierung, die Schulung? Bedenken Sie, wer die Befugnis hat, das Go-live-Datum zu verschieben, statt den Sicherheitsspielraum zu erodieren, und ob dieses Gespräch offen im Vorstand oder standardmäßig vor Ort geschieht. Eine ehrliche Antwort nennt die Prioritätenfolge vor der Krise, behandelt ein verrutschtes Datum oder eine neu geplante Phase als legitimes Ergebnis und weigert sich, ungesagten Zeitdruck in unprotokolliertes klinisches Risiko umzumünzen.

5. Ist unser RAID-Log ein lebendes Instrument, das verändert, was wir tun, oder ein Dokument, das wir pflegen, um gesteuert zu wirken – und würde es das Risiko sichtbar machen, das das Projekt tatsächlich versenkt? Ein RAID-Log verdient seinen Platz nur, wenn seine Durchsicht Entscheidungen verändert; die häufige Pathologie ist ein bei Kickoff geschriebenes, in Vorständen präsentiertes und nie wirklich beachtetes Register, während die Risiken, die zählen, unbeobachtet reifen. Bei einer Migration oder einem Cutover sind die entscheidenden Risiken oft spezifisch und erkennbar – historische Ergebnisse, die nicht sauber auf neue Referenzbereiche abgebildet werden, eine Abhängigkeit von den Firewall-Änderungen eines anderen Teams, eine Annahme, dass Ressourcen für klinische Validierung frei sein werden, wenn sie gebraucht werden –, und die Frage ist, ob das Log sie konkret benennt oder sich hinter generischen Einträgen wie „Ressourcenengpässe“ versteckt. Die Debatte sollte prüfen, ob Eskalation nach Ausnahme real ist: Arbeitet die Projektleiterin innerhalb vereinbarter Toleranzen und lenkt die Aufmerksamkeit des Vorstands nur, wenn eine bedroht ist, oder bleibt alles entweder still oder wird zur Krise? Bedenken Sie, ob Beinahe-Vorfälle und eingetretene Issues in die Planung der nächsten Phase zurückfließen oder nur protokolliert und vergessen werden. Eine gute Antwort kann auf eine Entscheidung verweisen, die das RAID-Log tatsächlich verändert hat, unterscheidet die zwei oder drei Risiken, die das Projekt wirklich stoppen könnten, vom langen Schwanz der kleinen und behandelt das Log als Arbeitskontrolle statt als für Assurance produziertes Artefakt.

6. Prüft nach unserem Abschluss und der Auflösung jemand, ob die Nutzen im Business Case tatsächlich eintraten – und würden wir es wissen, wenn nicht? Der Business Case verspricht Nutzen, um die Ausgaben zu rechtfertigen, doch projektgeführte Arbeit endet naturgemäß mit Go-live und Freigabe des Teams, sodass der Moment der Wahrheit – hat die Migration tatsächlich Risiko gesenkt, Kosten geschnitten oder Versorgung verbessert – meist nach dem Weiterziehen aller anfällt und niemand rechenschaftspflichtig ist, ihn zu bestätigen. Das ist in öffentlicher Gesundheit und Pflege besonders wichtig, wo Geld gegen einen Five-Case-Business-Case gebunden ist, von dem Parlament, Prüfern und Vorständen gesagt wurde, er werde bestimmte Ergebnisse liefern, doch Nutzenrealisierung ist der am häufigsten übersprungene Schritt, weil das Projekt, das sie verantwortet hätte, nicht mehr existiert. Die Diskussion sollte entscheiden, wer die Nutzenverfolgung erbt, wenn das Projekt schließt, über welchen Zeitraum und gegen welche Baseline-Messungen – die vor dem Go-live erfasst werden müssen, sonst gehen sie verloren. Bedenken Sie ein jüngst abgeschlossenes Projekt und fragen Sie unverblümt, ob seither jemand seine versprochenen Nutzen geprüft hat und ob ein Defizit den Vorstand, der es genehmigte, je erreichen würde. Eine ehrliche Antwort weist die Nutzenverantwortung nach Abschluss einer ständigen Funktion statt dem aufgelösten Team zu, erfasst die Baseline, solange das Projekt noch lebt, und ist bereit festzuhalten, dass ein Projekt seinen Output pünktlich und im Budget lieferte, aber nicht den Wert, der es rechtfertigte.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Akut-Trust muss sein alterndes Laborinformationsmanagementsystem für die Pathologie ersetzen, bevor der bisherige Lieferant den Support in 14 Monaten einstellt. Das ist Lehrbuch-Arbeit für projektgeführtes Vorgehen: festes Enddatum, definierter Umfang, eine harte vertragliche Klippe und akutes Risiko für die Patientensicherheit, wenn Ergebnisse bei der Migration verloren gehen.

Der Trust schreibt einen Five-Case-Business-Case, der drei Optionen bewertet (Upgrade an Ort und Stelle, Beschaffung eines neuen Systems, Mitnutzung einer regionalen Instanz), wählt die Beschaffung und richtet ein PRINCE2-Projekt mit klarem Vorstand ein: eine Executive, die den Business Case verantwortet, ein leitender Nutzer (der leitende Biomedizinische Wissenschaftler) und der leitende Lieferantenvertreter. Die Arbeit ist in Managementphasen gegliedert – Beschaffung, Aufbau und Konfiguration, Datenmigration, Tests und Go-live –, die jeweils in einem Entscheidungstor enden.

Die Projektleiterin führt ein RAID-Log. Ein zentrales Risiko ist, dass historische Ergebnisse nicht sauber auf die Referenzbereiche des neuen Systems abgebildet werden; eine Abhängigkeit sind die Firewall-Änderungen des Netzwerkteams; eine Annahme ist, dass Ressourcen für klinische Validierung für Tests verfügbar sind. Am Stage Gate der Migration zeigen Tests, dass das Risiko der Datenzuordnung schlimmer ist als angenommen, sodass der Vorstand das Tor wie vorgesehen nutzt: Er geht nicht blind weiter, sondern genehmigt eine neu geplante Phase mit verlängertem Validierungsfenster und getestetem Rollback-Plan und stellt die Patientensicherheit über den ursprünglichen Terminplan.

Der Go-live erfolgt an einem kontrollierten Wochenende, mit dem Rollback-Plan in Bereitschaft und einer Freigabe der klinischen Sicherheit nach DCB0160. Das System wird abgenommen, an das Betriebsteam übergeben, das es betreiben wird, Erkenntnisse werden protokolliert, und das Projekt wird formal abgeschlossen. Das Team löst sich auf – zu Recht, denn die Aufgabe ist wirklich erledigt. Was danach kommt (kontinuierliche Verbesserung des Live-Dienstes), ist eine andere Arbeitsweise, und der Trust achtet darauf, nicht ein volles Projektteam dauerhaft weiterlaufen zu lassen, um sie zu leisten.

Sektorperspektiven#

Startup#

Ein kleines Unternehmen der digitalen Gesundheit führt selten formale PRINCE2-Projekte durch, doch wirklich endliche Arbeit taucht dennoch auf – eine einmalige Datenmigration auf eine neue Cloud-Plattform, ein Vorstoß zu Cyber-Essentials- oder DTAC-Zertifizierung, Behebung von Pen-Test-Befunden vor einem großen NHS-Vertrag. Das Startup handhabt diese als leichtgewichtige, befristete Vorhaben mit benannter Verantwortlicher und klarer Definition von „fertig“ und borgt sich die Disziplin (fester Umfang, ein Enddatum, ein Go/No-go) ohne das Zeremoniell (kein formaler Projektvorstand, kein fünfstufiges Gating). Finanzierung ist eigentlich Aufmerksamkeit der Gründer und Runway, sodass das Risiko besteht, dass endliche Arbeit zwischen Produkt-Sprints eingeklemmt und nie wirklich abgeschlossen wird. Die Korrektur ist, eine einzelne Verantwortliche und eine harte Frist zu benennen und die Zertifizierung oder Migration als erledigt statt als ewig „in Arbeit“ zu behandeln.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder eine Einzelstandort-Klinik – begegnet projektgeführter Arbeit als gelegentlichen, aber unvermeidlichen Ereignissen: Wechsel des Lieferanten des klinischen Systems, Migration auf eine neue Praxismanagement-Plattform oder Ersatz von Geräten am Ende der Lebensdauer, bevor der Support endet. Die Organisation hat reale Patientinnen und laufenden Betrieb, aber keine dedizierte Projekt- oder IT-Funktion; das „Projektteam“ ist daher meist die Praxismanagerin oder eine eingetragene Leiterin, die das neben dem Tagesgeschäft erledigt und sich oft auf den neuen Lieferanten stützt, um die Migration durchzuführen. Die Disziplin, die den Kontakt mit dieser Realität überlebt, ist der leichtgewichtige Kern: ein klarer Endzustand, ein als Baseline festgelegter Umfang, damit der Lieferant ihn nicht still erweitert, eine benannte rechenschaftspflichtige Person und ein getesteter Rollback vor jedem Cutover, der Patientenakten berührt. Die Falle ist, nicht nur die Arbeit, sondern das Urteil auszulagern – das Go-live-Datum und die Zusicherungen des Lieferanten zur Datenzuordnung ohne unabhängige Prüfung zu akzeptieren –, denn dieselben Pflichten der klinischen Sicherheit und Informationsgovernance (DCB0160, eine DPIA) gelten, wie klein die Organisation auch ist. Die Korrektur ist, die Verantwortung für die Go/No-go-Entscheidung und die Abnahmekriterien im Haus zu behalten, auch wenn alle anderen helfenden Hände dem Hersteller gehören.

Großunternehmen#

Ein großer NHS Trust oder ein Integrated Care System (ICS) ist der Ort, an dem projektgeführte Arbeit am meisten zu Hause ist: EPR-Ablösungen, WLAN im ganzen Gelände, Rechenzentrumsausstiege und Cutover tragen alle harte vertragliche und patientensicherheitsrelevante Klippen. Hier ist der volle Apparat gerechtfertigt – ein Five-Case-Business-Case, ein PRINCE2-Vorstand mit benannter Executive/SRO, leitender Nutzerin und leitendem Lieferantenvertreter, Managementphasen mit echten Toren und ein lebendes RAID-Log –, weil die Summen groß, die Sicherheitsexposition akut sind und interne Revision und Vorstand die Ausgaben prüfen werden. Das charakteristische Versagen in dieser Größenordnung ist, dieselbe Governance unterschiedslos auf lebende Dienste (Thema 5.0 — Produktgeführte Arbeit) und auf endliche Arbeit anzuwenden; eine Portfolio-Sicht (Thema 5.3 — Enterprise-Projektportfoliomanagement (EPPM)), die jedes Stück Arbeit in die richtige Arbeitsweise leitet, ist daher wichtig. Klinische Sicherheit (DCB0160) und ein getesteter Rollback sind Lieferergebnisse am Tor, keine optionalen Extras.

Regierung#

Im nationalen oder Großprojekt-Maßstab sitzt projektgeführte Arbeit innerhalb des Assurance-Regimes der Regierung: Die Infrastructure and Projects Authority führt Gateway Reviews durch, das Green Book und das Five Case Model des HM Treasury steuern den Business Case, und die größten Projekte gelangen in das Government Major Projects Portfolio mit veröffentlichter Rechenschaft gegenüber dem Parlament und dem National Audit Office. Rechenschaft ist intensiv öffentlich – die leitende verantwortliche Person (SRO) ist persönlich rechenschaftspflichtig und kann vor einen Ausschuss geladen werden –, sodass Stage Gates und Optionsbewertungen Kontrolle auf gesetzlichem Niveau sind, kein Theater. Finanzierung wird tranchenweise gegen genehmigte Business Cases freigegeben, und die Risikobereitschaft ist gering, weil Scheitern zur Titelseite wird. Der wahre Wert der Disziplin liegt hier in der Befugnis, ein scheiterndes Projekt zu stoppen oder neu zuzuschneiden, bevor es zur öffentlichen Abschreibung wird.

Häufige Fehlermuster#

• Einen sich entwickelnden Dienst als Projekt managen. Fixer Umfang und Auflösung am Ende, angewandt auf ein lebendes digitales Produkt, erzeugt die Pathologie des Verlassens. Abhilfe: produktgeführte Arbeit (Thema 5.0) nutzen, wo der Dienst fortlaufend ist.
• Der Business Case als einmaliges Ticket zur Finanzierung. Einmal geschrieben, um Geld freizuschalten, dann nie wieder angesehen. Abhilfe: an jedem Stage Gate überprüfen; bereit sein aufzuhören.
• Durchgewinkte Stage Gates. Tore, die nie „Stopp“ sagen, bieten keine Kontrolle. Abhilfe: Aufhören oder Neuplanen zu einer echten Vorstandsoption machen und sie nutzen.
• Scope Creep ohne Änderungskontrolle. Unkontrollierte Ergänzungen sprengen Zeit und Kosten. Abhilfe: Umfang als Baseline festlegen und jede Änderung durch die Änderungskontrolle führen.
• Kein Plan für den Übergang in den Betrieb. Das Projekt endet, und niemand verantwortet den Output. Abhilfe: übernehmendes Team und Supportmodell vor dem Go-live vereinbaren.
• RAID als Aktenschrank. Ein Log, das geschrieben und nie beachtet wird. Abhilfe: RAID regelmäßig überprüfen und nach Ausnahme eskalieren.
• Nie wirklich abschließen. Zombie-Projekte, die Ressourcen ohne Ende verbrauchen. Abhilfe: ein bewusster Abschluss mit Abnahme, Übergabe und festgehaltenen Erkenntnissen.

Reifegradmodell#

Checkliste#

• Ist die Arbeit wirklich endlich mit definiertem Umfang und Endzustand (kein laufender Dienst)?
• Gibt es einen lebenden Business Case (Five Case Model), der an jedem Stage Gate überprüft wird?
• Ist der Umfang als Baseline festgelegt, mit einem funktionierenden Änderungskontrollprozess?
• Sind die Arbeitsphasen definiert, jede mit einem echten Stopp-/Weiter-Entscheidungstor am Ende?
• Sind die Rollen des Projektvorstands klar – Executive/SRO, leitende Nutzerin, leitender Lieferantenvertreter?
• Wird ein lebendes RAID-Log geführt, mit Eskalation nach Ausnahme?
• Sind klinische Sicherheit (DCB0160), DPIA und Cutover-/Rollback-Tests Lieferergebnisse am Tor?
• Sind das übernehmende Betriebsteam und das Supportmodell vor dem Go-live vereinbart?
• Gibt es einen bewussten Abschluss: Abnahme, Übergabe, Freigabe des Teams, Erkenntnisse protokolliert?
• Ist die fortlaufende Verbesserung des Live-Dienstes der richtigen Arbeitsweise zugewiesen worden?

Zentrale Quellen#

• AXELOS / PeopleCert — Managing Successful Projects with PRINCE2 (7. Auflage) und die PRINCE2-Prinzipien, -Themen und -Prozesse.
• Project Management Institute (PMI) — A Guide to the Project Management Body of Knowledge (PMBOK Guide) und The Standard for Project Management.
• HM Treasury — Guide to Developing the Project Business Case (das Five Case Model / Green Book).
• Infrastructure and Projects Authority (IPA), Cabinet Office — Leitlinien zu Assurance und Gateway Reviews für Großprojekte.
• NHS-Digital-Standard der klinischen Sicherheit DCB0160 (Einsatz von Gesundheits-IT-Systemen).
• NHS England — NHS Service Manual und Digital Service Standard (für Service-Übergang und Kontext der Nutzerbedürfnisse).

Referenzen#

1. Project management — Wikipedia — https://en.wikipedia.org/wiki/Project_management
2. PRINCE2 — Wikipedia — https://en.wikipedia.org/wiki/PRINCE2
3. Project management triangle (iron triangle) — Wikipedia — https://en.wikipedia.org/wiki/Project_management_triangle
4. Project Management Institute — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Institute
5. Project Management Body of Knowledge — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
6. Business case — Wikipedia — https://en.wikipedia.org/wiki/Business_case
7. Phase-gate process (stage gates) — Wikipedia — https://en.wikipedia.org/wiki/Phase-gate_process
8. Scope creep — Wikipedia — https://en.wikipedia.org/wiki/Scope_creep
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
11. HM Treasury — Wikipedia — https://en.wikipedia.org/wiki/HM_Treasury
12. Managing Successful Projects with PRINCE2 (7th edition) — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/PRINCE-2-1005
13. A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute — https://www.pmi.org/
14. The Green Book and Guide to Developing the Project Business Case (Five Case Model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
15. Assurance and gateway review guidance for major projects — Infrastructure and Projects Authority, Cabinet Office — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
16. Clinical risk management standard DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety