Direkt zum Hauptbereich

Feuerwehr Aufträge



"Feuerwehr Aufträge" - keiner mag sie bekommen, aber was kann helfen?

Ein jeder von uns leistet einem anderen früher oder später einen Dienst. Aus dem Tausch von Dienst gegen Moneten ist ein ganzer Wirtschaftszweig entstanden: die Dienstleistung. Berater zum Beispiel erbringen gegen eine oft nicht unwesentliche Menge an monetärer Vergütung den Dienst von Beratung, deren prinzipieller Vorteil neben der zeitlichen Begrenzung der Zusammenarbeit (Zeitarbeit) die externen Perspektive des Beraters gegenüber dem Auftraggeber ist, dessen Blick vielleicht durch operative Aufgaben eingeschränkt ist.
In der IT-Beratung ist allerdings üblich, dass der Berater in vielen Fällen nicht etwa für strategische sondern für operative Tätigkeiten eingesetzt wird, was damit eher den Geschmack von Anstellung bekommt, auch wenn IT Probleme per se komplex sind. Die Komplexität allein rechtfertigt die Tagessätze von Beratern in der IT-Branche. Auf operativer Ebene gilt das jedoch als hochbezahlt, denn komplex heißt auch schwer verständlich und damit schwer nachvollziehbar.
Von den inhaltlichen Aspekten zurück zur Vergütung. Wer hochbezahlt ist, an den ist die Erwartung nach hoher Effizienz in der Erfüllung seiner täglichen Aufgaben groß. Ergo delegiert ein Auftraggeber seine (komplexen) Anfragen gern mit engen Zeitvorgaben. Im konkreten Fall von unvorhergesehenen Ereignissen, deren Natur der Sache es ist von Zeit zu Zeit aufzutreten, entstehen „Feuerwehr Aufträge“.

„Feuerwehr Aufträge“ kombinieren komplexe Aufträge und enge Zeitvorgaben mit einem dritten, wesentlichen Aspekt: einer unklaren Verantwortlichkeit. „Feuerwehr Aufträge“ erkennt man an Folgendem:
  • dass sie an einen großen Verteilerkreis adressiert werden, 
  • eine schwammige, unklare Aufgabenstellung enthalten und 
  • umgehend zu erledigen sind.
Zurück zum Berater: Effizient arbeitet, wer schnell zu Ergebnissen kommt. Um also die Erwartungen eines hochbezahlen Beraters zu erfüllen, ist der erste Ansatz die Aufgabe anzunehmen und schnellstmöglich zu erfüllen. Soweit so gut, oder?

Auf den ersten Blick mag der Ansatz Sinn ergeben, denn operativ gesehen ist es erstrebenswertes Ziel, Aufgaben gut und schnell zu erfüllen. Doch auf den zweiten Blick wird deutlich, dass der strategisch Effekt – also die Langzeitauswirkungen - von großem Nachteil werden. Die Qualität der Arbeitsergebnisse und der Zusammenarbeit von Auftraggeber und Berater wird sich verschlechtern:
Der Auftraggeber erkennt, dass seine Taktik „Feuerwehr Aufträge“ funktioniert hat und er wird daher in Zukunft ähnlich verfahren. Beim nächsten Arbeitsauftrag könnte er erwarten, dass die Aufgabe ebenso effizient, wenn nicht sogar noch besser, gelöst werden wird. Er kann die hervorragenden Ergebnisse dann schnellstmöglich weiterverarbeiten. Und noch einen Vorteil hat die Taktik „Feuerwehr Auftrag“ für den Auftraggeber: Er muss sich wenig Gedanken über die Aufgabenstellung, die Terminierung und die Zuweisung der Aufgabe machen. Er muss die Aufgabe nicht managen, denn der Berater übernimmt das Arbeitspaket komplett.
Wechseln wir den Standpunkt: Der Berater hingegen wird in diesem Modus früher oder später an die Grenzen seiner Kapazität stoßen, denn um Zeitvorgaben und Qualität bei steigender Arbeitslast zu erhalten, muss er schlicht mehr arbeiten. Seine Aufgabe besteht nämlich nicht nur darin die Aufgabe an sich zu erledigen, sondern vorab zu klären was genau die Aufgabe eigentlich ist. Das alles in einem engen Zeitplan und vielleicht gepaart mit anderen Aufträgen gleicher Art. Unabhängig vom persönlichen Arbeitsdurchsatz hat die Belastbarkeit bei diesem Spiel in jedem Fall Grenzen. 
Ergo wird der operative Ansatz die Aufgabe zu fassen und zu erledigen langfristig zu Qualitätsverlusten der Arbeitsleistung führen. Aber wo liegt das Problem?

Das eigentliche Problem liegt in der Sache der „Feuerwehr Aufträge“. Sie sind in ihrer Natur grundsätzlich schwierig. Und auch wenn es leicht zu tun ist, es bleibt ein Fehler, Aufgaben zu vergeben, die keine klare Aufgabenstellung, eine unrealistische Zeitvorgabe und keinen klaren Verantwortlichen haben. Es ist ein operativer Fehler im Management, dessen Verantwortung derjenige trägt, der die Aufgabe formuliert oder weiter gibt. Wenn das Management der Aufgaben nicht auch Teil des Aufgabenbereichs der Berater werden soll, dann muss dieses Bewusstsein beim Auftraggeber geschaffen werden. Doch um wiederum diese Aufgabe zu erfüllen, dieses Bewusstsein herzustellen, brauch es strategisch denkende Berater. Und guter Rat ist nun mal teuer.

Kommentare

Beliebte Posts aus diesem Blog

Agile product teams

In this article, I’d like to share my condensed view on agile product development teams. It might help you to find your personal role in such a team or even setup a team based on my blueprint, as a team architect. Let me know, if you need any additional input. I’m happy to learn, help and speak about this topic. In the last years, I gained experience in different projects from delivering individual software with a single small team to developing large IT platforms with multiple agile teams (and non agile management) involved. In parallel, I deduced the principles from frameworks, i.e. Scrum, Kanban, Scrumban, LeSS and SAFe , and adapted them to our specific problems in the project. In the following sections, I will cover the process, the roles and responsibilities inside the team and how to combine them as well as supportive methods and tools to develop products. The following drawing provides an overview of these aspects, which I will describe in greater detail below. Agile...

Leading the agile way

What about leadership in the agile world? Do we still need leaders if we run agile? Due to my experience in agile teams my answer is: "Yes, we need leadership but less managers! " The tasks itself are straight forward. But leading agilely means solving them different, new, agile. That means,no power to micro-managers by transparency. Instead, accomplishment and affiliation driven smart enabler and servant leaders without ego. But this is easier said than done. Lots of stuff is written about working agile. Frameworks, such as Scrum , define the basic team structure, processes and tools about organizing small teams of about 7 people. Other methods, such as SAFe , sketch how to interact between teams and scale agile to enterprise level. And lot’s of best practices (e.g. Spotify engineering culture ) describe how to run agile companies by example. However, I'd like to share my thought on the topic "agile leadership"  I gained from agile projects and teams in the...

Building great APIs - the art of developer experience

Developing successful business by adapting your products to the diverse global market, relies on quick and sustainable technical integration. Hence, designing a great interface (API) is the key for product success today. Classical IT architects, however, don't really care for design, but developer experience people do. I show 5 techniques to design great APIs based on the experience in my last project. Let me start with a story about the importance of integrated systems for customer experience. I'm humanistic nerd and triathlete. So, I enjoy to track and analyze my sport performance. I train with a Polar M400 watch and use training plans from the corresponding cloud service Polar Flow . Now, I missed an additional navigation system to not ride the same track all the time and I'd liked to track cadence, which is, unfortunately, not possible with the Polar M400. However, I neither liked the bicycle computer Polar M460 , since it's just the features of watch in a b...