Erste-Hilfe-Konzept für PDMS-/KIS-Projekte in Not

Werden wir als Berater zu einer Klinik gerufen, weil es Schwierigkeiten mit einem PDMS- oder KIS-Projekt gibt, dann können die Gründe dafür endlos vielfältig sein: komplizierte Schnittstellen, ein komplexer, neuer Qualitätsvertrag, umfangreiche Probleme mit Performance oder Usability und so weiter.

Jede dieser Herausforderungen erfordert einen ganz eigenen Lösungsansatz — zugeschnitten auf das Problem, das Projekt, die Klinik und das sonstige Umfeld. Während wir diesen Ansatz allerdings erarbeiten, habe ich über die letzten Jahre festgestellt, dass wir immer dieselben Schritte gehen, um dem Projekt und der Klinik erst einmal die nötige Handlungsfähigkeit zu geben, die zum Bewältigen des Projekts gebraucht wird.

Dieser Artikel beschreibt diese ersten Schritte, mit denen wir jede Kooperation beginnen — nicht jede Klinik braucht jeden einzelnen Schritt, aber es gab noch kein Projekt, bei dem wir nicht mindestens einen Teil dieser ersten Mobilisierung angewandt haben.

Einer der unterhaltsamsten Momente in den meisten Projekten kommt für mich oft ganz zu Anfang: wenn ich in einem Kennenlernen mit dem Projektteam in großer Runde die ganz harmlose Frage stelle, welche Stationen und Bereiche denn eigentlich von dem Rollout/dem Projekt/der Änderung betroffen sind.

Es gibt in der Regel oft klare Hauptstationen, deren Involvierung keine Rolle spielt. Interessant wird es dann oft über die Bereichsgrenzen hinweg. Sollte die Anästhesie auch mit dem PDMS ausgestattet werden? Wie ist das eigentlich mit der Schmerzvisite? Wollten wir Visitenwagen beschaffen?

Die wenigsten Projekte, die in Schwierigkeiten stecken, fangen mit einem klaren, schriftlichen Arbeitsauftrag an alle Beteiligten an. Stattdessen werden sie oft spontan in Meetings verteilt, über eine E-Mail zugeteilt oder über drei Führungsebenen im Stille-Post-Verfahren an die betroffenen Personen herangetragen.

Das führt dazu, dass die Information, was denn nun eigentlich im Projekt zu bewerkstelligen ist, oft unvollständig und auf viele Schultern verteilt existiert.

Aus diesem Grund ist der erste Schritt für mich immer derselbe: die Frage, wer alle betroffenen Personen für ein Projekt sind.

Das sind direkte Projektteilnehmer, Manager, betroffenes Fachpersonal und andere Personen, die von dem Ergebnis abhängig sind. Fachsprachlich: die Stakeholder.

Während diese Informationen zusammengetragen werden, sehe ich mir alle Dokumente an, die ich über das Projekt finden kann. Ausschreibungsdokumente, Aufträge oder eventuell vorliegende Protokolle.

Auf dieser Grundlage entsteht für mich die Auftrags-Wahrheit des Projekts, die ich mit in das erste Meeting mit den Stakeholdern nehme. Deren Aussagen führen dann oft zu einem etwas anderen Gesamtbild, woraus der erste Auftrag entsteht: sicherstellen, dass sich alle Beteiligten über das Projektziel und den Umfang einig sind.

Ist der Umfang klar, dann steht die zwischenmenschlich komplizierteste — aber beinahe schon wichtigste — Aufgabe dieser Liste auf dem Programm: zu evaluieren, ob die Größe des Projektteams angemessen ist.

In einer perfekten, unkomplizierten Welt würde man für seine Fragen im Projekt eine einzelne Person ansprechen und immer eine akkurate, belastbare und offiziell tragbare Antwort bekommen. Da das leider nicht realistisch ist, bleibt unsere Mission dennoch klar: wir wollen so nah wie möglich an diesem perfekten Ideal bleiben.

Der Grund? Jede Person, die Teil des zentralen Projektteams ist, sollte für alle wichtigen Meetings, Entscheidungen und Pläne berücksichtigt werden. Ist dieser Kern zu groß, dann droht das Projekt schon an den einfachsten Entscheidungen und Meetings zu erlahmen, weil plötzlich tausend Interessen, Kalender und Urlaubspläne kollidieren.

Die schwierigste Hürde ist hierbei erfahrungsgemäß, wenn man Personen aus ihrer Pflicht der Projektteilnahme entbinden will, um die eigene und deren Zeit zu schonen.

Wichtig hierbei ist, im Hinterkopf zu behalten, dass ein Austreten aus dem zentralen Projektteam nicht bedeutet, dass die Person an Wichtigkeit oder Verbindung zum Projekt verlieren muss — eine solche Person kann noch immer als Stakeholder regelmäßige Reports erhalten und in größere Strategieberatungen involviert sein, ohne Teil jedes Projektteammeetings werden zu müssen.

Ein häufiger Grund für schleppenden Fortschritt selbst in den motiviertesten Teams ist oft die Tatsache, dass nicht genug aufgeschrieben wird.

Die Auswirkungen sind subtil: besprochene Sachverhalte müssen rekapituliert statt gelesen zu werden, einzelne Entscheidungen müssen mehrfach ausdiskutiert werden, und in regelmäßigen Meetings fehlt eine Grundlage für die Arbeiten und Abklärungen, die in der Zwischenzeit hätten erfolgen müssen.

Aus diesem Grund empfehle ich dringend zwei Festlegungen:

1. Wer wird wann und wie informiert?

Gerade wenn im Schritt zuvor das Team verkleinert wird, ist diese Festlegung eine wichtige Grundlage für ein vertrauensvolles Arbeiten miteinander. Mein Minimum ist, dass alle Teilnehmer und Interessenten Zugriff auf jedes Gesprächsprotokoll an einem zentralen Ort (Netzlaufwerk, Sharepoint, Confluence, …) erhalten. Zusätzlich kann vereinbart werden, dass wichtige Protokolle (z.B. die regelmäßigen Projektstandmeetings) per E-Mail an alle Stakeholder verteilt werden, um präsent zu sein.

Zusätzlich empfehle ich, das Auftauchen von neuen Protokollen im gemeinsamen Ablageort mit in die Tagesordnung der regelmäßigen Projektsitzungen zu nehmen, um jeden über neue Protokolle auf dem Laufenden zu halten.

2. Wie haben Protokolle auszusehen und wer erstellt sie?

Es gibt endlos viele Vorlagen und Philosophien hinsichtlich Projekten, weshalb ich gar nicht allzu viel darüber schreiben möchte, fest steht allerdings, dass ein gutes Protokoll mindestens das Datum, die Teilnehmer, die besprochenen Themen und herausgestellt die nächsten Schritte (wer und zu wann?) beinhaltet.

Zusätzlich sollte immer klar sein, wer ein Protokoll erstellt — je nach Umfeld kann das entweder eine Person treffen (ich würde viel meiner Karriere dem Sachverhalt zuschreiben, dass ich mich praktisch immer zum Schreiben des Protokolls bereit erklärt habe), oder man einigt sich darauf, dass die erste zu klärende Frage in jedem Meeting ist, wer das Protokoll führt.

Der finale Punkt liest sich beinahe wie eine Wiederholung des ersten, allerdings ist hier der Fokus ein anderer: haben wir im ersten Schritt den Fokus darauf gelegt, wer am Projekt beteiligt ist, so geht es jetzt darum zu ermitteln, was im Rahmen des Projekts umgesetzt werden muss.

Hierbei kann der Teufel oft im Detail liegen, denn die Aussage „Wir binden das Laborsystem an unser PDMS an“ bedeutet für praktisch jeden Mitarbeiter etwas völlig anderes. Deshalb kann ich nur dazu ermutigen, die Furcht davor abzulegen, offensichtliche Fragen zu stellen und immer ganz genau nachzufragen.

Wir arbeiten in einem komplexen Umfeld, in dem Aufträge, Projektanträge und selbst Ausschreibungen praktisch immer nicht das gesamte Bild transportieren, weshalb Justierungen im Projektverlauf und iterative Vorgehensweisen an der Tagesordnung sind.

Deshalb kann ich nur empfehlen, die Projektdokumentation bis hierhin als Absprungpunkt zu nehmen und dann mit allen Beteiligten möglichst detailliert auszuarbeiten, wie groß der Umfang der Ausarbeitungen ist. Es geht hierbei nicht darum, jeden einzelnen Button, jedes Blatt oder jeden Handgriff zu Papier zu bringen, aber zumindest die groben Aufwandstreiber müssen bekannt sein, damit man fair planen, verhandeln und das Projekt vorantreiben kann.

Hierbei muss man sich viel auf die Expertise der Projektteilnehmer und der eigenen Person verlassen — eine meiner Erfahrung nach hilfreiche Frage ist oft: „Und wo seht ihr bei diesem Thema Probleme?“. Damit lassen sich sehr oft Diskussionen vom Zaun brechen, die unerwartet tiefen Einblick in die kommenden Umsetzungen bieten können.

Sind all diese Dinge geregelt und gesichert, so ist der Erfolg des Projekts natürlich noch nicht garantiert, aber ein wichtiger, erster Schritt in die richtige Richtung ist damit erledigt. Und hat man einmal den Fuß auf den richtigen Weg gesetzt, dann ist jeder weitere Schritt oft einfacher als der vorangegangene.

Ich hoffe, dass Sie die in diesem Artikel erwähnten Schritte entweder gar nicht brauchen oder aber etwas für Ihren eigenen Projektalltag mitnehmen können.

Im Kern aller Aussagen steckt auch die Grundlage für jeden Projektmanager: Kommunizieren, Kommunizieren, Kommunizieren.

Wenn Sie als externer Berater oder Dienstleister mit an Bord sind, dann gleich doppelt.

Und natürlich wie immer: sollten Sie Fragen, Erfahrungsberichte oder emotionalen Zuspruch benötigen, dann scheuen Sie sich nicht, mich zu kontaktieren.

Herzlichst,