In einer Dreiecksbeziehung

In Softwareprojekten kommt es nicht selten vor, dass nicht nur zwei, sondern drei oder mehr Parteien zusammenarbeiten müssen. Oft gibt es einen Auftraggeber, aber mehrere Lieferanten. Der Auftraggeber benötigt ein neues Softwaresystem, aber dazu muss nicht nur ein Softwarehaus wie INDAL tätig werden, sondern auch ein Systemhaus, das etwa die Server und die sonstige Infrastruktur bereitstellt. Es ergibt sich eine klassische Dreiecksbeziehung mit all ihren ganz besonderen Herausforderungen, insbesondere der Gefahr der gegenseitigen Schuldzuweisungen der Lieferanten, wenn irgendein Problem erst spät im Projektverlauf erkannt wird.

Manchmal glaubt man, dass solche Herausforderungen durch eine klare Trennung der Verantwortlichkeiten gelöst werden können. Das ist aber vor allem bei der Erfüllung nicht-funktionaler Anforderungen zumeist nicht der Fall. Beispiel Performance: Ob die Reaktionszeit einer Programmfunktion durch Optimierung der Algorithmen oder durch Aufrüsten der Hardware verbessert werden kann, ist dem Nutzer letztlich egal, demjenigen, der das Projekt finanzieren muss, allerdings vielleicht nicht. Welche Lösung optimal ist, können die Beteiligten nur gemeinsam herausfinden.

Zumeist ist gerade weniger Verantwortungstrennung besser als zu starke Abgrenzung. Am besten ist es, wenn frühzeitig, noch bevor das erste Problem überhaupt auftritt, offen über die Felder gesprochen wird, auf denen es Konflikte geben kann, und Mechanismen vorgesehen werden, nach denen im Fall des Falls gehandelt wird. Regelmäßige Abstimmungs-Meetings werden oft vorab zwar vereinbart, aber so lange alles ganz gut läuft, nicht wahrgenommen. Dabei könnte man gerade in Zeiten der ruhigen See ganz gut darüber sprechen, welche Risiken bestehen könnten, und wie man mit ihnen umgehen will.

Lieferanten neigen manchmal dazu, unterschwellig und in Anspielungen die Kompetenzen und Fähigkeiten anderer Lieferanten gegenüber dem Auftraggeber in Frage zu stellen. Handelt es sich etwa um einen großen Konzern, macht man schon gern mal einen Scherz über mangelnde Flexibilität und bürokratische Entscheidungswege. Gern wird auch durch Nebensätze das Know How des anderen Lieferanten bezweifelt, vor allem dann, wenn es sich um einen Wettbewerber handelt.

Solche Spielchen sind allerdings nie eine gute Idee. Sie schaden vielleicht dem Ansehen des anderen Lieferanten, aber sie nützen nie dem, der sie spielt. Beim Auftraggeber bleibt immer nur der Eindruck zurück, dass er sich auf die Kompetenz seiner Lieferanten nicht verlassen kann und dass er nicht einschätzen kann, wo die Ursachen für Probleme wirklich liegen. Am Ende wächst das Misstrauen im Projekt insgesamt. Besser ist, dass jeder zunächst davon ausgeht, dass alle Projektbeteiligten einen guten Job machen, und dass Schwierigkeiten nur selten in der Unfähigkeit der Anderen, sondern in der Komplexität der Materie begründet sind.