Auch in der Projektentwicklung geht es zunächst erst einmal um das, was der Kunde wünscht. Weiß der Kunde, was wünschenswert ist? Je nach Branche fällt die Antwort auf diese Frage unterschiedlich aus. Mal stehen Architektur bzw. Kommunikationsarchitektur stärker im Vordergrund. Immer kommt es auf Marktanalyse, präzise Analyse der Profile repräsentativer Zielgruppen an und Strategien für Projektmarketing an. Für die Budgetplanung von Projekten und auch schon für die Angebots-kalkulation der Projektentwickler selbst braucht es einen mehr oder weniger ausdifferenzierten Businessplan. Aus dessen Grundlage sowie einer sorgfältigen Stakeholderanalysis für das Kooperationsmanagement basiert der in Zielgrößen für Projektkoordination zu „übersetzende“ Realisierungsfahrplan.

Rechtzeitig gilt es zwecks absehbar erforderlicher Projektoptimierung die Projektdokumentation bzw. Prozessevaluation sicher zu stellen. Je nach Projekttyp sind verschiedene Evaluationskriterien für die Projektplanung und damit für die Wahl des geeigneten Projetmanagementsystems relevant. Ob der Kunde auch dazu Beratung wünscht, ist damit noch nicht gesagt. Was Kunden verständlicherweise wünschen, ist, dass sie sich während der zu betreuenden Projektumsetzung trotz der vielen in einem Projekt aufeinander angewiesenen Berufe, Kompetenzfelder und Leistungsträger mit möglichst wenigen, bereichsspezifischen Ansprechpartnern auseinander setzen müssen. Im Idealfall reicht ein zentraler Ansprechpartner, welcher alles weitere orchestriert.

Wenn dieser gleichzeitig die Person ist, welche die Sinfonie des Projektes auch geplant hat, stehen die Zeichen besonders günstig, dass die definierten Projektziele auch erreicht werden. Bei größeren Projekten geben das größere Budgets her, dass ein Projektsteuerer sich voll auf Projektkoordination konzentrieren kann. Bei kleineren Projekten droht die Gefahr, aufgrund der unterkritischen Projektgröße nur ansatzweise arbeitsteilig arbeiten zu können. Projektmanager müssen in kleineren Projekten mehr Kompetenzen in einer Person abdecken. Stehen solche genialen Dilettanten zur Verfügung, die dem Investor das Grübeln dank ihrer Breitbandkompetentenz abzunehmen vermögen? Oder muss er folge der Devise „Vertrauen ist gut, Kontrolle ist auch gut.“ hier selbst stärker in die Verantwortung von Projektsteuerungsfunktionen gehen?

Aus den komplexen, schon während der Projektanbahnung entstehenden Beratungsbedarfen erklärt sich die Bedeut-samkeit unserer Eingangsfrage. „Weiß unser Kunde, was zu wissen für ihn wünschenswert ist, weiß er worauf es in der für das Projekt maßgebenden Branche ankommt?“ Bei Projektentwick-lungen in der Baubranche können wir uns bei der Planung am Erscheinungsbild, an Nutzensaspekten sowie Rahmendaten ver-gleichbarer Projekte orientieren. Bei PE in der Wissenschaft hin-gegen weiß man oft erst im Prozess, was für eine Komposition an Funktionsmerkmalen am Ende realisiert werden sollte. In der Soft-wareentwicklung bewegen wir uns in etwa dazwischen und arbeiten mit engmaschigem Feedback zwischen theoretischen Erwartungs-horizonten und frisch gewonnenen Erkenntnissen bezüglich Machbarkeit. Im Hinblick darauf lohnen Blicke über den Tellerrand:

Worum es unseren Kunden ganz grundsätzlich geht, wenn sie externe Unterstützung für die systematische Einlösung ihre Entwicklungsbedarfe konsultieren, das lässt sich anhand der Zahl 16 veranschaulichen: Einer Studie zufolge erreichen nur 16 Prozent aller Projekte weltweit ihre Ziele! Dabei ist noch nicht berücksichtigt, ob Budgetvorgaben eingehalten oder aufgestockt und inwieweit Zeithorizonte erweitert werden mussten. Wer braucht so etwas? Niemand! Und doch sind die 16 Prozent Fakt und decken sich mit unserer Sicht der Kontraste zwischen Wunsch und Wirklichkeit bei der Planung, Realisierung und Skalierung von Projekten. „Erstes kommt es anders und zweitens …“ Wie überwinden wir den Abgrund, der zwischen dem Wunsch unserer Kunden nach abgesicherten Planungsgrundlagen und der prinzipiellen Unsicherheit künftiger Entwicklungsdynamken liegt?

Die klassische Antwort wäre, dass wir uns auf mündliche Überlieferung zwischen den mit Verantwortung betrauten Kompetenzträgern verlassen. Damit dieser steinzeitliche Modus für Wissensmanagement unsere Projektvision ins Ziel trägt, zahlen wir diesen Kompetenzträgern ein Schmerzensgeld, suchen sie durch kunstvolle Vertragsgestatung oder Anstellungsverträge hinsichtlich Loyalität zu binden und lassen uns graue Haare wachsen über der Frage, wie wir unsere Konkurrenz abhalten, diese Multiplikatoren bewährter Erfolgsrezepte abzuwerben, bevor sich das eingesetzte Schmerzensgeld „gerechnet“ hat. Eine scheinbar modernere Lösungsidee für das Problem der rechtzeitigen Mitteilung von erfolgsträchtigem Erfahrungswissen ist die Gewährleistung der Austauschbarkeit von Projektmitarbeitern. Je nach Branche kann das eine prima Idee sein, muss aber nicht.

Gemeint ist mit diesem Hinweis auf die Branche, dass wir das Umfeld für die Planung berücksichtigen müssen. Je nachdem wie dynamisch es ist, sind andere Methoden und Tools für Planung, Projektumsetzung und Skalierung angemessen. Es macht bspw. einen riesen Unterschied, ob bei einem Projekt „nur“ etwas beforscht und gelernt werden soll oder ob ein konkretes Produkt mit physischen Qualitätsmerkmalen koproduziert werden soll. Ein weiterer Einflussfaktor ist auch das Bildungsniveau bzw. Vorwissen der Projektarbeiter vor Ort. Die Baubranche bspw. ist dadurch gekennzeichnet bzw. gezeichnet, dass die Arbeiter, welche letztendlich die operativen Zieldefinitionen praktisch umsetzen, keine Fachkräfte sind. Vielfach handelt es sich um Ungelernte, die auf der Grundlage von Zeitarbeit zwischen höchst verschiedenartigen Baustellen wechseln. Dilettantismus ist hier die Norm deren Schattenseiten es durch die Artistik von Projektsteuerern aufzufangen gilt.

Wenn angesichts von Baufehlern geklagt wird, wie schwierig es sei, gute Handwerker zu finden, dann bleibt für gewöhnlich außerhalb der Betrachtung, welche Voraussetzungen ein Arbeiter bräuchte, um Expertise aufzubauen, diese auskömmlich bezahlt zu bekommen und vorausschauend anzuwenden. Selbst für Arbeiter, die dazu lernen und aufsteigen wollen, ist der Aufbau eines Projekte übergreifenden Erfahrungsschatzes aufgrund der sehr verschiedenenartigen Anforderungen auf verschiedenen Baustellentypen erschwert. Eine weitere Branche die weitestgehend durch Projektarbeit gekennzeichnet ist, ist die Softwareentwicklung. Im Hinblick auf die frage, worum es für Kunden im Hinblick auf Projektentwicklung geht, sind von den lehrreichen Ähnlichkeiten und Unterschieden zur Baubranche einige erwähnenswert. IT-Entwickler neige dazu, sich effektiv und effizient dagegen zu wehren, wenn sie mit dem Ideal des möglichst komplett auswechselbaren Kompetenzträgers konfrontiert werden.

Im Gegensatz zu den, inmitten organisierter Planungsun-sicherheit ums Überleben kämpfenden Zeitarbeitern in der durch scheinbar kostengünstigen Dilettantismus geprägten Baubranche, können sie über die Aussichten auf den Projekterfolg einer Softwareentwicklung einfach mit den Füßen abstimmen, wenn ihnen die Führungsphilosophie eines Projektmanagements nicht mehr zusagt. Wieso verfügen die Angehörigen des digitalen Proletariats im Gegensatz zu den Angehörigen des Baustellen-prekariats über diese, für den Projekterfolg so verdammt ziel-kritische Verhandlungsmacht? Geht das Projektmanagement mit ihnen pfleglicher um, weil sie i. d. R. über höheren Bildungsstand oder zumindest einen für höherwertig angesehenen Qualifizierungs-nachweise verfügen? Oft genug arbeiten auch in der IT mehr oder minder projekterfahrene Quereinsteiger …

Zumindest die Budgets sind in der Softwareentwicklung vergleichbar mit denen von Baustellen. Bei Baufehlern können auf den Bauherren Personenschäden und Mängelklagen in erheblicher Höhe zu kommen. In der Softwareentwicklung scheint es nur auf den ersten Blick anders zu sein, weil bei einer fehlerhaften Software doch niemandem ein Balken oder Stahlträger auf den Kopf kracht. Wenn aufgrund fehlerhaft programmierter Steuerung ein Flugzeug abstürzt oder ein Fahrstuhl Eigensinn entwickelt, relativiert sich das Bild. Im Gegensatz zu den, inmitten organisierter Planungsunsicherheit ums Überleben kämpfenden Zeitarbeitern in der durch scheinbar kostengünstigen Dilettantismus geprägten Baubranche, verfügen Digitalarbeiter über größere Gestaltungsspielräume.

Sie können über die Aussichten auf den Projekterfolg einer Softwareentwicklung einfach mit den Füßen abstimmen, wenn ihnen die Führungsphilosophie eines Projektmanagements nicht mehr zusagt. Wieso verfügen die Angehörigen des digitalen Prekariats im Gegensatz zu den Angehörigen des Baustellenprekariats über diese, für den Projekterfolg so verdammt zielkritische Verhandlungsmacht? Schaden anrichten kann man in der Softwareentwicklung offenbar ebenso wie auf dem potentiellen Millionengrab einer Baustelle. Geht das Projektmanagement mit Digitalarbeitern pfleglicher als mit Bautagelöhnern um, weil sie i. d. R. über einen höheren Bildungsstand verfügen? Die Lösungen für diese Rätsel bringen uns der Antwort auf die Eingangsfrage näher, worum es Kunden bei extern unterstützter Projektentwicklung geht.

Der dritte Lösungsversuch für die zu gewährleistende Überbrückung des Abgrunds zwischen dem Wunsch nach Planungssicherheit und einer trotz Projektumfeld-dynamik zielgetreuen Planungsumsetzung tritt mit der zunehmenden Digitalisierbarkeit der für Projekterfolg tragenden Strukturen, Prozessroutinen und Feedbacksysteme für Projektkoordination auf den Plan. Bei den Kompetenzträgern für Softwareentwicklung verschmelzen in einer höchst bemerkenswerten Weise zwei Rollen. Wenn wir die Baustellensituation als Metapher nehmen, so könnte man sagen, dass bei ihnen die Rolle der Bauausführenden und die Rolle des Bauplaners in einer Person ein Stück weit zusammenkommen. Das ist ein entscheidender Punkt, das lohnt sich, tiefer verstanden zu werden.

Aus der Not des Bedarfes an verbesserter Planungssicherheit heraus wurden in der IT die bislang unzureichend erforschten Voraussetzungen für erfolgreiche Softwareentwicklung durch intensiv getaktete Zyklen des Abgleichs zwischen Theorie und Praxis ausgelotet und beim Forschen gleich verbessert. Auf Bau-stellen mit der typischen Trennung zwischen Architekten und den auf Zuruf eingesetzten Zeitarbeitern in ihren Bauwägen, konnte diese Kultur des schnellen, kurzzykligen Prototypings nicht realisiert werden. Man begnügte sich damit, Bauleiter bzw. Projektsteuerer als Übersetzer zwischen den Welten einzusetzen. Ebenso wurde dieses Potential bislang übrigens auch noch nicht in der Wissenschafts-organisation mit ihrer, teils anachronistisch gewordenen Teilung zwischen Forschung / Lehre zum flächendeckenden Kulturstandard.

Wer sich in der Wissenschaft einen weiteren Dilettantismus immer neuer ungelernter Projektarbeiter mit allzu oft bei 0 startenden Projekten leisten will, der wird sich einfallen lassen müssen, wie man Universal-genies ausbildet. Das Genie Heinz von Förster – einer unserer zentralen Inspiratoren – hat auf das Potential dieser Rollenver-schmelzung von Macher und Manager für den Erfolg von Unter-nehmungen mit als erstes hingewiesen. Auf die selten intensive, transdisziplinäre Verschmelzung der Rollen, Einsichten und Umsetzungsbefugnisse von Softwareprogrammierer und Software-architekt führen wir zurück, dass die Professionalität in der jungen Branche der Softwareentwicklung das Professionalitätslevel für Projektarbeit in teils Jahrtausende alten Branchen innerhalb weniger Jahre überflügelt hat.

Parallelen zur Großbaustelle BER und dem aktuellen Produk-tivitätsniveau unserer Wissenschaftsorganisation sind nicht zufällig sondern symptomatisch und umprogrammierbar. Der bemerkenswerte Professionalisierungsschub infolge zumindest teilweiser Rollenverschmelzung von Planern und Planung Aus-führenden im Bereich der Softwareentwicklung zeigt im Ansatz auf, wohin sich Wissenschaftsorganisation entwickeln wird. Abseh-bar wird nicht nur die Wissenschaftskultur einem zunehmen-dem Rationalisierungsdruck ausgesetzt werden. Serious Sciences werden die Chancen der Gamification als Handlungs-aufforderung begreifen. Es ist nur eine Frage der Zeit, bis das Spontantheater Universität mit seinen mehr oder weniger überholten Rollen, Skripts und archetypischen Charaktere zum Serious Game wird.

Für uns wird aus diesem, für andere Branchen beispielhaften Innovationsschub in und durch Softwareentwicklung deutlich, worum es für Investoren und ihre Projektpartner künftig bei Projektentwicklung gehen wird. Bspw. auf Baustellen ist für die Planungsausführenden und potentiellen Projektnutzer oft nicht nachvollziehbar, was sich die oft weit weg vom Ort des Geschehens vor sich hin konzipierenden Planer nur gedacht haben mögen. Derlei Ärgernisse werden in dem Maße der Vergangenheit angehören, als – so wie in der Softwareentwicklung – eine engere Verzahnung zwischen Planern und Machern dank kurzzykliger Prototyping-prozesse und engmaschigerem Feedback zu Zwischen-resultaten gewährleistet ist. Natürlich war die Konstellation im Bereich der Softwareentwicklung besonders günstig.

Um Konstruktionsdetails sinnvoll durchprogrammieren zu können, brauchten „Codemonkeys“ ein gewisses Maß an Überblick über die mit der Gesamtkonstruktion verbundenen Intentionen. Softwarearchitekten mussten darauf Rücksicht nehmen, was en detail auch wirklich umsetzbar ist. Entscheidend war jedoch, dass sich aus dieser Verschränkung von Vogelperspektive und Liebe für´s Detail die Gestaltungsmacht ergeben hat, Werkzeuge wie stackoverflow und github für schnellen Abgleich zwischen Theorie und Praxis aus eigener Kraft und unmittelbarem Wissen zu den benötigten Arbeitsverbesserungen selbst derart bedarfs- und bedürfnisadäquat zu gestalten. Derzeit ist diese Sondersituation in der Softwareentwicklung gekennzeichnet durch Fachkräftemangel. Abhilfe dafür ist aber schon unterwegs.

In dem Maße die Kohorten der „Google-Kids“ in den Unternehmen, in der Wissenschaft, auf den Baustellen unserer Gesellschaft ankommen und beginnen nach der Führungsmacht zu greifen, werden wir absehbar ein Aufblühen völlig neuartiger Organisationsformen und eine drastische Verbesserung der Professionalität von Projektarbeit erleben. Die Anreize, selbst die Strukturqualitäten und Prozessroutinen der eigenen Arbeit zu hinterfragen, verschmilzt mit der, für diese Kohorte normal gewordene Gestaltungsmacht, selbst auch Prototypen programmieren und designen zu können. Die berühmte Zeichnung, der sich selbst zeichnenden Hände von Escher bringt den Glücksfall der Kompetenzverschränkung von Planern und Machern in ein Bild.