Raumaufteilung und Projekterfolg

Kommunikationsproblem à Projekterfolg?
 Pieter Bruegel der Ältere 1563

Wie schon Frederick Brooks im "Mythical Man Month" feststellte, scheitern Softwareentwicklungsprojekte reihenweise an Kommunikationsproblemen. Klare Zielvorstellungen, genügend Personal, Zeit und Geld, sowie state-of-the-art Werkzeuge und Frameworks helfen genauso wie beim Turmbau zu Babel nichts, wenn die Kommunikation nicht passt. Kommunikationsprobleme sind die Hauptursache dafür, dass ein großer Teil der Softwareentwicklungsprojekte scheitern.

Was aber ist Hauptverursacher für Kommunikationsprobleme? In den wenigsten Fällen liegt es an den handelnden Personen. Der immer wieder zitierte ungepflegte, langhaarige, bebrillte, introvertierte Informatiker ist seit längerem so gut wie ausgestorben. In den meisten Fällen ist die ungeeignete Kommunikationsstruktur des handelnden Unternehmens für die Kommunikationsprobleme verantwortlich. Und diese wiederum ist abhängig von der räumlichen Aufteilung der Projektmitarbeiter.

Was haben Projekte, deren Mitarbeiter in schönen, großen, individuell gestaltbaren Arbeitsräumen sitzen, bei denen es aber undenkbar ist, die Raumaufteilung dynamisch an die Projekterfordernisse anzupassen? Diese Projekte haben Kommunikationsprobleme und deshalb geringere Chancen auf Projekterfolg. Eine gewagte These. Warum sollten sie Kommunikationsprobleme haben, wenn doch alle dieselbe Sprache sprechen und räumlich so gut wie nicht voneinander getrennt sind? Kommunikationsprobleme gibts doch nur in Offshoring Projekten...".

Die Erfahrung zeigt leider: Das Zimmer nebenan ist soweit entfernt wie Hütteldorf von Favoriten, das nächste Stockwerk so wie Wien von Sofia (und Indien liegt überhaupt bei Beteigeuze). Sobald Teams räumlich voneinander getrennt arbeiten, entstehen unterschiedliche Wissensstände, Anschauungen, Entscheidungen - in einem Wort Kommunikationsprobleme.

Zunächst einmal tauchen Missverständnisse auf - und noch viel mehr Missverständnisse bleiben im Verborgenen. Später wird dann von "die anderen" gesprochen, wenn doch die Projektmitarbeiter im Nachbarzimmer oder anderen Stockwerk gemeint sind. Schlussendlich schotten sich die Zimmer voneinander ab - man versucht so wenig Kommunikation wie möglich mit anderen zu haben - die Kommunikation wird auf weit weniger als das Notwendigste reduziert und Schuld sind immer die anderen. Haben die Kollegen auf Grund einer hierarchischen- oder Matrixorganisation auch noch unterschiedliche Vorgesetzte, oder sitzen Externe in anderen Zimmern als Interne, wird das meist sogar unbewusst forciert.

Was aber tun, wenn man ein größeres Softwareentwicklungsprojekt umsetzen muss, welches so viele Mitarbeiter benötigt, dass sie nicht alle in einen Raum passen? Falsch gedacht - die Software kann ziemlich sicher genausogut von einem kleinen Team umgesetzt werden. Es gibt jede Menge Studien, die belegen, dass kleine, schlagkräftige Teams um viele Faktoren produktiver sind, als große, noch dazu über mehrere Räume verteilte Teams. 7 gute Mitarbeiter in einem Raum schaffen meist weit mehr als 50 Mitarbeiter in 10 Räumen

Melvin Edward Conways "Clean State Approach" besagt, dass die IT-Organisation entsprechend der umzusetzenden Geschäftsprozesse zu strukturieren ist - also z.B. für ein Projekt eine geeignete räumliche Aufteilung gefunden werden muss. Ansonsten scheitert ein Projekt entweder an den Schnittstellen zwischen den einzelnen Zimmern, oder bekommt eine Architektur, die der räumlichen Aufteilung der Projektmitarbeiter entspricht (und nicht den Erfordernissen der Software)

Fazit: Liebe Projektmanager - bevor ihr ein neues Softwareprojekt beginnt, überlegt wie ihr alle Projektmitarbeiter in einen Projektraum bekommt. Gute Mitarbeiter zeichnen sich durch Flexibilität aus - auch Flexibilität hinsichtlich ihres Arbeitsplatzes. Die besten Informatiker die ich kennenlernen durfte reissen sich darum in einem kleinen, schlagkräftigen Team in einem gemeinsamen Raum zu arbeiten.