Projektmanager als Vermittler: Die Kommunikationsbarriere zwischen Business und Technik

Für eine bereits bestehende Lösung, wollte ein Kunde Tausende von Dollar ausgeben: Die Implementierung einer API für einen Überwachungsdienst eines Drittanbieters, der mehrere Tausend Euro pro Jahr kosten würde. Als unser Projektmanager nachfragte, welche Anforderungen dahintersteckten, stellte sich heraus: Das Team sammelte bereits intern alle benötigten Metriken, der Kunde brauchte nur einen benutzerfreundlichen Weg, um sie abzurufen. Unter Verwendung der vorhandenen Daten erstellten wir ein maßgeschneidertes Dashboard, das dieselben Erkenntnisse zu einem Bruchteil der Kosten und ohne wiederkehrende Gebühren lieferte. Diese Lösung gab den Managern einen direkten Einblick in die Stabilität der Zahlungsströme, eine wichtige Geschäftsinformation, die sie benötigten, und nutzte dabei die Daten, die sie bereits gesammelt hatten.

Dieses Szenario veranschaulicht den Kern des Projektmanagements: Die wichtige Rolle der technischen Vermittlung. Jeden Tag erleben Projektmanager, wie Stakeholder in Meetings von ihren neuesten Ideen für Features schwärmen, während die Entwicklungsteams schweigend dasitzen und mit gerunzelter Stirn an die technische Komplexität denken, die die Stakeholder jedoch nicht sehen können. Es ist an der Zeit, diesen Umstand zu ändern.

Die grundlegende Diskrepanz in der Wahrnehmung von Erfolg zwischen Managern und Entwicklerteams ist in Unternehmen auf der ganzen Welt zu beobachten. Denken Sie zum Beispiel an den typischen Ablauf eines Projekts: Die Stakeholder konzentrieren sich auf das Markt-Timing und die Rendite und verfolgen den Fortschritt anhand von vierteljährlichen Indikatoren sowie Terminen für die Fertigstellung von Funktionen. Im Mittelpunkt stehen dabei immer der Wettbewerbsvorteil und die Kundenzufriedenheit. Die Entwicklungsteams konzentrieren sich derweil auf die Systemstabilität, die Wartbarkeit des Codes und die technischen Schulden. Sie messen den Erfolg anhand von Leistungsmetriken und architektonischer Nachhaltigkeit – Faktoren, die für das Management oft unsichtbar sind, bis etwas schiefgeht.

Diese Diskrepanz kostet viel Zeit und Geld. So könnte die überstürzte Einführung einer neuen Funktion durch ein Geschäftsteam zu einer übertechnisierten Lösung führen, die das Dreifache des veranschlagten Budgets kostet. Ein scheinbar einfaches Update des Kundenportals könnte zu vielen Supportanrufen führen, sodass das Supportteam übermäßig belastet wird, da 50 % des Anrufvolumens auf eine unklare Benutzeroberfläche und nicht auf fehlende Funktionen zurückzuführen sind. Selbst wenn die Funktionen einwandfrei funktioniert hätten, habe ich erlebt, dass Geschäfte Monate damit verschwendet haben, komplexe Lösungen zu implementieren, obwohl es einfachere Alternativen gegeben hätte.

Die Herausforderung besteht nicht darin, dass eine der beiden Seiten Unrecht hat, sondern dass beide Seiten Recht haben, aber unterschiedliche Sprachen sprechen. Um diese Kluft zu überbrücken, müssen beide Perspektiven auf nicht konkurrierende Art und Weise berücksichtigt werden, was wiederum eine Änderung des Blickwinkels erfordert – diese Perspektiven stehen nicht a priori in Konkurrenz zueinander. Wir werden sehen, ob das machbar ist.

Bei einer effektiven technischen Mediation geht es darum, Geschäftsprobleme zunächst tiefgreifend zu verstehen, bevor man sich auf Lösungen stürzt. Ein weiteres Beispiel aus unserer Praxis: Ein Geschäftsteam bat um eine „einfache“ Funktionserweiterung für das Kundenportal. Die vorgeschlagene Lösung hätte jedoch erhebliche Änderungen erfordert. Anstatt jedoch sofort technische Anforderungen zu erstellen, wandte der Projektmanager die 5-Why-Technik an:

F: „Warum brauchen Sie diese Funktion?“
A: „Um den Kunden zu helfen, ihre Bestellungen zu verfolgen.“
F: „Warum ist die derzeitige Auftragsverfolgung unzureichend?”
A: „Die Kunden rufen ständig wegen der Lieferzeiten beim Support an.“
F: „Warum rufen sie an, obwohl sie Tracking-Nummern haben?“
A: „Sie können die zu erwartenden Verzögerungen oder Probleme nicht leicht erkennen.“

Und da haben wir es - nach bereits drei Fragen. Nicht das Fehlen von Funktionen war das Problem, sondern die Zugänglichkeit. Anstelle einer komplexen Überarbeitung wurde das Kernproblem durch gezielte UX-Verbesserungen an der bestehenden Schnittstelle gelöst. Innerhalb weniger Wochen nach der Einführung gingen die Supportanfragen zur Lieferverfolgung um 50 % zurück. Das verbesserte sowohl die Kundenzufriedenheit als auch die Effizienz des Teams.

Erfolgreiche technische Mediatoren setzen bestimmte Techniken ein, um einen produktiven Dialog zu führen:
 
Meetingstruktur:

Beginnen Sie jede Diskussion über eine Funktion mit der Aussage: „Heute werden wir uns darauf konzentrieren, das Problem zu verstehen, nicht Lösungen zu diskutieren.“ Mit dieser einfachen Aussage verlagert sich das Gespräch vom „Wie“ zum „Warum“.
 
Erstellung einer Problemdokumentationsvorlage:
 

• Geschäftsauswirkungen: Welche Kosten oder Probleme verursacht das Problem?
• Betroffene Benutzer: Wer ist von diesem Problem direkt betroffen?
• Aktuelle Umgehungslösungen: Wie wird das Problem heute gelöst?
• Erfolgsmetriken: Woran werden wir erkennen, dass wir das Problem gelöst haben? 

Übersetzung des technischen Kontextes:

Wenn Entwickler technische Bedenken äußern, helfen Sie, diese in geschäftliche Auswirkungen zu übersetzen:
 

• Aus „Dies wird die technischen Schulden erhöhen“ wird „Diese Entscheidung wird die Wartungskosten im nächsten Jahr verdoppeln.“
• „Die Architektur wird dies nicht unterstützen“ wird zu „Dieser Ansatz wird unsere Fähigkeit einschränken, mehr als 1.000 gleichzeitige Benutzer zu bedienen.“

Für eine wirksame Mediation ist eine klare Verantwortlichkeit auf beiden Seiten erforderlich:
 

• Die Stakeholder müssen das tatsächliche Problem und dessen Auswirkungen auf das Geschäft dokumentieren, bevor sie Lösungen vorschlagen. Diese Dokumentation dient als gemeinsamer Bezugspunkt für die Bewertung jeder vorgeschlagenen Lösung.
• Die Entwicklungsteams müssen die technischen Implikationen anhand klarer Geschäftskennzahlen erläutern. Anstatt zu sagen: „Das ist nicht skalierbar“, sollten sie sagen: „Bei diesem Ansatz müssen wir unsere Serverkosten verdoppeln, wenn wir 10.000 Benutzer erreichen.“
• Die Projektmanager müssen ein Dokument zum gemeinsamen Verständnis erstellen und pflegen, das von beiden Seiten geprüft und abgezeichnet wird. Dieses Dokument entwickelt sich im Laufe der Diskussionen weiter, konzentriert sich aber immer zuerst auf die Probleme und dann auf die Lösungen.

Goodharts Gesetz besagt, sobald eine Messgröße zum Ziel wird, ist sie keine gute Messgröße mehr.
 
Sie können den Erfolg nicht anhand von Anforderungsdokumenten oder Projektartefakten definieren. Möglichst viele davon zu schaffen, ist nicht Ihr Endziel. Achten Sie stattdessen auf folgende Indikatoren:
 

• Stakeholder beschreiben Probleme, anstatt Lösungen vorzuschreiben
• Entwicklungsteams schlagen proaktiv Alternativen auf der Grundlage des geschäftlichen Kontextes vor
• Weniger „Notfall“-Funktionsanfragen
• Mehr Lösungen, um die vorhandenen Funktionen nutzen
• Geringere Nacharbeit bei der Implementierung
• Verbesserte Zufriedenheit der Stakeholder auf beiden Seiten

1. Lösungen hinterfragen, um Probleme zu verstehen

In unserem Fall zur Überwachung von Metriken zeigt sich, wie ein einfaches „Warum” unnötige Komplexität und Kosten verhindern kann. Indem wir den wirklichen Bedarf verstanden haben – Einblick in vorhandene Daten statt neue Datenerfassung – konnten wir Tausende von wiederkehrenden Kosten einsparen und gleichzeitig schneller einen Mehrwert schaffen.
 
2. Übersetzen Sie die Auswirkungen, nicht nur die Anforderungen

Als unser Entwicklungsteam Bedenken bezüglich der Entwicklung des Kundenportals äußerte, führte die Übersetzung dieser Bedenken in geschäftliche Begriffe – potenzielle Supportanrufe, Wartungskosten und Benutzerzufriedenheit – zu einer einfacheren Lösung, die das Kundensupportvolumen halbierte.
 
3. Frameworks für das Verständnis aufbauen

Die Problemdokumentationsvorlage und die 5-Why-Technik sind nicht nur Prozesswerkzeuge, sondern auch Kommunikationsbrücken. Wenn sich Unternehmens- und Entwicklungsteams vor der Lösung auf die Dokumentation von Problemen konzentrieren, finden sie auf natürliche Weise effizientere Wege nach vorn.
 
4. Messen Sie, was wichtig ist

Der Erfolg in der technischen Mediation hängt nicht von der Anzahl der Anforderungsdokumente oder den abgeschlossenen Funktionsanforderungen ab. Es geht um messbare Geschäftsergebnisse: weniger Supportanrufe, kürzere Implementierungszeiten und Lösungen, die vorhandene Funktionen nutzen, anstatt sie von Grund auf neu zu entwickeln.