In der Höhle des Löwen

Ihr Projekt ist schon anstrengend genug, dann finden Sie heraus, dass Sie 15 PT mehr brauchen, weil die Fachabteilung die Masken mehrfach geändert haben wollte; naja, vielleicht wäre es auch besser gewesen, den Absolventen nicht gleich alleine daran arbeiten zu lassen, aber erfahrene Leute wachsen nicht auf Bäumen. Woher bekommen Sie jetzt den Mehraufwand? Im Festpreis ganz klar vom Kunden. Oder? Haben Sie mal wieder ein „de-facto-Festpreis“, wie Ihr Vertriebler erklärt? Also, auf zum Kunden und mal Tacheles reden!

Vor einigen Jahren traf ich als Projektleiter in einem für den Kunden und meine Firma ambitionierten, wichtigen Projekt nach dem Initialisierungsstress auch schon auf die ersten Hindernisse: die zugeteilten Kundenmitarbeiter konnten ihre Mitwirkungsleistungen nicht erbringen wie geplant. Wir malten uns also Verzögerungen und Streit aus – obwohl wir noch ziemlich am Anfang des Projektes waren. Beide Seiten waren nervös wegen der möglichen Risiken und des ungeheuren Drucks. Ich veranlasste also ein Eskalationsgespräch. Da saßen wir nun vor dem Sponsor, ein älterer, sehr erfahrener Manager, der uns musterte. Wir hatten schön aufgelistet, was wer nicht getan hatte und wohin das führen könnte. Ich glaube, innerlich hat der Sponsor sich halb totgelacht. Äußerlich hat er uns – beide Seiten, auch seine eigenen Kollegen – mit ruhiger, aber sehr klarer Ansage zur Ordnung gerufen: Wir sollten mal die Kirche im Dorf lassen. Wir fühlten uns alle wie ertappte Schulkinder. Und kamen danach wieder sehr gut miteinander aus, ohne dass eine Lösung mit echten Aktivitäten überhaupt nötig war.

Niemand überbringt gerne schlechte Nachrichten – falls doch, sollten Sie mal über Ihre Berufswahl nachdenken. Als Projektleiter gehört ernsthafte Kommunikation nun mal zu Ihren Aufgaben, was können Sie tun?

Die Vorbereitung ist natürlich entscheidend: rennen Sie nicht einfach ins Messer, vor allem, wenn Ihnen Manager gegenübersitzen, die deutlich mehr Erfahrung haben oder rhetorisch geschickter sind als Sie!

Klären Sie vorab wichtige Punkte!

Welche vertraglichen Regelungen sind vorhanden? 

Haben Sie die geklärt?

Oft erwarten Kunden über den Vertragstext hinaus eine Gesamt-Problem-Lösung: Stellen Sie sich vor, in der Werkstatt sagt man Ihnen nach der Reparatur: „Tja, dass wir die Ölablassschraube nicht wieder reinbekommen, ist halt Ihr Problem“. Oft sehen Kunden das genauso – zumal sie mit der Technik nicht immer Erfahrungen haben. Unter „Web-Server im Internet einrichten“ versteht der normale Kunde auch, dass die Installation hinreichend gesichert sein muss. Natürlich sollten Ihnen solche unterschiedlichen Sichtweisen schon früher bewusst sein – spätestens jetzt müssen Sie die erkennen können!

Was wollen Sie erreichen?

Geht es um 15 PT Budget-Erhöhung? Was ist Ihr Minimal-Ziel? Welchen Anteil sind Sie / Ihre Firma bereit zu übernehmen?

Wichtig: Bereiten Sie eine Win-Win-Situation vor, in der möglichst noch alle ihr Gesicht bewahren können. Ein Kundenmitarbeiter, den Sie im Beisein seines Managers vorführen, wird wohl so schnell nicht Ihr bester Freund werden! Gute Manager werden Sie auch daran hindern...

Win-Win ist umso einfacher zu erreichen, wenn Sie sich immer und immer wieder die Ziele des Projektes vor Augen führen: Was will der Kunde eigentlich, wie kommen wir dahin? Welche Ziele sind weniger wichtig? Muss die ausgefeilte Hierarchie-Selbstverwaltung wirklich zum Go-Live vorhanden sein, wenn es knapp wird? Oder kann man auch für zwei Monate mit manueller Pflege leben, wenn dadurch die Anwendung rechtzeitig Nutzen bringt? Nutzt des dem Kunden wirklich, wenn die Anwendung nicht rechtzeitig kommt und man nur noch über Anwälte miteinander kommuniziert?

Sie sollten möglichst sicher sein, dass das Problem mit der Lösung dann aber auch behoben ist – schließlich möchten Sie eher nicht noch mal vorstellig werden, um weitere 10 PT zu bekommen, oder? Andererseits dürfen die Schätzungen auch keine Mond-Schätzungen sein: klar, mit 100 PT schaffen Sie das auf jeden Fall. Aber würden Sie 3.000 EUR für einen Ölwechsel bezahlen? Kosten und Nutzen müssen nachvollziehbar bleiben. 

Warum ist es zu dieser Situation gekommen?

Können Sie das sachlich darstellen? Was hätte man tun müssen? „Wir hätten früher eskalieren müssen“ wirkt oft besser als „Ihre Leute haben ja dauernd die Meinung geändert!“.

Zudem sollten Sie auf eine Management-kompatible Darstellung achten: „Also, am 1.3. hat Herr Maier bei uns morgens angerufen und mit Herrn Müller gesprochen. Danach hat nachmittags...“ Verdichten Sie auf die wesentlichen Inhalte. Manager sind ungeduldig, haben wenig Zeit und wollen vor allem: Entscheidungen treffen. Verwickelte Streitgeschichten zeigen oft nur mangelnde Distanz zum Thema und fehlende Professionalität.

Gerne werden hierzu auch Listen von Verfehlungen aufgestellt. Ich wundere mich immer wieder, dass Projekte mit Akribie und viel Arbeit derartige „Munition“ erstellen – sollten die nicht eigentlich Probleme lösen und Nutzen schaffen? Welchen Nutzen hat eine Beschuldigungsliste? Ja, ich weiß auch, dass es nicht nur gute Manager gibt, und dass man in der ein oder anderen Situation eine solche Aufstellung zumindest in der Tasche haben sollte. Meist zeigt dies aber, dass schon länger etwas nicht stimmt im Projekt: Kommunikation, Kalkulation, Risikomanagement, Zielvorgaben? Hätten Sie das dann als Projektleiter nicht längst klären sollen?

Bereiten Sie sich auch mental vor!

Wenn Sie unter Hochdruck im Besprechungsraum eintreffen – hilft das bei der entspannten Lösung? Zum Beispiel beginnen solche Gespräche auch gerne mal mit Smalltalk, um eine menschliche Basis zu schaffen. Schließlich repräsentieren wir alle nicht verfeindete Sekten, sondern Firmen und Organisationen. Und wir arbeiten eher, um zu leben, und nicht als einziger Lebensinhalt!

Bleiben Sie also gelassen: so mancher Kunde hat schon viel schlimmere Gespräche mit seinen Dienstleistern geführt! Versuchen Sie sich durchaus, mal von dem Schuldempfinden des engagierten Projektleiters freizusprechen! Letztlich gehen Dinge einfach auch mal schief. Gerade in den agilen Verfahren versucht man intensiv, aus Fehlern und auch aus Erfolgen zu lernen – nichts ist auf Dauer wirkungsvoller, da Mitarbeiter und Kunden rational mit ihren Erfahrungen umgehen können. Denn die meisten Projektmitarbeiter, die ich kennengelernt habe, identifizieren sich sehr mit ihrer Arbeit und wollen sie so gut wie möglich erledigen.

Begegnen Sie dem Löwen auf Augenhöhe!

Will sagen: der auf der anderen Seite ist auch nur ein Mensch. Stellen Sie eine Kommunikationsbasis her. Sprechen Sie ruhig, auch wenn sich jemand mal aufregt! Beruhigen Sie Kollegen, die emotional werden. Sie glauben gar nicht, wie viele Manager künstliches Aufregen sehr gut beherrschen. Und versuchen Sie, den anderen ausreden zu lassen.

Visualisieren Sie – wenn es irgendwie geht – und betonen Sie Gemeinsamkeiten.

Zudem empfehle ich das Harvard-Konzept, es sei denn, Sie haben schon mehr als zehn Jahre Erfahrung im Einkauf oder Verkauf hinter sich.

Ein Kollege, der mich rhetorisch sehr beeindruckte, hatte die Angewohnheit, nach Antworten der Gesprächspartner erst mal zu schweigen und nachzudenken. Absichtliche Spitzen, rhetorische Fallen und Aufgeregtheiten liefen so ins Leere. Ich gestehe aber, dass ich an dieser Fähigkeit noch arbeiten muss...

PS: das eingangs erwähnte Projekt wurde zu einem der erfolgreichsten meiner Laufbahn.

Ist noch was zu retten?

Ihr Projekttermin kommt rasend näher, und Sie haben den Eindruck, es bewegt sich nichts? Und die neue Version des Application Servers funktioniert gar nicht so reibungslos im Cluster wie Sie dachten. Und die Performance der Java-Batch-Läufe macht den Tagesabschluss eher zu einem Dauerläufer, der tagsüber die Dialoge runterzieht wie Blei.

Sie haben dem Projektleiter schon zum dritten Mal erklärt, dass JUnit-Tests extrem wichtig sind und Sie nicht darauf verzichten sollten, auch wenn die nächste Schnittstelle dringend fertig werden muss?

Nun sind die wenigsten Projekte „Death March Projects“, die gestoppt oder kernsaniert werden müssen. Was können Sie in einem „normalen“ Projekt denn überhaupt retten? Und warum?

Ganz einfach – machen Sie sich das Leben leichter! Der Burn-Out-Mode, in dem Ihr Team versucht, das Projekt zu stemmen, ist nicht lange machbar. Normalität kann wieder einkehren, wenn Sie klare Ziele verfolgen – und die auch erreichen können.

1. Ziele erkennen

Kennen Sie die Ziele Ihres Projektes? Kennen Sie die Ziele auch so gut, dass Sie entscheiden können, ob der Batchlauf optimiert werden muss oder auf einem anderen Server laufen kann?

Ziele zu erkennen ist nicht immer einfach. In Kundenprojekten kann man sich daran orientieren, was für den Kunden nutzen schafft. Und das ist oft eine Geschichte voller Missverständnisse... Braucht der Kunde wirklich die hochintegrierte Gesamtlösung ab Go Live? Oder kann man auch mal für einige Monate mit Datei-Transfer wie bisher leben?

Oberstes Gebot ist die Analyse der Stakeholder: wer hat welche Interessen an dem Projekt? Auch Ablehnung und jahrelange Streitereien um Tabu-Themen sollte man besser kennen. In der Regel entscheidet derjenige, der das Geld gibt.

Oft verfügen Fachabteilungen über die Budgets, haben aber wenig IT-Hintergrundwissen. Dies resultiert häufig in impliziten Zielen:

• die Lösung muss nicht „Klicki-Bunti“ sein – aber unansehnlich und unverständlich in der Bedienung soll sie auch nicht sein
• Natürlich (!) soll der Benutzer sein Kennwort ändern können... Aber in welchem System? In Ihrem, das dem ID-Managementsystem das neue Kennwort mitteilt?
• Schnittstellen sollen für alle zu übergebenden Fälle stabil sein. Früher Dateien, heute Web Services. Ist doch fast dasselbe?

Also müssen Sie implizite Vorstellungen eingrenzen, wenn Sie dies nicht am Anfang getan haben, dann holen Sie es nach. Dies heißt nicht, dass die Fachabteilung „wünsch dir was“ spielen kann, weder in Festpreis-Projekten noch in Aufwandsprojekten!

2. Ziele priorisieren

Explizite Ziele sind häufig plakativ kommuniziert von den Stakeholdern. Schwierig ist dabei die Priorisierung: benötigt die Fachabteilung wirklich die komplexe Anbindung an das SAP-System oder ist man eigentlich schon mit einer lose gekoppelten Datenverwaltung zufrieden? Dies erfordert gerade in Krisensituationen eine klare Kommunikation und gute Darstellungsfähigkeiten. Oft muss erst ein gemeinsames Problemverständnis entstehen: „wir sitzen alle in einem Boot“.

3. Realistisch planen

Viele Kunden sehen gerne Gesamtpläne über Zeiträume von durchaus mehreren Jahren. Andererseits fordern sie auch gerne Änderungen, weil sich ihr Geschäft – natürlich – in der Zwischenzeit ändert. Die erfolgreichsten Unternehmen passen sich schnell dem Markt an. Versuchen Sie also einen REALISTISCHEN Plan für den naheliegenden, überschaubaren Zeitraum aufzustellen. Realistisch heißt: mit Puffern. Wer ohne Puffer plant, fährt quasi ohne Gurt und Airbag. Versuchen Sie vor allem, Ihrem Kunden zu erklären, dass langfristige Pläne nur sehr, sehr grob sein können – das kann unterstützt werden durch einen Blick auf bekannte Änderungshäufigkeiten des Kunden oder mit absehbaren Marktänderungen.

4. Offener Umgang und Win-Win-Situation schaffen

Stellen Sie Vertrauen her – durch Transparenz und Verfolgbarkeit. Erst in einer halbwegs vertrauensvollen Situation wird es Ihnen gelingen, eine Win-Win-Situation zu finden, die beiden Seiten nutzt.

Win-Win heißt z.B.: der Kunde bekommt die wichtigsten Funktionen zum Termin, alles andere wird zurückgestellt und neu bewertet. Vielleicht braucht er später ganz andere Funktionalitäten, als ursprünglich mit einem Vorlauf von mehreren Monaten mal geplant? Alternativ können Sie – nur mal als Überlegung – ja etwas ausliefern, was der Kunde den Buchstaben des Vertrages mal wollte. Ob ihm das dann irgendeinen Nutzen bringt? Nutzen Sie also den Nutzen Ihres Kunden! Helfen Sie ihm, den Nutzen zu verwirklichen.

5. Richtig eskalieren

Wenn Sie sich nicht in einem Death March Project befinden – was und wann sollten Sie dann eskalieren? Hüten Sie sich davor, jeden Kleinkram als Staatskrise auszugeben. Finden Sie vielmehr eine Verständigungsebene mit Ihrem Kunden, auf der Dinge unaufgeregt geklärt werden können. Das geht vor allem leicht, wenn man einen Kanal aufgebaut hat durch regelmäßige Termine, auf denen auch mal Erfolge berichtet werden. 

Rette sich - wer kann?

Wenn es brennt oder bei einem schweren Unfall rufen wir die „Rettungskräfte“: Profis wie Feuerwehrleute, Sanitäter, Notärzte und Polizisten, die für solche Situationen ausgebildet sind und wissen, was zu tun ist. Wenn es in Ihrem Software-Projekt soweit gekommen ist, dass Sie externe, professionelle Retter in Anspruch nehmen müssen: mein Beileid. Dann ist es eher fünf nach als fünf vor Zwölf.

Retten sollte also früher beginnen, zum Beispiel:

Im Angebot sind das geplante, iterative Vorgehen und die dafür notwendigen, zeitnahen und arbeitsintensiven Abnahmen durch den Kunden nicht dargestellt. Wer ist dafür zuständig? Ihr Vertriebler? Der Geschäftsführer? Weiß er, dass Sie glauben, dass er zuständig sei? Weiß er, was Sie benötigen?

Die Design-Agentur hat Ihr Kunde ausgewählt, die „Pixelschubser“ liefern ja auch nur zu – das aber mal wieder zu spät. Klar, im Vertragswerk ist schön abgegrenzt, wer für was zuständig ist. Also kümmern Sie sich nicht drum, richtig? Und der Kunde muss schließlich selbst seine Dienstleister steuern! Kann er das? In wie weit ist Ihr Erfolg abhängig davon, dass am Ende wirklich etwas bei dem Projekt herauskommt?

Sie sind Entwickler und kommen spontan als Unterstützung in das hippe Web-Projekt: man braucht nämlich mal eben einen Java-Profi, der die Daten von der Web-Anwendung in das Buchungssystem in SAP bringen kann, und mit Java ist der SAP-Zugriff ja technisch eher einfach. Alle sind gut drauf – nur Sie haben so etwas schon mal gemacht: mit viel mehr Aufwand als den zehn geplanten Tagen, weil die Fachlichkeit nicht geklärt war. Eskalieren Sie – und sind der Spielverderber?

Sie wundern sich, dass in Ihrem neuen Projekt der Projektleiter die Aufgaben kleinteilig vorgibt, bis hin zur Struktur der Entity Beans der Persistenzschicht. Sie haben das ungute Bauchgefühl, dass die Schnittstellen zwischen den Komponenten nur durch den Projektleiter geprüft wurden. Die Entwickler untereinander reden auch nicht miteinander, man arbeitet vor sich hin. Ob das gut geht?

Die Rettung des Projektes sind: Sie selbst! Fühlen Sie sich in professioneller Verantwortung zuständig – unabhängig von der Rolle im Projekt. Vermeiden Sie aber, sich zu sehr in fremde Verantwortungsbereiche einzumischen und prüfen Sie sich selbst, ob Sie gerade den „Projektkümmerer“ darstellen.

Reden ist immer nützlich in Krisensituationen, einerseits. Andererseits sagt man: melden macht frei. 

Was hilft also?

1. Reden Sie mit den Verantwortlichen, oder mit denen, die Sie dafür halten.
2. Erkennen und benennen Sie Ihre Annahmen explizit: „Ich vermute, dass Sie für die Vertragsgestaltung zuständig sind, ist das korrekt?“. Versetzen Sie sich mal gedanklich in die Lage des vermeintlich Verantwortlichen - was kann er, was braucht er? 
3. Bei Gleichgestellten wie z.B. anderen Projektleitern oder Entwicklern ist es hilfreich, Interesse und eigene Kompetenz zu demonstrieren. Gedankenaustausch und unverbindliche Gespräche nehmen viele Menschen eher an als gute Ratschläge.
4. Überlegen Sie sich Lösungsvorschläge, vor allem Manager lieben es, aus Alternativen auszuwählen: das verringert ihre Arbeitslast. Wenn Sie dafür nicht genügend Hintergrundwissen haben, schlagen Sie Experten vor, die an der  Lösungsfindung mitwirken können.
5. Zeigen Sie Konsequenzen auf, möglichst mit ganz konkreten Auswirkungen oder Beispielen aus Projekten: „Die SAP-Integration hat damals das zwanzigfache gekostet, weil wir die fachlichen Prozesse auch noch klären mussten“.
6. Manchmal hilft so gar nichts und man will nicht immer als „Meckerfritze“ darstehen. Dann geht nur noch: vermerken. Schriftlich – heute normalerweise als e-Mail – mit einer Zusammenfassung, etwa nach einem Gespräch zu dem Thema. Das rettet nicht das Projekt, hilft aber den professionellen Rettern, wenn’s denn gekracht hat.

Auch als Entwickler unter einem mitunter nicht interessierten Projektleiter hat man Möglichkeiten: so kann man sich aus den agilen Methoden einfache Maßnahmen abschauen:

• Stand Up Meetings: maximal 15 Minuten, nur das Team, jeder erzählt, was er getan hat, was er tun wird und was ihn behindert. Hilft bei Informationsflut und schwacher Projektorganisation.
• Gegenseitige Code-Reviews: aufwändig, zugegeben, aber effektiv. Alle Beteiligten müssen dann aber auch lernen wollen!
• Kundenfeedback: auf Termine mit dem Kunden drängen – Feedback einsammeln.
• Ziele klären: Ziele kann man nur erreichen, wenn sie glasklar sind. Dazu gehört auch, die Ziele zu verstehen, sie zu hinterfragen und Risiken zu benennen.
• Überschaubare Schritte: Der Projektleiter will Sie erst in vier Wochen wiedersehen? Setzen Sie sich im Team Wochenziele! 

Eigenverantwortung kann viel bewirken - suchen und nutzen Sie die Ansatzpunkte! 

Primus inter pares

Ein Projekt in der Krise: Ziele wurden nicht erreicht, Termine drängen, Mitarbeiter sind frustriert und überarbeitet. Nehmen wir mal an, Sie können mit Wochenend-Arbeit doch noch - realistisch - etwas erreichen, etwa, um die peinlichen Fehler in der Auslieferungsversion für die nächste Woche zu beheben. Sie müssen also dem Team verkünden, dass am Wochenende gearbeitet wird. Unschön. Macht keinen Spaß, weder Ihnen, noch dem Team. Sie selbst können zur Fehlerbehebung wenig tun, weil Sie den betroffenen Teil fachlich nicht mal ansatzweise kennen. Wenn das Team also am Samstag und vielleicht sogar am Sonntag arbeiten muss - sind Sie dann vor Ort oder zu Hause?

Das Team sitzt im Großraumbüro. Schön ist es nicht, aber man macht das beste daraus. Weil keiner mehr konzentriert programmieren und debuggen kann, wenn nebenan jemand lautstark redet, hat sich das Team selbst auf "ground rules" geeinigt: rausgehen zum Telefonieren, Gespräche am Schreibtisch nur in gedämpfter Lautstärke oder verlagern in den Besprechungsraum, Schreibtischtelefone und Handys leise oder lautlos stellen. Das läuft nach Eingewöhnung gut, jeder macht andere auch freundlich auf die Regeln aufmerksam, wenn nötig. Der Projektleiter will dem Team näher sitzen, zieht in das Großraumbüro um - und telefoniert dauernd. Und laut. Und stellt sein Handy nicht leise. Darf er die "ground rules" ignorieren?

Ein Unternehmen im Wandel: man ist bequemer geworden, springt nicht mehr auf jedes Thema an - und hat den Anschluss an die Marktstandards verpasst. SOA? Heute ein alter Hut, ein Commodity-Feature wie Web-basierte Oberfläche (gut, das ist übertrieben...) - aber schwierig für das Unternehmen. Die Geschäftsführung strampelt, um den Laden wieder profitabel zu machen, ein neuer Entwicklungschef wird eingesetzt, die Mitarbeiter dürfen nicht mehr im Home Office arbeiten (zumindest nicht als Arbeitszeit) und die Kernzeiten vor Ort werden strikter geregelt. Der Entwicklungsleiter muss wichtige Unterlagen vorbereiten für eine Besprechung. Da es im Büro stets hektisch ist und er häufig im Zentrum der Kommunikation steht, zieht er sich nach Hause zurück. In der Woche, wohlgemerkt. Darf der das?

In einem Unternehmen herrscht eine strikte Politik bezüglich Hardware-Ausstattung: die Mitarbeiter haben Desktops oder Laptops auf Windows-Basis, lediglich die beiden Grafiker und Web-Designer haben schicke 17-Zoll-iMacs. Der Projektleiter eines großen Web-Projektes für einen Kunden beantragt ein MacBook Pro: schließlich muss er die Mac-Formate der Kreativen verwenden und bearbeiten können. Ist das noch OK?

Ein Projektleiter ist vor allem "primus inter pares" - erster unter Gleichen: zumindest wird er so wahrgenommen. Natürlich gibt es Statussymbole, selbst in Organisationen, die nichts auf teure Autos oder schicke Hardware setzen, gibt es die. Und sei es nur die Kaffeetasse von einer elitären Konferenz etc. Unterschiede bleiben, der Projektleiter ist aber vor allem gut beraten, seine Truppe nicht alleine zu lassen. Versetzen Sie sich mal ein paar tausend Jahre zurück: Würden Sie gegen einen übermächtigen Säbelzahntiger antreten, wenn Ihr Anführer lieber in der Höhle bleibt?

"Primus inter pares" bedeutet schlicht: ordnen Sie sich den Regeln unter, die Sie selbst (oder das Team sich selbst) erlassen haben! Unbedingt! Auch wenn Sie die höchste Hierarchiestufe haben, der am härtesten arbeitende Mitarbeiter des Projekts sind und den Auftrag schon fast ganz alleine geholt haben: Ihr Job ist es, dem Team die Arbeit zu ermöglichen. Und nicht im Weg zu stehen. Wenn der Laut-Telefonierer fünf Mitarbeiter von der Arbeit abhält: was das wohl kostet? Bringt er damit sein Projekt nach vorne? Und zeigen Sie dem Team, dass auch Sie mitleiden: bei Samstagsarbeit und mit der womöglich hässlichen Laptop-Hardware.

Jede Regel hat auch Ausnahmen. Wenn man sich nur noch zu Hause konzentrieren kann: ist dann nicht schon was an der Arbeitsorganisation falsch? Zu wenig Delegation und zu viele Zuständigkeiten in einer Hand? Und ja, Ausnahmen soll und darf es auch für das Team geben: wenn der Installateur gelegentlich kommen muss, dann arbeitet der Mitarbeiter halt mal zu Hause. Das Team-Zugehörigkeitsgefühl wird dadurch in einem funktionierenden Team nur verstärkt. Und das wirkt auf Produktivität und Identifikation des Mitarbeiters mit der Aufgabe wahre Wunder.