Das Management von Erwartungshaltungen

In Fachbereichen klassischer Industrieunternehmen herrscht nach wie vor fast vollständiges Unverständnis darüber, wie die Werkzeuge entstehen, die sie täglich benutzen.

Es dominieren unrealistische Vorstellungen davon, wie lange Softwareentwicklung dauert und warum. Sie rufen Dir heute eine "Anforderung" zu und fragen, ob Du es nächste oder erst übernächste Woche liefern wirst..

Das führt natürlich regelmäßig zu Enttäuschungen. wenn der Releaseplan "angepasst" wird. Schwierig ist es, wenn die Stakeholder ranghöher sind, als die Projektleitung des Softwareprojektes.

Man landet dann immer schnell beim "Management der Erwartungshaltung". Und es stimmt, dass man Erwartungen der Anspruchsgruppen besser selbst lenkt, als von ihnen gelenkt zu werden. Es ist aber fast immer schwierig, dies von Anfang zu tun. Denn meistens ist man selbst neu in einer eingespielten Szenerie. Man kommt gerade aus irgendeiner Art von Bewerbungsprozess und will nicht als erstes die zugesagte Leistungsfähigkeit zurücknehmen.

Was aber helfen kann, sind Analogien. Wie lange dauert es, bis SAP eine populäre Anforderung seiner Kunden umsetzt? Wie lange dauert es, bis Apple Betriebssysteme so aktualisiert, wie es sie auf seiner Entwicklerkonferenz gezeigt hat?

Manche Stakeholder haben in ihrer Jugend oder im Studium mal selbst programmiert. Hier ein Excelmakro, dort ein Fortran- oder C-Programm. Codiert, kompiliert, von Fehlern bereinigt, neu kompiliert, fertig. Alles auf ihrem PC. Von diesen eigenen "Programmiererfahrungen" schließen sie dann darauf, wie lange so etwas bei Unternehmenssoftware "dauern kann".

Außer Acht lassen sie: die Periodisierung von Anforderungen, die Verfeinerung, die Abhängigkeitsanalysen, das Testen.

Begründet wird der Druck meist mit: "Wir brauchen das jetzt." Wenn ich sie aber vor einem Jahr nach  ihren Prozessen oder Aktivitäten fragte, kam da nichts bis wenig. "Wir sind ja selbst neu, das Thema ist neu, wir müssen uns erst mal selbst finden. Aber fangt schon mal an. Wir brauchen ja nur eine editierbares Tabelle. Was wir machen ist nicht so kompliziert." Tja, und dann entstehen halt solche Außenwirkungen wie: Der Produktionsstart verzögert sich, wir wissen nicht, ob das Produkt überhaupt kommt usw.

Meine Erkenntnis ist: Es hat keinen Sinn, so zu tun, als sei es diesmal anders. Sage niemals zu, dass Du so schnell wie möglich, einen laufenden Prozess "schon bald" unterstützen kannst. Dass Sie Excel schon bald ablösen können. Sag ihnen zu, dass Du im danach folgenden Zyklus etwas liefern wirst. Nimm Dir und Deinem Team die nötige Zeit, tiefer zu verstehen, worauf sie eigentlich hinaus wollen. Gehe Top-Down vor, auch wenn sie Dir Bottom-Up oder nur Bottom anbieten. Frage nach den Topzielen, zu denen sie beitragen sollen (Was?) und den bestehenden Prozessen (Wie?). Du wirst dann die Frage beantworten "Womit?".

Obwohl Du ein "Lieferant" bist, muss Du die "Bestellungen" einfordern: Beschreibungen der Abteilungen, die Strategie, die Hauptprozesse. Welche Unternehmensziele wollen sie operativ wie erreichen? Erst dann kommt: Und wie kann IT dabei helfen?

Viele untere und mittlere Manager verstehen selbst nicht, wozu sie eigentlich beitragen sollen. Sie reichen Dir einfach das Genörgel ihrer Mitarbeiter weiter und nennen das "Anforderung". Wenn Du solche nach Prozessen fragst und als Antwort "Papierkrieg brauchen wir nicht" bekommst, weißt Du, dass der Weg bis zum ersten Sprint noch weit und steinig ist.

Wie auf einer Reise musst Du wissen, wo Du ankommen willst. Und zwischen A und B planst Du eine sinnvolle Route. Wenn man Dir das Ziel verschweigt und sagt "plane erst mal nur bis Wanne-Eickel, wir sind ja agil" muss die Warnlampe angehen.

Ferne musst Du die Systemstruktur kennen, in der Du Dich bewegen kannst. Rede mit dem oder den Architekten. Jeden Tag. Sitzt am besten im gleichen Büro und beschreibt die Whiteboards. Macht Euch alles klar.

Wenn Du das Ziel kennst und die Route, kannst Du das richtige Transportmittel auswählen.

Senior xy... was denn eigentlich genau?

Hausintern diskutieren wir derzeit auf vielen Plätzen, was wir künftig besser können wollen. Ein Auslöser dafür sind die Erfahrungen als "Home Officer".

Angefangen von den Ressourcen in der Infrastruktur (VPN-Zugänge), über die zugreizbare Dokumente und Artefakte und Systeme. Bis hin zum Bedarf neuer Tools, die das Skizzieren mit Eddings auf Flipcharts oder Weißtafeln ersetzen können.

Viele Nachzügler und Skeptiker, die erlebt haben, dass das selbstverantwortliche Arbeiten remote tatsächlich klappt, tun jetzt so, als hätten sie es erfunden. Sie setzen sich jetzt an die Spitze der Bewegung und rufen: "Mir nach!"

Mein Projekt lief natürlich schon vorher "modern". Für uns hat sich wenig geändert. Außer, dass uns Budget nur in Schritten freigegeben wird und ich alle paar Wochen in diesen Runden bin.

Ich bin einerseits eigentlich innerlich "gut aufgestellt". Ich habe keinen Einbrund, keine Unterbrechung erlebt und ich musste auch keine Zeit investieren, um Dokumente von irgendwo nach irgendwo umzuziehen und Wikispace zu beantragen, zu warten usw. Auch reizen mich die Poser-Diskussionen der nacheilenden Propheten nicht. Ich habe das alles schon vor fünf Jahren propagiert. Irgendwann wird es langweilig.

Und da wir gut -und zwar nach Standards- dokumentieren, was wir uns selbst -teils unter Schmerzen, und immer mit den Fachbereichen- klar gemacht haben, ist es für mich auch wenig Aufwand, Budgetrunden vorzubereiten. Ich kann alles im Zusammenhang erklären und ausgehend vom großen Lenkungskreis priorisieren. Ich kann sagen, was wir an Implementierung nicht schaffen und wozu wir Fachbereiche nicht befähigen werden, wenn wir 10 oder 20 Prozent weniger Budget kriegen. So wissen die Entscheider, was sie entscheiden.

So weit so gut also. Von außen besehen.

Innerlich aber geht es mir schon wieder so, wie häufig. Wenn das Flugzeug seine Reiseflughöhe erreicht hat, genieße ich eine Weile den Autopilot. Im Homeoffice zumal. Aber die Routine nimmt einem auch ein bisschen den Schwung. Ich dachte erst, mir fehle die körperliche Bewegung und das schlage nun in geistige Trägheit um. Aber was mir eigentlich fehlt, ist ein neues Ziel. Projektziel. Um nicht anfällig für Anfragen von Kollegen zu werden, setze ich jetzt erstmal einen Produktvision-2-Workshop auf die Agenda. Irgendwas mit Standardisierung und Automatisierung und Personalbedarfseinsparung. Ich denke, das wird in der nächsten Zeit gut ankommen..

Am meisten reizt mich daran aber die Frage, wie man da methodisch hinkommt. Klar, wir werden das  ARIS-Mehrebenenmodell nach unten erweitern. Wir werden den ITIL-Servicekatalog dann weiter planen. Und da wir ja auch einer Softwareplattform laufen, muss da auch irgendwas mit Cloud in den Projektsteckbrief. ("Ich will alle 11 Minuten -also immer wenn mir was neues eingefallen ist, deployen können.." ;-).

Aber was bin ich eigentlich? Ich schaue schon gerne über den Tellerrand und weiß gerne, wozu wir was machen. Aber mich öden abgehobene Runden auch an. Ich bin schon gerne da, wo es auch passiert. Auch gerne im direkten Austausch mit den Entwicklern. Und gerne etwas ganz konkretes beisteuernd: Methodik, Kopfwerkzeuge, die Zusammenhänge zwischen Fachbereichszielen und Softwareumfängen.

Aufbruchstimmung im Januar

Der Januar ist für mich der Monat, Neues zu planen und innere Aufbruchstimmung zu erzeugen. Auch wenn die Tage noch kurz sind, und es draußen kalt und stürmisch ist. Im engsten Kreis entwickle ich dann neue Pläne und Zielbilder.

November und Dezember waren großartig verlaufen. In beiden Projekten konnte ich Ergebnisse liefern, die anerkannt wurden.

In dem schwierigeren von beiden war ich schon mit der Entscheidung des Kunden zufrieden, mein Konzept zu beschließen und es ab sofort in der neu gegründeten Organisationseinheit umzusetzen. Das Umfeld in diesem Projekt war und ist äußerst herausfordernd. Sowohl auf Kunden- als auch der eigenen Seite. Wir waren ohne fachliche Kenntnis in ein "strategisches" Modernisierungsprojekt gestartet und unsere Leitung meinte, als Stratege brauche man von der Sache her nicht so viel zu verstehen, weil es nur um Strukturen gehe. Dazu kann ich nur sagen: So redet nur jemand, der sein Leben ausschließlich als Berater verbraucht hat. Strategie folgt immer aus den Zielen des Geschäftszweckes, egal ob es um Produkte in einem Markt oder interne Verbesserungen geht.
Meine Empfehlung lautete: Dann helfen wir dem Kunden eben herauszufinden, was seine Ziele sind, und wie er dort hinkommt. Mein Beitrag war ein möglichst konkretes Konzept und Handbuch für ein agiles Anforderungsmanagement. Gegeben waren nur die jahrzehntealten Altsysteme und ihre Betreuer bzw. Programmierer. Inzwischen haben wir die ersten Geschäftsprozesse analysiert, Anforderungen geklärt und testen prototypenhaft die Umsetzbarkeit mit Standardsoftware.

Extern lief es also gut, intern weniger. Denn meine Projektleiter hat bis heute den Zusammenhang der Dinge nicht verstanden oder gar anerkannt. Sie konnte auch nicht gut damit umgehen, dass ich besseres Feedback bekommen habe als sie. Ich meine: Wenn wir dem Kunden "agil" empfehlen, können wir nicht gleichzeitig Distanz und die Arroganz des Beraters exerzieren.

Mein zweites Projekt war ein konzeptioneller Turnaround bzw. eine Feuerlöschaktion. Der Kunde konnte mit seinem Konzept seine Abstimminstanz nicht überzeugen. Die meiste Zeit war im Herbst verbraucht und bis Weihnachten sollte ein neues Konzept her und die Zustimmung der Abstimminstanz ebenso.
Auch hier ging es um Anforderungsmanagement, aber weniger um Systemmondernisierung sondern Konsolidierung und Standardisierung. Wir besetzten unser kleines Team optimal und konnten mit Erfahrung und Sachkenntnis einsteigen. Auch die Zusammenarbeit mit Projektpartnern startete gut. Interviews und Workshops liefen gut, weil das Kundenteam sofort verstand, dass wir wussten wovon wir sprachen. Und in weniger als zwei Monaten entstand ein neues Konzept, dem die Mitglieder der Abstimminstanz zustimmten. Danach stimmte auch noch das erste Entscheidungsgremium zu. Und diese Woche hörten wir, dass nicht nur nicht gemeckert wurde, sondern sogar gelobt :-).

Was will man als Berater mehr? Was kann mehr bestätigen, dass Beratung nicht von abstrakter Strategie sondern angewandter, systematisierter Erfahrung lebt? So wie Hubraum beim Automotor ist im IT-Geschäft Erfahrung durch nichts zu ersetzen :-)

Zur positiven Erfahrung des vorigen Jahres zähle ich auch die Weiterbildung, die ich genießen durfte. Die meisten Erkenntnisse hatte ich im Architekturmanagement nach TOGAF. Dies versetzt mich noch besser in die Lage, mich künftig mit Architekten abzustimmen.

Also, gut gerüstet und ohne Kater sondern mit Aufbruchstimmung gehe ich ins neue Jahr. Ich sehe es positiv, dass das neue Jahr vor mit liegt. Ich freue mich darüber umso mehr, weil ich lange gegen Widerstände, externe wie interne, ankämpfen musste. Am Ende ging die Runde an mich.

Wie man als Product Owner neue User gewinnt..

Ihr wisst, dass man vieles erst zu schätzen weiß, wenn man es nicht mehr hat. Sigmund Freud erklärte sich das damit, dass der Mensch (bzw. alle Lebewesen) vorrangig den Unterschied sehen, und nicht das, was sie kennen. Die Fokussierung auf den Unterschied diente in der Evolution der Erkennung von Gefahren.

Wenn wir also über Werte, oder Preise, einer Sache sprechen, ist das subjektiv. Nämlich abhängig davon, ob man es hat oder nicht. Wenn man es nicht hat, ist es abhängig davon, ob wir es kriegen können. Das kennt man ja auch: Wer in der Nähe einer Sehenswürdigkeit wohnt, schiebt ihre  Besichtigung auf ewig hinaus. "Das kann ich immer noch machen." sagt man sich, bis zu dem Tag an dem man aus der Stadt wegzieht.

Auch wenn man um diese Zusammenhänge weiß, kann man sich ihnen kaum entziehen, weil sie nicht über den Kopf sondern das Gefühl funktionieren. Trauer um Verlust, oder antizipierend die Verlustangst, kann man kaum durch Nachdenken verkleinern. Sondern durch Erleben, dass es auch ohne geht, oder die Angst unbegründet war.

Man kann sich diese Effekte allerdings auch zunutze machen, wenn man von anderen etwas will. Wer jemanden etwas verkaufen will, muss es seiner Zielgruppe zeigen. Sobald sie Interesse signalisiert, muss man Hürden aufbauen. Das steigert das Interesse und regt Phantasien über das Produkt an. Der, dem wir es vorenthalten beginnt, das Produkt zu idealisieren. Es sich als Lösung für immer mehr Probleme auszumalen. Er wird es um jeden Preis bekommen wollen.

Wenn das jetzt verlockend klingt, muss ich allerdings bremsen. Es ist schwer, seine Rolle als Verkäufer so zu spielen, weil es gegen das eigene Ziel gerichtet ist, verkaufen zu wollen. Hier muss der eigene Kopf den eigenen Bauch beherrschen. Das gelingt nur durch Experimente und erste Erfolge.

Ich erlebe das seit längerem als Product Owner einer Softwarelösung. Zuerst rannte ich allen potenziellen Usern quer durch unseren Konzern hinterher. Ich machte die typischen Demotermine. Und hakte nach, wie ich das vor zehn Jahren bei IBM mal gelernt hatte: "Dran bleiben, nachhaken, anrufen, nerven." Das hat bei mir nur selten funktioniert, nämlich bei denen, die von Anfang an mitmachten. Die also schon überzeugt waren.

Bei den meisten anderen erntete ich Fragen und Einwände. Immer wieder, und es vergingen Monate. Erst als ich aufhörte nachzufragen und daran zu denken, kamen sie zu mir. Plötzlich wollten sie Testzugänge, stellten konstruktivere Fragen, schickten mir Checklisten und Anforderungswünsche.

Ich habe das mehrmals so erlebt. Diese User sahen den Unterschied zwischen meinen Nutzenversprechen und ihrer Arbeitswelt erst, als ich den Raum wieder verlassen hatte. Und dann gingen sie weiter. Sie dachten selbst nach, entwickelten eigene Szenarien. Bis sie es nicht mehr für meine Idee hielten, sondern zum Teil auch ihre eigene.

Und damit sind wir bei einem weiteren psychologischen Effekt: Der Zustimmung zu einer Idee erst dann, wenn man sie für die eigene hält. Aber davon erzähle ich beim nächsten Mal...