Management

Dezentral gute Entscheidungen treffen

Unzählige Entscheidungen prägen IT-Projekte, sei es die Priorisierung von Anforderungen, das Design und die Architektur oder auch das Vorgehen im Team. Doch wie trifft man gute Entscheidungen?

IT-Berater Andreas Rüping beschäftigt sich mit möglichen Ursachen für Fehlentscheidungen und praxisorientierten Instrumenten, mit denen man alleine oder im Team zu besseren Entscheidungen gelangen kann, und kombiniert dabei Erkenntnisse aus der Entscheidungstheorie und Kognitionswissenschaft mit bewährten Praktiken aus IT-Projekten – allen voran aus dem agilen Umfeld. Im IT-Channel von buchreport.de schlägt er mit der dezentralen Entscheidung ein klassisches Prinzip vor, das die Wahrscheinlichkeit eines Scheiterns bedeutend reduzieren kann.

 

Die dezentrale Entscheidung ist ein Prinzip, das es erleichtert, gute Entscheidungen zu treffen, und sich – wenngleich mehr oder weniger gut – in ganz unterschiedliche Organisationskulturen integrieren lässt. Dies wird leichter gelingen in Organisationen, in denen ein agiles Vorgehen üblich ist oder zumindest angestrebt wird, weil agile Methoden für selbstorganisierte Teams eintreten und eine Kultur der Offenheit fordern. Generell ist das Prinzip aber auch in Organisationen anwendbar, die ein traditionelleres Bild der Softwareentwicklung favorisieren.

Kontext

Eine Organisation besteht aus vielen Einzelpersonen und Teams. Naturgemäß kann es unterschiedliche Auffassungen darüber geben, wer für welche Entscheidung zuständig ist.

Problem

Wie können wir verhindern, dass Menschen Entscheidungen treffen, ohne deren Tragweite absehen zu können und ohne die Konsequenzen zu verstehen?

Hintergrund

Fragen zu IT-Projekten können praktisch immer die Teams am besten beurteilen, die für das Projekt zuständig sind. Entsprechend ist es naheliegend, Teams auch die Entscheidungshoheit über ihre Projekte zuzugestehen. Natürlich kann der Blick von außen gelegentlich für Klarheit sorgen, gerade dann, wenn ein Team Gefahr läuft, betriebsblind zu werden. Aber generell ist es wenig sinnvoll, Teams Entscheidungen von außen aufzuzwingen.

Falls genau dies doch geschieht, hat es zumeist negative Folgen. Zum einen leidet die Qualität der Entscheidung, da Personen, die von außen entscheiden, in der Regel nicht die notwendigen Kenntnisse mitbringen und von den Folgen der Entscheidung auch nicht direkt betroffen sind. Zum anderen leidet die Motivation im Team ganz massiv. Eine Kombination aus Projektverantwortung einerseits und Mangel an Entscheidungsfreiheit andererseits ist nicht gut.

Wir müssen allerdings im Auge behalten, dass in Organisationen immer auch das große Ganze berücksichtigt werden muss. Teams können nicht all die Dinge im Blick behalten, die organisationsweit eine Rolle spielen. Häufig betrachtet es daher das Management als seine Aufgabe, organisationsweite Ziele zu formulieren und in diesem Sinne auch in Entscheidungen des Teams einzugreifen. Dies mag seine Berechtigung haben, wenn es um strategische Ziele geht. Wenn es aber dazu führt, dass von außen Einfluss auf die internen Prozesse des Teams genommen wird, kann der Effekt verhängnisvoll sein.

In der Summe spricht all dies für Entscheidungen, die möglichst lokal getroffen werden, in die aber auch der Blick für globale Zusammenhänge einfließt.

Lösung

Eine Entscheidung muss aus dem Kreis der Personen heraus getroffen werden, die für die Umsetzung der Entscheidung zuständig sind und die auch die Konsequenzen der Entscheidung tragen werden.

Dieses Prinzip betont das Zusammenspiel von Verantwortung und Entscheidungshoheit. Es bleibt aber Spielraum, um das Prinzip mit Leben zu füllen:

  • Das Prinzip favorisiert dezentrale Entscheidungen in dem Sinne, dass Entscheidungen generell in dem Personenkreis angesiedelt sein sollen, der letztlich auch die ausgewählte Handlungsoption in die Tat umsetzen wird.
  • Das Prinzip lässt aber zu, dass sich Personen von außen in bestimmte Teamentscheidungen einklinken, um die Berücksichtigung teamübergreifender Belange sicherzustellen, allerdings unter der Voraussetzung, dass diese Personen dann auch die Mitverantwortung für die Konsequenzen aus der Entscheidung übernehmen.
  • Das Prinzip besagt nicht, dass alle von einer Entscheidung betroffenen Personen gleichermaßen in die Entscheidung eingebunden sein müssen. Die Delegation der Entscheidung an eine kleine Gruppe von Personen ist zulässig, sofern sie aus dem Kreis der betroffenen Personen heraus vorgenommen wird.

In jedem Fall verhindert das Prinzip, dass Entscheidungen über die Köpfe der Betroffenen hinweg gefällt werden. Dezentrale Entscheidungen wirken sich damit gleichermaßen positiv auf die Qualität der Entscheidungen wie auf die Motivation von Personen und Teams aus.

Beispiele

1. Selbstorganisierte Teams in der agilen Entwicklung

Innerhalb eines Gesamtprojekts zur Entwicklung einer großen Applikation sind einzelne Teams jeweils für die Weiterentwicklung einer Komponente zuständig. Die einzelnen Teams setzen als Entwicklungsmethode Scrum ein.

In Scrum-Projekten wird, wie in anderen agil durchgeführten Projekten auch, Teams eine größtmögliche Autonomie eingeräumt. Das Team trifft seine Entscheidungen selbst. Es entscheidet, wie viel Arbeit es innerhalb eines bestimmten Zeitraums, beispielsweise eines Sprints, leisten kann und wofür es ein Commitment abgibt. Der Product Owner, der ebenfalls zum Team gehört und als Ansprechpartner verfügbar ist, ist bevollmächtigt, Entscheidungen zu treffen, was die fachlichen Anforderungen anbetrifft. Von außen wird während eines Sprints kein Einfluss auf das Team genommen. Ausnahme ist eine Situation, in der aufgrund komplett veränderter Rahmenbedingungen ein Sprint abgebrochen werden muss, weil er sinnlos geworden ist. Diese Entscheidung kann von außen getroffen werden, wird dann aber auch von außen verantwortet. Dies ist allerdings eine sehr seltene Situation.

IT-Grundlagen und Technologien der Zukunft

Mehr zum Thema IT und Digitalisierung lesen Sie im IT-Channel von buchreport und Channel-Partner knkHier mehr?

Damit haben wir eine Situation, in der wie gewünscht Entscheidungen bei den Personen liegen, die auch mit den Folgen der Entscheidungen leben müssen. Dies gilt im Übrigen auch für den Fall, dass das Team keinen Konsens erreicht und deshalb ein Entscheidungsverfahren anwendet, um die Zerschlagung des Gordischen Knotens zu erreichen, oder es gar zur Delegation der Entscheidung kommt. Auch hier gilt: Niemand wurde übergangen.

Auch wenn das Team weitgehend autonom agiert, ist die Möglichkeit für teamübergreifende Entscheidungen gegeben. Dazu dient in erster Linie das sogenannte Scrum-of-Scrums-Meeting, das regelmäßig stattfindet und in das jedes Team zumindest einen Vertreter entsendet. Hier werden teamübergreifende Themen diskutiert und gelegentlich auch teamübergreifende Entscheidungen getroffen, die dann in die einzelnen Teams hineingetragen werden.

2. Entscheidungen im klassischen Projektgeschehen

Ein IT-Dienstleister führt Projekte im Auftrag von Kunden durch. Das Management übernimmt dabei die Akquisitionstätigkeit. Ist ein Projekt gewonnen, übergibt das Management die konkrete Zusammenarbeit mit dem Kunden bis hin zur Realisierung der Software an ein Projektteam.

Dieses Vorgehen ist nicht unproblematisch, da es die Gefahr birgt, dass im Zuge der Akquisition Annahmen getroffen werden, die sich später als unrealistisch herausstellen. Kern der Akquisition ist es, herauszufinden, wie und unter welchen Bedingungen eine Zusammenarbeit mit dem Kunden sinnvoll ist. Dies betrifft eine Reihe von Punkten: Was kann dem Kunden, zumindest für eine erste Iteration, an Leistung zugesagt werden? Wann ist die erste Lieferung möglich? Welcher Aufwand muss dem Kunden in Rechnung gestellt werden? Welche Unterstützung durch den Kunden ist erforderlich? Und, wenn das Terrain soweit abgesteckt ist, auch die ultimative Frage: Kann dem Kunden überhaupt ein sinnvolles Angebot unterbreitet werden?

Zumindest sollte es so sein, dass diese Fragen im Zuge des Akquisitionsprozesses gestellt werden. Sind für die Akquisition allerdings Manager zuständig, die mit der Umsetzung der gewonnenen Projekte letztlich überhaupt nichts mehr zu tun haben, kommt es leicht zu übertrieben optimistischen Einschätzungen, was die Machbarkeit des Projekts betrifft. Die Folgen muss am Ende das Team ausbaden, das an der Entscheidung gar nicht beteiligt war. Der Projekterfolg gerät so in Gefahr.

In einer agilen Organisation stellt sich das Problem in dieser Form nicht, weil die Idee autonom agierender Teams dieser Art der Projektorganisation entgegensteht. Aber auch in einem eher klassisch operierenden Unternehmen wie dem hier beschriebenen IT-Dienstleister ist es möglich, das Problem zu entschärfen.

Eine Lösung besteht darin, Akquisition und Projektverantwortung organisatorisch nicht voneinander zu trennen: Manager, die ein Projekt akquirieren, werden auch in die Umsetzung des Projekts eingebunden. Ein Manager, der letztlich auch am Projekterfolg gemessen wird, wird alles daran setzen, unrealistisch optimistische Einschätzungen zu verhindern. Dies kann auch gelingen, da er das Projektgeschäft selbst kennt. Die Kombination aus Akquisitionstätigkeit und Projektverantwortung hilft, Fehlentscheidungen zu vermeiden, die nahezu zwangsläufig sind, wenn eine reine Vertriebsabteilung entscheidet, was dem Kunden angeboten wird.

Wirklich befriedigend ist die Situation aber erst dann, wenn das Management auch fachliche und technische Experten in die Entscheidungen rund um die Akquisition einbezieht, idealerweise diejenigen Kollegen, die auch für die Umsetzung des Projekts vorgesehen sind. Nur so gelingt es, sicherzustellen, dass das notwendige Know-how in die Entscheidungen einfließt.

Mit freundlicher Genehmigung des dpunkt.verlags.

 

Andreas Rüping, Gute Entscheidungen in IT-Projekten. Unbewusste Einflüsse erkennen, Hintergründe verstehen, Prozesse verbessern.

  • dpunkt.verlag
  • ISBN 9783864906480
  • 204 Seiten
  • Broschiert: 29,90 Euro
  • E-Book (PDF + ePub + Mobi): 23,99 Euro