Na ja, die Sache hat mehrere Seiten. ME macht es der richtige Mix und die immer wieder gegenseitig von Respekt für die Notwendigkeiten des anderen getragene Abstimmung der Beteiligten. Reine „Nerd“-Projekte gehen regelmäßig kostentechnisch in die Hose, und reißen gerne auch mal die Terminschiene. Da wird dann häufig in Schönheit gestorben, weitet sich das Projekt unkontrolliert aus, weil man meint - Auftrag hin oder her - auch noch 1001 andere identifizierte Baustellen gleich mit bearbeiten zu müssen/zu können, … Da fehlt dann bei den IT-Nerds auch gerne mal das Branchenwissen und die Bereitschaft sich mit den Hintergründen dessen auseinander zu setzen, was da eigentlich der Sinn und Zweck des Ganzen ist, wie man diesen Sinn und Zweck ggf. auch kostenoptimiert anders erreichen kann, …
Umgekehrt braucht es natürlich IT-Wissen, und je weiter dieses reicht, um so besser. Aber ein Projektleiter muss nicht auch gleich noch der Chefentwickler oder IT-Architekt sein. Wichtig, dass man von diesen Dingen auch ein gewisses Verständnis hat, und bereit ist, sich mit entstehenden Problemen auseinander zu setzen. Aber ein Projektleiter in einem größeren Projekt sollte jetzt nicht Build-Verantwortlicher oder letzte Review-Instanz für den Code sein. Da geht es dann eher um Dinge wie den ständigen Abgleich der beauftragten Leistung mit der zu erbringenden Leistung um ggf. Nachträge zu stellen, damit Mehraufwand dann auch bezahlt wird und im Terminplan hinreichende Berücksichtigung findet, Entscheidungen herbei zu führen, notfalls noch mal Personal für Spezialthemen nachzuziehen, Konzepte zur Aufholung von Verzug abzustimmen, … Und ja, dabei kommt es dann oft zu Entscheidungen, die auf der „Nerd-Ebene“ nicht nachvollziehbar erscheinen, aber aus übergeordneten Gründen durchaus notwendig sein können.
Ich habe selbst viele Jahre ohne echte IT-Ausbildung in sehr unterschiedlichen Positionen in IT-Unternehmen gearbeitet, darunter durchaus auch Positionen mit eindeutigem IT-Schwerpunkt. Unter den Nicht-IT-lern war ich dabei immer einer derjenigen, der von den echten IT-lern aufgrund seiner Bereitschaft sich auch in die Tiefen der IT zu begeben geschätzt wurde, durchaus auch den ein oder anderen Code-Schnipsel lesen konnte, bei Architektur-Entscheidungen mitgewirkt hat, später ITIL-Prozesse mit designed hat, und insbesondere auch immer versucht hat, den IT-Kollegen zu erklären, warum wir gelegentlich nicht den „perfekten“ Weg beschreiten konnten, sondern aufgrund welcher übergeordneter Themen auch mal andere Entscheidungen fallen mussten. So war das immer ein recht gutes Zusammenarbeiten. Aber klar, ich habe auch Leute erlebt, die als reine Kaufleute mit keiner Ahnung von nicht mehr als Zahlen Projekte versägt haben.
