Ein Project Manager sorgt dafür, dass Entscheide getroffen werden, nicht dafür, dass alle zufrieden sind.

Project Manager steht in fast jeder Offerte für ein Softwareprojekt, meistens als Position mit Stundensatz und ohne Erklärung. Wer ein Projekt bezahlt, will wissen, was diese Person den Tag über tut und warum sie auf der Rechnung steht. Die kurze Antwort: Ein Project Manager sorgt dafür, dass ein Projekt bis zum Ende in Bewegung bleibt. Er sorgt nicht dafür, dass alle zufrieden sind, weil das in einem Projekt mit Budget und Termin nicht möglich ist. Irgendjemand bekommt nicht, was er wollte und die Aufgabe des Project Managers ist, dass dieser Entscheid getroffen und ausgesprochen wird, statt dass er drei Monate offen bleibt. Wir erklären die Rolle deshalb über ihre Arbeit, nicht über den Titel und grenzen sie am Ende vom Product Manager ab, mit dem sie am häufigsten verwechselt wird.

Ein Project Manager ist dafür zuständig, dass Entscheide fallen.

In jedem Projekt gibt es Fragen, die niemand gern beantwortet: ob die Funktion im ersten Release dabei ist oder im zweiten, ob der Termin hält oder das Budget, welche der drei Abteilungen ihren Wunsch nicht bekommt. Diese Fragen beantworten sich nicht von selbst. Wenn niemand sie stellt, bleiben sie offen und ein offener Entscheid kostet jede Woche, weil das Team entweder wartet oder auf Verdacht weiterbaut und später umbaut.

Der Project Manager stellt diese Fragen und zwar der Person, die sie entscheiden darf. Er entscheidet sie in der Regel nicht selber, weil er weder das Budget hat noch das Fachgebiet. Er sorgt dafür, dass die Frage sauber formuliert ist, dass die Optionen mit Preis auf dem Tisch liegen und dass bis Freitag eine Antwort da ist. Das ist unbequem, weil die Person, die entscheiden muss, lieber noch etwas warten würde. Genau deshalb braucht es jemanden, dessen Job es ist, nicht zu warten.

Zufriedenheit ist dabei kein Ziel, sondern ein Nebeneffekt. Ein Projekt, in dem alle Wünsche berücksichtigt werden, wird nie fertig und ein Projekt, das nie fertig wird, macht am Ende niemanden zufrieden. Ein Project Manager, der es allen recht machen will, schiebt Entscheide auf und das ist das Gegenteil seiner Aufgabe.

Der Alltag besteht aus Fragen sammeln, Termine halten und Abhängigkeiten kennen.

Konkret sieht die Arbeit so aus. Am Anfang klärt der Project Manager, was fertig heisst: welche Funktionen, welche Qualität, welcher Termin, welches Budget. Nicht als Wunschliste, sondern als Reihenfolge, weil bei Zeitdruck die Reihenfolge entscheidet, was wegfällt. Danach kennt er die Abhängigkeiten: dass die Schnittstelle zur Buchhaltung nicht gebaut werden kann, bevor der Anbieter der Buchhaltung die Dokumentation liefert und dass der Anbieter dafür drei Wochen braucht.

Im laufenden Projekt sammelt er die offenen Fragen aus dem Team und bringt sie gebündelt zum Kunden, statt dass fünf Entwickler fünf Mails schreiben. Er hält den Termin im Blick und sagt früh, wenn er nicht hält, weil ein Termin, der drei Wochen vorher wackelt, verschoben werden kann und einer, der drei Tage vorher wackelt, nicht. Er hält fest, was entschieden wurde, weil sich in Monat vier niemand mehr erinnert, warum in Monat eins etwas weggelassen wurde. Und er sagt dem Kunden, was ein Änderungswunsch kostet, bevor er umgesetzt wird, in Franken und in Tagen.

Das ist keine Vollzeitstelle in einem KMU Projekt. Ein Beispiel: In einem Softwareprojekt von CHF 50'000 mit vier Monaten Laufzeit sind das fünf bis acht Arbeitstage, also 10 bis 15 Prozent des Aufwands. Das klingt nach wenig und es ist der Teil, der am häufigsten gestrichen wird, weil er kein sichtbares Ergebnis liefert. Das sichtbare Ergebnis ist, dass die anderen 85 Prozent das Richtige bauen.

Ein Projekt braucht die Rolle, sobald mehr als zwei Parteien aufeinander warten.

Nicht jedes Projekt braucht einen Project Manager. Eine Website mit fünf Seiten, ein Entwickler, ein Kunde: Da reicht es, wenn die beiden miteinander reden. Die Rolle wird nötig, wenn die Abhängigkeiten nicht mehr in einem Kopf Platz haben. Das ist unserer Erfahrung nach ab drei Parteien der Fall: ein Kunde mit mehreren Abteilungen, ein Entwicklungsteam und ein externer Anbieter, dessen System angebunden wird. Ab dann wartet jeder auf jemanden und niemand sieht, dass alle warten.

Weitere Zeichen: Das Projekt dauert länger als drei Monate, weil dann Entscheide vom Anfang vergessen gehen. Es gibt ein festes Budget, das eingehalten werden muss, weil dann jeder Änderungswunsch bewertet werden muss. Oder der Kunde hat intern niemanden, der die Zeit hat, jede Woche eine Stunde für das Projekt zu reservieren. Im letzten Fall ersetzt der Project Manager nicht den Entscheider. Er sorgt dafür, dass die Stunde des Entscheiders auf die richtigen Fragen verwendet wird.

Wer eine App Idee für CHF 10'000 bis 30'000 bauen lässt, hat in der Regel genau diese Konstellation: ein Entwicklungsteam, ein Kunde, der neben dem Tagesgeschäft entscheidet und meistens ein Drittsystem, das angebunden wird. Ob die Rolle dann beim Anbieter, beim Kunden oder bei jemandem von aussen liegt, ist zweitrangig. Sie muss besetzt sein.

Ein kleines Projekt braucht keinen Titel, aber eine Person, die zuständig ist.

Bei kleinen Projekten wird die Rolle nicht überflüssig, sie schrumpft auf eine Person, die nebenbei zuständig ist. Das kann der Entwickler sein, der das Projekt ohnehin baut, oder die Person beim Kunden, die es bestellt hat. Wichtig ist, dass beide wissen, wer es ist, weil sonst beide davon ausgehen, dass der andere nachfragt.

Der häufigste Fehler in kleinen Projekten ist deshalb nicht der fehlende Project Manager, sondern die Annahme, dass es keinen braucht, weil das Projekt klein ist. Klein heisst wenige Arbeitstage, nicht wenige Entscheide. Ein Projekt von zehn Arbeitstagen mit vier offenen Fragen, die niemand stellt, dauert acht Wochen. Wer die Rolle bewusst einer Person gibt und ihr dafür eine Stunde pro Woche reserviert, hat das Problem für ein kleines Projekt gelöst.

Ein Product Manager entscheidet, was gebaut wird, ein Project Manager, dass es gebaut wird.

Die beiden Rollen werden oft verwechselt, weil beide Manager heissen und beide in derselben Sitzung sitzen. Die Frage, die sie beantworten, ist eine andere. Der Product Manager beantwortet, was das Produkt können soll und für wen: welche Funktion ein Problem der Nutzer löst, welche weggelassen wird, in welcher Reihenfolge. Er trägt die Verantwortung für den Inhalt. Der Project Manager beantwortet, wie das in Zeit und Budget umgesetzt wird: wer was bis wann macht, was blockiert ist, was ein Änderungswunsch kostet. Er trägt die Verantwortung für den Ablauf.

In einem grossen Unternehmen sind das zwei Personen. In einem KMU Projekt ist es oft eine und das ist in Ordnung, solange die Person weiss, welche der beiden Fragen sie gerade beantwortet. Die Verwechslung wird teuer, wenn ein Project Manager beginnt, über den Inhalt zu entscheiden, weil er den Termin halten will, oder wenn ein Product Manager Termine verspricht, die er nicht einschätzen kann. Im ersten Fall wird das Richtige nicht gebaut, im zweiten das Richtige zu spät.

Eine dritte Rolle steht noch eine Stufe davor. Ob das Projekt überhaupt gebaut wird, ob ein gekauftes Produkt reicht und was das Ganze über drei Jahre kostet, ist der Entscheid eines CTO, nicht des Project Managers. Der Project Manager beginnt, wenn dieser Entscheid gefallen ist. Was Bauen gegenüber Kaufen über drei Jahre kostet, haben wir separat beschrieben.

Ohne die Rolle wird ein Projekt nicht schlechter, sondern langsamer und teurer.

Ein Projekt ohne Project Manager scheitert selten laut. Es wird still länger. Entscheide werden nicht getroffen, sondern vertagt, das Team baut auf Verdacht, der Kunde sieht nach drei Monaten etwas, das er nicht bestellt hat und die Änderungen kosten das Doppelte, weil sie auf Fertiges treffen. Am Ende ist das Ergebnis oft brauchbar. Es hat nur mehr gekostet und länger gedauert und niemand kann einen einzelnen Fehler benennen, weil kein einzelner Fehler passiert ist.

Bei uay ist Project Manager eine der Rollen in der Disziplin Produkt und Anforderungen, zusammen mit Product Manager, Business Analyst und Requirements Engineer. Bei jedem Problem schauen wir zuerst, welche Rollen es braucht und bei einem Projekt mit mehr als zwei Parteien ist diese fast immer dabei. Welche Rolle danach prüft, ob das Gebaute auch das Richtige tut, beschreiben wir beim QA Engineer. Sie muss nicht bei uns liegen. Wenn der Kunde jemanden hat, der die Fragen stellt und die Antworten einholt, ist das der bessere Weg, weil die Person das Unternehmen kennt. Wenn niemand die Zeit hat, übernehmen wir es und dann steht die Position in der Offerte mit Tagen und Preis, nicht als Prozentsatz ohne Erklärung.