Vintage Projekt Management #2 – Die erste Herausforderung #Unternehmertagebuch

Wie ich zu meinem zweiten und so ganz vielen Projekten kam.

Projekt #2

Mein Studium setzte ich nach meinem Restart im Oktober 1971 bis zum glücklichen Ende fort (dem Gewinn des Diploms univ.). Das ging so: Im 4. Semester im Sommer 1973 merkte ich, dass das Vordiplom anstand. Und ich stellte fest, dass ich doch eine Reihe von Wissenslücken hatte.

So waren Wochen des Durch-Lernens angesagt. Das war eine stressige Zeit vor den vier mündlichen Prüfungen zum Vordiplom. Tag und Nacht lernen. Ich erkrankte an Wissens-Bulimie, einer Krankheit, die heute weit verbreitet ist und sich in allen mir bekannten Schul- und Universitäts-Systemen wie eine Seuche ausgebreitet hat.

Wie ich das Vordiplom so immerhin ordnungsgemäß geschafft hatte (erstaunlicher weise sogar mit der Note „gut“), war ich ziemlich erschöpft und musste mich erst Mal ausruhen. Das Ausruhen machte besonders viel Spaß in der Rechnerluft beim Siemens. Da gab es wirklich viel Hardware: Großrechner mit BS2000 und BS1000, Prozessrechner,  Büro-Systeme, Netzrechner und vieles mehr. Und an alle kam ich fast jederzeit ran.

Es war um mich geschehen. An der TH – die jetzt TU hieß, weil ja eine Universität etwas besseres als eine Hochschule war – waren die Rechenzeiten sehr knapp – also sah man mich dort nur noch selten. Die nächsten 4 Semester verbrachte ich folgerichtig viel beim Siemens und nur selten in den für Menschen recht unfreundlichen (und wohl damals auch schon verseuchten Räumen) des damals neuen Südbaus Informatik  (Fertigstellung auch so Anfang der 70iger).

Der ist übrigens vor Jahren abgerissen worden. Mannomann, wenn ich mir überlege, dass ich das Gebäude, in dem ich studiert habe, überlebt habe, obwohl es erst 20 Jahre nach meiner Geburt errichtet wurde, dann ist das doch auch irgendwie befremdlich. Ich dachte immer, dass Universitäten auch als Gebäude respektabel sein sollten, der ehrwürdige Altbau der TH steht der TUM auch heute noch prächtig zu Gesicht. Bin mal gespannt, wie lange es der Neubau in Garching schaffen wird …

Mein Hauptfach, die Mathematik, kann man gut aus Büchern lernen. Das war mein Glück, so konnte ich die Abwesenheiten in den Vorlesungen kompensieren. Nach 8 Semestern bemerkte ich dann, dass vor den Prüfungen die Diplomarbeit geschrieben werden sollte. Ich fand als Professor für meine Diplomarbeit Dr. Werner Heise. Leider ist er – obwohl er der jüngste Mathematikprofessor aller Zeiten an der TUM war – schon verstorben. Werner fand für mich eine wirklich spannende Aufgabe aus der Kombinatorik (es ging um eine Vermutung von George Polya, die noch nicht bewiesen war) – und so entstand der Satz von Dürre :). Das war nicht einfach und so war die Lösung auch für mich persönlich ganz toll. Schön war auch, dass ich Mr. Polya aus Ungarn sogar noch auf einem Kongress der Kombinatorik in Berlin erleben durfte. Besonders faszinierend an diesem Ausflug war übrigens, dass Berlin damals noch die herrliche Insel im feindseligen Umfeld war.

Nach der Diplomarbeit kamen die Abschlussprüfungen – und ich erkrankte wieder an Wissensbulimie. Noch heftiger als beim Kraftakt zum Vordiplom. Aber auch das zweite Mal hat das System „Wissen in Massen verschlingen und es dann noch schneller wieder vergessen“ gut funktioniert. So hielt ich eines Tages zwar total erschöpft aber doch sehr glücklich meine Diplom-Urkunde in der Hand. Zwar wusste ich nicht, ob ich da stolz darauf sein sollte oder eher nicht. Aber ich hatte es geschafft und ich war unendlich glücklich, dass das leidige Kapitel Uni für mich vorbei war.

Auf Arbeiten hatte ich eigentlich keine große Lust. Eine Weltreise oder auch nur Urlaub gingen auch nicht und so probierte ich, einen Job zu finden. Ich bewarb mich bei Softlab. Diese Firma fand ich ganz toll, weil ich bei Siemens mal eine Hektographie eines Buches von Peter Schnupp (Strukturiertes Programmieren) fand und das mir wie eine Fackel im Dunklen vorkam. Und der Peter Schnupp, den ich später sehr gut kennen lernen und lieb gewinnen sollte, war ja einer Gründer (gemeinsam mit den Kollegen Neugebauer und Heldmann) von Softlab.

Also schickte ich meine erste (in meinem Leben gab es dann vier Jahre später noch eine weitere) Bewerbung zu Softlab. Softlab hatte aber damals wohl eine kleine Krise und so haben sie mir sehr liebevoll abgesagt. Mit der sinnigen Aussage, dass sie an mir durchaus interessiert wären, aber zurzeit keine Aufgaben für mich hätten und ich mich in einem Jahr wieder melden sollte.

Natürlich war das für mich nicht sehr hilfreich. Aber wie es der Lauf der Dinge so wollte bin ich gut vier Jahre später dann tatsächlich bei Softlab gelandet – aber das ist eine andere Geschichte.

„Nach dem Studium muss man arbeiten!“ – das gab mir der bürgerliche Teil meines Über-Ichs vor. Also bewarb ich mich nach der Absage von Softlab mit denselben Papieren nochmal bei der Siemens AG. Ich war optimistisch, weil die mich ja schon kannten. Und siehe da, sie nahmen mich – und hatten gleich ein richtiges Projekt für mich. Das war Teil eines größeren Projekts, das wiederum Teil eines ganz großen Projektes war.

Ich landete bei UB D WS ST DF 131, was als Abkürzung für Unternehmensbereich Datenverarbeitung, Werk für Systeme, Systemtechnik, Datenfernübertragung, 1. Kompanie, 3. Zug, 1. Gruppe. Die letzten drei Begriffe sind meine Interpretation der 131. Der Gründer von Siemens hat das Unternehmen ja nach dem Vorbild der Reichswehr organisiert.

Ganz DF (sozusagen die Kompanie für Datenfernverarbeitung in der Siemens-Armee) arbeitete an einem Hardware- und einem Betriebssystem zur Realisierung von Datennetzen, genannt TRANSDATA. Es ist übrigens eine Schande mehr für die deutsche IT, dass es diesen Begriff in Wikipedia nicht gibt (wollte ihn gerade verlinken und habe ihn nicht gefunden). Immerhin war das die einzige und technisch wahrscheinlich sogar überlegene Konkurrenz für „SNA“ (System Network Architecture) von IBM  – und Big Blue war der Marktführer und schon so etwas wie unser großes Vorbild.

Die Software von Transdata nannte sich PDN (Programmierbare Daten Netztechnik) und generierte die Betriebssysteme, die für Datenstations-, Netzknoten- und die Vorrechner an den Mainframes notwendig war. Die wohl zwei spannendsten Jahre meines Berufsleben begannen, ich könnte mehrere Bücher darüber schreiben.

Wir waren im offiziellen Sprachgebrauch ein Labor, das 131 von DF und entwickelten APS (Abkürzung für Anwenderprogrammiersprache). Diese Sprache bestand aus einem Interpreter und einem auf Makro-Basis realisierten Übersetzer, der den Bit-Teppich für den Interpreter erzeugte. Die Sprache diente dazu, die „dummen“ Vermittlungsrechnern in die Lage zu bringen, intelligente (Vor-)Verarbeitung schon am Rande des Netzes zu erledigen wie z.B. Daten für einen Geschäftsprozess im Anwenderdialog aufzusammeln und zu überprüfen oder „intelligentes Routing“ und vieles mehr.

Innerhalb DF waren wir eine ganze Reihe von Teams, die alle Neues entwickelten, denn so ein Rechnernetzwerk braucht viele Module und war für die damalige Zeit schon ganz schön komplex (oder hochkompliziert). Und das hochintensiv zusammen arbeitete.

Gemeinsam mit den Kunden und den Partnern der FBZ (Fachberatungszentren der Siemens AG) brachten wir Transdata als die Basis für die neuen großen IT-Projekte voran. Und das lief ganz agil, offen und schlank. Die Protokolle der Abstimmungsgespräche mit den Großprojekten und den Fachberatungs-Zentren waren unsere Pflichtenhefte . Es gab auch ein Management, aber dessen Aufgabe war es vor allem, sich um die Menschen zu kümmern. Und die Teams vor dem Siemens Management zu schützen.

Wir arbeiteten in einer Enklave, in der Ortenburgstr. Die war  eine der vielen Dienststellen außerhalb der Hofmannstr. Im Erdgeschoß gab es noch eine richtige Bäckerei, allein das machte den Standort schon attraktiv. Keine Kasernierung und gute Brezen und Semmeln.

Irgendwie waren wir alle zusammen bei DF gut und haben den Laden geschmissen. Alle waren wir Ingenieure, die Technologie für echte Projekte entwickelten. Und Transdata wurde erfolgreich. Ich war stolz, an Systemen zu arbeiten, die doch so oft in wichtigen und revolutionären Projekten lief.

Mein Job sah damals so aus:
Ich arbeitete als Programmierer parallel an drei Versionen. Die Version A (z.b. 4.0), die aktuell im Markt lief, pflegte ich. Da ging es um Fehlerbehebung und Kommunikation mit den Nutzern. Für die Folgeversion entwickelte ich die besprochene und beschlossene Funktionalität (Version B genannt 4.1). Und dann musste gemeinsam mit den Partnern in den Projekten die Version C – bei uns 5.0 – geplant werden.

Die Zeit, die wir so in die Zukunft investierten, war nicht unerheblich. Denn der Markt war war anspruchsvoll und in großer Dynamik, die Konkurrenz war schnell und das Tempo musste so hoch sein.

Neben der Arbeit des Programmierens an zeitgleich drei Versionen hatte ich noch mehr Aufgaben. Natürlich habe ich das Manual zu unserer Programmiersprache selbst geschrieben. Ich musste die Großprojekte fachlich betreuen und bei den Systemingenieuren, die unser System nutzten, Kurse gehalten.

So wie ich auch den Test unserer neuen Funktionen gemeinsam mit unseren Pilot-Anwendern organisiert und  die Produkt-Blätter fürs Marketing geschrieben habe. Damals kamen auch laufend neue Mitarbeiter zu uns, nach einem halben Jahr war man damals beim Siemens vor lauter „newbies“ schon ein alter Hase. Und weiterbilden mussten wir uns auch – dazu dienten vor allem Papiere wie die „lecture notes“ der ACM oder von IEEE.

Nebenher haben wir noch eine Kaffeemaschine und einen Kühlschrank für unser Büro organisiert und damit bei der Siemens-Administration ein Erdbeben ausgelöst. Eine Kaffee-Maschine in einem Siemens-Büro – das war gegen alle Regeln (obwohl es diese Maschine im „Für uns“-Laden angeblich günstiger für die Mitarbeiter zu kaufen gab). Aber sogar das haben wir hinbekommen.

Und dann ging das Unglück los. Das Management wurde immer mächtiger. Es führte eine Arbeitsteilung ein. Das war so eine Art von Entwicklungs-Taylorismus im Labor. Dazu kamen immer aufwändigere Verwaltungsprozesse ein. Das war in der zweiten Hälfte der siebziger Jahre. Schluss war es mit der Labor-Idylle.

Zuerst kam die Manualredaktion. Wir mussten Menschen, die NULL Ahnung von IT hatten, beibringen, was in einem Programmier-Manual drinstehen muss. Dann kam das Quality Management. Dort sassen Menschen, die unsere Software getestet haben mussten, bevor sie prototypisch von den Kunden eingesetzt wurden. Nur hatten sie keine Ahnung von Software und auch nicht vom Testen.

Dann wurden Produkt-Planung (Product Management) und Requirement Engineering eingeführt. Plötzlich gab es Meilensteine wie A20, A30, B20 … B50. Das Wasserfall-Modell kam. Sogar das Ende des Produktes wurde in großer Gründlichkeit definiert. Das war T50, wenn ich mich richtig erinnere (Falsch, der Andi hat mir das Diagramm geschickt, es war der berühmte Meilenstein B90 – siehe unten). Das ganze nannte sich Projektphasen-Modell. Und wir durften nicht mehr programmieren, sondern mussten uns überlegen, welchen Reifegrad unser Werk gerade hatte.

Man führte Budget-Denken ein und verlangte von uns, dass wir für jede diskutierte Funktion Aufwandsabschätzungen tätigen (erraten) mussten. Blöderweise waren die meisten der neuen Funktionen sehr innovativ und hatten so einen hohen Anteil an kreativer Forschung. So wurde das „Aufwandsabschätzen“ schnell aufwändiger als das Programmieren. Nur programmieren durften wir ja nicht mehr, denn für den Beschluss, ob das ganze programmiert werden sollte, brauchte man ja erst eine gültige und geprüfte Aufwandsabschätzung.

Und so wurde das – was wir früher mit Kunden und FBZ direkt an einem Nachmittag vereinbaren konnten, immer länger diskutiert. Aus Wochen wurden Monate. Eigenartige Beschlüsse waren die oft absurden Ergebnisse, die man dann alle wieder aufwendig wegdiskutieren musste – oder heimlich U-Boote bauen. Was in einem gut kontrollierten Konzern auch nicht ungefährlich ist. Aber was tut man nicht alles für ein erfolgreiches Projekt.

Zusätzlich wurden Arbeitszeitregelungen durchgesetzt, die uns klar machten, dass wir nicht soviel arbeiten durften, wie das Projekt es erforderte. In logischer Konsequenz wurden dann später in Neuperlach auch für die Ingenieure Stechuhren eingeführt. Und wenn man erwischt wurde, dass man nach dem Stempeln noch ein wenig weiter gearbeitet hatte, gab es vom Betriebsrat erzwungene Schelte.

Sogar das „Arbeit nach Hause mitnehmen“ wurde immer schwieriger, denn der Werkschutz hatte sich an den Toren einen Zufallsgenerator einfallen lassen. Wenn der bimmelte, wurde man kontrolliert (gefilzt) und Unterlagen nach Hause mitnehmen war ja strengstens verboten.

So wurde es immer schlimmer. Es gab neue Sitzungen mit 3- oder 4-Buchstaben-Abkürzungen (die ich vergessen habe). Da sassen plötzlich Leute am Tisch, die von neuen Abteilungen kamen, die man bis dahin gar nicht kannte. „Querschnittsverantwortliche“ demonstrierten, wie wichtig sie waren. Leute, die keine Ahnung vom Markt und der Technologie hatten aber mit Allgemeinplätzen gut umgehen konnten bestimmten immer mehr die Produktentwicklung. Das kostete viel Zeit und mancher Blödsinn wurde beschlossen, der natürlich nie zum Fliegen kam. Wenn es überhaupt zu Entscheidungen kam. Das alles bewirkte vor allem Hilflosigkeit und Frust.

Kurz gesagt – es wurde Zeit zu gehen. So bin ich – noch innerhalb der Siemens AG – zu einer der Abteilung gewechselt, die die Projekte gemacht hat (UB D V S 3 – Unternehmensbereich Datenverarbeitung, Vertrieb Sonderprojekte Abteilung 3). Dort musste man ja noch echte Projekte stemmen und blieb – zumindest noch eine zeitlang – von Bürocrazy und Management-Wahnsinn verschont.

Ich hatte ein gutes Angebot, denn bei UB D V S 3 kriselte es (nicht nur) in einem Projekt, dass der Führung ganz wichtig war. Und das kräftig in Verzug war. Ich sollte es über die Bühne bringen. Es nannte sich DISPOL und wurde für die Bayerische Staatsregierung entwickelt. Aufgabe war es, bei der Polizei den Fernschreiber (Kommunikation), den Aktenschrank (Datenbank und -archiv) und die Schreibmaschine (Dokumentenerzeugung) durch IT-Equipment abzulösen.

Bei diesem Produkt habe ich dann das erste Mal in meinem Leben einen richtigen Projekt Manager erlebt … Der sollte es retten – und das war auch mein Job. Gemeinsam haben wir es auch geschafft. Weil er die Techniker machen ließ und nichts machte. Aber mehr erzähle ich hier noch nicht, denn das ist genau die dritte Geschichte aus meiner Serie Vintage Projekt Management vom PM-Camp in Berlin.

RMD

P.S.
Mittlerweile gibt es Personal Manager und Service Manager. Auf einer Visitenkarte der BVS.de habe ich vor kurzem „Ausbildungsmanager“ gelesen. HumanResource kümmert sich um BGM (Betriebsgesundheits Management). Die Unternehmen haben ihr Wissensmanagement  und zertifizierte Wissens Manager, die schaffen sollen dass „Siemens weiß was Siemens weiß“ – Siemens hier als Metapher.

Wenn das nichts hilft, wird ein Innovations Manager installiert und es dann immer noch klemmt, dann kommt der Change Manager. Und macht ein „Programm“. Und braucht dann natürlich einen oder mehrere „Programm Manager“.

What a brave new world …!

P.S.1
Hier noch das Diagramm, nach dem tatsächlich ein paar Jahre später bei Siemens gearbeitet wurde … Ist doch auch wunderschönes Projekt Management Vintage … Der Andreas Weber hat es mir zugesandt – Danke – lieber Andi!