Projektabwicklung ist ein Tanz auf der Messerschneide. Allein deswegen, weil es mehrere Stakeholders gibt.

Beim Kunden gibt es zum Einen Product Manager. Das ist die Person, die ein erfolgreiches Produkt für sich und sein Unternehmen will. Sie definiert die Featureset des Produkts und bezieht mehrere Abteilungen mit ein, damit das Produkt mehr Unterstützung im Unternehmen und bessere Chancen auf Genehmigung und Funding hat.

Ein Fachmann(sei es ein Techniker oder ein Designer), wenn vorhanden, kann die fachliche Position des Kunden vertreten und den Projektablauf von der fachlichen Seite überwachen.

Einem Prozessler ist es wichtig, dass die Kommunikation nicht formlos, sondern unbedingt durch seine Formulare und Workflows erfolgt. Dadurch erhofft er eine Effizienzsteigerung für sein Unternehmen und nicht zuletzt eine Machtsteigerung für sich.

Manchmal gibt es eine separate Person, die Budgetfragen entscheidet und von daher von den anderen überzeugt werden will.

Und manchmal gibt es einen Micromanager, der seiner Angst nicht Herr wird, dem Team nicht ganz vertraut und allen Fragen einbezogen werden will.

Beim Dienstleister gibt es unter Umständen all diese Rollen auch. Und wenn am Projekt mehrere Dienstleister arbeiten, steigt die Zahl von Stakeholders entsprechend.

In einem Projekt mit einem Kunden und zwei Dienstleistern kannes theoretisch bis zu 18 Stakeholders geben. Und diese Zahl ist nicht nur theoretisch, denn mein persönlicher Record war ein Projekt mit 13 Stakeholders.

Ein Team-Mitglied eines Dienstleister, sei es Developer, Project Manager oder Designer, muss bei allen anderen Stakeholders Position seiner Firma vertreten und, wenn nötig, durchsetzen. Und das ist nicht trivial. So viele Menschen, die unterschiedliche Ziele, Kenntnisse und Lebenssituationen haben, haben auch höchst unterschiedliche Interessen und Positionen, so dass eine Schnittmenge davon des Öfteren leer ist, und, wenn überhaupt, nur selten zu einem gemeinsamen Punkt wird.

Und das ist mitnichten ein ruhiger, gemütlicher und harmonischer Punkt. Vielmehr ist er ein Brennpunkt von mehreren Kriegschauplätzen, denn einige Stakeholders versuchen stets, die schon vorhandenen Zuständigkeiten und Positionen noch weiter zu verbessern.

Kann der Team-Mitglied sich in dieser Situation nicht behaupten, verliert seine Firma fast zwangsläufig Geld, auch dann, wenn der Kunde mit dem Ergebnis eigentlich zufrieden ist. Der Team-Mitglied muss also entsprechende Kenntnisse und Erfahrung haben, damit er in diesem Brennpunkt “überleben” kann.

Und da kommen wir zum Truck-Factor. Der Truck-Faktor wird definiert als die maximale Anzahl von Team-Mitgliedern, die von einem Truck überfahren werden können, so dass das Projekt nicht in erste Schwierigkeiten gerät. Sie haben den Truck-Faktor gleich eins? Dann sind Sie in Gefahr. Der Truck-Faktor ist gleich zwei? Schon etwas besser, jedenfalls können Sie Verlust eines Team-Mitglieds verkraften. Soweit die Theorie. Die Realität sieht etwas anders auch.

Denn in Umkehrschluss, wenn Sie einen Truck-Faktor größer eins haben, haben Sie jemanden im Team, dessen Zuarbeit unpersönlich und unwichtig genug ist, dass er jederzeit ersetzt werden kann. Da solche Kollegen nicht umsonst arbeiten, und auch noch Zeit von den anderen für sich beanspruchen, bedeutet es zwangläufig, dass das Team nicht so wirtschaftlich arbeitet, wie es könnte. Besonders dann, wenn Projekt und Team klein sind (zwei-drei Monate bzw. Menschen), bedeutet jede weitere Person prozentuell gesehen relativ viel Mehraufwand.

Das wäre aber eventuell in Ordnung, wenn dadurch das Risiko tatsächlich gemindert worden wäre. Damit das tatsächlich funktioniert, müssen aber diese zwei Bedingungen erfüllt werden:

a) Weil der Truck alle Menschen mit gleicher Wahrscheinlichkeit treffen kann, müssen alle Rollen im Team von mindestens zwei Personen bekleidet werden. Also, mindestens zwei Project Managers, zwei Developers und zwei Designers muss ein Durchschnittsteam schon haben.

b) Damit Team-Mitglieder wirklich ersetzbar wären, müssen sie alle vergleichbare Erfahrung und Kenntnisse haben.

Diese Bedingungen sind aber meistens nicht erfüllbar.

Und es geht nicht nur darum, dass erfahrene Personen wählerisch sind, um ihren Value für die Firma wissen und oft ungern Verantwortung mit den anderen teilen wollen. Es geht auch darum, dass es unwirtschaftlich sein kann, die Mindestgröße des Teams auf sechs Personen festzulegen. Und darum, dass wenn alle sechs Personen auf einem Workshop aufkreuzen, das Workshop schnell unproduktiv wird, einfach weil es so viele Personen gibt. Jeder von uns hat ja schon solche “Design by Commitee” Workshops erlebt, wo Themen ewig rumdiskutiert werden, einfach weil jede beteiligte Person zu Wort kommen will. Und im Endeffekt wird eine scheußliche Kompromisslösung gefunden, die niemand eigentlich möchte.

Junior-Kollegen im Team zu haben bringt auch wenig für die Risikominderung im Sinne von dem Truck-Faktor. Wenn der Senior-Developer ausfällt, und der Junior einspringen muss, wird er weder die technische Position der Firma gegenüber den anderen Stakeholder vertreten können, noch wichtige technische Informationen dem neuen Senior Dev mitteilen (weil er sie zum Teil gar nicht begreifen kann). Alles, was er ihm hätte erzählen können, sind nur offensichtliche Peanuts, die der neue Senior Dev sich auch sonst in einem halben Tag durch Datenbankstrukturen, Quellcode und Dummy-Screens aneignen kann.

Alle Team-Mitglieder, auch solche, die mit den anderen nicht direkt kommunizieren, haben eine Position zu vertreten und sind in dem Sinne Stakeholders. Die Qualität der Projektabwicklung hängt sehr stark von Erfahrung und Kenntnissen allen Team-Mitglieder ab. Wird ein Team-Mitglied ersetzt, ist es zwangsläufig mit einer Qualitätänderung zu rechnen. Eine Teamaufstellung nach dem Truck-Faktor-Prinzip kann deshalb, wenn überhaupt, nur bei Projekten in der Größenordnung von einem Jahr und einem Dutzend Team-Mitglieder überhaupt denkbar sein.