Fragt einfach, wie ihr euch verbessern könnt

Gemäß den Grundsätzen des Lean Management haben wir in den letzten Wochen mit vielen Kunden diskutiert. Wir haben sie gefragt, was sie persönlich von unserer Arbeit halten. Also ihre Einschätzung, wie wir als Presales-Team arbeiten, und nicht die Leistung des Unternehmens als Ganzes oder die derzeitige Kundenzufriedenheit. Und wer könnte diese Frage besser beantworten als jeder Vorgesetzte? Unsere Kunden!

Inzwischen haben wir glücklicherweise eine ganze Menge Übung darin. Wenn man das zum ersten Mal macht, braucht man einige Überredungskünste und es fühlt sich auf beiden Seiten komisch an. Kundenbefragungen zu Produkten oder Dienstleistungen sind uns vertraut.  Dass Beraterinnen und Berater  darum bitten, kritisiert zu werden, fühlt sich eher seltsam an.

Nach anfänglicher Irritation realisieren die Kunden, dass es uns als Team darum geht, uns zu verbessern. Dieses Verständnis wird durch eine an Lean angelehnte Methode gefördert. Auch dieses Mal waren alle Gespräche großartig. Es gab Komplimente, aber auch einige Erkenntnisse, die schmerzen, und das ist genau der Grund, warum wir das tun.

In diesem Jahr war ich überrascht, wie schnell sich unser Geschäft verändert. Wir haben 2018 einen agilen Presales-Ansatz „Agile Business Accelerator“ gestartet mit der Erwartung, dass etwa 25 % des Marktes iterative Ansätze nachfragen würden. Während der Kundeninterviews stellten wir jedoch fest, dass alle Kunden, die wir befragten, einen iterativen, geschäftsgenerierenden Ansatz benötigten.

Die Kunden haben dies in ihrem Stil und in der Kultur der Unternehmen sehr unterschiedlich dargestellt. Vielfach verwenden sie nicht einmal das Wort „agil“. Ich halte dies für sehr wertvoll, geschäftliche Werte sind gefragt, und wir finden gemeinsam eine passende Methodik.

Vielen Dank für eure Bereitschaft und Offenheit!

Generative

Über Transparenz

Vor einigen Jahren nahm ich an einem Antrittsvortrag einer Bereichsleiterin teil, in der sie aktuelle Zahlen aus ihren Berichten analysierte, Ungereimtheiten feststellte und ein Resümee zog. Sie kam zu dem Schluss, dass diese Diskrepanzen auf vorsätzliche Vertuschung hinwiesen. Ein Umstand, den sie ändern werde. Denn nur ein transparentes System bietet den Menschen die Möglichkeit, zielgerichtet zu handeln.

Dem letzten Satz schließe ich mich mit all meinem Wissen und meiner Erfahrung an. Schummeleien, geschätzte Zahlen oder Schlamperei in Verbindung mit einem 80er-Jahre-„Management by Objective“-Apparat sind der bestmögliche Nährboden für Missmanagement. Sie führen bestenfalls zu Frustration in einzelnen Bereichen, wenn zwar alles nach den Vorgaben passt, aber das Gesamtergebnis schlecht ist.

Mein eigenes Fallbeispiel oben hat übrigens nicht gut geendet; es wurde ein neues System geschaffen, das vor allem konsistent war. Das konnte man an den nach und nach geschlossenen Defekten gut beobachten. Ich kann nicht sagen, ob das ursprüngliche intransparente System absichtlich geschaffen wurde. Aber ich bin mir sehr sicher, dass das neue System auf Verschleierung abzielte.

Nun gibt es bestimmte Bereiche, in denen Transparenz nicht erlaubt ist. Die Gründe für diese Einschränkungen der Transparenz sind meiner Erfahrung nach fast immer vorgeschoben. „Wir können Ihnen die aktuellen Zahlen nicht nennen, denn wie Sie wissen, ist einer unserer Unternehmensteile börsennotiert.“ Wenn sich Systeme um Transparenz bemühen, hört sich das meist ganz anders an: „Wir wollen besser verstehen, wie unsere Services bei den Kunden ankommen, also vergleichen wir x und y. Der börsennotierte Teil des Konzerns kann nur auf diese und jene Weise in die Analyse einbezogen werden. Aber auch hier arbeiten wir weiter an verschiedenen Lösungen.“

Es geht darum, was man messen will und was man messen kann. Wer Lean oder Agile versteht, der weiß, dass es eine lange Reise ist. Schafft Metriken, die euch wirklich voranbringen, und das sind im besten Fall Lead-Measures. Vergesst nicht, die vorhandenen Möglichkeiten des „was man messen kann“ kreativ zu nutzen und bessere Bedingungen zu schaffen.

Meiner Erfahrung nach ist wirklich gute Transparenz immer eine Wegstrecke und nicht etwas, das man am Ende erreichen oder gar per Dekret festlegen kann.

Transparaenz

Warum ich Visionen mag

Oft haben Visionen einen schlechten Ruf. Manch einer sieht sie sogar als belanglose Dekoration. Das trifft auf viele Visionen zu. Es gibt global-galaktische Versionen, allumfassende Schöner-Weiter-Schneller-Ausgaben bis hin zu absurden Visionen, die im Wesentlichen als eine Art irreführende Werbung gedacht sind.

Meiner Erfahrung nach können Manager, die nicht viel von Visionen halten, sehr selten in aller Kürze sagen, welche Richtung sie einschlagen wollen. Wenn sie nach der Richtung gefragt werden, sagen sie in der Regel etwas über das Geldverdienen in der Branche, in der sie arbeiten. Aber die Kunden kaufen nicht bei mir, damit ich Geld verdienen kann. Geld ist die Gegenleistung für etwas, das sich lohnt.

Visionen zu haben, kann ein besonders guter Nordstern sein. Bei Programmen oder Projekten lohnt sich ein halbtägiger Visionsworkshop auf jeden Fall, vor allem wenn das Projekt unter Zeitdruck steht. Die Beteiligten wissen dann, woran sie sind und haben weniger Falten auf der Stirn. Sie entscheiden häufiger in eine gemeinsame Richtung. Wenn Probleme auftauchen, sind die alternativen Lösungsmöglichkeiten meist gut vorsortiert.

Visionen sind richtungsweisend für jede Art von Team. Neu gebildete Teams finden sich schneller zusammen. Teamarbeit hat so meist weniger Reibungspunkte. Gerade wenn sich das Unternehmen im Wandel befindet, identifizieren die Beteiligten leichter Ankerpunkte.

Auch Visionen, die zu konkret und zu nah sind, erweisen sich als hilfreich. Vor allem, weil die gemeinsame Beschäftigung mit dem Ziel zur Teambildung beiträgt. Mit etwas Anleitung und Zeit wird der Umgang mit Vision, Mission, Unternehmenszweck, Werten etc. immer professioneller.

Für die Einübung ist es am besten, über sich selbst nachzudenken: Was willst du erreichen? Wie willst du Erfolg haben? Warum willst du genau das? Ähnlich wie oben, wird die erste Antwort auf solche Fragen ein solides „Ähm, äh“ sein. Und das ist schon mal ein Anfang!

Spitzer Bleistift

Eine Frage der Schuld

Ich durfte eine Zeitlang in meinem Berufsleben als Eskalations-Projektleiter in Projekte gehen, die eine erhebliche Schieflage hatten. Meist wurde ich dort extrem kurzfristig eingeflogen und musste mir in wenigen Tagen ein Bild vom Projekt und der aktuellen Lage verschaffen. Dabei hat es mich oft in meiner Arbeit gestört, wenn meine Zeit in diesen ersten Meetings mit gegenseitigen Schuldzuweisungen verschwendet wurde. Weitergebracht hat mich das Thema „Schuld“ nämlich nie. Es ist für die Projekte eher verlustbringend – und ja ich rede über Euro.

Der herausragendste Fall war ein Projekt in dem drei Provider für einen Kunden eine längst überfällige Umstellung umsetzen mussten. Wir waren einer der Provider. Es waren einige Milestones gerissen worden, wir mussten schon Vertragsstrafen zahlen und der Go-Live-Termin schien aussichtslos, da fast nichts fertig war.

Das Projekt wurde von einem externen Projektmanager ausgesteuert, der mir lang und breit erklärte, dass die drei Provider nicht zusammen arbeiten würden und erzählte mir viele Anekdoten. Nach der dritten oder vierten Anekdote fragte ich ihn, was er denn zur Lösung dieser Situation versucht hat, darauf bekam ich keine überzeugende Antwort. Das war schon mal kein gutes Zeichen.

Mit den Vertretern des eigenen Teams und der anderen beiden Provider kam es zu massiven Schuldzuweisungen. Sowohl innerhalb, als auch Außerhalb der Teams. Es wurde lang und breit immer wieder in diese Diskussionen verfallen. Es gelang mir kaum, mit den Beteiligten die wichtigsten nächsten Schritte zu besprechen oder gar einen Schlachtplan für die nächsten Wochen aufzustellen. Immer wieder ging es um Schuld. Irgendwann kam mir der Gedanke, den ich auch laut ausgesprochen habe „Okay, ich stelle mich als Sündenbock zur Verfügung, ich nehme alle Schuld auf mich!“.

Die nächsten 4-5 Schuldzuweisungen – die natürlich aufkamen – nahm ich an und sagte: „Stopp, ich habe die Schuld daran, das hatten wir doch vereinbart“ und diese Diskussionen endeten. Das tat ich auch bei Mitarbeitern der anderen Provider, die in anderen Projekten unsere Mitbewerber waren. Das sorgte für ein wenig mehr Konzentration in der großen Runde. So das wir genug Material hatten um die wichtigsten Themen in einer verkleinerten Runde am nächsten Tag zu besprechen.

In dem Projekt selbst war ein entscheidendes Hemmnis anscheinend nicht angegangen worden, es fehlten allenthalben die Zuarbeit des Kunden. Deshalb stockte es sogar bei den Teams, die durchaus eigenständig hätten arbeiten können. Auch kam es mir komisch vor, dass Vertragsstrafen gezahlt werden, obwohl auf Kundenseite fast keine Ansprechpartner benannt waren.

Der Projektleiter sagte mir, dass er dafür nicht zuständig sei, er erklärte mir mit vielen Worten warum dies nicht in seinem Auftrag abgedeckt ist. Mir war das an der Stelle schon lange zu bunt, also traf ich mich mit den anderen beiden Providern und ging zum Kunden. Mithilfe des Vertriebs hatten wir hochrangige Ansprechpartner, die sich entsetzt zeigten und sowohl für eine (etwas) bessere Unterstützung sorgten, als auch die Pönaleforderungen sofort stoppten. Das war tatsächlich etwas Glück, Überraschungsmoment und vor allem dem gut vernetzten Vertrieb zu verdanken.

Am nächsten Tag kam der Projektleiter mit einem kleinen Stapel Papier in das Büro – seinem Vertrag – und wollte mir schriftlich Darlegen, dass er nicht zuständig sei. Ihm schwante, glaube ich schon nichts Gutes. Ich fragte ihn, ob er mir jetzt wirklich erklären will, dass er für eine monatliche Einsparung eines unteren 5-stelligen Betrages für seiner Auftraggeber nicht zuständig sei.

Das Projekt haben wir drei Provider dann gemeinsam noch einigermaßen retten können. Es hat sich irgendwie schnell ein guter  Kampfgeist im Projekt entwickelt. Den Projektleiter haben wir einstimmig aus seinen Verträgen entlassen und – jeder in seiner Organisation – einige Teammitglieder so gut es ging ausgetauscht oder mit Freelancern ergänzt. Wir haben dann gegenseitig Aufgaben übernommen, Testsysteme bereitgestellt und es fast pünktlich geschafft. Die notwendigen Abnahmen konnten gerade noch rechtzeitig meist auf Beta-Ständen eingeholt werden, Version 1.0 konnte nur allerwichtigste Funktionen und die finale Version kam 6 Wochen zu spät.

Ein anfangs sehr erboster Fachbereichsleiter des Kunden hat zum Schluss sogar geholfen, das die 6 Wochen Verzug vermutlich nur wenigen Endkunden aufgefallen sind. Es waren alle stolz auf die Arbeit und Mitbewerber fanden es schade nun zu Projektende auseinander gehen zu müssen.

Aber ich wollte ja über Schuld schreiben. Die Schuldzuschreibungen haben uns gar nichts geholfen. Wobei wenn ich so recht bedenke, die am lautesten über Schuld gestritten haben, waren die Personen, die wir austauschen mussten. Nicht zu schuldig sein und andere zu beschuldigen, bedeutet nämlich ganz oft, keine Verantwortung übernehmen zu wollen.

Ich habe diesen Satz „Okay, ich nehme alle Schuld auf mich!“ noch oft eingesetzt. Denn ich habe in keinem dieser angebrannten Projekte jemals erlebt, dass es wirklich diesen einen Schuldigen gab. Das dichteste was ich an „Schuld“ erlebt habe war Inkompetenz. Wenn Firmen Personen in Projekte schicken, die nicht die notwendige fachliche Kompetenz haben und dann Mist bauen, dann reden wir auch hier nicht über Schuld, sondern einen Mangel an Professionalität.

Schuldzuweisungen führen fast immer zu einer Verantwortungslosigkeit, die oft mit finanziellem Schaden einhergeht. Es gibt tatsächlich einen Schlag von Mitarbeitern, denen nicht wichtig ist, dass ihre Firma Geld verliert. Sie sind ja nicht Schuld an dem Problem, sondern ein anderer.

Projekte und Organisationen, die als Teil ihrer Kultur Schuldzuweisungen pflegen, sind in den meisten Reifegrad-Modellen tatsächlich Reifegrad Null. Das hat auch einen guten Grund, nicht nur das es nervt dort zu arbeiten, sondern Schuldzuweisungen wirken wie Betäubungsmittel in der eigenen Entwicklung. Ein Streben nach Effizienz oder gar Innovation ist in solchen Organisationen nicht in der Mehrheit, weil Exploration immer Gefahr, Fehler und Stolpern mit sich bringt.

Man findet in Projekten diese Art von Kultur tatsächlich öfter als man denkt. Meist in einer Art sinnfreiem Sündenbock-Prinzip, die Schuldigen haben eigentlich keine Konsequenzen zu erwarten, beim nächsten Projekt sitzen sie auf der anderen Seite und dann bestimmen sie den nächsten Sündenbock.

Wenn Menschen einen Sündenbock brauchen, so ist das zwar verständlich aber schlichtweg ein Mangel an Kultur.

Was habe ich aus dieser Zeit mitgenommen:

  • Schuldzuweisungen sind weder produktiv, noch lösen diese Probleme
  • Eine Sündenbock-Kultur fördert verantwortungsloses Verhalten, das kostet immer Geld. Auch fehlende Effizienz ist bares Geld.
  • Ungerechte Schuldzuweisungen sind gigantische Demotivatoren für Projektmitarbeiter
  • Eine Vorgeschichte des Ignorierens oder killen der Messenger ist eine große Hypothek für Projekte. Probleme verschwinden nie, aber die Überbringer der schlechten Nachrichten werden still. Probleme in der Endphase kosten eine Menge Geld. Hier muss versucht werden Vertrauen zurückzugewinnen.
  • In komplexen Projekten oder in empirisch fortschreitenden Projekten sind Fehler unvermeidlich und müssen als Antrieb genutzt werden. Schuld hat da nichts zu suchen.
  • Wenn es gelingt den Blick aufs Ganze zu lenken, wird auch aus manchem „nicht zuständigen“ ein ganz passabler Projektmitarbeiter.
  • Gewonnenes Vertrauen kann sogar einen von seinem Management als Sündenbock geschlagenen und getretenen Mitarbeiter motivieren. Ist mir einmal gelungen, dieser gute Mensch war 15 Monate vor Rente, das hat mich sehr gefreut.

Manno, ist IT kompliziert! Ist es wirklich die IT?

Ich „mache ja IT“ oder zumindest so ähnliche Gesprächsanfänge kenne ich nun seit Jahren und dann erzählen mir Bekannte und Freunde von ihren Abenteuern mit IT. Wie kompliziert das alles ist und das IT doch eigentlich das Leben erleichtern soll, uvm. Eine Geschichte geht ungefähr so, Namen und Rollen wurden absichtsvoll weggelassen.

Benutzer: „Ich wechsele zum 1.12. in die Abteilung Einkauf und soll einen User im System EiKaSys42 beantragen“
IT: „Das machen sie im UserPortal, ich kopiere ihnen den Link in den Chat“
Benutzer: „Dort habe ich schon gesucht“
IT: „Ah, Okay, ich schaue mal… Den finden sie unter Sonstiges→Extern→Einkauf→Verfahren→Rolle“
Benutzer: „OK, Danke“
…10 Minuten später
Benutzer: „Ich kann ohne den Eintrag in den Feldern AssKeyU, EiRoMan und HerNoMo das Formular nicht abschicken. Auch passt meine Personalnummer nicht in das Feld.“
IT: „Dort tragen sie ja auch ihre internationale Personalnummer ein, die ist 6-stellig. AssKeyU steht für den ihnen zugeordneten Key User und EiRoMan für den Bereich. Was HerNoMo ist weiß ich auch nicht, ich bin nur IT“
Benutzer: „Ich kenne aber weder einen Key User noch einen Bereich, auch habe ich noch nie etwas von einer internationalen Personalnummer gehört“
IT: „Da kann ich ihnen nicht helfen, ich bin nur für IT zuständig“

Kennt ihr bestimmt auch, gerade als neuer Mitarbeiter oder bei neuen Verfahren ein sehr beliebter Stafettenlauf. Manchmal dauert es Tage die Informationen zusammenzutragen oder Benutzer raten Einträge zusammen, was im Nachhinein für eine Menge Ärger sorgt.

Ein anderes beliebtes Szenario ist, eine Fachabteilung gibt einen automatisierten Prozess vor, den Benutzer einmal im Jahr oder seltener befüllen müssen. Diese Maschinerie fragt dann ähnliche kryptische Eingaben ab, Zwischenstände lassen sich nicht abspeichern und Hilfefelder enthalten sehr erhellende Einträge wie etwa „Im Feld HerNoMo müssen sie die HerNoMo ihres Bereichs ohne führende Nullen eingeben“.

Wer ist da eigentlich das Problem? Aus Sicht des Benutzers ist das Problem ganz oft „die IT“ sonst würden die mir diese Stories nicht erzählen. Das ist so aber nicht ganz richtig. Ja, es eine ideale IT würde hier beratend tätig werden. Es wäre sehr schön, wenn in der IT ein Projektteam nicht jeden Unsinn in Portale und Workflows gießen würde, ohne betroffene Endanwender und umfängliche Anwendungsbeispiele zu bemühen. Oft wird so etwas in aller Hast als letzte Aktion, bevor ein neue Fachanwendung eingeführt wird, ohne viel Fehlerlesen eingebaut.

Es ist aber auch die Verantwortung der Fachbereiche, Eingaben auf ein Minimum reduzieren. Einen Laufzettel und einen Ansprechpartner für neue Mitarbeiter bereitzustellen. Auch ist es meiner Ansicht – zumindest aus der Sicht des Gesamtunternehmens – gar nicht sinnvoll, fachfremde Mitarbeiter in Fachprozesse zu schmeißen. Die Arbeitszeit die dort durch Unkenntnis der Prozesse, der (nicht intuitiven) Bedienung von Fachanwendungen und falsche, geratene Einträge verschwendet wird, könnte man gut in ein Backoffice stecken, dass den Anwender passende Fragen stellt und ihn höflichst bedient.

Also, tu mir einen Gefallen und baut System und Portale, die Anwenderfreundlich sind, auch wenn es um nicht IT Verfahren geht.