Einige Ereignisse der letzten Zeit lassen uns aufhorchen. Amazon kauft die Traditionsfirma Metro-Goldwyn-Mayer. Der Löwe brüllt also künftig für ein Unternehmen, das als Online-Buchhändler gegründet wurde, sein Geschäftsfeld allerdings massiv ausgeweitet hat. Amazon als Versandhändler weit über Bücher hinausgehend ist allen bewusst. Aber Amazon ist mit Amazon Music und Prime Video ein großer Player im Streaming-Geschäft (im Wettbewerb mit Apple, Netflix, Spotify u.a.) und verdient einen Großteil des Geldes mit Amazon Web Services, ist damit einer der führenden Anbieter von Cloud-Services im Wettbewerb mit IBM, Microsoft und anderen klassischen IT-Unternehmen.
Klassische Branchengrenzen verschwinden, völlig neue Wettbewerber tauchen auf. Die Medienbranche wurde früher und stärker als andere Branchen von der Digitalisierung zu einer völligen Neuorientierung ihrer Geschäftsmodelle und Prozesse gezwungen. Hier eine Analyse von McKinsey aus dem Jahr 2017, die das belegt, die wichtigste Grafik dazu hier gleich eingefügt.
Es lohnt sich daher, die Erfahrungen eines der führenden internationalen Medienmanagers zu hören und zu überlegen, was wir daraus für unsere Unternehmen und auch für unsere persönliche Karriereplanung lernen können.
Gerhard Zeiler war in seiner Karriere u.a. Generalintendant des ORF, CEO der RTL Group und ist jetzt President von Warner Media International. Damit kennt er wie kaum ein anderer die Entwicklung der Content-Industrie im internationalen Maßstab. Seine Botschaft: „Jeder, der ein Medienunternehmen führt, das von Wholesale-Distribution zu Direct-To-Consumer-Distribution übergehen möchte, muss auch ein Software-Technologieunternehmen werden“. Damit wird klar, dass die IT-Branche weiterhin mit immer neuen Wettbewerbern rechnen muss und sich überlegen muss, wie sie in diesem neuen Spiel der Kräfte bestehen will.
Gerhard Zeiler und ich sind seit dem Beginn unserer Berufslaufbahn freundschaftlich verbunden und ich konnte ihn für ein Interview zu diesen Themen gewinnen. LSZ wird dieses Gespräch als Web-Café im Vorprogramm der CIO-Konferenz organisieren. Ich danke Elmar Rodler, Ronald Subkus und Erika Kutner für die Gelegenheit, dieses wichtige Thema einem großen Kreis von Betroffenen und Interessierten nahezubringen.
Einige Stichworte, an denen wir uns in unserem Gespräch am 28. Juli 2021 orientiert haben:
Hier gibt es einen Bericht und die Aufzeichnung des Web-Cafés.
Wirft man einen Blick zurück, dann sah die IT-Branche vor 20 Jahren völlig anders aus als heute. Dass sich die Marktanteile zwischen den Unternehmen verschoben haben, einige Unternehmen fusioniert wurden und prominente Marken völlig vom Markt verschwunden sind, gehört zur “normalen” Entwicklung einer Branche. In der IT-Branche gibt es allerdings Entwicklungen, die diesen Korridor der „Normalität“ deutlich verlassen haben.
Die großen Konzerne haben ihre Geschäftsbereiche durch Unternehmenskäufe oft erweitert und haben erfolgreiche Nischenplayer der Vergangenheit mehr oder minder erfolgreich in ihr Geschäftsfeld integriert. Einige Big Player der Vergangenheit sind daher nicht mehr als eigenständige Unternehmen am Markt, wie z.B. HP, Compaq, DEC, Bull, Univac, Siemens. Viele der heute marktbeherrschenden Unternehmen kommen hingegen nicht aus der IT, sondern haben ihre Entwicklung in völlig anderen Branchen begonnen. Dazu einige Beispiele.
Amazon startete als Online-Buchversand, ein Marktsegment, wo Amazon zunächst als Außenseiter startete. Das Geschäftsmodell wurde schrittweise erweitert zu einem Versandhaus für Waren aller Art. Da Jeff Bezos mit dieser Strategie das Wachstumstempo nicht ausreichend schien, folgte der nächste Schritt: die Unterstützung von eigenständigen Händlern mit dem Programm „Fulfillment by Amazon (FBA)„. Amazon übernimmt die gesamte Logistik und Verrechnung mit den Kunden. Damit trat Amazon in Konkurrenz mit eBay, das als Versteigerungsplattform begonnen hatte, mittlerweile aber mit der Funktion „Sofort kaufen“ auf Auktionsprozesse meist verzichtet. Allerdings bietet eBay keine Logistik und Verrechnung an. So hat Amazon mit FBA, von vielen unbemerkt, einen völlig neuen Markt begründet. Das alles ist aber immer noch nahe dem Ursprung als Online-Buchhändler, nur haben sich Sortiment und Geschäftsmodell wesentlich erweitert.
Amazon erkannte bald, dass die für eigene Zwecke aufgebaute IT-Infrastruktur auch als Produkt geeignet sein könnte. Amazon Web Services (AWS) sind generische Cloud-Services und Amazon ist damit – nach dem Start im Jahr 2002 – mittlerweile deutlicher Marktführer. Mit Alibaba ist Amazons chinesisches Gegenstück ebenfalls in der Spitzengruppe und dahinter folgt wieder ein Unternehmen, das ein anderes Kerngeschäft hat, nämlich Alphabet mit der Google Cloud Platform (GCP). Insgesamt ist unter den vier umsatzstärksten Anbietern von Cloud-Services nur ein klassisches IT-Unternehmen. Nur Microsoft mit Azure (Start 2010) kann hier mithalten, alle anderen Platzhirschen der IT-Branche firmieren dahinter, konkret liegt die einst marktberrschende IBM auf Platz 5.
Dies ist also ein Beispiel dafür, dass die “Big Player” in einem Zukunftsmarkt der IT-Branche Quereinsteiger waren: Ein Online-Handelshaus ist heute der mit Abstand größte Anbieter von Cloud-Services und lässt in diesem zukunftsträchtigen Geschäftsfeld klassische IT-Unternehmen weit hinter sich.
Das Potenzial der eigenen IT-Infrastruktur nutzt Amazon zur Verbreitung von Musik und Filmen. Mit Amazon Prime Video und Amazon Music konkurriert Amazon mit Streaming-Anbietern wie Netflix und Sky, mittlerweile auch mit traditionsreichen Produzenten von Filmen wie Disney oder Warner Bros.
Genau hier hat Amazon seine jüngste Akquisition getätigt: Im Mai 2021 gab Amazon bekannt, das Filmstudio MGM (Metro-Goldwyn-Mayer) und damit eines der prestigeträchtigsten Unternehmen der Unterhaltungsbranche zu kaufen. Der Versandhändler begründet seine Entscheidung vor allem damit, die Rechte der diversen bekannten TV-Franchises von MGM (James Bond, Rocky, …) sowie die “talentierten Leute” dort haben zu wollen. Strategisch interessant der Entwicklungspfad: vom Händler zum Plattformanbieter und dann weiter zum Anbieter eigener Inhalte. Ein anderer Weg als ihn Alphabet mit Youtube oder Facebook gehen, die eine Plattform betreiben, jedoch keine eigenen Inhalte produzieren und anbieten.
Wer mehr dazu wissen will, findet das in diesem aktuellen Buch von Amazon-Insidern. Ein Kapitel ist der Entwicklung von AWS gewidmet, man lernt, dass es keineswegs eine gerader Weg war, der zu diesem großen Erfolg führte.
Ein anderer Konzern, der sein Leistungsangebot signifikant erweitert ist Microsoft. Begonnen hat alles mit Software und hier vor allem mit Betriebssystemen für Personal-Computer. IBM nutzte 1981 für den schnelleren Markteintritt das Betriebssystem DOS von Microsoft und überließ, in einer völligen Fehleinschätzung der Potenziale, die Ausstattung von PCs anderer Hersteller Microsoft. Was niemand erwartet hatte, trat ein: der PC-Markt wurde bald von anderen Unternehmen als IBM dominiert und Microsoft hatte so das goldene Los gezogen. Heute stellt IBM überhaupt keine PCs mehr her, die Notebook-Sparte (Thinkpad) verkaufte man an die chinesische Lenovo.
Microsoft war allerdings nicht mit allen Versuchen der Markterweiterung erfolgreich. So endete der Versuch, Windows auch auf Mobiltelefonen zu etablieren mit einem finanziellen Desaster. Auch der Einstieg ins Hardware-Geschäft verlief wechselhaft, erst seit einigen Jahren hat Microsoft mit seinen “Surface”-Geräten am Markt einigermaßen Fuß gefasst. Hier ist Apple erfolgreich und punktet mit geschlossenen Systemkonzepten von Hard- und Software, gerade wird auch eine Rückkehr zu einer eigenständigen Chip-Ausstattung vollzogen. Diese Strategie gilt auch für Services wie Facetime, das anders als Skype von Microsoft nur auf Apple-Systemen funktioniert. Apple setzt auf vertikale Integration, lockt seine Kunden in ein geschlossenes und attraktives Öko-System, das man nur mit hohem Aufwand verlassen kann, Alex Osterwalder nennt das die Strategie des „goldenen Käfigs“.
Hier ging Microsoft unter dem CEO Sundar Pinchai einen völlig anderen Weg und öffnete sich gegenüber anderen Plattformen. Das Cloud-Service Azure ist nicht zuletzt deshalb so erfolgreich, weil hier alle früheren Berührungsängste zu Mitbewerbsprodukten über Bord geworfen wurden. Was Kunden nutzen wollen, wird angeboten, auch wenn es ein Mitbewerbsprodukt ist oder Open Source, was früher ein No-Go für Microsoft gewesen wäre.
Microsoft bietet mit SQL Server auch eines der führenden Datenbanksysteme an und hat damit IBM mit DB2 deutlich überholt, lediglich Oracle als Spezialist und Pionier relationaler Datenbanksysteme kann hier mithalten. Allerdings mischt auch hier Amazon bereits kräftig mit. SAP ist ein neuer Wettbewerber, der aus einer völlig anderen Ecke kommt, nun aber mit HANA in den Markt für Datenbanksysteme eingetreten ist. Damit hat SAP die bisher geltende Linie verlassen, neutral gegenüber den unterschiedlichen Datenbankanbietern zu sein, eine Entwicklung, die wir hier nicht weiter analysieren wollen, um das Bild nicht völlig unübersichtlich werden zu lassen.
Interessant ist, dass Microsoft SQL Server nicht nur On Premise anbietet, sondern mit Azure eine Auswahl vollständig verwalteter relationaler, NoSQL- und In-Memory-Datenbanken für proprietäre Engines und Open-Source-Engines anbietet, damit also – wie schon oben beschrieben – ohne Rücksicht auf Konkurrenzverhältnisse in anderen Bereichen als Cloud-Anbieter quasi auf alle Pferde setzt, die im Rennen sind. Im traditionsreichen Marktsegment der Datenbanksysteme spielen zwar „klassische“ IT-Unternehmen wie Microsoft und Oracle noch eine führende Rolle, aber die schon genannten Herausforderer sind vorne mit dabei bzw. holen auf. Mit SAP kommt ein atypischer Herausforderer ins Spiel, der seine langjährige Neutralität gegenüber allen Datenbankanbietern mit der HANA-Technologie aufgegeben hat. Mehr dazu im Quadranten der Gartner Group.
Im Jahr 2016 kaufte der Konzern das Karriere-Netzwerk LinkedIn für etwa 26 Mrd. US-Dollar. Social Media ist vom bisherigen Geschäftsmodell von Microsoft doch weit entfernt, daher ist das ein bemerkentswerter Schritt. LinkedIn kann zwar in Größe und Bekanntheit nicht mit Facebook, Instagram und Twitter mithalten, ist in der Nische “professionelle soziale Medien” aber international klarer Marktführer. Nur in Europa kann XING nennenswerte Marktanteile halten.
Doch hier endet der “Ausflug” des Softwareanbieters in die Social-Media-Branche noch nicht. Im Jahr 2020 versuchte Microsoft, das US-Geschäft der Video-App TikTok zu kaufen, für die das Argument der Business-Orientierung wie bei LinkedIn nicht gilt. Der damalige Präsident Donald Trump hatte Bedenken zur (Daten-) Sicherheit der amerikanischen Nutzer, da das Unternehmen “ByteDance”, welches hinter TikTok steht, in China ansässig ist. Daher stellte er ein Ultimatum: Entweder wird das US-Geschäft an ein amerikanisches Unternehmen verkauft bzw. ausgelagert oder TikTok in den USA vollständig gesperrt. Letztendlich hat Trump aber zurückgerudert und ein Verkauf wurde obsolet.
Ein weiteres Geschäftsfeld, das bei Microsoft ins Auge sticht und eigentlich nur bedingt etwas mit seinem Kerngeschäft zu tun hat, ist Internet- und Videotelefonie. In diese Branche hat sich Microsoft im Jahr 2011 eingekauft, als es den Pionier der Internet-Telefonie Skype für 8,5 Mrd. Dollar erwarb und damit eBay als Eigentümer des 2003 gegründeten Unternehmens ablöste.
Microsoft hat hier Cisco mit WebEx erfolgreich herausgefordert und konkurriert mit Zoom, einem Unternehmen, dass auf Online-Meetings und Webinare spezialisiert ist. Gegen Zoom und WebEx sowie andere Lösungen dieses Marktsegments punktet Microsoft vor allem damit, dass MS Teams mit anderen Angeboten von Microsoft wie Office365, Sharepoint und OneDrive integriert wird.
Ein weiterer Vertreter dieser Art ist übrigens auch Facebook, wenn auch bei weitem nicht so stark, wie beispielsweise Microsoft. Begonnen hat Facebook als soziales Netzwerk für Privatpersonen. In dieser Branche hat er die Konkurrenz (Google+, Myspace etc.) sehr schnell verdängt und ist zum klaren Marktführer aufgestiegen. Als dann Instagram und WhatsApp immer stärker wurden, hat Facebook beide aufgekauft und besitzt seitdem quasi ein Monopol auf dem Markt der sozialen Medien (zumindest im Privatbereich).
Doch das Unternehmen hat sich mittlerweile auch stark in andere Branchen eingekauft oder expandiert dorthin. Man denke nur einmal an den Kauf des VR-Anbieters Oculus vor einigen Jahren. Die virtuelle Realität ist mit Sicherheit ein spannendes Konzept in der IT, hat aber mit Social Media nicht viel zu tun. Oder siehe auch Facebooks Arbeit in der Welt der Kryptowährungen. Hier ist das Netzwerk seit Jahren dabei, eine Alternative zu Bitcoin zu etablieren. Wiederum zeigt sich, dass die Branchengrenzen von einst heute keine Aussagekraft mehr haben.
Mit “das Beste” ist hier selbstverständlich nicht gemeint, dass Google (oder der Mutterkonzern Alphabet) das beste Unternehmen der IT-Branche sei. Vielmehr geht es darum, dass die einstige Suchmaschinenfirma mittlerweile zum Universalanbieter von IT-Services geworden ist. Das Foto zu diesem Beitrag habe ich am 25. August 2014 in Mountain View, der Konzernzentrale von Google aufgenommen.
Begonnen hat Google, wie wir alle wissen, als Web-Suchmaschine. In dieser Nische hat es die Konkurrenz (damals vor allem Yahoo) schnell abgehängt und wurde rasch zu einem der größten Technologieunternehmen der Welt. Hier kann bisher nur Microsoft mit Bing einigermaßen mithalten, allerdings mit großem Abstand zu Google. Im Markt für Internet-Browser hat Microsoft einst mit dem Internet Explorer aus scheinbar aussichtsloser Position eine führende Marktstellung erobern können, mittlerweile aber zuerst gegen Firefox und nun gegen Google Chrome stark verloren. Mit der Positionierung von Edge hat Microsoft ebenfalls wenig Erfolg und muss Google Chrome immer weitere Marktanteile überlassen.
Google hat auf der technischen, vor allem aber finanziellen Grundlage seiner Suchmaschine eine enorme Palette an Produkten und Dienstleistungen auf den Markt gebracht und gehört überall zu den Marktführern. Hier einige Beispiele:
Nicht überall war Google mit solchen Erweiterungsversuchen erfolgreich. So war etwa Google+ ein Flop und wurde 2019 eingestellt. Google Lens kämpft mit Akzeptanzschwierigkeiten und wurde von Microsofts HoloLens überholt. Auch Googles Versuch, mit eigenen Mobiltelefonen („Pixel“) Marktanteile zu erobern, verlief bisher für das erfolgsverwöhnte Unternehmen enttäuschend. Von der Öffentlichkeit weitgehend unbemerkt arbeitet Google jedoch mit Google X an disruptiven Innovationen, von denen sicher einige den gewünschten Erfolg bringen und Alphabet (die Google Muttergesellschaft) bald in neuen Märkten positionieren werden.
All diese großen Konzerne mit ihren Geschichten zeigen vor allem eines: Die Geschäftswelt und hier vor allem die IT-Branche hat sich in den letzten Jahren und Jahrzehnten massiv gewandelt. Gab es um die Jahrtausendwende noch klare Abgrenzungen und Strukturen, so sind diese mittlerweile sehr verschwommen und kaum noch wahrnehmbar. Die “Big Player” kommen meist aus ganz anderen Bereichen oder kleinen Nischen, haben sich aber im Laufe der Jahre in immer neue Geschäftsfelder in- und außerhalb der Branche “eingekauft” oder hineinentwickelt.
Junge Unternehmen und deren Führungskräfte tun also in jedem Fall gut daran, die eigene Strategie immer wieder zu hinterfragen und über den Tellerrand der heutigen Branchengrenzen zu blicken. Vielleicht bieten andere, ähnliche oder verwandte Nischen ja spannende Chancen für die geschäftliche oder auch persönliche Etwicklung.
Wenn es um die persönliche Karrierestrategie geht, dann kann ich auf meinen Beitrag zur Anwendung des „Business Model You“ in Verbindung mit der EKS-Strategielehre verweisen.
Wer mehr über solche Marktentwicklungen lernen will, ist herzlich zu meinem Gespräch mit dem Medienmanager Gerhard Zeiler eingeladen. Hier geht es zu einem Bericht und zur Aufzeichnung unseres Gesprächs.
Ein kurzes Video, in dem ich meine Schwerpunkte und Interessen im Allgemeinen vorstelle und besonders darauf eingehe, warum ich aktives Mitglied der ADV bin.
Digitalisierung und Agilität sind einige der Stichworte. Und auch, wie man mit einer Community umgehen soll.
Der Mangel an Ressourcen für die Umsetzung von IT-Anforderungen ist mittlerweile in allen Branchen angekommen. Dass dieser Engpass nicht kleiner, sondern immer größer wird, ist ebenfalls unbestritten. Initiativen zur Behebung des Problems erfolgen bisher vor allem auf Unternehmensebene, dabei geht es allerdings nur darum, den eigenen Engpass zu Lasten anderer Marktteilnehmer zu reduzieren.
Was hat das mit meiner neuesten Zertifizierung (siehe Bild oben) zu tun? Dazu muss ich doch ein wenig ausholen. Ich denke nämlich, dass es sich lohnt, diesem Thema etwas Zeit zu widmen.
Der steigenden Nachfrage nach IT-Fachkräften steht kein ausreichendes Angebot gegenüber. Es ist klar, dass Handlungsbedarf auf der Angebotsseite besteht. So soll das Gesamtangebot an IT-Fachkräften durch verstärkte Werbung für technische Berufe und die gezielte Ansprache von noch nicht ausgeschöpften Potenzialen (z.B. Frauen) gesteigert werden. In Österreich wurde auch ein neuer Lehrberuf (Applikationsentwickler – Coding) eingeführt, um Personen anzusprechen, für die ein Studium – zumindest als Berufseinstieg – nicht in Frage kommt.
Wie immer man es auch dreht, es ist klar: es wird nicht reichen. Noch kann in Europa durch Offshoring (Auslagerung von Entwicklungsleistungen in Schwellenländer wie z.B. Indien) oder Nearshoring (Auslagerung vorwiegend in östliche Nachbarstaaten) ein gewisser Ausgleich geschaffen werden. Es ist allerdings absehbar, dass diese Ländern früher oder später diesen qualifizierten Arbeitskräften im eigenen Land hinreichend attraktive Jobangebote machen können, was ja auch wünschenswert ist. Zudem steht Europa hier im globalen Wettbewerb und ist gegenüber Silicon Valley, Israel und anderen Regionen, die schon lange in diese Branchen investieren, ins Hintertreffen geraten.
Machen wir einfach die Augen zu und hoffen, dass es schon irgendeine Lösung geben wird, auch wenn wir keine Ahnung haben, wie diese aussehen könnte? Das ist keine Strategie, auf die man ernsthaft setzen kann, auch wenn es ganz so aussieht. Niemand kann allerdings seriös die Frage beantworten, wie der Bedarf an Entwicklern unter den gegebenen demografischen und technologischen Rahmenbedingungen abgedeckt werden soll.
Es liegt daher nahe, das Problem auch von der Nachfrageseite anzugehen. Hier setzt eine Initiative des Project Management Instituts (PMI) unter dem Titel „Citizen Development“ an. Ich finde diese Bezeichnung nicht besonders glücklich, weil man bei diesem Begriff eher an Bürgerinitiativen als an Softwarenentwicklung denkt. Technisch gesehen geht es um den Einsatz von Low-Code- bzw. No-Code-Plattformen, die es Anwendern ermöglichen, Anwendungen zur Gänze oder zumindest überwiegend selbst zu entwickeln. Die Technologie ist ein Faktor von vielen, die über den Erfolg entscheiden, daher ist die Verwendung eines untechnischen Begriffs sicher sinnvoll; man gewöhnt sich auch bald daran, kann ich aus eigener Erfahrung berichten.
Microsoft investiert massiv in diese Technologien und berichtet, dass weltweit mehr als 500.000 Unternehmen derzeit (2021) bereits Low-Code-Tools von Microsoft nutzen, darunter 97 Prozent der Fortune 500-Unternehmen. Gartner erwartet, dass Low-Code-Technologien bis 2025 bei rund 70 Prozent der Entwicklungen von Unternehmensanwendungen eingesetzt wird und dass die Zahl der aktiven Citizen Developer bis 2023 viermal so hoch sein wird wie die Zahl professioneller Entwickler.
Die Zusammenarbeit von Anwendern und Technikern ist ein Thema, dass mich seit den Anfängen meiner Berufslaufbahn begleitet. Allein schon deshalb, weil ich als Psychologe schon bald in einem technischen Umfeld gearbeitet habe. Zuerst an einem interdisziplinären Forschungsschwerpunkt der TU Wien und der ETH Zürich, dann in Beratungsunternehmen, wo ich damals der einzige Sozialwissenschaftler unter lauter Technikern und Betriebswirten war.
Meine Vorträge bei Fachkongressen widmeten sich daher nicht zufällig Fragen wie: „Die Pflichten des Anwenders bei Prototyping und Rapid Application Development“ (1993) oder „Ist IT Chefsache? Wie geht das Business-Management mit IT um“ (2008). In einer breit angelegten Initiative von österreichischen CIOs und internationalen Beratungsunternehmen fiel mir die Aufgabe zu, das Human Resource Management in IT-Organisationen zu beleuchten (2004).
Agilität war implizit immer meine Leitlinie, ab 2010 habe ich agile Vorgehensmodelle nicht nur praktiziert, sondern auch in Vorträgen und Publikationen propagiert. Dabei habe ich mich immer für undogmatische Vorgangsweisen ausgesprochen und habe in meinen Projekten Elemente von Scrum, Kanban und Extreme Programming je nach Kontext und Bedarf kombiniert. Die Kommunikation und Kooperation von Anwendern und Informatikern in unterschiedlichen Ausprägungen ist mein ureigenstes Betätigungsfeld und daher engagiere ich mich gerne für die professionelle Umsetzung dieses Ansatzes. Die von PMI angebotenen Zertifizierungen haben meine positive Einstellung bestätigt und eine Reihe von interessanten Anregungen mit sich gebracht.
Untypisch für einen Psychologen und Projektmanager habe ich allerdings auch zu den technologischen Aspekten des Citizen Developments langjährige persönliche Erfahrung. In den frühen 90-ger-Jahren hatte ich eine Software für das Produktmanagement von Versicherungen konzipiert und in Kooperation mit der Generali-Versicherungsgruppe und einem deutschen Softwarehaus 1995 auf den Markt gebracht. Daraus entstand das Produkt VP/MS, das auch heute noch weltweit bei zahlreichen Versicherungsunternehmen im Einsatz ist, wenn ich selbst auch seit 1999 nach dem Verkauf an ein internationales Softwareunternehmen (heute Teil von DXC) keinen direkten Bezug mehr dazu habe.
Die Idee dieses Produktes war es, Fachabteilungen von Versicherungen zu ermöglichen, das Regelwerk und die Berechnungslogik von Versicherungsprodukten selbst zu implementieren, anstatt es in einem Pflichtenheft zu dokumentieren und auf dessen mehr oder minder korrekte Umsetzung zu setzen. Auslöser dafür war die Erfahrung, dass es zwischen den Fachbereichen (meist Aktuare) und der IT regelmäßig zu Kommunikationsproblemen kam und diese zu langen Durchlaufzeiten und hohem Test- und Korrekturaufwand führten.
Was ich damals konzipierte, war eine Business Rule Engine mit einem Definitionsarbeitsplatz, dessen User-Interface hinsichtlich seiner technischen Komplexität mit Excel zu vergleichen war. Die Gestaltung des User-Interface orientierte sich an einer kundenorientierten und daher nicht-technischen Sicht auf das Versicherungsprodukt. Dank eines genialen Entwicklerteams auf Seiten des technischen Kooperationspartners konnte aus dieser Produktdefinition Code erzeugt werden, der die gesamte Produktlogik den Anwendungssystemen gekapselt zur Verfügung stellte. Informatiker benötigten keine detaillierte Auseinandersetzung mit der Berechnungs- und Prüflogik verschiedener Produkte, sondern integrierten das „Produktmodell“ mittels einer generischen Schnittstelle in die verschiedenen Anwendungssysteme.
Die praktische Anwendung zeigte, dass mit dieser neuen Aufgabenverteilung zwischen Anwendern und IT eine enorme Reduktion des Gesamtaufwandes erzielt werden konnte. Zusätzlich wurde die IT von Aufgaben entlastet, die nicht zu deren Kernkompetenz gehören.
An diesem Fallbeispiel wird deutlich, dass Citizen Development und klassische, professionelle Softwareentwicklung kein Gegensatz sind, sondern nur in einer sinnvollen Verschränkung und gegenseitigen Ergänzung zum Erfolg führen können. Für mich zeigte diese Erfahrung aber auch, dass Technologie und Vorgehensmodelle einander beeinflussen. Technologie ist auch kein beliebig austauschbares Element, sondern ermöglicht bzw. erfordert adäquate Vorgehensmodelle, wenn man den Erfolg sichern will.
Mehr über den Nutzen von Business Rules Engine habe ich schon 2014 hier publiziert.
PMI sieht in seinem Framework für Citizen Development (kurz: CD) die Governance als die zentrale Herausforderung. Die Akzeptanz von CD leidet tatsächlich daran, dass man auf Seiten der IT einen Wildwuchs von Anwendungen befürchtet. Die gefürchtete „Schatten-IT“, früher z.B. in Form von Access-Datenbanken, heute durch Cloud-Services, die Anwender ohne Abstimmung mit der IT nutzen, könnte durch Citizen Development einen neuen Aufschwung erleben.
PMI hingegen sieht CD als ein Instrument, um die Schatten-IT zurückzudrängen. Dazu ist allerdings ein disziplinierter Umgang mit den Potenzialen der Low-Code/No-Code-Plattformen (kurz: LCNC) entscheidend.
PMI unterscheidet 3 Varianten der Umsetzung, je nach technischer Komplexität und Risiko, wie folgende Grafik zeigt (© PMI):
Grundlage der Entscheidung ist eine strukturierte und obligate Analyse von Vorhaben, die in Abstimmung mit der IT und für diese völlig transparent geschehen muss. Während in der Variante „Fast track“ Citizen Developer weitgehend eigenständig arbeiten, sind sie in der Variante „IT Delivery“ Teil eines von der IT geführten Projektes. Bei „Assisted“ liegt der Ball zwar bei den Citizen Developern, die IT ist jedoch regelmäßig zur Unterstützung oder auch zu Reviews und bei Entscheidungen mit technischen Implikationen einbezogen. PMI bietet zu allen relevanten Kriterien nützliche und qualitativ hochwertige Templates, die nicht nur bei CD-Projekten eingesetzt werden können.
Die oben beschriebene Business-Rule-Engine VP/MS erforderte jedenfalls ein Vorgehensmodell „IT Delivery“, allerdings nur bei der Integration des gekapselten Produktmodells in die Zielsysteme. Die damals erlebten Hürden der Akzeptanz dieses Lösungsansatzes gelten auch für Citizen Development. Die IT sah vielfach die Zusammenarbeit mit „Laien“ als belastend, manche empfinden diese auch als Konkurrenz oder fürchten, sie könnten den Mythos der Software-Entwicklung entzaubern und damit das Prestige des Software-Ingenieurs beschädigen. „Das Einzige was stört, ist der Anwender“, diesen Vortragstitel habe ich 2006 nicht zufällig gewählt.
In einigen Unternehmen mussten wir hilflos zusehen, wie die IT die Fachbereiche schrittweise aus der Projektarbeit verdrängte und VP/MS als Entwicklungsplattform für Techniker nutzte. Damit ging ein Großteil der Effizienzgewinne wieder verloren.
Unternehmen, die das Potenzial dieses Ansatzes verstanden, bauten ein eigenes Skill-Profil auf Seiten der Fachbereiche auf. Die Gesamtmigration aller IT-System der Generali Versicherung anlässlich der Euro-Einführung konnte z.B. durch die parallele Arbeit von VP/MS-Modellierern und klassischen Entwicklern innerhalb der unverhandelbaren Terminsetzung umgesetzt werden. Übrigens gibt es auch heute noch Stellenanzeigen für „VP/MS-Modellierer“.
Ich sehe Citizen Development (CD) als eine – mehr oder minder neue – Option für die Gestaltung der Zusammenarbeit von Business und IT. Die Erfolgsfaktoren dafür sind dieselben wie sie generell gelten. Allerdings kann ich mir nicht vorstellen, dass ein Unternehmen ohne agile Kultur damit Erfolg haben kann.
CD ist am ehesten mit Extreme Programming (XP) vergleichbar und ich meine, dass man viel von den mit XP gewonnenen Erfahrungen profitieren könnte. Damit ließe sich CD auch in ein agiles Framework wie SAFe integrieren, wo ja auf Projektebene Scrum, Kanban und XP wahlweise eingesetzt werden können.
Generell ist die Zusammenarbeit von Business und IT der alles entscheidende Erfolgsfaktor im Zeitalter der Digitalisierung. Mehr dazu habe ich im Kapitel 10 meines Buches „12 Halbwahrheiten über IT-Projekte“ geschrieben. Tragen Sie sich in meine Mail-Liste ein und Sie bekommen sofort dieses Kapitel meines Buches als Download.
Sehr interessante und detaillierte Präsentationen gibt es hier bei PMI Austria.
The lack of resources for the implementation of IT requirements has now become reality across all industries. It is also undisputed, that this bottleneck situation is not getting better, but getting worse. So far, initiatives to solve the resource problem have mainly taken place at company level, where the objective is only to reduce one’s own bottleneck, if necessary at the expense of other market participants. How does this relate to my latest certification (see picture above)? To explain the correlation, please let me to elaborate on this. I think it is worth devoting some time to this topic.
The increasing demand for IT specialists is not matched by an adequate supply. It is clear that there is a need for action on the supply side. The overall number of IT specialists could be increased through advertising for technical professions and targeted addressing of potentials that have not yet been exhausted (e.g. women). In Austria, a new apprenticeship (application developer – coding) was introduced in order to address people for whom studying – at least as a career entry – is not an option. Whichever way you turn it, it is clear: it will not be enough. A certain amount of compensation can still be created in Europe through offshoring (outsourcing of development services to emerging countries such as India) or nearshoring (outsourcing primarily to neighboring countries in the east). It is foreseeable, however, that sooner or later these countries will be able to offer these qualified workers sufficiently attractive job opportunities in their own country, which is of course desirable. In addition, Europe is in global competition here and has lagged behind Silicon Valley, Israel and other regions that have been investing in these industries for a long time. Do we just close our eyes and hope that there will be some solution, even if we have no idea what it might look like? This is not a strategy that you can seriously bet on, although it might look like it at the moment. However, no one can reliably answer the question of how the need for developers can be covered under the given demographic and technological framework.
It therefore makes sense to tackle the problem from the demand side as well. This is where an initiative by the Project Management Institute (PMI) comes in under the title “Citizen Development”. I am not particularly happy with this term, because when you hear it you think of citizens‘ initiatives rather than software development. From a technical point of view, it is about the use of low-code or no-code platforms that enable users to develop applications entirely, or at least predominantly, themselves. Technology is one of many factors that determine success. So the use of a non-technical term certainly makes sense; you will soon get used to it, I can tell from my own experience. Microsoft is investing heavily in these technologies and reports that more than 500,000 companies worldwide are currently (2021) already using Microsoft low-code tools, including 97 percent of the Fortune 500 companies. Gartner expects that low-code technologies will be used in around 70 percent of corporate application developments by 2025 and that the number of active citizen developers will be four times the number of professional developers by 2023.
The cooperation between users and technicians is a topic that has accompanied me since the beginning of my professional career. Perhaps because I was working as a psychologist in a technical environment almost from the beginning. First at an interdisciplinary research project at the Vienna University of Technology and the ETH Zurich, then in a consulting company, where at that time I was the only social scientist among technicians and business economists. It is no coincidence, that my presentations at congresses were devoted to questions such as: “The duties of users in prototyping and rapid application development” (1993) or “Is IT a C-level topic? How does business management deal with IT ”(2008). In a broad initiative by Austrian CIOs and international consulting firms, I was given the task of human resource management in IT organizations (2004). Agility was always my guideline implicitly, from 2010 on I not only practiced agile process models, but also propagated them in lectures and publications. I have always spoken out in favor of undogmatic approaches and have combined elements of Scrum, Kanban and Extreme Programming in my projects depending on the specific context and needs. The communication and cooperation of users and IT specialists in various forms is my very own field of activity and therefore I am happy to be involved in the professional implementation of this approach. The certifications offered by PMI have confirmed my positive attitude and brought a number of interesting suggestions with them.
Atypical for a psychologist and project manager, however, I also have many years of personal experience with the technological aspects of citizen development. In the early 1990s I designed software for product management for insurance companies and launched it in 1995 in cooperation with the Generali insurance group and a German software company. This gave rise to the product VP/MS, which is still used by numerous insurance companies around the world, I however haven’t had any direct reference to it since 1999 after selling it to an international software company (now part of DXC). The idea of this product was to enable specialist departments of insurance companies to implement the rules and the calculation logic of insurance products themselves, instead of documenting it in a specification and relying on its more or less correct implementation. The trigger for this was the experience that there were regular communication problems between the departments (mostly actuaries) and IT, which led to long lead times and high testing and correction efforts. What I designed at the time was a business rule engine with a definition workstation whose user interface could be compared to Excel in terms of its technical complexity. The design of the user interface was based on a customer-oriented and therefore non-technical view of the insurance product. Thanks to an ingenious team of developers on the side of the technical cooperation partner, code could be generated from this product definition, which encapsulated the entire product logic and made available to the application systems. Computer scientists did not need a detailed analysis of the calculation and test logic of various products, but integrated the „product model“ into the various application systems using a generic interface. The practical application showed that with this new distribution of tasks between users and IT, an enormous reduction in the overall effort could be achieved. In addition, IT was relieved of tasks that were not part of its core competency.
This case study makes it clear that Citizen Development and classic, professional software development are not mutually exclusive, but can only lead to success if they are meaningfully interlinked and complement each other. For me, however, this experience also showed that technology and procedural models influence one another. Technology is also not an arbitrarily exchangeable element, but enables or requires adequate procedural models if one wants to ensure success. Citizen Development and Governance PMI sees governance as the central challenge in its framework for Citizen Development (CD for short). The acceptance of CD actually suffers from the fear of a proliferation of applications on the IT side. The dreaded „shadow IT“, earlier e.g. in the form of access databases, today through cloud services that users use without coordination with IT, could experience a new upswing through Citizen Development. PMI, on the other hand, sees CD as an instrument to push back shadow IT. For this, however, a disciplined handling of the potential of the low-code / no-code platforms (short: LCNC) is crucial. PMI distinguishes between 3 implementation variants, depending on the technical complexity and risk, as the following graphic (© PMI) shows.
The basis of the decision is a structured and obligatory analysis of projects, which has to be done in coordination with the IT and in a completely transparent manner. While in the „Fast Track“ variant Citizen Developers work largely independently, in the „IT Delivery“ variant they are part of a project led by IT. With “Assisted” the ball lies with the citizen developers, but IT is regularly involved for support, reviews and decisions with technical implications. PMI offers useful and high-quality templates for all relevant criteria that can be used not only for CD projects.
The business rule engine VP / MS described above required an “IT Delivery” process model, but only when integrating the encapsulated product model into the target systems. The hurdles encountered at that time in the acceptance of this approach also apply to Citizen Development. IT often saw working with „laypeople“ as stressful, some also perceive them as competition or fear that they could demystify the myth of software development and thus damage the prestige of software engineers. “The only thing that bothers you is the user”, I didn’t choose this lecture title in 2006 by chance. In some companies we had to watch helplessly as IT gradually pushed the departments out of project work and used VP / MS as a development platform for technicians. As a result, a large part of the efficiency gains was lost again. Companies that understood the potential of this approach built their own skills profile inside the departments. The overall migration of all IT systems of Generali Versicherung on the occasion of the introduction of the Euro could be implemented e.g. through the parallel work of VP / MS modelers and classic developers within the non-negotiable schedule. Incidentally, there are still job advertisements for “VP / MS modelers” today.
I see Citizen Development (CD) as a – more or less new – option for structuring the collaboration between business and IT. The success factors for this are the same as they generally apply. However, I cannot imagine that a company without an agile culture can be successful with it. CD can best be compared to Extreme Programming (XP) and I think that one could benefit a lot from the experience gained with XP. This means that CD can also be integrated into an agile framework such as SAFe, where Scrum, Kanban and XP can optionally be used at the project level. In general, the cooperation between business and IT is the all-important success factor in the age of digitization.
Der Umgang mit der IT ist ein wichtiges Thema im öffentlichkeitsnahen und öffentlichen Bereich. Nicht immer wird das unter diesem Titel abgehandelt, nicht immer systematisch, außer im Falle einer verpflichtenden externen Prüfung, die mittlerweile auch im öffentlichen Sektor immer häufiger ist.
Worum geht es bei IT Governance im Kern? Es geht darum, dass sich das Top-Management mit dem Thema IT in adäquater Weise auseinandersetzt. Man könnte das mit dem Rechnungswesen vergleichen: Es ist undenkbar, dass sich das Top-Management nicht für „die Zahlen“ interessiert und das auch noch laut verkündet. IT sollte ähnlich gesehen werden, denn diese kann einem Unternehmen zum Erfolg verhelfen oder es entscheidend schwächen. Das Ignorieren der IT als Handlungsfeld des Top-Managements ist daher höchst problematisch und in den meisten Fällen sogar unverantwortlich.
Auch die interne Sicht der IT als Dienstleister ist nicht optimal. Wichtig ist der Dialog zwischen der IT und deren Anwendern (damit sind nicht nur die „User“ gemeint, sondern primär das Management der operativen Bereiche). Innovative und funktionierende Lösungen können nur im Dialog entstehen. Hier gibt es aktuell viel Bewegung unter dem Stichwort „Agilität“, wir sollten diese Chance nutzen, um uns von hinderlichen Paradigmen wie z.B. dem „Wasserfallmodell“ zu lösen.
Die Entwicklung der Geschäftsprozesse wird entscheidend von Technologieimpulsen geprägt. So lächerlich es scheinen mag, hat das vorher Jahrzehnte lang notleidende Thema der Management-Informations-Systeme durch Tablets (insbesondere das iPad) einen Schub bekommen und ist vielerorts selbstverständlicher Teil der Management-Instrumentarien geworden. Die Organisation muss lernfähig sein und solche Impulse annehmen, sonst wird viel Potenzial vergeudet.
Das Gesamtbild der Faktoren, die Gegenstand von IT-Governance sind, habe ich in dieser Grafik zusammengefasst, in besserer Auflösung und im Kontext einer ausführlicheren Präsentation gibt es diese Grafik hier.
Damit allerdings IT Governance nicht zu einem Feld für jene wird, die gerne im Fachgebiet der anderen dilettieren, habe ich für mich die „Regel vom letzten Wort“ entwickelt. In Business-Fragen hat das Business das letzte Wort. In IT-Themen hat die IT das letzte Wort. Dazwischen kann jeder einen Beitrag leisten. Dies führt dazu, dass am Ende die entscheiden, die das fundierteste Wissen im jeweiligen Themenbereich besitzen und vor allem auch die Verantwortung tragen. Im Gegensatz zu früheren Formulierungen meine ich, dass das erste Wort jedem zusteht; auch dafür ist die Nutzung von iPads im Management ein aktuelles Beispiel, wo eine technologische Weichenstellung von Business-Managern gesetzt wurde.
Das Verhältnis von Business und IT ist auch Gegenstand meines Buches „12 Halbwahrheiten über IT-Projekte“, Kapitel 10 behandelt die Halbwahrheit „Die IT ist ein Dienstleister“. Das Buch gibt es als Hardcover, Softcover oder Kindle hier.
In einem Interview mit Christopher Schulz von Palladio-Consulting hatte ich Gelegenheit, die Ursache für das so häufige Scheitern von IT-Projekten zu analysieren.
Kurz zusammengefasst: Es gibt keine grünen Wiesen mehr, die vollständige Überwälzung der Ergebnisverantwortung auf ein noch so großes und noch so qualifiziertes IT-Unternehmen kann daher nicht mehr funktionieren. Denn: „Kein externer Dienstleister ist in der Lage, die Chancen und Risiken einer IT-Investition ohne intensive Mitwirkung des Kunden, und dort sowohl IT als auch Business, zu erkennen und umzusetzen.“
Das vollständige Interview gibt es hier.
Mehr zu meinem Buch, das Auslöser für dieses Interview war, gibt es hier.
Derzeit ist ChatGPT in aller Munde. Was also lag näher als mein zentrales Thema mit diesem Tool zu diskutieren. Meine Frage war: What can improve communication in IT projects?
Die Antwort habe ich dann mit DeepL ins Deutsche übersetzt und hier ist das Ergebnis (ohne jede inhaltliche Änderung von meiner Seite, habe nur Bullet Points eingefügt!):
Es gibt mehrere Möglichkeiten, die Kommunikation in IT-Projekten zu verbessern:
Mein Resümée: Nicht schlecht! Keine überraschenden Erkenntnisse, aber das ist auch nicht die Aufgabe solcher Tools. Es bringt meiner Einschätzung nach den Common Sense zu dieser Frage gut auf den Punkt.
Das war für mich ein Anstoß, eigene Beiträge zu diesem Thema zu sichten. Das sind die Ergebnisse meiner Bestandsaufnahme, wo ich Themen adressiere, die zur Beantwortung der gestellten Frage dazu gehören, vom AI-Tool aber nicht als relevant erkannt wurden:
Empfehlungen zur Gestaltung der Anforderungsdefinition (dieses für IT Projekte spezifische Thema hat die AI nicht berücksichtigt – insofern „common sense“).
Empfehlungen zur Art der Formulierung von Aussagen, die einen großen Unterschied machen.
Empfehlungen zu einem wirkungsorientierten Reporting
Umgang mit Kommunikationsproblemen, die nicht an mangelhafter Kommunikation liegen, sondern tiefere Ursachen haben (also Konflikte)
Aber wie anfangs gesagt: Das Ergebnis der AI-Tools ist durchaus beachtlich und ich verstehe, dass Google aufgeschreckt ist. Da kündigt sich die nächste Generation an Tools an, die über die Leistungen der aktuellen Suchmaschinen hinausgehen (auch wenn Google schon sehr viel implementiert hat, was deutlich mehr ist als eine Sammlung von Links). Es wird spannend.
BTW: Deutsche Version hier
Especially in highly regulated companies and organizations, a disproportionate amount of effort is spent on project controlling and quality management. A wide range of data is used to measure the progress of the project (measured in terms of deadlines, timeframes, costs and results etc.). Very often , I have seen project controllers enthusiastically operating with milestone trend analysis or Monte Carlo simulations. Never, really never, have I seen that this effort was experienced as helpful by the operational teams.
However, I have often seen that experienced project managers have used project controlling to reassure the stakeholders and avoid counterproductive interventions in the project work. At one point, I was in this role myself and, as project controller, quite deliberately took on the role of a protective shield for the project work. In the end, everyone involved was happy and for me it is still the project in which I contributed the least to the success and still received a lot of praise and recognition from all sides. Of course, I paid very close attention to making sure the project was well on track. The only thing was that I refrained from passing on problems and deviations from the planned values that arose at short notice to the client without filtering them, but instead supported the project management team in overcoming these challenges. Of course, I would have reported very well if a real threat to the project goals had occurred, but that too in the sense of supporting the project team.
Unfortunately, only a few project controllers are prepared to interpret their role in this way. This probably requires sufficient project management experience of one’s own and also courage. If something went wrong, the project controller would be left out in the cold.
An important idea for me is also that the systematics of project controlling has a decisive influence on project work.
„You get what you measure“ is known as a managerial maxim. The conclusion from this is that you have to measure everything that is important, because only then will it happen.
This is undoubtedly a correct approach. But there is another effect. From quantum physics we know that the measuring process is part of every measuring result. It makes no sense to imagine a reality (the Kantian „thing in itself“ or the „objective reality“), which would then be more or less correctly represented by a measuring process. There is no reality independent of our observation which could be compared with our perception.
Depending on how the project progress is defined and measured, priorities will be set in the project. Project management will ensure that the criteria for measuring project progress are given particular weight. The use of resources will be managed accordingly. The agile manifesto has drawn a radical conclusion: Functioning software is the key measure of project progress. In many projects, however, other results count as well or even more. Documentation, acceptance protocols, status reports, error statistics, lines of code, etc., etc. Depending on what is measured, the way a project works also changes. At the latest, when a project participant has once proudly reported what has been achieved and then had to take heavy criticism because of missing documents, the next time the team will prefer to complete the documentation and submit it for review than to further develop and stabilize the software.
The management mantra quoted at the beginning, „You get what you measure,“ is therefore correct. Depending on how I define my metrics in project controlling, how often I measure and how accurately I measure, the way a project works will change. So it’s not simply a matter of finding the right measurement method to identify the „reality“ of the project. Project controlling intervenes massively in the project, and quite deliberately. Project controlling should always have a package insert, it is a very strong medicine with possibly not desired effects.
English version here/englische Version hier.
Große IT-Projekte können nicht ohne Mitwirkung externer Dienstleister abgewickelt werden. Natürlich benötigen die Beteiligten als Grundlage für die Beauftragung eine entsprechend ausführliche Vertragsgestaltung.
Die Durchführung von detaillierten Vertragsverhandlungen hat einen unschätzbaren Vorteil. Die Arbeitsweise im Projekt wird gemeinsam durchgearbeitet, es werden Risikoszenarien diskutiert und darüber gesprochen, wie man diese bewältigen würde. Wenn man dies unterlässt, fehlt eine wichtige Phase des gegenseitigen Abtastens und Einander-Kennenlernens vor dem Start der eigentlichen Projektarbeit.
Vertragsinhalte müssen jedenfalls folgende Themen abdecken:
Da der Erfolg eines Projektes wesentlich von der Performance des externen Dienstleisters abhängt, ist das Bestreben, das Erfolgsrisiko durch Verträge auf diesen zu überwälzen, verständlich. Betrachtet man allerdings die finanzielle Leistungsfähigkeit eines solchen Unternehmens, so erkennt man, dass es eine relativ geringe Kapitalausstattung hat. IT-Dienstleistungsunternehmen finanzieren sich über Deckungsbeiträge aus laufenden Umsätzen. Selbst große IT-Konzerne können Honorarminderungen nur in beschränktem Ausmaß kompensieren. Eine Haftung für Vermögensschäden durch entgangene Gewinne des Kunden übersteigt jedenfalls deren finanzielle Leistungsfähigkeit. Es würde auch kein großes Unternehmen einen Werkvertrag oder Dienstvertrag unterschreiben, der eine solche Verpflichtung beinhaltet.
Dies gilt umso mehr für kleinere IT-Dienstleister. Würde ein solches Unternehmen das Risiko eingehen, einen solchen Werkvertrag oder Dienstvertrag zu unterzeichnen, wäre bei Eintritt des Haftungsfalles der Konkurs die unausweichliche Folge. Eine Fortführung des Projektes wäre in diesem Fall nahezu unmöglich.
Aus diesem Grund schrecken die Auftraggeber selbst bei gravierenden Leistungsmängeln davor zurück, die volle Härte der Verträge in Anspruch zu nehmen. Harte Verträge, die zu Beginn zu Lasten des Auftragnehmers durchgesetzt werden, belasten häufig das Klima der Zusammenarbeit und erweisen sich im Ernstfall regelmäßig als zahnlos. Damit wird deutlich, dass der reale Schaden eines gescheiterten IT-Projektes für den Auftraggeber immer wesentlich höher ist als für den Auftragnehmer, egal wie die Vertragsgestaltung dies darstellt.
Die Vertragsgestaltung ist Sache der Juristen. Dabei gibt es ein grundsätzliches Problem. Juristen kennen Projekte nur aus Vertragsverhandlungen und haben selten mit der normalen Projektabwicklung zu tun. Erst wenn Projekte scheitern und vielleicht sogar vor Gericht landen, kommen die Juristen wieder ins Spiel. In einer solchen Situation, in der eine Fortführung des Projekts ohnehin ausgeschlossen ist, sind „harte“ Vertragsklauseln viel wert. Es ist daher nur natürlich, dass Juristen auf harte Absicherungsformulierungen achten, z.B. Vertragsstrafen und Haftungsbestimmungen. Diese Regelungen spielen bei einem einigermaßen gut laufenden Projekt keine Rolle. Sie stören auch nicht.
Wenn es bei einem gescheiterten Projekt nur noch um finanzielle Schadensbegrenzung geht, kann man aus solchen Klauseln je nach Bonität des Auftragnehmers zumindest eine gewisse Schadensminderung herausholen. Eine gerichtliche Auseinandersetzung wird gescheut, da die Schuldfrage nur durch eine Reihe von teuren, zeitaufwendigen und in ihren Aussagen nicht vorhersehbaren Gutachten geklärt werden kann. Daher enden solche Streitigkeiten meist mit einem außergerichtlichen Vergleich. Der Schaden des Auftraggebers ist dabei regelmäßig weit höher als das, was in der Praxis durch Vertragsstrafen und Haftungsansprüche erreicht werden kann. Je härter aber die Vertragsklauseln zugunsten des Auftraggebers formuliert sind, desto besser sind die Karten bei Vergleichsverhandlungen.
Wenden wir uns nun den Auswirkungen eines Vertrages auf den „normalen“ Projektverlauf zu. Je härter und bedrohlicher die Vertragsbestimmungen für den Auftragnehmer sind, desto mehr werden Projektmanager, Anwälte und Claim Manager beim Auftragnehmer von der Geschäftsleitung angewiesen, Bedrohungsszenarien mit aller Macht abzuwenden. Vorsorglich versuchen sie natürlich, die Zugeständnisse, die sie bei den Vertragsverhandlungen machen mussten, wieder auszugleichen. Die Chancen dafür stehen gut. Es gibt kein IT-Projekt, bei dem die zu Projektbeginn gegebenen Vorgaben und Rahmenbedingungen bis zum Projektende konstant bleiben.
Je genauer alles in den Vertragsverhandlungen festgelegt wurde, desto größer ist die Wahrscheinlichkeit, dass auf Seiten des Auftraggebers etwas passiert, was nicht den vertraglichen Regelungen entspricht. Ein Klassiker sind die Mitwirkungspflichten des Auftraggebers. Diese sind immer erforderlich, je größer das Projekt, desto mehr. Je mehr Druck auf den Auftragnehmer in den Vertragsverhandlungen ausgeübt wird, desto mehr wird der Auftragnehmer darauf bestehen, auch die Mitwirkungspflichten des Auftraggebers genau zu definieren. Dies ist für den Auftraggeber schwer abzulehnen. Sobald der erste Punkt aus dem Pflichtenkatalog des Auftraggebers nicht erfüllt wird, setzt ein Dominoeffekt ein.
Ist der Auftraggeber bis zur Auftragsvergabe und auch noch in den ersten Monaten des Projektes der umworbene Kunde, dessen Entscheidungen zählen, so entwickelt sich mit zunehmendem Projektfortschritt eine Abhängigkeit des Auftraggebers von den mittlerweile mit der Materie vertrauten Mitarbeitern des externen Dienstleisters. Irgendwann ist der Punkt erreicht, an dem die größte Sorge des Auftraggebers darin besteht, dass diese Schlüsselpersonen nicht mehr zur Verfügung stehen. Während in anderen Branchen, z.B. im Baugewerbe, die Austauschbarkeit der Dienstleister hoch ist, ist dies bei IT-Projekten nicht der Fall, insbesondere bei agilen IT-Projekten.
Die externen Mitarbeiter sind nach relativ kurzer Zeit mit den Details besser vertraut als die Mitarbeiter des Auftraggebers. Zum einen deswegen, weil es sich im Regelfall um hoch qualifizierte und hoch motivierte Leute handelt, und zum anderen, weil sie nicht im Tagesgeschäft verfangen sind. Sie erwerben daher sehr schnell solide Kenntnisse der Anforderungen. Aufgrund ihrer Routine und Fokussierung sind sie schnell mit der Materie vertraut und bald wissen sie darüber mehr als ein durchschnittlicher Sachbearbeiter, was besonders in agilen IT-Projekten von Vorteil ist.
Der Auftraggeber ist daher darauf angewiesen, dass der Auftragnehmer sein Schlüsselpersonal nicht abzieht. Diese Personen, die als Know-how-Träger umso wichtiger sind, je weniger Mitwirkungsleistungen der Auftraggeber akzeptiert hat, werden schließlich zu Assen im Machtspiel zwischen den Vertragsparteien. Ist diese Spirale erst einmal in Gang gesetzt, folgt das dicke Ende meist auf dem Fuß. Neue Vertragsverhandlungen, jetzt unter deutlich schlechteren Voraussetzungen für den Auftraggeber, der mit dem Rücken zu Wand steht, regeln die Fortführung des Projektes. Immerhin kann dieses nun zu Ende gebracht werden, es wird insgesamt später fertig als geplant und es wird auch teurer. Dass genau die „großartigen“ Vertragsbestimmungen zu Beginn die Probleme deutlich verschlimmert haben, ist nicht offensichtlich. Es will zu diesem Zeitpunkt auch niemand hören. Es ist auch vernünftig, jetzt keine Diskussionen über Vergangenes zu führen, besonders in agilen IT-Projekten.
Wenn die Beteiligten also Verträge erarbeiten, so sollten sie sich auf eine produktive Zusammenarbeit ausrichten und deren Modalitäten regeln. So unbefriedigend es auch ist, wenn kein Festpreis vereinbart werden kann, so ist doch die Vereinbarung eines Verfahrens zur Preisermittlung und zum Umgang mit erkannten Mehraufwänden der vernünftigere Ansatz für eine faire Vergütung.
Es gibt IT-Projekte, bei denen eine Fixpreisvereinbarung möglich und sinnvoll ist. Das gilt für den Betrieb eines Rechenzentrums, für die Installation von Hardware und Standardsoftware oder auch für die Abwicklung von Help-Lines. Dort können auch Pönalen so definiert werden, dass sie eine steuernde Wirkung auf die Leistungen des Auftragnehmers haben. Es ist nur gefährlich, ein wirksames Werkzeug am falschen Objekt anzuwenden, besonders wenn es um Festpreisvereinbarungen geht.
Verträge müssen eine konstruktive und produktive Zusammenarbeit ermöglichen. Wenn ein Projekt gut läuft, dann schaut man allenfalls in den Vertrag im Sinne von „Was haben wir dazu vereinbart? – Aha, dann machen wir es so!“, was eine gute Vertragsgestaltung ausmacht.
Es bringt dem Auftraggeber mehr, auf das wirtschaftliche Interesse des Auftragnehmers an einem gelungenen Projekt zu setzen als auf Pönalen und Haftungen für den Fall des Misslingens. Dafür ist allerdings erforderlich, die Arbeitsweise eines agilen Projektes zu verstehen und entsprechend zu handeln, was eine durchdachte Vertragsgestaltung voraussetzt.
Generell beweisen die Zahlen der Standish Group, dass vor allem große IT-Projekte mit einem agilen Vorgehensmodell deutlich bessere Chancen auf Erfolg haben. Während das Handwerkszeug eines klassischen Werkvertrages als allseits bekannt vorausgesetzt werden kann, ist die Vertragsgestaltung für agile Projekte noch nicht Allgemeingut. Wird in Projektaufträgen bzw. in Verträgen eine Philosophie der Projektsteuerung festgeschrieben, die einer agilen Vorgehensweise widerspricht, geraten die Vertragspartner entweder in einen vertragsfreien Raum oder sie kollidieren ständig mit Vertragsbestimmungen, die nicht zum tatsächlichen Vorgehen passen, was die agile Softwareentwicklung behindert.
Generell beruht agile Softwareentwicklung im Kern auf einer Aufwandsverrechnung, da ein fixer Werklohn mangels detaillierter Ergebnisbeschreibung nicht definiert werden kann. Die daraus resultierende Unschärfe wird von allen Beteiligten regelmäßig stark überschätzt: Dabei weiß jeder aus eigener Erfahrung, dass Fixpreise durch Change Requests regelmäßig ausgehebelt werden. Daher ist eine Aufwandsschätzung mit eingestandener Bandbreite sowie einer darauf aufsetzenden Projektsteuerung durch Burn-Down-Charts 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. Dies gilt umso mehr, wenn die Umsetzung nicht durch die unternehmenseigene IT-Abteilung erfolgt, sondern durch ein externes Unternehmen. Eine flexible Vergütung ist daher oft die bessere Wahl.
Die zentrale Herausforderung kann so formuliert werden: Professionelle Projektsteuerung ersetzt detaillierte Ergebnisdefinition. Abweichungen werden so früher erkannt als in klassischen Projekten. Damit das funktioniert, müssen geeignete Prozesse (auch vertraglich) definiert und gelebt werden. Agile Projekte erfordern mehr Projektmanagement-Skills, vor allem aufseiten des Kunden, und können durch Methoden wie Scrum unterstützt werden.
Agile Projekte können daher nur gelingen, wenn es aktive und sachkundige Mitwirkungsleistungen des Kunden gibt. Im Falle einer externen Beauftragung gilt dies nicht nur für die Anwenderbereiche („Business“), sondern auch für die IT-Abteilung des Auftraggebers. Diese durchgängigen Mitwirkungsleistungen erscheinen gegenüber einem Wasserfallmodell als Mehraufwand. Ob man diese Ersparnis in späteren Projektphasen durch Nachbesserungen wieder verliert, weiß man zu Beginn nicht. Meine eigene Erfahrung und die aller agil arbeitenden Projektmanager zeigt, dass der tatsächliche Gesamtaufwand gut gemanagter agiler Projekte deutlich geringer ist als der eines klassischen Projektes gemäß einem Wasserfallmodell. Allerdings ist der Aufwand anders verteilt, nämlich über die gesamte Laufzeit ziemlich gleichmäßig. Zu Fragen des Aufwandes habe ich in agilen IT-Projekten mit verschiedenen agilen Methoden (Scrum, Kanban, XP) positive Erfahrungen gemacht.Kapitel 4 meines Buches ausführlicher Stellung genommen.
Ebenso gilt: Agiles Vorgehen und agile Zusammenarbeit erfordern eine vertrauensvolle Zusammenarbeit. Dafür müssen Bereitschaft und Fähigkeit zu interdisziplinärer Arbeit und Social Skills bei allen Beteiligten verfügbar sein.
Nach meiner Erfahrung 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 Aufwandsschätzungen können auf Architekturmängel zurückzuführen und daher in Wirklichkeit angemessen sein. In der Praxis werden diese allerdings meist als Indikator für eine unfaire Preisgestaltung des Auftragnehmers interpretiert, führen zu Konflikten, gegenseitigen Vorwürfen und Schuldzuweisungen. Diese können, wenn überhaupt, nur durch externe Expertise oder – der häufigere Fall – Resignation des Auftraggebers angesichts der Ausweglosigkeit einer Trennung vom aktuellen Auftragnehmer gelöst werden.
Das Vertragsmodell muss vom Ideal des Werkvertrages (transaktionaler Vertragstyp: Definition eines zu erstellenden Werkes zu einem vorab fixierten Preis) abgehen und relationale Verträge sowie Dienstverträge implementieren. Solche Verträge regeln die Zusammenarbeit. Teil der Vereinbarungen ist das Vorgehen zur Festlegung des angestrebten Ergebnisses und der damit verbundenen finanziellen Transaktionen.
Ein Autorenteam rund um den Nobelpreisträger Oliver Hart hat im Harvard Business Review (September/Oktober 2019) diesen Paradigmenwechsel so beschrieben:
IT-Projekte erfüllen heute ab einer gewissen Größenordnung genau die von Hart u. a. genannten Voraussetzungen. Es ist also nicht verwunderlich, dass sie durch die Anwendung von traditionellen Vertragsmodellen so häufig scheitern. Karl Kraus hat einst gemeint, die Psychoanalyse sei die Krankheit, für deren Heilung sie sich hält. Ich meine, so etwas kann man mit Recht über viele Verträge sagen, die den Erfolg eines IT-Projektes absichern sollen, besonders wenn agile IT und sorgfältige Vertragsgestaltung ins Spiel kommen.
