Kategorie-Archiv: IT-Governance

Die Standish Group, deren Chaos-Report seit 1994 jährlich die Erfolgs- bzw. Misserfolgsquote von IT-Projekten darstellt, kommt auf Grundlage von über 10.000 analysierten Software-Projekten zu einem klaren Befund: „The results for all projects show that agile projects have almost four times the success rate as waterfall projects, and waterfall projects have three times the failure rate as agile projects. … However, note that the smaller the project, the smaller the differenence is between the agile and the waterfall process“ (CHAOS Report 2015).
Agile Ansätze haben allerdings in stark budgetgetriebenen Unternehmen und bei öffentlichen Auftraggebern viele Vorurteile zu überwinden. Ein Dilbert-Cartoon bringt diese sehr gut auf den Punkt. Hier wird Agilität offenbar als das Chaos gesehen, bewirkt aber laut Chaos-Report genau das Gegenteil, nämlich eine höhere Erfolgsrate.

Warum ist der Umgang mit agilen Vorgehensweisen für viele Unternehmen so schwierig? Spitz könnte man sagen, weil Agilität ehrlich ist. Es wird klar gesagt, dass jedes größere Softwareprojekt mit einer Reihe von beträchtlichen Unsicherheiten behaftet ist. Kein noch so genaues Lasten- und Pflichtenheft garantiert, dass alle Eckpunkte des magischen Dreiecks (Ergebnis, Budget, Termin) im Voraus fixiert werden können. Je mehr man versucht, diese Vorgaben zu fixieren, umso schlimmer wird es: zwischen Projektinitialisierung und Fertigstellung vergeht entsprechend mehr Zeit. Selbst wenn anfangs die Anforderungen wirklich vollständig und eindeutig beschriebenen worden wären, durch die Entwicklung der Projektumwelt werden sie bis zum Fertigstellungstermin in großen Teilen obsolet. Je schneller man also liefert, umso eher werden die anfangs getroffenen Annahmen halten.

Dass der Aufwand eines Software-Projektes von sehr vielen Faktoren abhängt, die nur mit vielen Annahmen und entsprechender Unsicherheit prognostiziert und kontrolliert werden können, habe ich in einem anderen Beitrag schon beschrieben. Ist trotzdem eine Kombination von Agilität und Fixpreis möglich? Im Prinzip ja, man muss nur genügend hohe Risikozuschläge akzeptieren. Also de facto nein!

Letztlich gilt hier eine Unschärferelation wie in der Physik. Wenn man eine oder zwei Ecke(n) des magischen Dreiecks genau bestimmt, ist die bzw. sind die verbleibende(n) Ecke(n) entsprechend ungenauer bestimmbar. Also konkret: Ergebnis fix – Aufwand variabel. Aufwand fix – Ergebnis variabel. Und wenn man z.B. nur den Aufwand fixiert kann man sowohl beim Ergebnis als auch beim Termin drehen usw.

Ein Buch macht Hoffnung.

Wenn man es allerdings liest, kommt die Ernüchterung. Es werden durchaus sinnvolle Methoden beschrieben, Aufwandsschätzungen zu erstellen und schrittweise zu verfeinern, die wunderbare Quadratur des Kreises gelingt allerdings nicht. Die Lektüre lohnt sich trotzdem, nur darf man den verkaufsfördernden Titel nicht beim Wort nehmen.

Die Vertragsphilosophie agiler Projekte

Ich habe in der Festschrift für den CIO des österreichischen Justizministeriums versucht, die implizite Vertragsphilosophie agiler Projekte zu beschreiben. Da dieses Buch nicht mehr verfügbar ist, hier eine aktualisierte Darstellung:

Jedes Projekt agiert auf Grundlage von Vereinbarungen zwischen den beteiligten Organisationseinheiten bzw. Unternehmen, wobei diese mehr oder minder explizit und formalisiert sein können. Ob diese Vereinbarungen tatsächlich als schriftlicher und detaillierter Vertrag vorliegen oder nicht, ist unwesentlich. Professionelle Verträge sind immer ein wesentlicher Erfolgsfaktor, wenn allerdings ein Vertrag in Widerspruch zum tatsächlichen Vorgehen im Projekt steht, behindert dies die Projektarbeit ebenso schwerwiegend, wie ein guter Vertrag diese wesentlich erleichtert. Daher wird hier von einer Vertragsphilosophie gesprochen, die dem Handeln aller Beteiligten zugrunde liegen sollte, wenn ein Projekt mit sinnvoll eingesetzten agilen Elementen abgewickelt werden soll.

Zunächst muss festgehalten werden, dass für wesentliche Teile eines typischen IT-Projektes klassische Vertragsmodelle sinnvoll und notwendig sind, so z.B. für Planungsleistungen, Lizenzen, Infrastrukturleistungen etc. Ebenso gilt dies für die Schätzung des Gesamtaufwandes des Vorhabens (z.B. anhand eines Lastenheftes). Dies ist ja schon eine notwendige Grundlage für die Entscheidung, ob ein Projekt überhaupt gestartet werden soll.

Für jene Teile des Projektes, in denen die Entwicklung und/oder die Anpassung von Software erfolgt, gelten teilweise andere Regeln. So wird für die agil abzuwickelnden Teile des Vorhabens ein passendes Leistungsvolumen (Skills, Kapazitäten, Durchlaufzeit) eingekauft. Die Laufzeit des Entwicklungsprojektes wird in gleich lange Intervalle („Iterationen/Sprints“) aufgeteilt, wobei in jeder Iteration Software geliefert wird, die vom Kunden/Anwender getestet werden kann.

Die Feinsteuerung erfolgt aufgrund einer Aufwandsbewertung der Features („Story Points“/Planaufwand). Die konkreten Iterationsinhalte werden zu Beginn nur grob geplant, nach jeder Iteration erfolgt eine Aktualisierung, die Inhalte der jeweils nächsten und meist auch übernächsten Iteration werden im Detail fixiert.
Ein Spezifikum agiler Projekte ist auch die unveränderliche Iterationsdauer („Time Boxing“), innerhalb einer Iteration nicht realisierte Features werden nicht durch Terminverschiebung nachgeliefert, sondern zurück in den „Backlog“ gestellt und in einer späteren Iteration eingeplant.

Auf Grundlage der tatsächlichen Iterationsergebnisse wird eine regelmäßige Hochrechnung durchgeführt, die je Iteration abgearbeiteten Features („User Stories“) werden in dem für agile Projekte typischen „Burn-Down-Chart“ dargestellt. Letztlich ist dies die allgemein bekannte Earned-Value Darstellung, wenn auch mit umgekehrten Vorzeichen: man zeigt, wie die noch zu leistende Arbeit reduziert wird („burned down“), während der Earned Value die bereits geleistete Arbeit abbildet.
Da am Ende jeder Iteration funktionierende Software geliefert werden muss, zeichnet sich die Fortschrittsmessung solcher Projekte durch eine höhere Aussagekraft und Robustheit gegenüber Fehleinschätzungen des Arbeitsfortschritts aus. Werden Abweichungen vom geplanten Fortschritt je Iteration („Velocity“) erkannt, bleibt auch solchen Projekten nicht erspart, darauf mit den üblichen Maßnahmen zu reagieren, die da sind:
– Projektabwicklung optimieren
– Features streichen/zurückstellen
– Kapazität erhöhen
– Zusätzliche Iterationen und Verschiebung des Endtermins.

Als Auftraggeber von Projekten mit agilen Elementen ebenso wie als Projektmanager muss man darauf achten, die spezifischen Herausforderungen der mit agiler Methodik abgewickelten Projektteile zu erkennen und darauf adäquat zu reagieren. Wird in Projektaufträgen bzw. in Verträgen eine Philosophie der Projektsteuerung festgeschrieben, die das nicht richtig adressiert, gerät man entweder in einen vertragsfreien Raum oder man kollidiert ständig mit Vertragsbestimmungen, die nicht zum tatsächlichen Vorgehen passen.

Generell muss man feststellen, dass agile Softwareentwicklung im Kern auf einer Aufwandsverrechnung beruht, da ein fixer Werklohn mangels detaillierter Ergebnisbeschreibung nicht definiert werden kann. Vieles spricht dafür, auch in einer agilen Welt zu Beginn eine Spezifikation zu erarbeiten, ob das ein „traditionelles“ Fachkonzept ist oder User-Stories, kommt auf die Kultur und die verfügbaren Skills der beteiligten Personen und das Umfeld des Projektes an.

Man darf den Detaillierungsgrad nicht übertreiben und vor allem muss man sich dessen bewusst sein, dass es jedenfalls Veränderungen während der Umsetzung geben wird. Es bleibt also auch hier eine gewisse Unschärfe. Diese wird allerdings nach den Erfahrungen des Autors von Entscheidungsträgern, die agilen Methoden skeptisch gegenüberstehen bzw. damit keine Erfahrung haben, stark überschätzt: Jeder weiß aus eigener Erfahrung, dass Fixpreise trotz detaillierten Lasten- und Pflichtenheften durch Change Requests regelmäßig ausgehebelt werden. Daher erscheint eine Aufwandschätzung mit eingestandener Bandbreite sowie einer darauf aufsetzenden Projektsteuerung durch Burn-Down-Charts als die ehrlichere und de facto auch wirksamere Methode. Man muss allerdings der hier sichtbar gemachten Unsicherheit ins Auge blicken können, wozu nicht alle Auftraggeber bereit und in der Lage sind.
Eine zentrale Herausforderung ist also: professionelle Projektsteuerung ersetzt detaillierte Ergebnisdefinition. Abweichungen werden früh erkannt, können aber nicht an einem vertraglich fixierten detaillierten Pflichtenheft gemessen werden. Daher müssen geeignete Prozesse (auch vertraglich) definiert und gelebt werden.

Sachlich gesehen, ist das Vertrauen in die Angemessenheit der Aufwände des Realisierungspartners ein entscheidender Erfolgsfaktor. Das Aushandeln des Verzichts auf Features, um das Budget und den Endtermin zu halten, funktioniert nur, wenn die vom Auftragnehmer geschätzten Realisierungsaufwände vom Auftraggeber als angemessen und nachvollziehbar gesehen werden. Regelmäßig als überhöht empfundene Aufwandschätzungen können durchaus auf Architekturmängel zurückzuführen und daher in Wirklichkeit korrekt sein, sie sind also einer unzureichenden Projektvorbereitung geschuldet. Damit bleibt aber das Problem gleich, nur die Ursache liegt in der Vergangenheit.

Agile Projekte können daher nur gelingen, wenn es aktive und sachkundige Mitwirkungsleistungen des Kunden gibt, wobei dies im Falle einer externen Beauftragung nicht nur für die Anwenderbereiche („Business“) gilt, sondern auch für die IT-Abteilung des Auftraggebers. Dies erscheint gegenüber einem Wasserfallmodell als Mehraufwand. Ich wage die Behauptung, dass der tatsächliche Gesamtaufwand gut gemanagter agiler Projekte geringer, aber anders verteilt ist als bei Projekten nach einem Wasserfallmodell.

Ebenso gilt: Agiles Vorgehen erfordert eine vertrauensvolle Zusammenarbeit. Dafür müssen Bereitschaft und Fähigkeit zu interdisziplinärer Arbeit und social skills bei allen Beteiligten verfügbar sein.

Nachtrag im Oktober 2019: Im Preview zu SAFe 5.0 gibt es auch eine ausführliche Stellungnahme zur Vertragsgestaltung in agilen Projekten, hier der Link.

Was heißt eigentlich „agil“?

Die Standish Group macht keine klaren Aussagen, wie sie Agilität definiert. Tatsächlich gibt es verschiedene Ausprägungen. Dazu eine Übersicht mit Links zu den Quellen:

Die Grundlage für alles: Das agile Manifest.
Der Marktführer: Scrum.
Leider zu wenig bekannt ist DSDM: Dynamic Systems Development Method.
Verdient ebenfalls mehr Aufmerksamkeit: Lean Software Development.
Flexibel mit anderen Ansätzen gut kombinierbar: Kanban.
Mein Favorit, wenn es in einem Projekt eng wird: Extreme Programming. 
Der Geheimtipp auf Grundlage der „Theory of Constraints: Critical Chain Project Management. 
Eine Integration verschiedener agiler Methoden auf Unternehmensebene, wenn auch starr und überladen: SAFe.
Der ideale Rahmen, um die Vorgehensweise zu finden, die in der konkreten Situation am besten funktioniert:
Disciplined Agile.

Projektmanagement wird oft als administrative Aufgabe verstanden, ich kenne einige Unternehmen, die diese Leistung als Commodity sehen und regelmäßig per Body-Leasing zukaufen. Bei der Auswahl der Projektmanager wird meist darauf geachtet, dass diese zertifiziert sind, in Österreich ist das meist eine Zertifizierung nach IPMA, international dominiert natürlich die Zertifizierung durch PMI. Die Professionalisierung des Projektmanagements, die mit diesen Standards und den darauf aufbauenden Zertifizierungen einher geht, ist grundsätzlich zu begrüßen. Allerdings rückt dabei oft der Bezug zum Projektinhalt  in den Hintergrund und das sehe ich sehr kritisch, denn „Content is King„!

Ebenfalls ein Defizit ist aber auch das Fehlen von Führungskompetenz in Projekten, auch das eine Funktion, die ein externer Projektmanager nur in Ausnahmefällen erfolgreich wahrnehmen kann. Der Unterschied zwischen Management und Leadership sollte immer beachtet werden: Projektmanagement ist delegierbar, Projektleadership nicht.

Was macht nun erfolgreiche Führung aus? In der aktuellen Ausgabe (Mai/Juni 2017) des Harvard Business Review wird über eine Studie berichtet, die 4 Faktoren identifiziert, die erfolgreiche von weniger erfolgreichen Führungskräften unterscheidet. Die Autoren sind Personalberater und die Datenbasis sind ca. 17.000 Assessments von Führungskräften auf Geschäftsleitungsebene.

Was sind diese 4 Erfolgsfaktoren?

1. Schnell und klar entscheiden („Deciding with speed and conviction“)
2. Ergebnisorientierung („Engaging for impact“)
3. Proaktiv handeln („Adapting proactively“)
4. Zuverlässigkeit („Delivering reliably“)

Die Bedeutung dieser Faktoren ist nicht überall gleich, in Branchen mit hoher Veränderungs- und Innovationsrate ist Faktor 3 (Proaktivität) wichtiger als in weniger dynamischen Branchen. Nicht alle erfolgreichen Führungskräfte sind in allen 4 Faktoren stark, aber die besonders erfolgreichen weisen häufiger mehrere positiv ausgeprägte Faktoren auf. Insgesamt am höchsten ist die Wirkung des Faktors 4 (Zuverlässigkeit)

Diese 4 Faktoren bestimmen den Erfolg von Führungskräften

Erfolgsfaktor 1 kann man kurz und pointiert so zusammenfassen: Schnell entscheiden ist wichtiger als richtig entscheiden. Dazu der frühere CEO von Greyhound Stephen Gorman, der das Unternehmen durch einen Turnaround geführt hat: “A bad decision was better than a lack of direction. Most decisions can be undone, but you have to learn to move with the right amount of speed.” Kluge, aber langsame Entscheidungen werden zu Engpässen, dieser Stil strahlt auf alle Mitarbeiter aus, sie werden auch immer vorsichtiger und langsamer in ihren Entscheidungen. Dieser kumulative Effekt verursacht enorme Kosten.

Erfolgsfaktor 2 betont die essenzielle Bedeutung des Stakeholder-Managements. „We found that strong performers balance keen insight into their stakeholders’ priorities with an unrelenting focus on delivering business results“. Allerdings scheuen gerade erfolgreiche Führungskräfte nicht vor Konflikten zurück, wenn diese zur Erreichung der gewünschten Ziele notwendig sind. Ihre Akzeptanz stützt sich nicht auf Wohlfühlfaktoren, sondern auf das Vertrauen der Stakeholder, mit ihnen erfolgreich zu sein. Wichtige Stakeholder sind auch die Mitarbeiter, die Auswahl und Förderung der richtigen Mitarbeiter ist Teil dieses Erfolgsfaktors

Erfolgsfaktor 3 betont die Bereitschaft, als notwendig erkannte Änderungen rasch und bereitwillig zu vollziehen anstatt sich auf etablierte und bewährte Regeln zurückzuziehen. Aber gerade deswegen versuchen solche Führungskräfte auch, sich auf Veränderungen frühzeitig vorzubereiten. „Most CEOs know they have to divide their attention among short-, medium-, and long-term perspectives, but the adaptable CEOs spent significantly more of their time—as much as 50%—thinking about the long term. Other executives, by contrast, devoted an average of 30% of their time to long-term thinking“.

Erfolgsfaktor 4 betont Zuverlässigkeit und Berechenbarkeit von Führungskräften als Vorteil gegenüber High-Performern, deren Spitzenleistungen als wahrscheinlich nicht nachhaltig eingeschätzt werden. In diesem Erfolgsfaktor ist allerdings auch das aktive Management der Erwartungen der Stakeholder inkludiert. Unrealistische Erwartungen von Stakeholdern müssen vermieden oder nötigenfalls korrigiert werden, auch wenn das manchmal weh tut. Zuverlässigkeit in diesem Sinne ist also nicht als Opportunismus und bedingungslose Anpassungsbereitschaft zu verstehen. Dazu gehört auch ein hoher Grad an Organisation: „CEOs who ranked high on reliability employed several other tactics as well. Three-quarters of them were rated strong on organization and planning skills. They established business management systems that included a cadence of meetings, dashboards of metrics, clear accountability, and multiple channels for monitoring performance and making rapid course corrections. Most important, they surrounded themselves with strong teams“.

Was lernen wir daraus für das Management von Projekten?

Es ist ganz einfach: Jeder dieser Erfolgsfaktoren trägt auch dazu bei, Projekte erfolgreich zu führen. Erfolgreiches Projektmanagement erfordert zweifellos hohes Engagement für alle vier Faktoren. Dass Faktor 3 (Proaktives Handeln) in Projekten ebenso wie in Unternehmen mit dynamischem Umfeld besonderes Gewicht hat, scheint mir evident.

Entspannungstechniken haben eine große Anhängerschar: kein Work-Out ohne ein Cool-Down am Ende, sei es in Form von Atem- oder Dehnungsübungen oder einfach einer Ruhephase. Wenn man Yoga oder autogenes Training betreibt, ist Entspannung ohnehin ein integrierter Teil jeder Übungseinheit. Keine Frage, dass dies alles sinnvoll ist und gerade wer in Projekten mit Termindruck und Bewältigung von Problemen zu tun hat, kann das besonders gut brauchen.

Viele gehen einen Schritt weiter und bevorzugen „spirituelle“ Angebote, die typischerweise mit Meditation und/oder Yoga verbunden sind. Ich muss zugeben, dass der Begriff Spiritualität für mich ein sehr schillerndes Konzept ist, am meisten kann ich damit im Sinne von Viktor Frankl etwas anfangen, nämlich als Aufforderung, allem was man tut einen Sinn zu geben. Dazu ein Literaturtipp am Ende des Beitrages.

Das führt uns aber auch schon dazu, dass es meiner Meinung nach darauf ankommt, wie man über Ereignisse denkt bzw. mit ihnen denkend umgeht. Das muss man verstehen und beeinflussen.

Meditation und Entspannungstechniken setzen an den Symptomen an

Ein kurzes und pointiertes Statement dazu stammt vom Sternekoch Alfons Schuhbeck, der meint, dass er Meditation nicht braucht, weil er Stress gar nicht an sich ranlässt. Wie er das schafft, deutet er nur kurz an, dazu mehr in diesem Blogbeitrag nach dem Video. Wie er zu dieser Art des Umganges mit Belastungen gekommen ist, wissen wir nicht, wahrscheinlich würde er es einem natürlichen Talent zuschreiben, das ihm in die Wiege gelegt wurde (so schätze ich ihn jedenfalls ein).

Hilfreich ist es zunächst, zwischen Stress und Stressoren zu unterscheiden. Stressoren sind Faktoren, die Stress auslösen können. Stress ist ein Zustand mit verschiedenen typischen körperlichen und psychischen Symptomen. Ob und wie Stressoren tatsächlich Stress auslösen, hängt von vielen Faktoren ab, die sowohl von der Person als auch von der Situation abhängen, wie es Lewin mit der Formel „V=f(P,U)“ ausdrückt.

Schuhbeck spricht in seinem kurzen Statement mehrere Ansätze an, um mit Stressoren umzugehen ohne diese näher auszuführen. Er selbst vergleicht seine Methode mit einem Winterreifen und nennt dies einen rauen Zugang. Aber wie man dazu kommt, sich quasi eine dicke Haut zuzulegen, bleibt bis auf eine Ausnahme offen.

Reframing – die Dinge einfach anders sehen

Was Schuhbeck erklärt, ist das sofortige „Wenden ins Positive“. Er verbindet das mit der Frage, was man tun kann, um mit der Situation fertig zu werden. Das ist eine Umsetzung des „Reframing„, eine Technik, die aus der Neurolinguistischen Programmierung (NLP) kommt.

Dieses Konzept gibt es in verschiedenen Formen, die wohl älteste Ausprägung ist die Aussage des Stoikers Epiktet: „Es sind nicht die Dinge, die uns beunruhigen, sondern die Meinungen, die wir von den Dingen haben“.

Ich selbst habe das erstmals im Rahmen der leider viel zu wenig bekannten Real-emotiven Verhaltenstherapie  (RET) von Albert Ellis kennengelernt. Vereinfacht spricht er von A (Activating Event: in unserem Fall der Stressor, also z.B. ein versäumter Termin, ein unzureichendes Arbeitsergebnis, Kritik des Kunden etc.) und C (Consequences, also unserer Reaktion, z.B. Stress, Panik, Freude, …). Dazwischen liegt B (Beliefs, die Annahmen und Denkweisen, die wir auf die Wahrnehmung und Bewertung von A anwenden). Ellis setzt dabei an, die Beliefs zu verändern, durch Training, Coaching oder Therapie, je nachdem wie stark diese in der Persönlichkeitsstruktur verankert sind und in wie hohem Maße sie destruktiv wirken. Die Anwendung der RET und anderer verwandter Techniken hat vielfach bewiesen, dass dies möglich ist und auch, dass es in der überwiegenden Zahl der Fälle keine tiefgehende und langwierige tiefenpsychologische Analyse erfordert – die RET ist ja eine auf die Gegenwart und Zukunft fokussierende Therapie. Sie gehört auch in die Denkschule der Konstruktivisten und deren bekanntester Vertreter, Paul Watzlawick hat viele Beispiele gegeben, wie man durch eine Änderung der Interpretation von Gegebenheiten sehr schnell und effektiv mit Problemen fertig werden kann. Seine „Anleitung zum Unglücklichsein“ transportiert diesen Gedanken in Form einer paradoxen Intervention, indem genau jene Denkweisen beschrieben werden, die dazu führen, sich unglücklich zu fühlen. Ändert man diese Art des Denkens, sind auch die Folgen andere.

Handlungsorientierung statt Problemanalyse

Das ist ein weites Feld und übersteigt den Rahmen eines Blogs, der sich mit Projektmanagement beschäftigt. Interessant für Projektmanager ist allerdings die Beschreibung Schubecks, wie er  auf Stressoren  reagiert. Er frägt sich sofort, was er tun kann. Das ist bei guten Projektmanagern (gemeint sind natürlich immer auch Projektmanagerinnen) geradezu ein Reflex. Jedes Problem wird als Herausforderung zum Handeln gesehen. Das reduziert Stress ganz automatisch, packt das Problem an der Wurzel. So gesehen, kann Meditation auch ein Weg sein, seine Denkweise zu verändern. Allerdings sehe ich die Gefahr, dass dabei Endlosschleifen in Gang gesetzt werden, die ohne externen Anstoß nicht gestoppt werden können. Ohne Coach halte ich daher eine solche Veränderung für eher aussichtslos.

Die Botschaft für Projektmanager, die sich regelmäßig gestresst fühlen, ist also die:

1. Suche die Ursache des Stress bei Dir selbst und ändere die Reflexe und Denkmuster, die aus Stressoren (also potenziellen Stressverursachern) bei Dir tatsächlich Stress erzeugen.
2. Akzeptiere, dass die Stressreaktion nicht unausweichlich ist, sondern Du selbst diese vermeiden kannst und letztlich auch der einzige Mensch bist, der diese wirklich ändern kann.
3. Ändere Deine Stress verursachenden Denkmuster mit Methoden wie NLP oder RET. Nutze dafür die Unterstützung von Coaches. Sei vorsichtig bei der Wahl von Therapeuten, bevorzuge jene, die kognitive und verhaltenstherapeutische Methoden einsetzen.
4. Nutze Entspannungstechniken als flankierende Maßnahmen, die diese Veränderung unterstützen, aber nicht ausreichend sind, um sie zu vollziehen.
5. Wenn das nicht hilft, überlege eine Änderung Deines beruflichen Umfeldes, denn selbst die besten Techniken zur Stressbewältigung können bei extremen Belastungen versagen. Nicht jeder hält gleich viel aus, nicht jeder hält alles aus und es gibt keine Wunderdrogen.

Wer meine Gedanken zu diesem Thema lieber als Podcast hören möchte, kann das hier tun:

Wenn Sie regelmäßig über neue Blogs informiert werden wollen, tragen Sie sich bitte hier ein. Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

Hier noch einige Literaturtipps:
    

Im Rahmen der Digital Enterprise Konferenz von LSZ Consulting hatte ich Gerhard Zeiler zu einem Gespräch über die Geschäftsmodelle von Medienunternehmen im Zeichen der Digitalisierung eingeladen. Gerhard Zeiler war u.a. Generalsekretär und später auch Generalintendant des ORF, CEO der RTL Group und ist jetzt President von Turner International. Mit Gerhard Zeiler verbindet mich eine gemeinsame erste berufliche Station im Österreichischen Institut für Berufsbildungsforschung. In seiner Zeit als Geschäftsführer von RTL Television in Köln war ich auch als Berater zum Thema IT-Governance für ihn tätig.

Unser Gespräch zur Digitalisierung in der Medienbranche fand zu einem Zeitpunkt statt, wo gerade Verkaufsverhandlungen zwischen AT&T und Turner im Gange sind. Diese Fusion zeigt, dass Telekommunikationsunternehmen versuchen, sich vom Infrastrukturbetreiber zum Content-Provider weiter zu entwickeln. Wer an der Präsentation zu diesem Thema interessiert ist, kann sie bei office*@*360pm.eu (* entfernen) anfordern.

Ich nutzte die Gelegenheit aber auch, um Gerhard Zeilers Meinung zu den Themen Agilität und IT-Projektmanagement zu erfahren. Dazu gab er ein klares und für manche vielleicht überraschendes Statement ab. Hören Sie selbst in diesem kurzen Video-Ausschnitt.

Die Bereitschaft, nicht auf die perfekte Lösung zu warten, sondern lieber eine unvollkommene Lösung schnell zu realisieren ist ja auch ein Leitbild von Startups, bekannt als Prinzip des „Minimum Viable Product„. Gerhard Zeiler sieht diese Denkweise auch für Großunternehmen als unabdingbar.

Wie kann man das realisieren, wenn das Vorhaben nun einmal größer ist als man in wenigen Monaten erledigen kann? Es erfordert ein iteratives Vorgehen, wobei jede Iteration ein greifbares, für Anwender nachvollziehbares Ergebnis liefern muss. Das hat das agile Manifest schon 2001 gefordert und vieles davon ist ja auch noch heute gültig (dazu mehr in einem anderen Blogpost).

Allerdings reicht es bei Großprojekten nicht, User Stories zu sammeln, ein Team zu etablieren, einen Backlog zu bilden, diesen in Sprints abzuarbeiten usw. Es braucht einen gesicherten Rahmen, der die Einbettung des zu entwickelnden Systems in das Geschäftsmodell und die Geschäftsprozesse des Unternehmens klärt, die Architektur des Systems auf eine sichere Basis stellt und nicht zuletzt auch die Finanzierbarkeit des Vorhabens sichert. Die beste Grundlage dafür ist meiner Meinung nach immer noch die bei uns leider wenig bekannte „Dynamic Systems Development Method“ (DSDM). Hier wird das iterative Vorgehen eingebettet in eine Ablaufstruktur, wie sie für Großprojekte unverzichtbar ist.

Eine ausführliche Anleitung findet man hier:

Angesichts aller Anleitungen, die Best Practices beschreiben und natürlich ihren unbestreitbaren Wert haben finde ich die kurze und trockene Ansage von Gerhard Zeiler, dass man nur rasch genug sein kann, wenn man sich vom Perfektionismus verabschiedet und inperfekten Lösungen den Vortritt gibt, als extrem hilfreich. Man sagt uns Österreichern ja nach, dass wir mit Provisorien besonders gut leben können. Das muss also kein Nachteil sein! Gerhard Zeilers Karriere könnte man als Beweis dafür werten.

BTW: English version here/Englische Version hier.

Neue Methoden und Werkzeuge verändern die Zusammenarbeit von Anwen­dern und Entwicklern. Neue technische Möglichkeiten, veränderte Aufwands­relationen für bestimmte Aufgaben eines Softwareentwicklungsprojektes schaffen neue Möglichkeiten oder gar Notwendigkeiten, ein Software-Projekt abzu­wickeln.

Die Welt der Softwareentwicklung hat sich stark geändert

Solange es aufwendig war (und vielfach noch ist), ein Bildschirm- oder Li­sten-Layout zu verändern, mussten diese Vorgaben möglichst früh im Projekt fest­geschrieben werden. Ist es hingegen auch in späten Projektphasen leicht mög­lich, sogar neue Felder in die Datenbank einzufügen, muss man sich mit diesen Vorgaben weniger Mühe geben. Der Anwender muss nicht mehr detaillierte Pflichtenhefte erstellen und dann unterschreiben, damit er nur mehr bei Strafe beträchtlicher Mehrkosten Änderungswünsche geltend machen kann. Kommt zwar immer noch vor, aber das ist mehr eine Art Gehorsamkeitsprüfung als eine echte Notwendigkeit.

Geht es aber in diesen Punkten sozusagen etwas lockerer zu, wo noch kann man auf harte Arbeit und Verbindlichkeit in frühen Projektphasen verzichten? Braucht man überhaupt noch ein Architekturkonzept, ein Datenmodell, Use-Cases etc. Arbeiten wir einfach wieder nach dem Motto HIG (Hirn ins Gerät), wie es in den Anfangszeiten der IT üblich war. Damals erfolgte Softwareentwicklung von Entwicklern für Entwickler und niemand war da, der Ansprüche an das Ergebnis stellte, ohne die Technik zu verstehen und zu beherrschen? Das einzige was stört, ist der Anwender, so denken wohl im Stillen viele Entwickler.

Spontan oder strukturiert?

Kann es sich vielleicht der Anwender angesichts der neuen Entwicklungswerk­zeuge und -plattformen überhaupt bequem machen, sich mit Informationen über seine Anforderungen in freier Prosa sowie kritischen Anmerkungen zu den ihm vorgestellten Prototypen begnügen, darauf warten, dass die Soft­wareentwickler früher oder später das erträumte Informationssystem liefern?
Oder gilt umgekehrt für die Softwareentwickler, dass sie nur noch dem Anwender ein Werkzeug in die Hand geben und es ihm erklären müssen, ihn damit einige Zeit arbeiten lassen und zum Schluss die abgelieferten Teile zu einem benutzer­freundlichen, fachlich optimalen und kostengünstigen Informationssystem zusammenfügen?

Natürlich wissen wir alle, dass beide Extreme nicht realisierbar sind und natürlich gibt es niemanden, der ernsthaft ein solches Szenario vertritt. Aber doch ist einiges in Fluss geraten und damit verbunden gibt es Verunsicherung bei allen Beteiligten.

Ich meine, dass auch in agilen Projekten einiges an Pflichten bleibt, diese betreffen alle Beteiligten. Flexibel sein ist nicht gleichbedeutend mit oberflächlich, sprunghaft und unverbindlich.

Die Pflichten der Anwender in agilen Projekten sind erheblich

Die Anwender (gemeint ist damit sowohl das Management als auch die Anwender im engeren Sinne) müssen eine klare Vorstellung davon entwickeln, welche Beiträge ein IT-System zum Erfolg des Unternehmens insgesamt und zur Verbesserung der adressierten Geschäftsprozesse im Besonderen leisten soll. Ein iteratives Vorgehen begünstigt die Entwicklung kreativer Lösungen, da strategische, organisatorische und technische Phantasie besser zusammenwirken können als im Rahmen eines klassischen, streng phasenorientierten Vorgehens nach dem Wasserfall-Modell. Aber es kommt auch hier der Zeitpunkt, wo man sich festlegen muss und das heißt immer auch, auf etwas zu verzichten, zumindest vorläufig.

Es gehört zu den Stehsätzen der IT-Strategie, dass zu­erst die organisatorischen Fragen geklärt werden müssen, bevor die  IT-An­wendung Sinn hat. Und es ist genauso wahr, dass in der Praxis regelmäßig versucht wird, über die IT organisatorische Probleme in den Griff zu bekom­men. Wenn eine Regel so oft ignoriert wird, besteht der Verdacht, dass sie entweder falsch oder zumindest in der Praxis nicht umsetzbar ist; gemäß einem pragmatischen Begriff von Richtigkeit ist sie damit aber auch im zweiten Fall falsch.

Organisation und IT-Systeme können natürlich separat und nacheinander optimiert wer­den. Dass dabei regelmäßig nur ein Suboptimum erreicht wird, steht für mich aber außer Zweifel: Wüsste der Anwender, welche Möglichkeiten ihm die IT bieten könnte, würde er sich vielleicht anders organisieren. Wüsste der Softwareentwickler, welche An­forderungen der Anwender nicht genannt hat, weil er sie für nicht realisierbar hält oder sich nicht vorstellen konnte, würde er manches anders lösen.

Alles ist möglich, nichts ist fix?

Wollte man grundsätzlich beide Teilsysteme gleichzeitig optimieren, würde man schnell die Grenzen der bewältigbaren Komplexität, der Beweglichkeit der Or­ganisation und der Geduld der Anwender überschreiten. Genau hier ist die mit modernen Entwicklungsplattformen gegebene Möglichkeit höchst nützlich, die Phantasie des Anwenders in frühen Phasen mit rasch entwickelbaren Prototypen zu stimulieren. Die letzte Entscheidung, bei welchen Aufgaben sich welche Art von IT-Unter­stützung mit welchem Grad an Komfort lohnt, kann aber wiederum nur der An­wender treffen und verantworten.

Gerade wenn man von einem streng phasenorientierten Vorgehensmodell ab­weicht, besteht die Gefahr, dass die Präzision der Projektplanung reduziert und das Projektmanagement lax wird. Es ist jedoch eine der Paradoxien, die wir aus den Projekten zur partizipativen Organisationsgestaltung gelernt haben, dass nicht nur mit zunehmender Zahl an Beteiligten sondern auch mit zunehmendem Grad an Partizipation das Projektmanagement umso straffer sein muss. Je mehr Gestaltungsspielraum man den Beteiligten einräumt, umso häufiger kommt es zu Veränderungen, die Auswirkungen in anderen Bereichen haben. Das Schnittstel­len-, Kommunikations- und Stakeholdermanagement müssen daher in agilen Projekten mit höchster Professionalität wahrgenommen werden, deutlich mehr als in Projekten nach einem mehr oder minder strengen Wasserfallmodell. Es müssen die Meilensteintermine aufeinander abgestimmt werden und der regelmäßige, proaktive Informationsaustausch gesichert werden.

Schriftliche und von allen Beteiligten verstandene und anerkannte Projektaufträ­ge, eine klar definierte Projektorganisation, insbesondere  Projektleiter mit ausreichenden Entscheidungsbefugnissen und Ressourcen sind einige weitere Elemente, die gutes Projektmanagement immer schon auszeichnen und unter den komplexeren Bedingungen des agilen Vorgehens umso wichtiger sind.

Es ist die nicht delegierbare Pflicht des Anwenders, insbesondere des Manage­ments, die Gesamtverantwortung für den Erfolg und damit das Gesamt-Projekt­management zu übernehmen.

Veränderung ist wichtig und möglich – aber welche Art der Veränderung?

Agile Vorgehensmodelle erlauben es, IT-Systeme im Verlaufe ihrer Entwicklung zu ändern. Watzlawick u.a. unterscheiden zwei Formen der Veränderung: „die eine findet innerhalb eines bestimmten Systems statt, das selbst unverändert bleibt, während das Eintreten der anderen das System selbst verändert“ (S. 29). Sie sprechen von einem Wandel erster Ordnung bzw. einem Wandel zwei­ter Ordnung.

Betrachten wir eine IT-Anwendung als ein System von Funktionen und Daten, die zu Applikationen zusammengefasst und auf bestimmten Hardware- und Be­triebssystemplattformen implementiert werden, so erleichtern agile Vorgehensmodelle den Wandel erster Ordnung. Ist es jedoch erforderlich, den Charakter des Systems insgesamt zu ändern, erleichtern dies agile Vorgehensmodelle nur noch marginal. Agilität erspart uns also nicht die Ausarbeitung einer durchdach­ten IT-Architektur, sie erleichtern jedoch entscheidend den Wandel erster Or­dnung, nämlich die Systemoptimierung im Rahmen einer gegebenen Architektur.

Gute Architektur kommt nicht von Gelegenheitsarchitekten!

Softwareentwicklung ohne Programmierer? Softwareentwicklung durch die An­wender? Mag sein, es kommt aber auch darauf an, wen man als Programmierer und wen man als Anwender bezeichnet. Und es kommt sicher auch darauf an, wie komplex ein Softwaresystem ist. Wenn wir uns darauf einigen, dass jemand der z.B. in Excel Makros schreibt oder vergleichbare Leistungen in anderen Systemen erbringt, kein Programmierer ist, kann man den oben zitierten Verheißungen nicht zustimmen. Wenn wir eine Analogie zum Bauen herstellen, so sehen wir, dass im Zeitalter der Fertighäuser sehr viele Bauherren keinen Architekten mehr brauchen. Allerdings sind die Fertighäuser von Architekten entworfen worden und die mehr oder minder hohe Qualität des Entwurfes erkennt jeder, der ein Fertighaus seinen indi­viduellen Bedürfnissen anpassen will. Wenn wir noch einen Schritt weiter zur Städteplanung gehen, so sehen wir die Grenzen der Eigenplanung deutlich an den städtebaulichen Fleckerlteppichen mancher Gemeinden. Wenn wir also einer „Verhüttelung“ der IT-Land­schaft (also einer Ansammlung von Insellösungen mit komplexen Schnittstellen) entgehen wollen, so kommen wir nicht umhin, die Anwender auch im Zeitalter von Scrum und XP durch Profis zu betreuen und manchmal auch zu führen.

Nicht zu vergessen: Es gibt auch Pflichten der IT in agilen Projekten

Die Pflichten des Anwenders enden also dort, wo es um die Gesamtarchitektur und die optimale technische Gestaltung des IT-Systems geht, sie gelten aber umso mehr, wenn es um die Klärung der strategischen, wirtschaftlichen und organisatorischen Voraussetzungen und Rahmenbedingungen des IT-Einsatzes geht. Aber dort wird der Erfolg des IT-Einsatzes zum Großteil entschieden, egal ob wir agil arbeiten oder nicht.

Das erfolgreiche Zusammenwirken von vielen Stakeholdern funktioniert nicht ohne stabile Strukturen und disziplinierte Zusammenarbeit. Flexibilität erfordert viel Arbeit, nicht nur, wenn es um Yoga geht.

Angewandte Stochastik. Experten für Aufkleber. Experten für Belange von Menschen. Experten für den Weg zurück. Experten für Einkaufszettel. Experten für die Gefühlswelt. Experten für Themengebiete. Experten für sich selbst. Experten für Haarausfall. Experte für krause Ideen. Experte für weltweite Risikolösungen. Experte für Wunder .

Sie schütteln den Kopf? Ich darf Sie beruhigen. Das sind noch nicht einmal die kuriosesten Ergebnisse, für die Internet-Suchanfrage „Experte für …“. Über 1,8 Millionen Einträge verzeichnet Google bei einem derartigen Research. Allein im Monat Februar wurde über eine halbe Million Mal, in der Suchmaschine Google nach „Experten“ gesucht. Man hat den Eindruck die Welt quillt über von Experten. Bei genauer Betrachtung muss die Botschaft allerdings lauten: „… und es werden unaufhaltsam mehr!“

From picks to bricks to clicks

Warum ist das so? Mehrere tausend Jahre waren die Menschen bevorzugt Rohstoffgewinner in einer Agrargesellschaft. Der rasante Wandel hat erst vor zweihundert Jahren eingesetzt. Zunächst mit der Industrialisierung und der maschinellen Rohstoffverarbeitung. Seit rund 60 Jahren werden wir von der Digitalisierung beflügelt und haben uns zu einer Dienstleistungsgesellschaft gewandelt. Ob der Begriff „Informationsgesellschaft“ in Anbetracht der Unmenge an „Desinformation“ angemessen ist, soll hier nicht weiter beschäftigen.

Fest steht: der dritte Sektor wächst. Und das schneller als dies der französische Ökonom Jean Fourastié in seiner Drei-Sektoren-Hypothese prognostiziert hat.

Im Jahr 2014 haben in den „Frühindustrialisierten Ländern“ 75 % der Beschäftigten ihr Geld mit Dienstleistung verdient. Drei Viertel haben also keine tangiblen Güter erzeugt sondern intangible Arbeitsleistungen erbracht. 40 Jahre früher als von Fourastié eingeschätzt. Die wichtigsten Produktionsfaktoren sind nicht mehr Grund- und Boden, nicht mehr die Maschinen sondern das Know-how. Das notwendige Werkzeug ist nicht mehr die Pickhacke, die Struktur ist nicht mehr der industrielle Ziegelbau. Mit durchschnittlich 30 Clicks im Netz, ist beinah jede Auskunft erteilt. Fragt sich nur wie?

Die Produktion des Wissens

Im Jahr 1963 erschien das Buch „Littel Science, Big Science“ des angloamerikanischen Wissenschaftshistoriker Derek de Solla Price. Darin beschreibt er zum ersten Mal das Phänomen der „Wissensproduktion“. Als Indikator verwendet de Solla Price die Anzahl der Originalveröffentlichungen in Fachzeitschriften. Sein Ergebnis: Wissenschaftliche Information wächst exponentiell und verdoppelt sich alle 15 Jahre. Aktuelle Messungen – wenngleich der Begriff „Messung“ hier durchaus kritisch zu sehen ist – gehen von einer Verdoppelung alle fünf bis zwölf Jahre aus. Parameter die dabei zur Anwendung kommen sind das Wachstum an gespeicherter Information und die im World Wide Web verfügbare Informationsmenge. Ein weiterer Indikator, der die Beschäftigten als Basis heranzieht, geht davon aus, dass sich die Anzahl der Menschen mit einer wissenschaftlich-technischen Ausbildung von 1950 bis zum Jahr 2000 von 10 Millionen auf 100 Millionen verzehnfacht hat. Tendenz stark steigend. Auch die enorme Zunahme an Literatur zum Thema „Wissensmanagement“ belegt diesen Trend.

Klavier oder Cello

Was heißt das für Unternehmen gleichermaßen wie für uns als Menschen? Unerheblich ist die Diskussion um die genaue Wachstumsgeschwindigkeit. Dies deshalb weil niemand von uns sein Wissen in drei, fünf oder sieben Jahren verdoppeln kann. Deshalb hat sich mehr und mehr die eine Bewältigungsstrategie herausgebildet: Spezialisierung. Stellen Sie sich folgende Situation vor:

Sie sitzen in einem Konzertsaal. Das Licht geht aus. Kein Laut ist zu hören. Alle Besucher warten darauf, dass der Star des Abends die Bühne betritt. In diese Ruhe hinein, tippt Sie Ihr Sitznachbar an die Schulter und fragt: „Sagen Sie, wissen Sie ob Lang Lang heute mit dem Klavier, mit dem Cello oder mit dem Englisch Horn auftritt?“ Verärgert antworten Sie: „Mit dem Klavier! So wie Anne Sophie Mutter immer mit der Violine auftritt!“

So ist es. Auch im Dienstleistungsbereich. Niemand kann gleichzeitig auf dem Klavier und auf der Violine Spitzenleistungen erbringen. Vielmehr ist es sogar so, dass sich die wahren Experten nicht nur auf das Werkzeug sondern auch auf das Werk spezialisieren. Spezialisierung ist also kein Trend. Spezialisierung ist ein Mindset. Allrounder kennen zwar die Nischen. Spezialisten fokussieren sich auf diese Nischen. Dringen in diese vor. Entwickeln neue Lösungen und neue Produkte. Warum soll dies nur in der Musik so sein. Warum sollen Wissensarbeiter davon aus ausgenommen sein. Das enorme Wissenswachstum macht es unumgänglich sich die Nische zu suchen und aus dieser heraus zu glänzen. Dazu braucht es aber Verbündete.

Die PayPal-Mafia

2007 erscheint im „Fortune Magazine“ ein Artikel. Darin werden ehemalige Gründer und Mitarbeitende, des 1998 von Peter Thiel in Palo Alto, Kalifornien, aus der Taufe gehobenen Bezahldienstes, als „PayPal-Mafia“ bezeichnet. Der Name ist eine Anspielung auf die eingeschworene Gemeinschaft und den enormen wirtschaftlichen Erfolg des Startup-Unternehmes. Bereits im Jahr 2002 wird PayPal um 1,5 Milliarden US-Dollar an eBay verkauft. Fast schon ein Märchen. Die Namen der Mitglieder dieser PayPal-Mafia lesen sich wie das Who-is-Who der New Economy: Steve Chen und Chad Hurley die Gründer von YouTube. Reid Hoffman Mitbegründer von LinkedIn. Elon Musk Gründer von Tesla Motors und SpaceX. Um nur einige zu nennen. Die Zeit der egoistischen Einzelentscheider ist vorbei. Wissen wächst exponentiell und damit die Notwendigkeit arbeitsteilig vorzugehen. Am besten eingeschworene Gemeinschaften die von ihrer Sache überzeugt sind.

Mehr als ein Team

Vielleicht waren Sie schon einmal in einem Zirkus und haben fasziniert den Meisterleistungen einer Artistengruppe zugesehen. Waren beeindruckt davon, wie ihre Körper, auf die Sekunde abgestimmt, die kompliziertesten Bewegungsabläufe beherrscht haben. Bei solch einem Schauspiel kann man sich des Eindrucks nicht erwehren, die Akrobaten sind sogar in Gedanken miteinander verbunden.

Oder vielleicht haben Sie schon einmal für eine Sportmannschaft die Daumen gedrückt, die durch ihr Kombinationsspiel den Gegner blass aussehen hat lassen. Beispiele die unsere Bewunderung hervorrufen. Formen der Zusammenarbeit die mehr sind als nur Ko-Produktion. Mehr als nur Ko-Ordination. Und mehr als nur Ko-Operation. Arten der Zusammenarbeit die auch mehr sind als Teamarbeit. Solche Formen ko-kompetenten Zusammenwirkens entstehen nicht dadurch, dass einzelne Mitarbeitende hin und wieder Fortbildungen in Anspruch nehmen oder Kongresse besuchen. In einer Organisationseinheit zusammenarbeiten oder in ein und demselben Unternehmen beschäftigt sind. Dazu braucht es schon ein bisschen mehr als das.

Ko-kompetente Systeme

Stellen Sie sich eine solche Sportmannschaft vor. Beispielsweise ein Fußballteam. Der Trainer schickt die Mitglieder getrennt auf verschiedene Seminare und Fortbildungen. Stürmer besuchen Stürmerseminare. Mittelfeldspieler nehmen an Mittelfeldkongressen teil. Verteidiger absolvieren die Verteidigerakademie. Von solch vielversprechenden Bildungsmaßnahmen zurückgekehrt, wundern sich Coach und Mannschaft, dass sie nicht in der Lage sind miteinander zum Erfolg zu kommen. Das Beispiel mag uns amüsieren, vielleicht absurd vorkommen. So aber funktioniert Personalentwicklung in vielen Unternehmen. Auf diese Art entstehen aber keine ko-kompetenten, unschlagbaren Systeme. So entstehen nicht einmal Teams.

Ko-Kompetenz

Das dynamische Wissenswachstum verlangt den Individuen besondere Eignungen ab. Fähigkeiten die dabei unterstützen, auf dem ruhelosen Wissensteppich nicht den Boden unter den Füßen zu verlieren. Ko-kompetente Systeme sind nur bedingt dauerhafte Strukturen, wie sie Unternehmen bislang waren. Größtenteils werden es ergebnisori­entierte Flechtwerke sein, die mit der Zielsetzung entstehen und gemeinsam mit der Zielerreichung wieder zerfallen. Zweifelsohne stellt dies einen gewöhnungsbe­dürftigen Gedanken dar. Um solche Know-how-basierten Organisationen erfolgreich zu machen, braucht es aber ganz neue Fähigkeiten und neue Werkzeuge. Für Menschen und für Unternehmen. Was immer ein Unternehmen in Zukunft ist. Was uns im Besonderen herausfordern wird ist die Tatsache, dass ko-kompetente Systeme nicht an den Unternehmensgrenzen halt machen. Wissen wächst exponentiell. Unternehmen nicht.

Experten-Kompetenz – Fachliche Fokussierung ist unumgänglich. Mit all ihren Vor- und Nach­teilen. Expertenwissen basiert auf einem breiten Grundwissen. Die Subspezialisierung selber ist idealerweise wis­senschaftlich abgesichert und deshalb beweisbasiert. Durch diese fachliche Kon­zentration erwerben Experten Selbstvertrauen, also das fundierte Vertrauen in die eigene Urteilsfähigkeit.

System-Kompetenz – Zunächst bedarf es einer ausreichenden Kenntnis über den Aufbau und die Pflege ko-kompetenter Systeme. Dazu braucht es den Blick über den Wissenstep­pich und das Verständnis dafür, wo welche Wissensträger zu finden sind und mit wel­chem Know-how diese ausgestattet sind. Dieses System gilt es zu pflegen. Dabei ist im Besonderen da­ran zu denken, dass Wis­sen nicht seri­ell wandert, sondern sich durch Teilen verbreitet.

Teilhabe-Kompetenz – Darunter verstehen wir die Fähigkeit sich am Wissensteppich ohne Argwohn zu bewegen. Die Bereitschaft des wechselseitigen Ge­bens und Nehmens von Know-how fußt auf dem Grundprinzip des Vertrauens. Dieses Vertrauen stellt die Grundlage dafür dar, auch ausreichend kriti­sches Reflexionsvermögen zu entwickeln. Der Wissensteppich ist in ständiger Bewegung und die Experten bewegen sich mit. Andere Wissensträger weben neue Kenntnisse in den Teppich ein, die das bisherige Know-how erweitern, verän­dern, ja so­gar stören oder ihm widersprechen. Umso wichtiger ist es, über diese Einflüsse einen offenen und kritischen Diskurs führen zu können. Das bedarf einer dement­sprechenden Haltung und Konfrontationsfähigkeit. Wenn das fehlt, fehlt es auch an der Fähigkeit kri­senbehaftete Situationen zu meistern.

Wagnis-Kompetenz – Im Zusammenhang mit dem richtigen Verhalten in ko-kompetenten Systemen wird Risikobereitschaft mit Kalkül eine ganz we­sent­liche Befähigung darstellen. Der Mut also, neue Wege zu wagen und kon­ven­tionelle Denkmodelle zu verlassen. Um dies tun zu können bedarf es auch ausreichender Kreativität. Rulebreaker zu sein gilt also nicht nur für das Unternehmen. Den Mut zur Unkonventionalität braucht es auch auf der personalen Ebene.

Diese Fähigkeiten und die dazu notwendigen Tools gilt es zu entwickeln um der Wissensexplosion mit ko-kompetenten Systemen erfolgreich zu begegnen.

Literatur:

de Solla Price, D. (1982): Little Science, Big Science and beyond. Von der Studierstube zur Großforschung, Suhrkamp Verlag KG, Deutschland

Goleman, D. (1997): EQ. Emotionale Intelligenz, Deutscher Taschenbuchverlag

Thiel, P.; Masters, B. (2014): Zero to One: Notes on Start Ups, or How to Build the Future, Virgin Digital, US

Umstätter, W. (2009): Zwischen Informationsflut und Wissenswachstum: Bibliotheken als Bildungs- und Machtfaktor der modernen Gesellschaft, Simon Verlag für Bibliothekarswissen, Deutschland

Vance, A. (2015): Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future, Ecco, US

Zulehner, C. (2011): Strategisches Führen in Gesundheits- und Pflegeunternehmen – Handbuch für die Praxis, Eul-Verlag, Deutschland

Kennen Sie das? Ein Software-Projekt läuft schon länger, es gab Vorstudien, dann wurde es neu aufgesetzt. Anforderungsdefinition ist angesetzt, ein Team des neuen IT-Anbieters erscheint und beginnt, Anforderungen zu sammeln. Die Anwender werden nach einiger Zeit unruhig. Schließlich meldet sich einer zu Wort und sagt: „Das alles haben wir doch schon einem Kollegen von Ihnen erzählt, da gibt es auch ein Protokoll. Da steht doch schon alles drin, warum müssen wir das schon wieder erzählen?“

IT-Projekte verlaufen oft so, als wären die Beteiligten dement. Es werden immer wieder die selben Fragen gestellt.

Was kann man dagegen tun? Es gibt leider kein einfaches Rezept. Notwendig ist zunächst einmal Problembewusstsein und der erklärte Wille, alle verfügbaren Informationsquellen der Vergangenheit zu nutzen. Es geht also um Wissensmanagement. Da man in einem Projekt nicht genug Zeit hat, eine Kultur des Wissensaustausches aufzubauen, muss man ad hoc und ganz pragmatisch agieren.

Not invented here!

Ich habe dieses Ignorieren von bereits vorliegenden Informationen schon mehrfach erlebt. Trotz vieler ausdrücklichen Hinweise wurden die Ergebnisse früherer Projektphasen nicht verwendet. Es ist wahrscheinlich eine Variante des bekannten NIH-Syndroms („Not Invented Here“). Das ist die Unfähigkeit oder der Unwillen von Software-Entwicklern, etwas zu verwenden, das nicht sie selbst entwickelt haben. Wenn es um Technik geht, ist das als „mangelnder Code-Reuse“ bekannt. Diesen durchzusetzen erinnert immer wieder an Sisyphus. Es gibt unglaublich kreative Argumente, warum man etwas nicht übernimmt, sondern lieber selbst neu schreibt. Aber das ist nicht mein Revier.

Worauf ich hier aufmerksam machen will, ist der mangelnde Reuse von fachlichen Informationen. Es beginnt bei Prozessanalysen, die links liegen gelassen werden. Man könnte natürlich oft sagen, dass diese zu oberflächlich seien, um eine detaillierte Analyse mit Blick auf die angepeilte Software-Lösung zu ersetzen. Ja, sicher, das kann ich bestätigen, aber man könnte doch einiges übernehmen, z.B. die Prozesslandkarte, Terminologie, Ansprechpartner etc.

Höchst unbeliebt ist auch die Analyse von Dokumenten und Reports, die im Ist verwendet werden. Aus diesen könnte man viel für das Datenmodell lernen, Use-Cases ableiten. Auf jeden Fall könnte man so frühzeitig beginnen, die notwendigen Dokumentvorlagen zu erstellen und zu integrieren.

Was kann man dagegen tun?

So banal es klingt, eine Kollaborationsplattform, auf die wirklich alle Zugriff haben und die auch vollständig befüllt wird, ist oft schon die erste Hürde. Ich habe z.B. bei einem komplett neu aufgesetzten Projekt keinerlei Informationen aus dem Vorprojekt bekommen, obwohl ich zumindest zwei Monate aktiv danach gefragt und gesucht habe. Als ich hörte, alle Dokumente seien auf einer Cloud-Plattform gespeichert gewesen, man wisse aber nicht, ob es jemand gäbe, der die Login-Daten habe, gab ich endgültig auf. Wir haben einfach alle Analysen gemacht, die wir für notwendig hielten, ob das Doppelarbeit war, habe ich nie erfahren, denn es hatten sich auch die Ansprechpartner auf Anwenderseite geändert.

Weiters muss es jemand geben, der immer wieder die Frage nach bereits vorhandenen Informationen stellt und deren Auswertung fordert. Das ist keine Rolle, mit der man sich beliebt macht, deshalb wird sie auch oft nicht besetzt. Anwender sind nach meiner Erfahrung erstaunlich geduldig – oder soll man sagen: durch lange Erfahrung resigniert – wenn sie mit diesem Phänomen konfrontiert sind.

Innovation durch Ignoranz?

Ich habe auch schon das Argument gehört, man wolle das bisherige IT-System überhaupt nicht analysieren, weil man ja etwas Neues entwickeln will. Schlimm, wenn man später erkennt, dass viele Funktionen, die im Wartungsprozess über Jahre entwickelt worden sind, nicht spezifiziert und daher auch nicht implementiert worden sind. Den Anwendern sind diese oft nicht  bewusst, sondern selbstverständliche Anforderungen. Dann großes Erstaunen und heftige Emotionen, wenn dies vom IT-Dienstleister mit Hinweis auf unterschriebene Pflichtenhefte, in denen davon kein Wort steht, zurückgewiesen wird. Je näher man am Ziel zu sein meint, umso härter schlagen solche Lücken der Spezifikation zu und das bisher so stetige Wachstum des Fertigstellungsgrades erleidet einen herben Rückschlag.

Wahrscheinlich tritt die „Dementia Informatica“ deshalb so oft auf, weil wir es alle hassen, in unserer Ablage nach Dokumenten zu suchen. Ich habe auch schon ein Buch gekauft und erst später bemerkt, dass ich es ohnehin schon im Bücherregal stehen hatte. Besonders schlimm, wenn ich bemerke, dass ich es auch schon (zumindest teilweise) gelesen und mit Anmerkungen versehen hatte.

Noch eine Bemerkung, die eigentlich nicht direkt zum Thema gehört, aber gut zum Bild am Anfang des Beitrages passt. Die Reset-Taste wird bei Projekten auch gerne gedrückt, wenn es um Kosten geht. Je ungünstiger ein Projekt verläuft, umso häufiger wird bei der Ermittlung der Projektkosten wieder bei Null angefangen. Darf man also den Technikern einen Vorwurf machen, wenn ihnen das Top-Management hier so ein schlechtes Vorbild ist?